Ignore:
Timestamp:
19/05/13 08:09:53 (10 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

Location:
draft-ietf-httpbis/latest
Files:
2 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>

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

    r2252 r2253  
    12561256<t anchor="rule.OWS">
    12571257   The OWS rule is used where zero or more linear whitespace octets might
    1258    appear. OWS &SHOULD; either not be generated or be generated as a single
    1259    SP. Multiple OWS octets that occur within field-content &SHOULD; either
    1260    be replaced with a single SP or transformed to all SP octets (each
    1261    octet other than SP replaced with SP) before interpreting the field value
    1262    or forwarding the message downstream.
     1258   appear. For protocol elements where optional whitespace is preferred to
     1259   improve readability, a sender &SHOULD; generate the optional whitespace
     1260   as a single SP; otherwise, a sender &SHOULD-NOT; generate optional
     1261   whitespace except as needed to white-out invalid or unwanted protocol
     1262   elements during in-place message filtering.
    12631263</t>
    12641264<t anchor="rule.RWS">
    1265    RWS is used when at least one linear whitespace octet is required to
    1266    separate field tokens. RWS &SHOULD; be generated as a single SP.
    1267    Multiple RWS octets that occur within field-content &SHOULD; either
    1268    be replaced with a single SP or transformed to all SP octets before
    1269    interpreting the field value or forwarding the message downstream.
     1265   The RWS rule is used when at least one linear whitespace octet is required
     1266   to separate field tokens. A sender &SHOULD; generate RWS as a single SP.
    12701267</t>
    12711268<t anchor="rule.BWS">
    1272    BWS is used where the grammar allows optional whitespace, for historical
    1273    reasons, but it &MUST-NOT; be generated in messages; recipients &MUST;
    1274    accept such bad optional whitespace and remove it before interpreting the
    1275    field value.
     1269   The BWS rule is used where the grammar allows optional whitespace only for
     1270   historical reasons. A sender &MUST-NOT; generate BWS in messages.
     1271   A recipient &MUST; parse for such bad whitespace and remove it before
     1272   interpreting the protocol element.
    12761273</t>
    12771274<t anchor="rule.whitespace">
    … …  
    13061303   field value or after the last non-whitespace octet of the field value
    13071304   is ignored and &SHOULD; be removed before further processing (as this does
    1308    not change the meaning of the header field).
     1305   not change the meaning of the header field).
     1306</t>
     1307<t>
     1308   A recipient of field-content containing multiple sequential octets of
     1309   optional (OWS) or required (RWS) whitespace &SHOULD; either replace the
     1310   sequence with a single SP or transform any non-SP octets in the sequence to
     1311   SP octets before interpreting the field value or forwarding the message
     1312   downstream.
    13091313</t>
    13101314<t>
Note: See TracChangeset for help on using the changeset viewer.