[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]