usefor-article-03 February 2000

[< Prev] [TOC] [ Next >]
5.3.  Message-ID

   The Message-ID header contains the article's message identifier, a
   unique identifier distinguishing the article from every other
   article. The content syntax makes use of syntax defined in [MESSFOR],
   subject to the following revised definition of no-fold-quote.
      Message-ID-content = msg-id
      id-left            = dot-atom-text / no-fold-quote
      no-fold-quote      = DQUOTE *( strict-qtext / strict-quoted-pair )

 NOTE: This syntax ensures that a msg-id is restricted to pure
 US-ASCII (and is thus in strict compliance with [MESSFOR]).

   Following the provisions of [MESSFOR], an agent generating an
   article's message identifier MUST ensure that it is unique and that
   it is NEVER reused. Moreover, even though commonly derived from the
   domain name of the originating site (and domain names are case-
   insensitive), a message identifier MUST NOT be altered in any way
   during transport, or when copied (as into a References header), and
   thus a simple (case-sensitive) comparison of octets will always
   suffice to recognise that same message identifier wherever it
   subsequently reappears.

        NOTE: some old software may treat message identifiers that
        differ only in case within their id-right part as equivalent,
        and implementors of agents that generate message identifiers
        should be aware of this.
[< Prev] [TOC] [ Next >]
#Diff to first older
NewerOlder
usefor-usefor May 2005
usefor-usefor April 2005
usefor-usefor November 2004
usefor-usefor September 2004
News Article Format and Transmission May 2004
News Article Format and Transmission November 2003
News Article Format June 2003
News Article Format April 2003
News Article Format February 2003
News Article Format August 2002
News Article Format May 2002
News Article Format November 2001
News Article Format July 2001
News Article Format April 2001
Son of 1036 June 1994
RFC 1036 December 1987

--- ../s-o-1036/Message-ID.out          June 1994
+++ ../usefor-article-03/Message-ID.out          February 2000
@@ -1,97 +1,28 @@
 5.3. Message-ID
 
-The  Message-ID  header contains the article's message ID, a
-unique identifier  distinguishing  the  article  from  every
-other article:
-
-     Message-ID-content  = message-id
-     message-id          = "<" local-part "@" domain ">"
-
-As  with  From addresses, a message ID's local part is case-
-sensitive and its domain is case-insensitive.  The  "<"  and
-">"  are  parts  of the message ID, not peculiarities of the
-Message-ID header.
-
-     NOTE: News message IDs are a restricted subset  of
-     MAIL message IDs.  In particular, no existing news
-     software copes properly with MAIL quoting  conven-
-     tions  within  the local part, so they are forbid-
-     den.  This is unfortunate, particularly for  X.400
-     gateways  that  often  wish  to include characters
-     which are not legal in unquoted message  IDs,  but
-     it  is  impossible to fix net-wide.  See the notes
-     on gatewaying in section 10.
-
-The domain in the message ID SHOULD  be  the  full  Internet
-domain name of the posting agent's host.  Use of the ".uucp"
-pseudo-domain (for hosts registered in the UUCP maps) or the
-".bitnet"  pseudo-domain  (for Bitnet hosts) is permissible,
-but SHOULD be avoided.
-
-Posters and posting agents MUST generate the local part of a
-message ID using an algorithm which obeys the specified syn-
-tax (words separated by ".",  with  certain  characters  not
-
-INTERNET DRAFT to be        NEWS                    sec. 5.3
-
-
-permitted)  (see  section  5.2  for  details),  and will not
-repeat itself (ever).  The  algorithm  SHOULD  not  generate
-message  IDs which differ only in case of letters.  Note the
-specification in section 6.5 of a recommended convention for
-indicating  subject  changes.  Otherwise the algorithm is up
-to the implementor.
-
-     NOTE: The crucial use of message IDs is to distin-
-     guish  circulating  articles  from  each other and
-     from articles circulated recently.  They are  also
-     potentially  useful  as  permanent  indexing keys,
-     hence the requirement for permanent  uniqueness...
-     but   indexers  cannot  absolutely  rely  on  this
-     because the earlier RFCs  urged  it  but  did  not
-     demand  it.  All major implementations have always
-     generated  permanently-unique   message   IDs   by
-     design,  but  in  some  cases this is sensitive to
-     proper administration,  and  duplicates  may  have
-     occurred by accident.
-
-     NOTE:  The most popular method of generating local
-     parts is to use the date and time, plus  some  way
-     of distinguishing between simultaneous postings on
-     the same host (e.g. a process number), and  encode
-     them  in a suitably-restricted alphabet.  An older
-     but now  less-popular  alternative  is  to  use  a
-     sequence  number,  incremented  each time the host
-     generates a new message ID; this is workable,  but
-     requires  careful  design  to  cope  properly with
-     simultaneous  posting  attempts,  and  is  not  as
-     robust  in  the presence of crashes and other mal-
-     functions.
-
-     NOTE: Some buggy news software  considers  message
-     IDs  completely case-insensitive, hence the advice
-     to  avoid  relying  on  case  distinctions.    The
-     restrictions  placed  on  the  "alphabet" of local
-     parts and domains in section 5.2 have  the  useful
-     side effect of making it unnecessary to parse mes-
-     sage IDs in complex ways to break them into  case-
-     sensitive and case-insensitive portions.
-
-The  local  part of a message ID MUST not be "postmaster" or
-any other string that would compare equal to "postmaster" in
-a  case-insensitive  comparison.   Message  IDs  MUST  be no
-longer than 250 octets, including the "<" and ">".
-
-     NOTE: "Postmaster"  is  an  irksome  exception  to
-     case-sensitivity  in  local  parts, inherited from
-     MAIL, and simply avoiding it is the  best  way  to
-     deal  with it (not that it's likely, but the issue
-     needs to be dealt  with).   The  length  limit  is
-     undesirable,  but is present in widely-used exist-
-     ing software.  The limit is actually  255,  but  a
-
-INTERNET DRAFT to be        NEWS                    sec. 5.3
-
-
-     small safety margin is wise.
+   The Message-ID header contains the article's message identifier, a
+   unique identifier distinguishing the article from every other
+   article. The content syntax makes use of syntax defined in [MESSFOR],
+   subject to the following revised definition of no-fold-quote.
+      Message-ID-content = msg-id
+      id-left            = dot-atom-text / no-fold-quote
+      no-fold-quote      = DQUOTE *( strict-qtext / strict-quoted-pair )
+
+ NOTE: This syntax ensures that a msg-id is restricted to pure
+ US-ASCII (and is thus in strict compliance with [MESSFOR]).
+
+   Following the provisions of [MESSFOR], an agent generating an
+   article's message identifier MUST ensure that it is unique and that
+   it is NEVER reused. Moreover, even though commonly derived from the
+   domain name of the originating site (and domain names are case-
+   insensitive), a message identifier MUST NOT be altered in any way
+   during transport, or when copied (as into a References header), and
+   thus a simple (case-sensitive) comparison of octets will always
+   suffice to recognise that same message identifier wherever it
+   subsequently reappears.
+
+        NOTE: some old software may treat message identifiers that
+        differ only in case within their id-right part as equivalent,
+        and implementors of agents that generate message identifiers
+        should be aware of this.
 

Documents were processed to this format by Forrest J. Cavalier III