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



 Iwasa & Patrick,

iwasa wrote:

> Good point.
> I reconsidered it with this issue,
> and now I inclined to believe we need to have
> ReplyTo element even if the AckRequested
> is not used, since this is an address for both
> Ack and Fault. It means ReplyTo should not
> be under AckRequested, since the address
> for Fault should be specified regardless
> of "AckRequested".
>
> Since we should be able to use WS-R protocol with
> SMTP, responder should be able to send back
> both Ack and Fault asynchronously, and the
> address should be specified in somewhere -
> ReplyTo - in the protocol.
>
> Sunil, how do you think?

  The faults we are talking about in the ReplyTo case are not application
  faults, rather RM-Faults, which are in some sense acknowledgments
  in it's own kind. These Faults are sent only to ReplyTo only when
  synchronous='false'. See example 3 in the initial spec.

  Just consider the anomaly in the current schema. If ReplyTo element
  exists and synchronous='true' attribute exists in AckRequested, and
  a RMFault occurs and has to be sent to the original sender. Are we not
  saying that this fault has to be sent (synchronously) in the initial response
  itself rather than the endpoint referred  by ReplyTo. I don't re-collect we saying
  that Fault or Ack should always be sent to ReplyTo if it exists. If that's case
  we don't even need the synchronous (or now re-named ackPattern) attribute.
  Because of the implicit dependency between the ackPattern attribute and
  ReplyTo element, I was suggesting that we club them together and change
  the name AckRequested to a more meaningful name (something like AckOrFaultContext).

  An alternate would be, we could say that ReplyTo MUST always exists for
  One-way Application-level MEPs and this will be used to send Acks and Faults.
  And this element could be optional for Request-Response MEPs. If present for
  R-R MEPs, Faults and Acks will be sent to this endpoint and not as response.
  Inefficient, but nothing wrong semantically. ackPattern attribute then will become
  information-only  and won't be tied to the ReplyTo element. In such case, we
  could have them separately.


  -Sunil




>
>
> Iwasa
>
> ----- Original Message -----
> From: "Patrick Yee" <kcyee@cecid.hku.hk>
> To: <tom@coastin.com>
> Cc: "wsrm" <wsrm@lists.oasis-open.org>
> Sent: Tuesday, July 29, 2003 1:15 PM
> Subject: Re: [wsrm] Action item for ReplyTo definition
>
> > 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?
> >
> > 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
> >



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