usefor-usefor-01 September 2004
[< Prev]
[TOC] [ Next >]
3.1.4 Message-ID
The Message-ID header contains a single unique message identifier.
This document updates the <msg-id> construct from Section 3.6.4 of
[RFC2822] so as to ensure that Internet Message Format Message-IDs
are usable in widely deployed news software. The ABNF should be used
as below, but the requirements and descriptive text from Section
3.6.4 of [RFC2822] still apply.
message-id = "Message-ID:" SP msg-id CRLF
msg-id = [FWS] msg-id-core [FWS]
msg-id-core = "<" id-left "@" id-right ">"
; maximum length is 250 octets
id-left = dot-atom-text / no-fold-quote / obs-id-left
id-right = dot-atom-text / no-fold-literal / obs-id-right
no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE
no-fold-literal = "[" *( htext / no-space-qp ) "]"
no-space-qp = ( "\" ptext ) / obs-qp
ptext = %d33-61 / ; Printable characters excluding ">"
%d63-126 /
obs-text
htext = HEXDIG / ; hexadecimal digits, case-insensitive
"." / ; IPv4 separator
":" ; IPv6 separator
The msg-id-core MUST NOT be more than 250 octets in length.
NOTE: The length restriction ensures that systems which accept
message identifiers as a parameter when retrieving an article
(e.g. NNTP [RFC0977]) can rely on a bounded length. Observe that
msg-id-core includes the < and >.
Observe that in contrast to the corresponding header in [RFC2822],
the syntax does not allow comments within the Message-ID header; this
is to simplify processing by relaying and serving agents and to
ensure interoperability with existing implementations.
Also note that this updated ABNF applies wherever <msg-id> is used,
including the References header discussed in Section 3.2.1.
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-13/Message-ID.out May 2004
+++ ../usefor-usefor-01/Message-ID.out September 2004
@@ -1,50 +1,49 @@
-5.3. Message-ID
+3.1.4 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 [RFC 2822]
- (but see the revised definition of msg-id in section 2.4.3).
-
- header =/ Message-ID-header
- Message-ID-header = "Message-ID" ":" SP Message-ID-content
- Message-ID-content = [FWS] msg-id [FWS]
+ The Message-ID header contains a single unique message identifier.
+ This document updates the <msg-id> construct from Section 3.6.4 of
+ [RFC2822] so as to ensure that Internet Message Format Message-IDs
+ are usable in widely deployed news software. The ABNF should be used
+ as below, but the requirements and descriptive text from Section
+ 3.6.4 of [RFC2822] still apply.
- The msg-id MUST NOT be more than 250 octets in length.
+ message-id = "Message-ID:" SP msg-id CRLF
+
+ msg-id = [FWS] msg-id-core [FWS]
+
+ msg-id-core = "<" id-left "@" id-right ">"
+ ; maximum length is 250 octets
+
+ id-left = dot-atom-text / no-fold-quote / obs-id-left
+
+ id-right = dot-atom-text / no-fold-literal / obs-id-right
+
+ no-fold-quote = DQUOTE *( qtext / no-space-qp ) DQUOTE
+
+ no-fold-literal = "[" *( htext / no-space-qp ) "]"
+
+ no-space-qp = ( "\" ptext ) / obs-qp
+
+ ptext = %d33-61 / ; Printable characters excluding ">"
+ %d63-126 /
+ obs-text
+
+ htext = HEXDIG / ; hexadecimal digits, case-insensitive
+ "." / ; IPv4 separator
+ ":" ; IPv6 separator
+
+ The msg-id-core MUST NOT be more than 250 octets in length.
NOTE: The length restriction ensures that systems which accept
message identifiers as a parameter when retrieving an article
- (e.g. [NNTP]) can rely on a bounded length. Observe that msg-id
- includes the '<' and '>'.
+ (e.g. NNTP [RFC0977]) can rely on a bounded length. Observe that
+ msg-id-core includes the < and >.
+
+ Observe that in contrast to the corresponding header in [RFC2822],
+ the syntax does not allow comments within the Message-ID header; this
+ is to simplify processing by relaying and serving agents and to
+ ensure interoperability with existing implementations.
- Observe that, in contrast to the corresponding header in [RFC
- 2822], the syntax does not allow comments within the Message-
- ID-header; this is to simplify processing by relaying and
- serving agents and to ensure interoperability with existing
- implementations.
-
- An agent generating an article's message identifier MUST ensure that
- it is unique (as also required in [RFC 2822]) and that it is chosen
- in such a way that it will NEVER be applied to any other Netnews
- article or Email message. However, an article emailed (without
- encapsulation) to a moderator (8.2.2 and 8.7) or gatewayed into some
- other medium (8.8.1) SHOULD retain the same message identifier
- throughout its travels so long as it remains recognizably the same
- article.
-
- 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 recognize that same
- message identifier wherever it subsequently reappears.
-
- NOTE: These requirements are to be contrasted with those of the
- un-normalized msg-ids defined by [RFC 2822], which may perfectly
- legitimately become normalized (or vice versa) during transport
- or copying in email systems.
-
- 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.
+ Also note that this updated ABNF applies wherever <msg-id> is used,
+ including the References header discussed in Section 3.2.1.