usefor-usefor-02 November 2004

2.2  Headers

   All headers in a news article are compliant with [RFC2822], however
   this specification is less permissive in what can be generated and
   accepted by news agents.  The syntax allowed for news articles is a
   strict subset of the "Internet Message Format", making all messages
   compliant with this specification inherently compliant with
   [RFC2822].  Note however that the converse is not guaranteed to be
   true in all cases.

   General rules which apply to all headers (even those documented in
   [RFC2822] and [RFC2045]) are listed below and those that apply to
   specific headers are described in the relevent sections of this
   document.

   o  All agents MUST generate headers so that at least one space
      immediately follows the ':' separating the header name and the
      header contents (for compatibility with deployed software).  News
      agents MAY accept headers which do not contain the required space.
   o  The header contents of every header line (including the first and
      any that are subsequently folded) MUST contain at least one
      non-whitespace character.
         NOTE: This means that no header content defined by or
         referenced by this document can be empty.  As a result, this
         document updates the <unstructured> construct from Section
         3.2.6 of [RFC2822] as follows:

   unstructured    =  1*( [FWS] utext ) [FWS]

   o  Compliant software MUST NOT generate (but MAY accept) headers of
      more than 998 octets.  This is the only limit on the length of a
      header line prescribed by this standard.  However, specific rules
      to the contrary may apply in particular cases (for example,
      according to [RFC2047] header lines containing encoded-words are
      limited to 76 octets).  [USEAGE] includes suggested limits for
      convenience of display by user agents.
         NOTE: There is NO restriction on the number of lines into which
         a header may be split, and hence there is NO restriction on the
         total length of a header (in particular it may, by suitable
         folding, be made to exceed the 998 octets restriction
         pertaining to a single header line).
   o  The character set for headers is US-ASCII.  Where the use of
      non-ASCII characters is required, they MUST be encoded using the
      MIME mechanisms defined in [RFC2045] and [RFC2231].

--- ../usefor-article-13/Headers.out          May 2004
+++ ../usefor-usefor-02/Headers.out          November 2004
@@ -1,9 +1,45 @@
-4.2.  Headers
+2.2  Headers
 
-   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.
+   All headers in a news article are compliant with [RFC2822], however
+   this specification is less permissive in what can be generated and
+   accepted by news agents.  The syntax allowed for news articles is a
+   strict subset of the "Internet Message Format", making all messages
+   compliant with this specification inherently compliant with
+   [RFC2822].  Note however that the converse is not guaranteed to be
+   true in all cases.
+
+   General rules which apply to all headers (even those documented in
+   [RFC2822] and [RFC2045]) are listed below and those that apply to
+   specific headers are described in the relevent sections of this
+   document.
+
+   o  All agents MUST generate headers so that at least one space
+      immediately follows the ':' separating the header name and the
+      header contents (for compatibility with deployed software).  News
+      agents MAY accept headers which do not contain the required space.
+   o  The header contents of every header line (including the first and
+      any that are subsequently folded) MUST contain at least one
+      non-whitespace character.
+         NOTE: This means that no header content defined by or
+         referenced by this document can be empty.  As a result, this
+         document updates the <unstructured> construct from Section
+         3.2.6 of [RFC2822] as follows:
+
+   unstructured    =  1*( [FWS] utext ) [FWS]
+
+   o  Compliant software MUST NOT generate (but MAY accept) headers of
+      more than 998 octets.  This is the only limit on the length of a
+      header line prescribed by this standard.  However, specific rules
+      to the contrary may apply in particular cases (for example,
+      according to [RFC2047] header lines containing encoded-words are
+      limited to 76 octets).  [USEAGE] includes suggested limits for
+      convenience of display by user agents.
+         NOTE: There is NO restriction on the number of lines into which
+         a header may be split, and hence there is NO restriction on the
+         total length of a header (in particular it may, by suitable
+         folding, be made to exceed the 998 octets restriction
+         pertaining to a single header line).
+   o  The character set for headers is US-ASCII.  Where the use of
+      non-ASCII characters is required, they MUST be encoded using the
+      MIME mechanisms defined in [RFC2045] and [RFC2231].