Re: i028: Implications of the presence of ReplyTo

I think the acknowledged PO operation, followed by a later Invoice, is 
an application specific protocol, where we
are working on an "infrastructure" protocol.

What I mean by this is that, the "callback" address for the supplier to 
deliver the later invoice to (which can occur months later for
a complicated Purchase) is an application level data Item, and belongs 
in the purchase order itself (in the soap body), not in a soap header.

So I now am thinking that the "wsa:replyTo" should only be scoped to a 
single MEP (i.e. the request response for the orginal PO request, with
the response being the ack with the Vendor's POID.   The wsa:replyTo 
should not be used by the application for the callback to send
the future invoice to.

Also, if there is no need for transport independence, the message should 
not have to send wsa:reply to when a wsdl request/response is bound
to a request/response transport (e.g., soap http/post binding).   I 
would say wsa:replyTo is only required to be send when the request / 
response
is bound to a one way underlying transport.

Tom Rutt

Marc Hadley wrote:

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

-- 
----------------------------------------------------
Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
Tel: +1 732 801 5744          Fax: +1 732 774 5133

Received on Friday, 12 November 2004 17:04:21 UTC