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

How does Message ID coordinate with existing message ID facilities?

From: David Hull <dmh@tibco.com>
Date: Mon, 13 Jun 2005 15:53:06 -0400
To: "public-ws-addressing@w3.org" <public-ws-addressing@w3.org>
Message-id: <42ADE422.4050607@tibco.com>
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.
Received on Monday, 13 June 2005 19:53:12 UTC

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