OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ws-rx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ws-rx] Issue i024


I think issues 6 and 9 make issue 24 more relevant/important and I can 
see at least a solution that covers all three. It certainly makes sense 
to think about them together and perhaps even find a single/common solution.

One question though I have about the existing RM policy assertions is:
are they (inactivity timeout, base retransmission interval, ack 
interval) meant to be shared between RMS and RMD or are they meant as 
configuration information for implementations? By shared, I mean shared 
by both the RMS and RMD (and not just attached in a WSDL document).



Doug Davis wrote:
> What's the relationship between this issue and issues 6, 9?  They seem 
> very similar - almost like 6 and 9 are a subset of 24.  Would it make 
> sense to try to find a single/common solution that covers all?
> thanks,
> -Doug
> Ashok Malhotra <ashok.malhotra@oracle.com> wrote on 09/14/2005 03:43:40 PM:
>  > This is in response to Sanjay's note asking for a proposal for issue 
> i024.
>  > In this case, though, what we are asking for may be a clarification 
> and not a change.
>  >
>  > The WS-RM Policy spec defines a RM assertion.  It also specifies how 
> this assertion
>  > may be attached to WSDL.  What is does not specify is the motivation 
> behind the
>  > assertion, how it is used and the messages it applies to.  We would 
> like this clarified.
>  >
>  > It is clear that the RM assertion is an 'informational assertion' in 
> that it is a
>  > property of the sequence and not a property of the messages in the 
> sequence.  As such,
>  > it does not make sense for each message to include this information.
>  >
>  > Second, policy information is meant to be conveyed by one party in a 
> conversation to
>  > the other.  In this case, the assertion seems to specify 
> implementation parameters
>  > that may be private to the RMS or the RMD.  If so, it does not need 
> to be part of the
>  > specification.
>  >
>  > If, indeed, the RM assertion is to be conveyed from the RMS to the 
> RMD it can be
>  > done as a header in the CreateSequence message.  The RMD can respond 
> with a header
>  > in the CreateSequenceResponse by agreeing, disagreeing or making a 
> counter proposal.
>  >
>  > If the RM assertion has to be conveyed from the RMD to the RMS, this 
> has to be done
>  > before the CreateSequence message and requires a new protocol element.
>  >
>  > All the best, Ashok
>  >

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]