Re: [wsrm] Action item for ReplyTo definition

[Sunil Kunisetty <sunil.kunisetty@oracle.com>]

Tom Rutt wrote:

> 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?

 Yes, we do. We added this as a requirement at the Oracle F2F. Note
 that this is different from Pull-Model that Iwasa has raised. That I believe
 is either closed or status-quo.

>
>
> >>
> >> 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?

 Why? Do you see any problem with it being an attribute? I just
 felt that it is less error-prone when it is an attribute of "AckRequested",
 which is the only case it is used anyway.

>
>
> >> *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