RE: How does Message ID coordinate with existing message ID facilities?

I also believe the last bullet is the only viable one, but am not sure
we need to say anything about this in the spec.  Do you have a concrete
suggestion we could consider?

 

________________________________

From: public-ws-addressing-request@w3.org
[mailto:public-ws-addressing-request@w3.org] On Behalf Of Rogers, Tony
Sent: Monday, June 13, 2005 6:06 PM
To: David Hull; public-ws-addressing@w3.org
Subject: RE: How does Message ID coordinate with existing message ID
facilities?

 

I agree with the last bullet, but I would not want to forbid re-use of
an id generated for another purpose, assuming it met our message id
requirements (correlation, "enough" uniqueness).

 

Tony Rogers

	-----Original Message----- 
	From: public-ws-addressing-request@w3.org on behalf of David
Hull 
	Sent: Tue 14-Jun-05 5:53 
	To: public-ws-addressing@w3.org 
	Cc: 
	Subject: How does Message ID coordinate with existing message ID
facilities?

	Existing transport mechanisms often add some sort of visible
message ID marker independent of the actual message payload.  There
would appear to be several ways to relate such IDs to the WSA [message
id] property.

	*	Abolish all other message IDs and make [message id] the
one and only universally mandatory ID.  I mention this for completeness.
It's obviously a non-starter. 
	*	Require [message id], where present, to align with
existing message IDs.  E.g., the [message id] of a message sent by email
would be required to be the same as the message-id: email header (if
present).  There are several technical problems with this, e.g., what to
do when the same message takes multiple hops, what to do if multiple
transport layers each assign an ID, what to do for transports which do
not assign easily accessible IDs. 
	*	Allow the [message id] to default to a particular
transport-level ID.  E.g., the [message id] property in an email binding
would be defined as the server-assigned value of the message-id: header,
unless [message id] was explicitly present.  This also presents problems
in the face of multiple hops.
	*	Either of the previous two options could apply instead
to IDs assigned by reliability mechanisms, assuming they are in use.
	*	Make [message id] completely independent of any other
message ID mechanisms, as an end-to-end ID of the message, no matter how
many hops it goes through. 

	As far as I can tell, the last option is the only viable one,
and it may well be what everyone has in mind, but I would like to see
some clarity on this.