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: ;
> 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
>
>
