Changeset 368 for draft-ietf-httpbis/latest/p1-messaging.xml

Timestamp:

13/11/08 19:27:20 (12 years ago)

Author:

mnot@…

Message:

Document LWS -> OWS, RWS, BWS

File:

• draft-ietf-httpbis/latest/p1-messaging.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -418 +418 @@
 <section title="Notational Conventions and Generic Grammar" anchor="notation">
 
-<section title="ABNF Extensions" anchor="notation.abnf">
-<t>
-   Two extensions to the ABNF rules of <xref target="RFC5234"/> are used to
-   improve readability.<cref>The current plan is to remove these extensions prior
-   to the last call draft.</cref>
-</t>
-
-<section title="#rule">
+<section title="ABNF Extension: #rule" anchor="notation.abnf">
+  <t>
+    One extension to the ABNF rules of <xref target="RFC5234"/> is used to
+    improve readability.
+  </t>
   <t>
     A construct "#" is defined, similar to "*", for defining lists of
     elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least
     &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas
-    (",") and &OPTIONAL; linear white space (LWS). This makes the usual
+    (",") and &OPTIONAL; linear white space (OWS). This makes the usual
     form of lists very easy; a rule such as
     <figure><artwork type="example">
- ( *<x:ref>LWS</x:ref> element *( *<x:ref>LWS</x:ref> "," *<x:ref>LWS</x:ref> element ))</artwork></figure>
+ ( *<x:ref>OWS</x:ref> element *( *<x:ref>OWS</x:ref> "," *<x:ref>OWS</x:ref> element ))</artwork></figure>
   </t>
   <t>
@@ -450 +447 @@
     two.
   </t>
-</section>
-
-<section title="implied *LWS" anchor="implied.LWS">
-  <iref item="implied *LWS" primary="true"/>
-    <t>
-      The grammar described by this specification is word-based. Except
-      where noted otherwise, linear white space (LWS) can be included
-      between any two adjacent words (token or quoted-string), and
-      between adjacent words and separators, without changing the
-      interpretation of a field. At least one delimiter (LWS and/or
-      separators) &MUST; exist between any two tokens (for the definition
-      of "token" below), since they would otherwise be interpreted as a
-      single token.
-    </t>
-</section>
 </section>
 
@@ -500 +482 @@
 </t>
 <t anchor="rule.LWS">
-  <x:anchor-alias value="LWS"/>
-   HTTP/1.1 header field values can be folded onto multiple lines if the
-   continuation line begins with a space or horizontal tab. All linear
-   white space, including folding, has the same semantics as SP. A
-   recipient &MAY; replace any linear white space with a single SP before
+   All linear white space (LWS) in header field-values has the same semantics as SP. A
+   recipient &MAY; replace any such linear white space with a single SP before
    interpreting the field value or forwarding the message downstream.
 </t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="LWS"/>
-  <x:ref>LWS</x:ref>            = [<x:ref>CRLF</x:ref>] 1*<x:ref>WSP</x:ref>
-</artwork></figure>
+<t>
+   Historically, HTTP/1.1 header field values allow linear white space folding across 
+   multiple lines. However, this specification deprecates its use; senders MUST NOT 
+   produce messages that include LWS folding (i.e., use the obs-fold rule), except
+   within the message/http media type <xref target="internet.media.type.message.http"/>. 
+   Receivers SHOULD still parse folded linear white space.
+</t>
+<t>
+    This specification uses three rules to denote the use of linear white space;
+    BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).
+</t>
+<t>
+        "Bad" white space is allowed by the BNF, but senders SHOULD NOT produce it in messages.
+        Receivers MUST accept it in incoming messages.
+</t>
+
 <t anchor="rule.whitespace">
   <x:anchor-alias value="BWS"/>