usefor-article-04 April 2001

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 (notablt local
   headers (4.2.2.3), 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.

--- ../usefor-article-03/Names_and_Contents.out          February 2000
+++ ../usefor-article-04/Names_and_Contents.out          April 2001
@@ -55,8 +55,9 @@
    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.
+   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.
 
    Header-names are case-insensitive. There is a preferred case
    convention, which posters and posting agents SHOULD use: each