Date: Mon, 30 Jun 1997 15:56:00 +0200
From: mail-std-list@faerber.muc.de (=?ISO-8859-1?Q?Claus_Andr=E9_F=E4rber?=)
To: drums@cs.utk.edu
Message-ID: <6ZpZgpuocDB@faerber.Muc.DE>
In-Reply-To: <v04000518afd0a35c257b@resnick1.isdn.uiuc.edu>
Subject: Message-ID creation (was: draft-ietf-drums-msg-fmt-02.txt...)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
REFERENCES: <v04000518afd0a35c257b@resnick1.isdn.uiuc.edu>
SENDER: claus@faerber.muc.de

Pete Resnick <presnick@qualcomm.com> wrote:
> 3.6.4 Identification fields
...
> The "Message-ID:" field provides a unique identifier which refers to a
> particular version of a particular message. The uniqueness of the message
> identifier is guaranteed by the host which generates it (see below). This
> identifier is intended to be machine readable and not necessarily meaningful
> to humans. A message identifier pertains to exactly one instantiation of a
> particular message; subsequent revisions to the message should each receive
> new message identifiers.
...
> The message identifier itself is a domain-dependent unique identifier. The
> domain portion of the identifier SHOULD be the domain name of the host on
> which it was created, to guarantee uniqueness. The local-part portion of the
> identifier MAY be any dot-atom or quoted-string. However, the entire
> identifier MUST be globally unique. In order to do this, a common practice is
> to form the local-part by using a combination of the current absolute time
> and some other currently unique identifier on the host (for example a system
> process identifier).

[ This issue was raised in USEFOR (Usenet Format Working group), but it
  applies to DRUMS as well. ]

The problem with this message id creation is: There are now computers  
that don't have an own FQDN to put on the rhs of the message id.
E.g. offline readers on computers which get an dynamically assigned IP  
addr. from their provider are wide-spread. Then, some companies might  
want not to reveal the names of their computers.
Both examples require the higher level domain name to be used as the rhs  
of the domain name, which is the current practice:

<lkasjf02@provider.com>

However, if two users happen to create one message at the same time  
using the same software, there's a chance that these message ids are not  
unique any longer.

Thus I'd like to suggest the following:

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
identifier      =       "<" unique-part "@" domain ">" /
                        "<" unique-part "%" addr-spec ">"

unique-part     =       dot-atom        ; should not contain '%'.

[...]

The message identifier itself is a domain-dependent unique identifier.  
The domain portion of the identifier SHOULD be the domain name of the  
host on which it was created, to guarantee uniqueness. If the creating  
host does not have an own domain name, it SHOULD use the second form of  
the message id, using the user's e-mail address on the right hand side  
of the "%". The unique-part portion of the identifier MAY be any dot- 
atom or quoted-string. Although lexically permitted, it SHOULD NOT  
contain a "%" character. However, the entire identifier MUST be globally  
unique. In order to do this, a common practice is to form the unique- 
part by using a combination of the current absolute time and some other  
currently unique identifier on the host (for example a system process  
identifier).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

There has been some discussion on wheter to put the email addr. local  
part on the LHS or RHS of the "@". The RHS has the disadvatage that it  
might clash with existing computer names and that many addresses would  
have to be encoded.
The LHS has the disadvantage that there might be old software invading  
the user's "id space". However, this is very unlikely, at least a lot  
less unlikely than name clashes with the situation of today.

Then there was a discussion about the character to use. I think "%" is a  
good choice, as it is/was used as a second-level delimiter in mail  
addresses: xxx%yyy@zzz == zzz!yyy!xxx. Thus this character very unlikely  
appears in real email addresses. Clashes of "new style" ids can be  
completly avoided if we ban the "%" in the unique-part.

Other, non-email-address-based ids should IMO be avoided, as we can be  
quite happy if a user gets his/her email address configured correctly.  
Something which is based on a parameter the user has to enter  
additionally is a bad idea, as misconfigurations would not lead to a non- 
working mail program, only to bad message ids.

Then, I think the BNF aboove is better, as readers might mistake
"addr-spec" as what is to be put there, not the lexical definition.

-- 
Claus "3247" Andre Faerber <cl@faerber.muc.de> <http://www.muc.de/~cfaerber/>
PGP: ID=1024/527CADCD FP=12 20 49 F3 E1 04 9E 9E  25 56 69 A5 C6 A0 C9 DC