OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [wsrm] Action item for ReplyTo definition


Sunil and Tom,

My comments are inline:

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

Agree.

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

Agree.

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

Agree with Sunil to move "ReplyTo" element to under "AckRequested".
And it looks like you prefer to making "ReplyTo"
an attribute of AckRequested, rather than making it sub-element of
AckRequested. In that case are you proposing to have two attributes
under "AckRequested" element as follows?
    - ackPattern attribute : Value is "Response", "CallBack", or "Poll"
    - replyTo attribute : Value is URL

I think this makes sense.
If I understand wrong, please correct it.

Thanks,

Iwasa

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