OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Message ID's


Dan,

This looks like a wording issue that needs cleaning up. The original
proposal came from Fujitsu, but let me try to recall the intent from
discussions last year (Shimamura-san, please confirm if this correct).

The key paragraph in RFC2392, IMHO, is:

"
   Both message-id and content-id are required to be globally unique.
   That is, no two different messages will ever have the same Message-ID
   addr-spec; no different body parts will ever have the same Content-ID
   addr-spec.  A common technique used by many message systems is to use
   a time and date stamp along with the local host's domain name, e.g.,
   950124.162336@XIson.com.
"

comments:

- the ebXML MessageId element should conform to RFC2392, in that it should
follow the mid scheme (short form, without cid, I think) and must be
*globally* unique as required above. All MSH's should have no confusion
about message id...

- at the time of this proposal, we were heavily into discussions of reliable
messaging and the synchronization of messages. Fujitsu suggested using a
<timestamp>.<domain name> structure for MessageID, so that the timestamp
portion could be relied on for discrimination and sequencing by the
receiving MSH; in other words, following the *common technique* noted in the
RFC extraction above, which obviously is not normative.

- the second sentence in MS 8.4.6.1 was put there to reinforce the point
that identification of the host's domain name was definitely implementation
dependent - we didn't want to get into resolving domains or implying that
there was some ability to resolve domain id clashes.

See below for in-line comments on your email.

Thus, I think we may need to clarify this, and it can be discussed in the
OASIS MS TC meeting next week. Thanks for pointing out the issue!

Jim Hughes
HP


> -----Original Message-----
> From: Dan Weinreb [mailto:dlw@exceloncorp.com]
> Sent: Wednesday, July 11, 2001 8:25 AM
> To: ebxml-msg@lists.oasis-open.org
> Subject: Message ID's
> 
> 
> In the Message Specification (TR&P) Version 1.0 (11 May 
> 2001), it says:
> 
>    8.4.6.1 MessageId element
>    The REQUIRED element MessageId is a unique identifier for 
> the message conforming to [RFC2392].
>    The "local part" of the identifier as defined in [RFC2392] 
> is implementation dependent.
> 
> As far as I can tell, RFC2392 does not actually specify unique
> identifiers.  Also, the phrase "local part" does not appear in RFC2392

Yes, RFC simply says that the identifiers must be unique. The user has this
responsibility to generate uniqueness, and there are some known schemes (the
method in DCE is quite common).

I believe "local part" refers to "local host's domain name" in the "common
technique" noted above.

> anywhere.  RFC2392 defines the "mid" URL scheme but does not say
> anything about where the unique ID strings come from.
> 
> There are a few examples of Message ID's in the Message 
> Specification document.
> 
> 
> From the latest JMS spec:
> 
> Page 25 shows this example: mid:UUID-2
> 
> Page 27 shoes this example: 29dmridj103kvna
> 
> Page 72 shows this example: 20001209-133003-28572@example.com
> 
> So the text in section 8.4.6.1 seems to be encouraging us to use the
> "mid:" prefix, and in the examples above, two are not using "mid:" at
> all.
> 
> Which side is right?

Can't speak to the JMS spec (I think you mean MSS spec!), but as long as the
three examples are unique (and, obviously, they are non-empty strings, to
match the schema), they should be accepted as valid ebXML MessageIDs. We
probably need to delete or fix the second sentence of 8.4.6.1.

> 
> Thanks.
> -- Dan
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC