usefor-article-12 November 2003

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 (see 2.4.2).  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 for two
   consecutive FWS (as least one of which is always optional), or for an
   optional FWS followed by an explicit CRLF. In the first case, (one
   of) the optional FWS MUST NOT be instantiated; in the second case,
   the [*WSP CRLF] within the optional FWS MUST NOT be instantiated.
   Thus 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.

   In accordance with the syntax, the header-name and colon on the first
   line MUST be followed by a SP (even if the rest of the header is
   empty, which in fact cannot occur because this standard defines no
   headers with empty content and extensions MUST NOT do so). Even
   though the syntax allows otherwise, at least some visible content
   MUST appear on that first line (to avoid the possibility of harm by
   any non-compliant agent that might eliminate a trailing WSP). Posting
   and injecting agents are REQUIRED to enforce these restrictions,
   deleting any headers with empty content that are encountered, but
   relaying and serving agents MUST accept and pass on untouched
   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.

   Relaying and serving agents MUST NOT refold headers (i.e. they must
   pass on the folding as received).

--- ../usefor-article-11/White_Space_and_Continuations.out          June 2003
+++ ../usefor-article-12/White_Space_and_Continuations.out          November 2003
@@ -4,8 +4,9 @@
    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:
+   before any WSP contained within any FWS (or CFWS), but not any other
+   SP or HTAB, allowed by this standard (see 2.4.2).  For example, the
+   header:
       Approved: modname@modsite.example (Moderator of example.foo.bar)
    can be represented as:
       Approved: modname@modsite.example
@@ -13,15 +14,15 @@
 
    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).
+   syntax is in fact ambiguous insofar as it sometimes allows for two
+   consecutive FWS (as least one of which is always optional), or for an
+   optional FWS followed by an explicit CRLF. In the first case, (one
+   of) the optional FWS MUST NOT be instantiated; in the second case,
+   the [*WSP CRLF] within the optional FWS MUST NOT be instantiated.
+   Thus 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
@@ -31,20 +32,22 @@
         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.
 
-   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.
+   In accordance with the syntax, the header-name and colon on the first
+   line MUST be followed by a SP (even if the rest of the header is
+   empty, which in fact cannot occur because this standard defines no
+   headers with empty content and extensions MUST NOT do so). Even
+   though the syntax allows otherwise, at least some visible content
+   MUST appear on that first line (to avoid the possibility of harm by
+   any non-compliant agent that might eliminate a trailing WSP). Posting
+   and injecting agents are REQUIRED to enforce these restrictions,
+   deleting any headers with empty content that are encountered, but
+   relaying and serving agents MUST accept and pass on untouched
+   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).