[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsrm] Action item for ReplyTo definition
Patrick Yee wrote: > Another thinking. > I understand the motivation to put ReplyTo under AckRequested. But > ReplyTo is not limited to acknowledgment as stated. It will be the > endpoint for sending fault messages as well. Where should I locate the > ReplyTo URL for sending fault messages if AckRequested is not used? Good point. Reply to could be used for other things, in general. However, if ack is not requested in a callback pattern manner, why is the fault not just sent in the HTTP response? When will a request using the request or polling ack patern need to send a fault in a callback? Tom Rutt > > > Regards, -Patrick > > > 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. >> >> - *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 >> >> “ >> >> 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]. >> >> “ >> >> > > > You may leave a Technical Committee at any time by visiting > http://www.oasis-open.org/apps/org/workgroup/wsrm/members/leave_workgroup.php > > -- ---------------------------------------------------- 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]