W3C home > Mailing lists > Public > public-ws-addressing@w3.org > November 2004

RE: i028: Implications of the presence of ReplyTo

From: Martin Gudgin <mgudgin@microsoft.com>
Date: Fri, 12 Nov 2004 03:08:50 -0800
Message-ID: <DD35CC66F54D8248B6E04232892B633803F292D9@RED-MSG-43.redmond.corp.microsoft.com>
To: <Marc.Hadley@Sun.COM>
Cc: <public-ws-addressing@w3.org>


> -----Original Message-----
> From: Marc.Hadley@Sun.COM [mailto:Marc.Hadley@Sun.COM] 
> Sent: 12 November 2004 04:08
> To: Martin Gudgin
> Cc: public-ws-addressing@w3.org
> Subject: Re: i028: Implications of the presence of ReplyTo
> On Nov 11, 2004, at 3:01 PM, Martin Gudgin wrote:
> >> 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
> >
> I understand what you mean but I'm not sure it makes sense ;-). If we 
> could say that presence of ReplyTo indicates that a reply is expected 
> then that would seem like a useful semantic. What's the purpose of a 
> ReplyTo in a message that isn't expected to generate a reply ?

OK, it depends on what you mean when you say 'generate a reply'. Do you

a) 'generate a reply as part of the same WSDL MEP'


b) 'generate a reply, not necessarily part of the same WSDL MEP'

I have certain protocols that do specify a [reply endpoint], do expect
(hope?) that a reply to be sent at some point, but NOT as part of the
same WSDL operation as the initial message.


Received on Friday, 12 November 2004 11:09:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:34:59 GMT