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 ?

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

In both cases they'd just be a syntactic optimization. If the presence 
of ReplyTo has no real semantic then we could make omission equivalent 
to inclusion with an anonymous address. If the presence of ReplyTo has 
some semantic (e.g. a reply is expected) then we couldn't make omission 
of ReplyTo equivalent to inclusion but we could do that for the 
included address element.

>  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.
>
That might be a good way to go.

>> 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.
>
Both are just syntactic convenience/optimizations.

Marc.

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

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