[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] New proposal for Reply to action item
Scott Werden wrote: >As I stated in my earlier email today, it is not clear to me why the >AckRequested element is required for Message Ordering. Message >acknowledgement should be orthogonal to message ordering. > > Sorry I missed that in the resolution. How about if we strike the words ""and message order" in the description. It is REQUIRED for > > guaranteeing message delivery and message order. >Scott > > > >>-----Original Message----- >>From: Tom Rutt [mailto:tom@coastin.com] >>Sent: Tuesday, July 29, 2003 1:18 PM >>To: wsrm >>Subject: [wsrm] New proposal for Reply to action item >> >> >>Here is a new proposal, which incorporates much of the discussion. >> >>----------------- >> >>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". >> >>Note: This proposal does not make reply to an attribute or >>sub-element >>of ackRequested, but includes the faults in the definition for the >>ackPattern attribute. >> >>"*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 (or application fault messages) >>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 "Response", when omitted. >> >>- *Response *: An Acknowledgment Message (or application >>Fault message) >>MUST be sent back directly in the Reply to the Reliable Message. >> >>- *Callback*: An Acknowledgment Message (or application Fault >>message) >>MUST be sent as a callback request, using the address in the >>ReplyTo element >> >>- *Poll*: An Acknowledgment Message(or application Fault >>message) MUST >>be sent as a response to a poll request >> >>" >> >>With this modification the ReplyTo definition can be modified >>as follows: >> >>" >> >>*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]. >> >>" >> >> >>-- >>---------------------------------------------------- >>Tom Rutt email: tom@coastin.com; trutt@fsw.fujitsu.com >>Tel: +1 732 801 5744 Fax: +1 732 774 5133 >> >> >> >> >> >>You may leave a Technical Committee at any time by visiting >> >> >http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.ph >p > > > -- ---------------------------------------------------- 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]