usefor-article-07 May 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 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).

        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
        certain 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.

   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-06/White_Space_and_Continuations.out          November 2001
+++ ../usefor-article-07/White_Space_and_Continuations.out          May 2002
@@ -1,46 +1,61 @@
 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, and the header-content.
-   For convenience, however, the header-content can be split into a
-   multiple line representation; this is called "folding". The general
-   rule is that wherever this standard allows for FWS or CFWS (but not
-   simply SP or HTAB) a CRLF may be inserted before any WSP. For
-   example, the header:
-      Approved: modname@modsite.example (Moderator of comp.foo.bar)
+   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 comp.foo.bar)
+         (Moderator of example.foo.bar)
 
-        NOTE: Though header-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.
-
-   Folding MUST NOT be carried out in such a way that any line of a
-   header is made up entirely of WSP characters and nothing else.
-
-   The colon following the header name on the first line MUST be
-   followed by a WSP, even if the header is empty. If the header is not
-   empty, at least some of the content MUST appear on the first line
-   (this is to avoid the possibility of harm by any non-compliant agent
-   that might eliminate a trailing SP). Posting agents MUST enforce
-   these restrictions, but relaying agents SHOULD accept even articles
-   that violate them.
+   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 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).
 
-        NOTE: This standard differs from [RFC 2822] in requiring that
-        WSP followng the colon (it was also an [RFC 1036] requirement).
+        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
+        certain 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.
+
+   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), and MUST
-   use SP immediately following the colon after a header-name. Relaying
-   agents SHOULD accept HTAB in all such cases, however.
-   Since the white space beginning a continuation line remains a part of
-   the logical line, headers can be "broken" into multiple lines only at
-   FWS or CFWS. Posting agents Ought Not to break headers unnecessarily
-   (but see 4.5).
+   is desired in headers (some existing software expects this). Relaying
+   and serving agents SHOULD accept HTAB in all such cases, however.