Re: i028: Implications of the presence of ReplyTo

On Nov 12, 2004, at 6:08 AM, Martin Gudgin wrote:
>>
>> 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
> mean
>
> a) 'generate a reply as part of the same WSDL MEP'
>
Yes.

> 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.
>
That's the kind of scenario I was getting it when I raised issue i015 
about redirection. E.g. if a responder in a request response MEP sends 
back a ReplyTo header, do we expect that to apply to subsequent 
interactions between the requester and responder. I.e. what is the 
scope of the effect of a ReplyTo, is it scoped to an instance of a 
particular MEP or something wider ? Till now I'd been assuming the 
former, are you suggesting it should be the latter ?

Cheers,
Marc.

---
Marc Hadley <marc.hadley at sun.com>
Web Technologies and Standards, Sun Microsystems.

Received on Friday, 12 November 2004 14:15:23 UTC