W3C home > Mailing lists > Public > public-ws-addressing@w3.org > June 2005

Re: Why is [message id] required for requests but not for other messages?

From: Mark Little <mark.little@arjuna.com>
Date: Thu, 16 Jun 2005 13:50:42 +0100
Message-ID: <42B175A2.2050306@arjuna.com>
To: "Conor P. Cahill" <concahill@aol.com>
CC: David Hull <dmh@tibco.com>, "Yalcinalp, Umit" <umit.yalcinalp@sap.com>, Jonathan Marsh <jmarsh@microsoft.com>, tom@coastin.com, public-ws-addressing@w3.org

Conor P. Cahill wrote:

> PS.  I'm sure the reason why this was called MessageId originally was 
> that people thought that it would be good to reuse the same unique 
> identifier in some cases of messages where this makes sense (clearly, 
> this would work with point-to-point messaging).    WS-A could handle 
> this by defining a specific correlation URI that states that the 
> correlation Id is carried in the message identification context of the 
> message and set this as the default should the CorrelationID not be 
> specified.

I think if we're going to get into the notion of sessions and 
correlation ids, that we should step back a moment. The WS-Context 
specification (http://www.oasis-open.org/apps/org/workgroup/ws-caf/) has 
been developed to cover that area and it would be best not to reinvent 
the wheel here. If you're not considering multi-message exchange 
correlations, then I'd suggest we stick with MessageId.


> On a related note, the current model of determining whether or not a 
> reply is expected based upon the presence or lack thereof of some 
> sort-of-related data (ReplyTo, MessageID) seems kind of broken to me.  
> Why don't we just have a flag somewhere (perhaps an attribute on the 
> wsa:To) that says a reply is expected.   I'm normally the one for 
> arguing against bits being added to a message, but I think this makes 
> things much clearer from an implemetnation point of view.
> Conor
> Conor P. Cahill wrote on 6/15/2005, 9:43 PM:
>> David Hull wrote on 6/14/2005, 2:40 PM:
>>> We are currently trying to define the semantics of [message id], and 
>>> I would like to understand the use cases.
>> I think the problem is that we aren't really talking about a 
>> MessageID at all.   The object that the spec refers to is really a 
>> CorrelationID and not a MessageID and the name is confusing everybody 
>> into trying to add semantics to it that shouldn't be there.
>> I think you need to be able to track the Correlation ID separately 
>> from the MessageID (if some other spec ever defines a MessageID) 
>> because in the case of intermediaries that are relaying messages, I 
>> would expect them to assign their own messageID as they sent off the 
>> message, but leave the Correlation ID alone.  This would be 
>> especially useful in the case where the submission path across 
>> intermediaries did not match the return path (which is very possible).
>> Conor 
Received on Thursday, 16 June 2005 12:50:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:09 UTC