[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] New proposal for Reply to action item
It is not clear to me how the receiver can know how to send RM-Fault back when ack is not requested. When ack is requested, the receiver can send RM-Fault in the same way as Ack. The definition below implicitly says that, when ack is not requested, the sender must specify ReplyTo and receive RM-Fault with the Callback pattern. Can the sender receive RM-Fault with the Response or Polling patterns when possible? In my previous mail I suggested that ackPattern should be specified even when ack is not requested (if the sernder needs to receive RM-Fault). Junichi Tatemura ----- Original Message ----- > Tom Rutt wrote: > > > Here is a new proposal, which incorporates much of the discussion. > > Oops. Wherever the text states "application Fault" it should be > replaced with "RM-Fault" > in the text below. > > We probable need a definition for RM-Fault. > > > > > > > ----------------- > > > > 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.php > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]