INTERNET-DRAFT Charles H. Lindsey
Usenet Format Working Group University of Manchester
July 2001
4.2.1. Names and Contents
Previous Up Next
4.2.1. Names and Contents
Despite the restrictions on header-name syntax imposed by the
grammar, relayers and reading agents SHOULD tolerate header names
containing any US-ASCII printable character other than colon (":",
US-ASCII 58).
Header-names SHOULD be either those for which a USENET-header-content
is established by this standard, or by [RFC 2822], or by any
extension to either of these standards including, in particular, the
MIME standards [RFC 2045] et seq., or else experimental headers
beginning with "X-" (as defined in 4.2.2.1). Software SHOULD NOT
attempt to interpret headers not described in this standard or in its
extensions, but relaying agents MUST pass them on unaltered and
reading agents MUST enable them to be displayed, at least optionally.
The possibility of allowing header-parameters to appear in all
headers is provided mainly for the purpose of allowing future
extensions to existing headers, since only a very few USENET-header-
parameters are actually defined in this standard. Observe that such
header-parameters do not, in general, occur in headers defined in
other standards, except for the MIME standards [RFC 2045] et seq. and
their extensions. Nevertheless, compliant software MUST accept all
such header-parameters in headers defined by this standard and its
extensions (ignoring them if their meaning is unknown) and SHOULD
accept (and ignore) them in all headers.
[but what about
address = mailbox / group
group = phrase ":" [mailbox-list] ";"
Does the following NOTE cover the situation?]
NOTE: The presence of a ";" in a header-content does not
indicate the presence of a header-parameter in the few
situations where it can be parsed as part of some USENET-
header-content or other-header-content.
On the other hand, posting agents SHOULD NOT generate header-
parameters (even those using x-tokens) except in those headers for
which a USENET-header-parameter has been defined, or where that usage
is permitted by some other standard (notably one of the MIME
standards). This restriction is likely to removed in a future version
of this standard.
NOTE: The given syntax is ambiguous insofar as a USENET-header-
content that is defined to be could contain,
within that , text of the form <*(";" header-
parameter)>. The intention is therefore that any such apparent
header-parameters are to be regarded as part of the
. This standard therefore does not (and extensions
to it SHOULD NOT) define any USENET-header-parameter to be
associated with such an unstructured USENET-header-content.
The order of headers in an article is not significant. However,
posting agents are encouraged to put mandatory headers (section 5)
first, followed by optional headers (section 6), followed by
experimental headers and headers not defined in this standard or its
extensions. Relaying agents MUST NOT change the order of the headers
in an article.
Header-names are case-insensitive. There is a preferred case
convention, which posters and posting agents Ought to use: each
hyphen-separated "word" has its initial letter (if any) in uppercase
and the rest in lowercase, except that some abbreviations have all
letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
used in this standard are the preferred forms for the headers
described herein. Relaying and reading agents MUST, however, tolerate
articles not obeying this convention.
Previous Up Next
Previous draft (04): 4.2.1. Names and Contents
Diffs to previous draft
--- {draft-04} Wed Jul 11 21:55:07 2001
+++ {draft-05} Wed Jul 11 21:55:08 2001
@@ -2,16 +2,15 @@
Despite the restrictions on header-name syntax imposed by the
grammar, relayers and reading agents SHOULD tolerate header names
containing any US-ASCII printable character other than colon (":",
- ASCII 58).
-[To bring it into line with <optional-field> as given in [MESSFOR].]
+ US-ASCII 58).
Header-names SHOULD be either those for which a USENET-header-content
- is defined in this standard, or those defined in [MESSFOR], or those
- defined in any extension to either of these standards including, in
- particular, the Mime standards [RFC 2045] et seq., or experimental
- headers beginning with "X-" (as defined in 4.2.2.1). Software SHOULD
- NOT attempt to interpret headers not described in this standard or in
- its extensions, but relaying agents MUST pass them on unaltered and
+ is established by this standard, or by [RFC 2822], or by any
+ extension to either of these standards including, in particular, the
+ MIME standards [RFC 2045] et seq., or else experimental headers
+ beginning with "X-" (as defined in 4.2.2.1). Software SHOULD NOT
+ attempt to interpret headers not described in this standard or in its
+ extensions, but relaying agents MUST pass them on unaltered and
reading agents MUST enable them to be displayed, at least optionally.
The possibility of allowing header-parameters to appear in all
@@ -19,7 +18,7 @@
extensions to existing headers, since only a very few USENET-header-
parameters are actually defined in this standard. Observe that such
header-parameters do not, in general, occur in headers defined in
- other standards, except for the Mime standards [RFC 2045] et seq. and
+ other standards, except for the MIME standards [RFC 2045] et seq. and
their extensions. Nevertheless, compliant software MUST accept all
such header-parameters in headers defined by this standard and its
extensions (ignoring them if their meaning is unknown) and SHOULD
@@ -34,12 +33,14 @@
situations where it can be parsed as part of some USENET-
header-content or other-header-content.
- On the other hand, posting agents SHOULD NOT generate them (even
- those using x-tokens) except in those headers for which a USENET-
- header-parameter has been defined, or where that usage is permitted
- by some other standard (notably one of the Mime standards). This
- restriction is likely to removed in a future version of this
- standard.
+ On the other hand, posting agents SHOULD NOT generate header-
+ parameters (even those using x-tokens) except in those headers for
+ which a USENET-header-parameter has been defined, or where that usage
+ is permitted by some other standard (notably one of the MIME
+ standards). This restriction is likely to removed in a future version
+ of this standard.
+
+
NOTE: The given syntax is ambiguous insofar as a USENET-header-
content that is defined to be <unstructured> could contain,
@@ -55,18 +56,14 @@
first, followed by optional headers (section 6), followed by
experimental headers and headers not defined in this standard or its
extensions. Relaying agents MUST NOT change the order of the headers
- in an article, though they MAY add additional headers (notablt local
- headers (4.2.2.3), preferably either before or after all the existing
- ones.
+ in an article.
Header-names are case-insensitive. There is a preferred case
- convention, which posters and posting agents SHOULD use: each
+ convention, which posters and posting agents Ought to use: each
hyphen-separated "word" has its initial letter (if any) in uppercase
and the rest in lowercase, except that some abbreviations have all
letters uppercase (e.g. "Message-ID" and "MIME-Version"). The forms
used in this standard are the preferred forms for the headers
described herein. Relaying and reading agents MUST, however, tolerate
articles not obeying this convention.
-
-