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

Jonathan Marsh wrote:

> 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?
>
Sure.  Make [message id] optional and the whole discussion goes away.

Failing that, the explicit disclaimer approach might be enough to get
around concerns about how a message travels.

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