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 (":",
ASCII 58).
[To bring it into line with <optional-field> as given in [MESSFOR].]
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
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 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.
NOTE: The given syntax is ambiguous insofar as a USENET-header-
content that is defined to be <unstructured> could contain,
within that <unstructured>, text of the form <*(";" header-
parameter)>. The intention is therefore that any such apparent
header-parameters are to be regarded as part of the
<unstructured>. 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, though they MAY add additional headers, preferably
either before or after all the existing ones.
Header-names are case-insensitive. There is a preferred case
convention, which posters and posting agents SHOULD 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.
[< Prev]
[TOC] [ Next >]
| Newer | Older |
|---|---|
| News Article Format November 2001 News Article Format July 2001 News Article Format April 2001 | Son of 1036 June 1994 |
--- ../s-o-1036/Names_and_Contents.out June 1994
+++ ../usefor-article-03/Names_and_Contents.out February 2000
@@ -1,73 +1,69 @@
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 ASCII printable character other
-than colon (":", ASCII 58).
-
- NOTE: MAIL header names can contain any ASCII
- printable character (other than colon) in theory,
- but in practice, arbitrary header names are known
- to cause trouble for some news software. Section
- 4.1's restriction to alphanumeric sequences sepa-
- rated by hyphens is believed to permit all widely-
- used header names without causing problems for any
- widely-used software. Software is nevertheless
- encouraged to cope correctly with the full range
- of possibilities, since aberrations are known to
- occur.
-
-Relayers MUST disregard headers not described in this Draft
-(that is, with header names not mentioned in this Draft),
-and pass them on unaltered.
-
-Posters wishing to convey non-standard information in head-
-ers SHOULD use header names beginning with "X-". No stan-
-dard header name will ever be of this form. Reading agents
-SHOULD ignore "X-" headers, or at least treat them with
-
-INTERNET DRAFT to be NEWS sec. 4.2.1
-
-
-great care.
-
-The order of headers in an article is not significant. How-
-ever, posting agents are encouraged to put mandatory headers
-(see section 5) first, followed by optional headers (see
-section 6), followed by headers not defined in this Draft.
-
- NOTE: While relayers and reading agents must be
- prepared to handle any order, having the signifi-
- cant headers (the precise definition of "signifi-
- cant" depends on context) first can noticeably
- improve efficiency, especially in memory-limited
- environments where it is difficult to buffer up an
- arbitrary quantity of headers while searching for
- the few that matter.
-
-Header names are case-insensitive. There is a preferred
-case convention, which posters and posting agents SHOULD
-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. "Mes-
-sage-ID" and "MIME-Version"). The forms used in this Draft
-are the preferred forms for the headers described herein.
-Relayers and reading agents are warned that articles might
-not obey this convention.
-
- NOTE: Although software must be prepared for the
- possibility of random use of case in header names
- (and other case-independent text), establishing a
- preferred convention reduces pointless diversity,
- and may permit optimized software that looks for
- the preferred forms before resorting to less-
- efficient case-insensitive searches.
-
-In general, a header can consist of several lines, with each
-continuation line beginning with white space. The EOLs pre-
-ceding continuation lines are ignored when processing such a
-header, effectively combining the start-line and the contin-
-uations into a single logical line. The logical line, less
-the header name, colon, and any white space following the
-colon, is the "header content".
+ 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].]
+
+ 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
+ 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 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.
+
+ NOTE: The given syntax is ambiguous insofar as a USENET-header-
+ content that is defined to be <unstructured> could contain,
+ within that <unstructured>, text of the form <*(";" header-
+ parameter)>. The intention is therefore that any such apparent
+ header-parameters are to be regarded as part of the
+ <unstructured>. 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, though they MAY add additional headers, preferably
+ either before or after all the existing ones.
+
+ Header-names are case-insensitive. There is a preferred case
+ convention, which posters and posting agents SHOULD 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.