Ignore:
Timestamp:
19/05/13 08:09:53 (7 years ago)
Author:
fielding@…
Message:

(editorial) properly target the whitespace requirements to sender or recipient; move the requirement on parsing whitespace sequences to the field parsing section

File:
1 edited

Legend:

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

    r2252 r2253  
    449449  }
    450450  @bottom-center {
    451        content: "Expires November 19, 2013";
     451       content: "Expires November 20, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-05-18">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-05-19">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">May 18, 2013</td>
     522               <td class="right">May 19, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: November 19, 2013</td>
     525               <td class="left">Expires: November 20, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on November 19, 2013.</p>
     553      <p>This Internet-Draft will expire on November 20, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    12421242      </div>
    12431243      <div id="rule.OWS">
    1244          <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. OWS <em class="bcp14">SHOULD</em> either not be generated or be generated as a single SP. Multiple OWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets (each octet other than SP replaced with SP) before interpreting
    1245             the field value or forwarding the message downstream.
     1244         <p id="rfc.section.3.2.3.p.2">The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements where optional whitespace
     1245            is preferred to improve readability, a sender <em class="bcp14">SHOULD</em> generate the optional whitespace as a single SP; otherwise, a sender <em class="bcp14">SHOULD NOT</em> generate optional whitespace except as needed to white-out invalid or unwanted protocol elements during in-place message filtering.
    12461246         </p>
    12471247      </div>
    12481248      <div id="rule.RWS">
    1249          <p id="rfc.section.3.2.3.p.3">RWS is used when at least one linear whitespace octet is required to separate field tokens. RWS <em class="bcp14">SHOULD</em> be generated as a single SP. Multiple RWS octets that occur within field-content <em class="bcp14">SHOULD</em> either be replaced with a single SP or transformed to all SP octets before interpreting the field value or forwarding the
    1250             message downstream.
     1249         <p id="rfc.section.3.2.3.p.3">The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender <em class="bcp14">SHOULD</em> generate RWS as a single SP.
    12511250         </p>
    12521251      </div>
    12531252      <div id="rule.BWS">
    1254          <p id="rfc.section.3.2.3.p.4">BWS is used where the grammar allows optional whitespace, for historical reasons, but it <em class="bcp14">MUST NOT</em> be generated in messages; recipients <em class="bcp14">MUST</em> accept such bad optional whitespace and remove it before interpreting the field value.
     1253         <p id="rfc.section.3.2.3.p.4">The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender <em class="bcp14">MUST NOT</em> generate BWS in messages. A recipient <em class="bcp14">MUST</em> parse for such bad whitespace and remove it before interpreting the protocol element.
    12551254         </p>
    12561255      </div>
     
    12721271         octet of the field value is ignored and <em class="bcp14">SHOULD</em> be removed before further processing (as this does not change the meaning of the header field).
    12731272      </p>
    1274       <p id="rfc.section.3.2.4.p.3">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
     1273      <p id="rfc.section.3.2.4.p.3">A recipient of field-content containing multiple sequential octets of optional (OWS) or required (RWS) whitespace <em class="bcp14">SHOULD</em> either replace the sequence with a single SP or transform any non-SP octets in the sequence to SP octets before interpreting
     1274         the field value or forwarding the message downstream.
     1275      </p>
     1276      <p id="rfc.section.3.2.4.p.4">Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one
    12751277         space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type
    12761278         (<a href="#internet.media.type.message.http" title="Internet Media Type message/http">Section&nbsp;7.3.1</a>). Senders <em class="bcp14">MUST NOT</em> generate messages that include line folding (i.e., that contain any field-value that contains a match to the <a href="#header.fields" class="smpl">obs-fold</a> rule) unless the message is intended for packaging within the message/http media type. When an <a href="#header.fields" class="smpl">obs-fold</a> is received in a message, recipients <em class="bcp14">MUST</em> do one of:
     
    12871289         in processing.
    12881290      </p>
    1289       <p id="rfc.section.3.2.4.p.4">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
     1291      <p id="rfc.section.3.2.4.p.5">Historically, HTTP has allowed field content with text in the ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> charset, supporting other charsets only through use of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a> encoding. In practice, most HTTP header field values use only a subset of the US-ASCII charset <a href="#USASCII" id="rfc.xref.USASCII.3"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>. Newly defined header fields <em class="bcp14">SHOULD</em> limit their field values to US-ASCII octets. Recipients <em class="bcp14">SHOULD</em> treat other octets in field content (obs-text) as opaque data.
    12901292      </p>
    12911293      <h3 id="rfc.section.3.2.5"><a href="#rfc.section.3.2.5">3.2.5</a>&nbsp;<a id="field.limits" href="#field.limits">Field Limits</a></h3>
Note: See TracChangeset for help on using the changeset viewer.