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