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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

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


Subject: Re: [wsrm] Action item for ReplyTo definition


Sunil Kunisetty wrote:

>
> Tom, 

My comments are entwined

> Few comments below:
>
> Tom Rutt wrote:
>
>> This mail is my contribution for fixing the definition for ReplyTo
>> element. I also made necessary
>> changes to the ackRequested element to get rid of the words
>> "asynchronous" and "synchronous".
>>
>> --------------------
>>
>> The current text states:
>>
>> “
>>
>> *3.2.2. ReplyTo Element*
>>
>> This is a REQUIRED element, used to specify the initial sender’s
>> endpoint to receive an
>>
>> asynchronous Acknowledgment message or Fault Message. The value of this
>> element is
>>
>> REQUIRED to be URL as defined in [RFC 1738].
>>
>> “
>>
>> However this does not properly reflect the differences between use of
>> the reply
>>
>> acknowledgment binding pattern and the callback acknowledgement pattern.
>>
>> Lets first modify the definition for the AckRequested element to change
>> the use of the
>>
>> terms synchronous and asynchronous to the new terms “reply
>> acknowledgment pattern”
>>
>> and “callback acknowledgement pattern”.
>>
>> “*3.2.4. AckRequested Element*
>>
>> The AckRequested element is an OPTIONAL element. It is REQUIRED for
>>
>> guaranteeing message delivery and message order. However this element
>> MUST NOT
>>
>> appear in a non-Reliable Message. This element is to be used for a
>> sender to request the
>>
>> receiver to send back an Acknowledgment message for the message sent. 
>> The
>>
>> AckRequested element contains the following attribute:
>>
>> - an *ackPattern *attribute
>>
>> *(1) ackPattern attribute*
>>
>> The ackPattern attribute is an OPTIONAL attribute. This attribute is
>> used to specify
>>
>> whether the Acknowledgment Message should be sent back directly in the
>> reply to the reliable message or
>>
>> in a separate callback request. This attribute, when used, MUST have one
>> of the following two values.
>>
>> The default value of this attribute is “Reply”, when omitted.
>>
> Shall we call it 'Response' since we decided to call the first pattern
> as ' Response Ack. Pattern'.

ok

>>
>> - *Reply *: An Acknowledgment Message MUST be sent back directly in the
>> Reply to the Reliable Message.
>>
>> - *Callback*: An Acknowledgment Message MUST be sent as a callback
>> request, using the address in the ReplyTo element
>>
>> “
>>
> It may also be useful to add a third value call 'Poll', to indicate 
> client's
> interest that it may Poll for a Ack. as long as the TTL (or what ever
> is the new name) doesn't expire.

Do we have this binding pattern in our requirements?

>>
>> With this modification the ReplyTo definition can be modified as 
>> follows:
>>
>> “
>>
> I'd also suggest to remove 'ReplyTo' as a sub-element of
> <RM:ReliableMessage> and add it as an _attribute_ to
> <RM:AckRequested> sub-element itself so that it won't accidently
> be used if <RM:AckRequested> is not used/present.

Not sure?

>> *3.2.2. ReplyTo Element*
>>
>> This is an OPTIONAL element, used to specify the initial sender’s
>> endpoint to receive a callback
>>
>> Acknowledgment message or Fault Message. A value of this element MUST be
>> present in the request
>>
>> message if the AckRequested element indicates that the Callback
>> Acknowledgement pattern is requested.
>>
>> If present, the ReplyTo element is required to be URL as defined in [RFC
>> 1738].
>>
>> “
>>
>
> -Sunil
>


-- 
----------------------------------------------------
Tom Rutt		email: tom@coastin.com; trutt@fsw.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133






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