usefor-article-05 July 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 (":",
   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 <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.
   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.

--- ../usefor-article-04/Names_and_Contents.out          April 2001
+++ ../usefor-article-05/Names_and_Contents.out          July 2001
@@ -3,16 +3,14 @@
    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
@@ -29,17 +27,18 @@
 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.
+   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,12 +54,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 (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