usefor-article-11 June 2003
[< Prev]
[TOC] [ Next >]
2.4.2. Syntax adapted from Email and MIME
Much of the syntax of Netnews Articles is based on the corresponding
syntax defined in [RFC 2822]. Therefore, wherever in this standard
the syntax is stated to be taken from [RFC 2822], it is to be
understood, unless explicitly stated to the contrary, as the syntax
defined by [RFC 2822], but NOT including any syntax defined in
section 4 ("Obsolete syntax") of [RFC 2822]. Software compliant with
this standard MUST NOT generate any of the syntactic forms defined in
that Obsolete Syntax, although it MAY accept such syntactic forms.
Likewise, certain syntax from the MIME specifications [RFC 2045] et
seq is also considered to have been incorporated into this standard
(see 6.21).
However, there are some differences arising from some special
requirements of Netnews, and the following syntactic rules therefore
supersede the corresponding rules given in [RFC 2822].
NOTE: Netnews parsers historically have been much less
permissive than Email parsers, and this is reflected in the
modifications referred to, and in some further specific rules.
In contradistinction to [RFC 2822], an unstructured header (e.g. a
Subject-header) MUST contain at least one non-whitespace character
(see also remarks about empty headers in 4.2.6).
unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS]
Extended-phrases (known somewhat confusingly in [RFC 2822] as obs-
phrases) are introduced to allow headers such as
From: Joe Q. Public <joe@public.example>
without the necessity of using a quoted-string. They MUST be accepted
by compliant software, but they SHOULD NOT be generated until
software capable of accepting them has become widely deployed.
phrase = 1*( [CFWS] encoded-word [CFWS] / word ) /
extended-phrase
extended-phrase = ( [CFWS] encoded-word [CFWS] / word )
*( [CFWS] encoded-word [CFWS] / word /
[CFWS] "." [CFWS] )
[ [RFC 2822] had
obs-phrase = word *( word / "." / CFWS )
Please can Pete check that what I have is equivalent?]
Within a date-time, two of the obs-zones from [RFC 2822] are retained
because of current widespread usage.
zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
The forms "UT" and "GMT" (indicating universal time) are to be
regarded as obsolete synonyms for "+0000". They MUST be accepted, and
passed on unchanged, by all agents, but they MUST NOT be generated as
part of new articles by posting and injecting agents.
Msg-ids are redefined to be a "normalized" subset of those defined by
[RFC 2822], ensuring that no string of characters is quoted unless
strictly necessary (it must contain at least one mqspecial) and no
single character is prefixed by a "\" in the form of a quoted-pair
unless strictly necessary, and moreover there is no possibility for
">" or WSP to occur inside a msg-id, whether quoted or not. Thus,
whereas under [RFC 2822]
<abcd@example.com>
<"abcd"@example.com>
<"ab\cd"@example.com>
would be considered semantically equivalent, only the first of them
is syntactically permitted by this standard, and hence a simple
comparison of octets will always suffice to determine the identity of
two msg-ids.
msg-id = "<" id-left "@" id-right ">"
id-left = dot-atom-text / no-fold-quote
id-right = dot-atom-text / no-fold-literal
no-fold-quote = DQUOTE
*( mqtext / "\\" / "\" DQUOTE )
mqspecial
*( mqtext / "\\" / "\" DQUOTE )
DQUOTE
mqtext = NO-WS-CTL / ; all of <text> except
%d33 / ; SP, HTAB, "\", ">"
%d35-61 / ; and DQUOTE
%d63-91 /
%d93-126
mqspecial = "(" / ")" / ; same as specials except
"<" / ; "\" and DQUOTE quoted
"[" / "]" / ; and ">" omitted
":" / ";" /
"@" / "\\" /
"," / "." /
"\" DQUOTE
no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
mdtext = NO-WS-CTL / ; Non white space controls
%d33-61 / ; The rest of the US-ASCII
%d63-90 / ; characters not including
%d94-126 ; ">", "[", "]", or "\"
[< Prev]
[TOC] [ Next >]
#Diff to first older
--- ../usefor-article-10/Syntax_adapted_from_Email_and_MIME.out April 2003
+++ ../usefor-article-11/Syntax_adapted_from_Email_and_MIME.out June 2003
@@ -1,35 +1,95 @@
2.4.2. Syntax adapted from Email and MIME
Much of the syntax of Netnews Articles is based on the corresponding
- syntax defined in [RFC 2822] or in the MIME specifications [RFC 2045]
- et seq, which are deemed to have been incorporated into this standard
- as required. However, there are some differences arising from some
- special requirements of Netnews and the fact that [RFC 2822] includes
- much syntax described as "obsolete" (which is excluded from this
- standard, as detailed below).
+ syntax defined in [RFC 2822]. Therefore, wherever in this standard
+ the syntax is stated to be taken from [RFC 2822], it is to be
+ understood, unless explicitly stated to the contrary, as the syntax
+ defined by [RFC 2822], but NOT including any syntax defined in
+ section 4 ("Obsolete syntax") of [RFC 2822]. Software compliant with
+ this standard MUST NOT generate any of the syntactic forms defined in
+ that Obsolete Syntax, although it MAY accept such syntactic forms.
+
+ Likewise, certain syntax from the MIME specifications [RFC 2045] et
+ seq is also considered to have been incorporated into this standard
+ (see 6.21).
+
+ However, there are some differences arising from some special
+ requirements of Netnews, and the following syntactic rules therefore
+ supersede the corresponding rules given in [RFC 2822].
NOTE: Netnews parsers historically have been much less
permissive than Email parsers, and this is reflected in the
modifications referred to, and in some further specific rules.
- The following syntactic rules therefore supersede the corresponding
- rules given in [RFC 2822] and [RFC 2045].
+ In contradistinction to [RFC 2822], an unstructured header (e.g. a
+ Subject-header) MUST contain at least one non-whitespace character
+ (see also remarks about empty headers in 4.2.6).
unstructured = 1*( [FWS] ( utext / encoded-word ) ) [FWS]
-[The one rule might not seem much of a difference, but there are likely
-to be others brought into here later as part of this reorganization. So
-the existing structure is left alone for now.]
-
- Observe, in contradistinction to [RFC 2822], that an unstructured
- header MUST contain at least one non-whitespace character (see also
- remarks about empty headers in 4.2.6).
-
- Wherever in this standard the syntax is stated to be taken from [RFC
- 2822], it is to be understood as the syntax defined by [RFC 2822]
- after making the above change(s), but NOT including any syntax
- defined in section 4 ("Obsolete syntax") of [RFC 2822]. Software
- compliant with this standard MUST NOT generate any of the syntactic
- forms defined in that Obsolete Syntax, although it MAY accept such
- syntactic forms. Certain syntax from the MIME specifications [RFC
- 2045] et seq is also considered a part of this standard (see 6.21).
+
+ Extended-phrases (known somewhat confusingly in [RFC 2822] as obs-
+ phrases) are introduced to allow headers such as
+ From: Joe Q. Public <joe@public.example>
+ without the necessity of using a quoted-string. They MUST be accepted
+ by compliant software, but they SHOULD NOT be generated until
+ software capable of accepting them has become widely deployed.
+
+ phrase = 1*( [CFWS] encoded-word [CFWS] / word ) /
+ extended-phrase
+ extended-phrase = ( [CFWS] encoded-word [CFWS] / word )
+ *( [CFWS] encoded-word [CFWS] / word /
+ [CFWS] "." [CFWS] )
+[ [RFC 2822] had
+ obs-phrase = word *( word / "." / CFWS )
+Please can Pete check that what I have is equivalent?]
+
+ Within a date-time, two of the obs-zones from [RFC 2822] are retained
+ because of current widespread usage.
+
+ zone = (( "+" / "-" ) 4DIGIT) / "UT" / "GMT"
+
+ The forms "UT" and "GMT" (indicating universal time) are to be
+ regarded as obsolete synonyms for "+0000". They MUST be accepted, and
+ passed on unchanged, by all agents, but they MUST NOT be generated as
+ part of new articles by posting and injecting agents.
+
+ Msg-ids are redefined to be a "normalized" subset of those defined by
+ [RFC 2822], ensuring that no string of characters is quoted unless
+ strictly necessary (it must contain at least one mqspecial) and no
+ single character is prefixed by a "\" in the form of a quoted-pair
+ unless strictly necessary, and moreover there is no possibility for
+ ">" or WSP to occur inside a msg-id, whether quoted or not. Thus,
+ whereas under [RFC 2822]
+ <abcd@example.com>
+ <"abcd"@example.com>
+ <"ab\cd"@example.com>
+ would be considered semantically equivalent, only the first of them
+ is syntactically permitted by this standard, and hence a simple
+ comparison of octets will always suffice to determine the identity of
+ two msg-ids.
+ msg-id = "<" id-left "@" id-right ">"
+ id-left = dot-atom-text / no-fold-quote
+ id-right = dot-atom-text / no-fold-literal
+ no-fold-quote = DQUOTE
+ *( mqtext / "\\" / "\" DQUOTE )
+ mqspecial
+ *( mqtext / "\\" / "\" DQUOTE )
+ DQUOTE
+ mqtext = NO-WS-CTL / ; all of <text> except
+ %d33 / ; SP, HTAB, "\", ">"
+ %d35-61 / ; and DQUOTE
+ %d63-91 /
+ %d93-126
+ mqspecial = "(" / ")" / ; same as specials except
+ "<" / ; "\" and DQUOTE quoted
+ "[" / "]" / ; and ">" omitted
+ ":" / ";" /
+ "@" / "\\" /
+ "," / "." /
+ "\" DQUOTE
+ no-fold-literal = "[" *( mdtext / "\[" / "\]" / "\\" ) "]"
+ mdtext = NO-WS-CTL / ; Non white space controls
+ %d33-61 / ; The rest of the US-ASCII
+ %d63-90 / ; characters not including
+ %d94-126 ; ">", "[", "]", or "\"