usefor-article-08 August 2002

4.2.3.  White Space and Continuations

   Each header is logically a single line of characters comprising the
   header-name, the colon with its following SP, the content, and any
   parameters. For convenience, however, the content and parameters can
   be "folded" into a multiple line representation by inserting a CRLF
   before any WSP contained within any FWS or CFWS (but not any other SP
   or HTAB) allowed by this standard. For example, the header:
      Approved: modname@modsite.example (Moderator of example.foo.bar)
   can be represented as:
      Approved: modname@modsite.example
         (Moderator of example.foo.bar)

   FWS occurs at many places in the syntax (usually within a CFWS) in
   order to allow the inclusion of comments, whitespace and folding. The
   syntax is in fact ambiguous insofar as it sometimes allows two
   consecutive instantiations of FWS (as least one of which is always
   optional), or of an optional FWS followed by an explicit CRLF.
   However, all such cases MUST be treated as if the optional
   instantiation (or one of them) had not been allowed. It is thus
   precluded that any line of a header should be made up of whitespace
   characters and nothing else (for such a line might otherwise have
   been interpreted by a non-compliant agent as the separator between
   the headers and the body of the article).

        NOTE: This does not lead to semantic ambiguity because, unless
        specifically stated otherwise, the presence or absence of
        folding, a comment or additional WSP has no semantic meaning
        and, in particular, it is a matter of indifference whether it
        forms a part of the syntactic construct preceding it or the one
        following it.
        NOTE: It may be observed that the content part of every header
        begins and ends with an optional CFWS (or FWS in the case of a
        few headers). Moreover, every parameter also begins and ends
        with an optional CFWS.

        NOTE: Although contents are defined in such a way that folding
        can take place between many of the lexical tokens (and even
        within some of them), folding should be limited to placing the
        CRLF at higher-level syntactic breaks, and should also avoid
        leaving trailing WSP on the preceding line. For instance, if a
        header-content is defined as comma-separated values, it is
        recommended that folding occur after the comma separating the
        values, even if it is allowed elsewhere.

   In accordance with the syntax, the header-name on the first line MUST
   be followed by a SP (even if the rest of the header is empty, but see
   4.2.6).  Even though the syntax allows otherwise, at least some of
   the content MUST appear on that first line (to avoid the possibility
   of harm by any non-compliant agent that might eliminate a trailing
   WSP). Although posting agents are REQUIRED to enforce these
   restrictions, relaying and serving agents SHOULD accept articles that
   violate them.

        NOTE: This standard differs from [RFC 2822] in requiring that SP
        following the colon (it was also an [RFC 1036] requirement).

   Posters and posting agents SHOULD use SP, not HTAB, where white space
   is desired in headers (some existing software expects this). Relaying
   and serving agents SHOULD accept HTAB in all such cases, however.

--- ../usefor-article-07/White_Space_and_Continuations.out          May 2002
+++ ../usefor-article-08/White_Space_and_Continuations.out          August 2002
@@ -15,13 +15,13 @@
    order to allow the inclusion of comments, whitespace and folding. The
    syntax is in fact ambiguous insofar as it sometimes allows two
    consecutive instantiations of FWS (as least one of which is always
-   optional), or of FWS followed by an explicit CRLF. However, all such
-   cases MUST be treated as if the optional instantiation (or one of
-   them) had not been present. It is thus precluded that any line of a
-   header should be made up of whitespace characters and nothing else
-   (for such a line might otherwise have been interpreted by a non-
-   compliant agent as the separator between the headers and the body of
-   the article).
+   optional), or of an optional FWS followed by an explicit CRLF.
+   However, all such cases MUST be treated as if the optional
+   instantiation (or one of them) had not been allowed. It is thus
+   precluded that any line of a header should be made up of whitespace
+   characters and nothing else (for such a line might otherwise have
+   been interpreted by a non-compliant agent as the separator between
+   the headers and the body of the article).
 
         NOTE: This does not lead to semantic ambiguity because, unless
         specifically stated otherwise, the presence or absence of
@@ -30,18 +30,18 @@
         forms a part of the syntactic construct preceding it or the one
         following it.
         NOTE: It may be observed that the content part of every header
-        begins and ends with an optional CFWS (or FWS in the case of
-        certain headers). Moreover, every parameter also begins and ends
+        begins and ends with an optional CFWS (or FWS in the case of a
+        few headers). Moreover, every parameter also begins and ends
         with an optional CFWS.
 
-        NOTE: Though contents are defined in such a way that folding can
-        take place between many of the lexical tokens (and even within
-        some of them), folding should be limited to placing the CRLF at
-        higher-level syntactic breaks, and should also avoid leaving
-        trailing WSP on the preceding line. For instance, if a header-
-        content is defined as comma-separated values, it is recommended
-        that folding occur after the comma separating the structured
-        items, even if it is allowed elsewhere.
+        NOTE: Although contents are defined in such a way that folding
+        can take place between many of the lexical tokens (and even
+        within some of them), folding should be limited to placing the
+        CRLF at higher-level syntactic breaks, and should also avoid
+        leaving trailing WSP on the preceding line. For instance, if a
+        header-content is defined as comma-separated values, it is
+        recommended that folding occur after the comma separating the
+        values, even if it is allowed elsewhere.
 
    In accordance with the syntax, the header-name on the first line MUST
    be followed by a SP (even if the rest of the header is empty, but see