RE: i028: Implications of the presence of ReplyTo

 

> -----Original Message-----
> From: Marc Hadley [mailto:Marc.Hadley@Sun.COM] 
> Sent: 11 November 2004 19:02
> To: Martin Gudgin
> Cc: public-ws-addressing@w3.org
> Subject: Re: i028: Implications of the presence of ReplyTo
> 
> On Nov 11, 2004, at 7:26 AM, Martin Gudgin wrote:
> >> Issue 28[1] concerns the implications of the presence of
> >> ReplyTo in a
> >> message. Does the presence of a wsa:ReplyTo imply that a reply is
> >> required, does absence of ReplyTo indicate a one-way message ?
> >>
> >> <wsa:ReplyTo> is optional and the specification states that:
> >>
> >> (i) It "MUST be present if a reply is expected",
> >> (ii) But "If the [reply endpoint] is absent, the contents of the
> >> [source endpoint] may be used to formulate a message to 
> the source."
> >> [reply endpoint] serializes as wsa:ReplyTo, [source endpoint]
> >> serializes as wsa:From.
> >>
> >> I.e. <wsa:ReplyTo> must be present, but if not use <wsa:From>
> >> instead -
> >> the two statements seem to be contradictory.
> >
> > I don't think they are. If you expect a reply ( e.g. you're 
> sending the
> > initial message a WSDL 1.1 request-response ) then the 
> message you send
> > MUST have a [reply endpoint] property. I think the second 
> clause about
> > [source endpoint] is just informational, it doesn't have 
> any bearing on
> > the previous text. May be it should be under [source endpoint]?
> >
> So it sounds like you'd be in favor of saying that presence 
> of ReplyTo 
> implies a request is expected and that absence indicates a one-way 
> message ?

Nope. I think that if you expect a reply, you MUST specify [reply
endpoint]. So in request-response style MEPs [reply endpoint] would
always be specified in the request message. However, I don't think that
specifying [reply endpoint] necessarily means you expect a reply (in
request/response stylee). Does that make sense. I'm saying

	if a then b

but I'm NOT saying

	if b then a



> 
> >>
> >> If we accept (i) then a typical use of a request response MEP
> >> using the
> >> SOAP/HTTP binding would require the presence of the 
> following header
> >> block:
> >>
> >> <wsa:ReplyTo>
> >>
> >> <wsa:Address>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/
> >> anonymous</wsa:Address>
> >> </wsa:ReplyTo>
> >>
> >> This is a lot of bytes that provide no real information. My
> >> preference
> >> would be that omission of a ReplyTo is semantically
> >> equivalent to its
> >> presence as shown above but that would mean that its presence
> >> cannot be
> >> used to determine whether a reply is expected or not.
> >
> > I think providing a 'default' value in the case is a 
> mistake. I saw one
> > of the benefits of WS-Addressing was that the headers that 
> appeared in 
> > a
> > message DID NOT vary depending on how the message was actually
> > transmitted.
> >
> I wasn't suggesting the headers would vary depending on how it was 
> transmitted, just that omission would be equivalent to inclusion with 
> an anonymous address. 

That implies that there is ALWAYS a [reply endpoint]. What if there
really isn't one?

> However, if we are going to attribute MEP 
> semantics to the presence or absence of ReplyTo then I'd modify my 
> suggestion to say that omission of a <wsa:Address> be made 
> semantically 
> equivalent to inclusion of one using the anonymous URI. 

I'm not sure I see the difference. And I don't think MEP semantics
should be inferred from the presence/absence of wsa: headers ( although
the set of such headers could be infered, or even explicitly stated, for
a given MEP ). My upcoming post on i003 explores this area.

> I see this as 
> similar to the ability to omit the soap:Header if there 
> aren't any soap 
> headers in a message and to omit the soap:mustUnderstand instead of 
> being forced to put soap:mustUnderstand='false' on a header block.

They don't seem like quite the same thing to me.

Gudge

> 
> Marc.
> 
> >>
> >> [1] http://www.w3.org/2002/ws/addr/wd-issues/#i028
> ---
> Marc Hadley <marc.hadley at sun.com>
> Web Technologies and Standards, Sun Microsystems.
> 
>

Received on Thursday, 11 November 2004 20:01:31 UTC