Ignore:
Timestamp:
Nov 13, 2008, 11:27:20 AM (11 years ago)
Author:
mnot@…
Message:

Document LWS -> OWS, RWS, BWS

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.xml

    r367 r368  
    418418<section title="Notational Conventions and Generic Grammar" anchor="notation">
    419419
    420 <section title="ABNF Extensions" anchor="notation.abnf">
    421 <t>
    422    Two extensions to the ABNF rules of <xref target="RFC5234"/> are used to
    423    improve readability.<cref>The current plan is to remove these extensions prior
    424    to the last call draft.</cref>
    425 </t>
    426 
    427 <section title="#rule">
     420<section title="ABNF Extension: #rule" anchor="notation.abnf">
     421  <t>
     422    One extension to the ABNF rules of <xref target="RFC5234"/> is used to
     423    improve readability.
     424  </t>
    428425  <t>
    429426    A construct "#" is defined, similar to "*", for defining lists of
    430427    elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least
    431428    &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas
    432     (",") and &OPTIONAL; linear white space (LWS). This makes the usual
     429    (",") and &OPTIONAL; linear white space (OWS). This makes the usual
    433430    form of lists very easy; a rule such as
    434431    <figure><artwork type="example">
    435  ( *<x:ref>LWS</x:ref> element *( *<x:ref>LWS</x:ref> "," *<x:ref>LWS</x:ref> element ))</artwork></figure>
     432 ( *<x:ref>OWS</x:ref> element *( *<x:ref>OWS</x:ref> "," *<x:ref>OWS</x:ref> element ))</artwork></figure>
    436433  </t>
    437434  <t>
     
    450447    two.
    451448  </t>
    452 </section>
    453 
    454 <section title="implied *LWS" anchor="implied.LWS">
    455   <iref item="implied *LWS" primary="true"/>
    456     <t>
    457       The grammar described by this specification is word-based. Except
    458       where noted otherwise, linear white space (LWS) can be included
    459       between any two adjacent words (token or quoted-string), and
    460       between adjacent words and separators, without changing the
    461       interpretation of a field. At least one delimiter (LWS and/or
    462       separators) &MUST; exist between any two tokens (for the definition
    463       of "token" below), since they would otherwise be interpreted as a
    464       single token.
    465     </t>
    466 </section>
    467449</section>
    468450
     
    500482</t>
    501483<t anchor="rule.LWS">
    502   <x:anchor-alias value="LWS"/>
    503    HTTP/1.1 header field values can be folded onto multiple lines if the
    504    continuation line begins with a space or horizontal tab. All linear
    505    white space, including folding, has the same semantics as SP. A
    506    recipient &MAY; replace any linear white space with a single SP before
     484   All linear white space (LWS) in header field-values has the same semantics as SP. A
     485   recipient &MAY; replace any such linear white space with a single SP before
    507486   interpreting the field value or forwarding the message downstream.
    508487</t>
    509 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="LWS"/>
    510   <x:ref>LWS</x:ref>            = [<x:ref>CRLF</x:ref>] 1*<x:ref>WSP</x:ref>
    511 </artwork></figure>
     488<t>
     489   Historically, HTTP/1.1 header field values allow linear white space folding across
     490   multiple lines. However, this specification deprecates its use; senders MUST NOT
     491   produce messages that include LWS folding (i.e., use the obs-fold rule), except
     492   within the message/http media type <xref target="internet.media.type.message.http"/>.
     493   Receivers SHOULD still parse folded linear white space.
     494</t>
     495<t>
     496    This specification uses three rules to denote the use of linear white space;
     497    BWS ("Bad" White Space), OWS (Optional White Space), and RWS (Required White Space).
     498</t>
     499<t>
     500        "Bad" white space is allowed by the BNF, but senders SHOULD NOT produce it in messages.
     501        Receivers MUST accept it in incoming messages.
     502</t>
     503
    512504<t anchor="rule.whitespace">
    513505  <x:anchor-alias value="BWS"/>
Note: See TracChangeset for help on using the changeset viewer.