Ignore:
Timestamp:
04/09/13 11:49:18 (7 years ago)
Author:
julian.reschke@…
Message:

(editorial) reorganize/tune changes sections (see #493)

File:
1 edited

Legend:

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

    r2365 r2369  
    446446  }
    447447  @bottom-center {
    448        content: "Expires March 5, 2014";
     448       content: "Expires March 8, 2014";
    449449  }
    450450  @bottom-right {
     
    488488      <meta name="dct.creator" content="Reschke, J. F.">
    489489      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    490       <meta name="dct.issued" scheme="ISO8601" content="2013-09-01">
     490      <meta name="dct.issued" scheme="ISO8601" content="2013-09-04">
    491491      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">September 1, 2013</td>
     519               <td class="right">September 4, 2013</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: March 5, 2014</td>
     522               <td class="left">Expires: March 8, 2014</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    548548         in progress”.
    549549      </p>
    550       <p>This Internet-Draft will expire on March 5, 2014.</p>
     550      <p>This Internet-Draft will expire on March 8, 2014.</p>
    551551      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    552552      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    29712971      <p id="rfc.section.A.2.p.1">HTTP's approach to error handling has been explained. (<a href="#conformance" title="Conformance and Error Handling">Section&nbsp;2.5</a>)
    29722972      </p>
    2973       <p id="rfc.section.A.2.p.2">The expectation to support HTTP/0.9 requests has been removed.</p>
    2974       <p id="rfc.section.A.2.p.3">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>)
    2975       </p>
    2976       <p id="rfc.section.A.2.p.4">HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is
    2977          fundamentally a message-oriented protocol. (<a href="#http.message" title="Message Format">Section&nbsp;3</a>)
    2978       </p>
    2979       <p id="rfc.section.A.2.p.5">Minimum supported sizes for various protocol elements have been suggested, to improve interoperability.</p>
    2980       <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>)
    2981       </p>
    2982       <p id="rfc.section.A.2.p.7">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted
     2973      <p id="rfc.section.A.2.p.2">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted
    29832974         to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section&nbsp;2.6</a>)
    29842975      </p>
    2985       <p id="rfc.section.A.2.p.8">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>)
    2986       </p>
    2987       <p id="rfc.section.A.2.p.9">The HTTPS URI scheme implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>)
    2988       </p>
    2989       <p id="rfc.section.A.2.p.10">Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their
     2976      <p id="rfc.section.A.2.p.3">Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their
    29902977         transmission on the wire. (<a href="#http.uri" title="http URI scheme">Section&nbsp;2.7.1</a>)
    29912978      </p>
    2992       <p id="rfc.section.A.2.p.11">Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability.
    2993          (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    2994       </p>
    2995       <p id="rfc.section.A.2.p.12">The ABNF productions defining header fields now only list the field value. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
    2996       </p>
    2997       <p id="rfc.section.A.2.p.13">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed
     2979      <p id="rfc.section.A.2.p.4">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. Furthermore, it implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section&nbsp;2.7.2</a>)
     2980      </p>
     2981      <p id="rfc.section.A.2.p.5">HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is
     2982         fundamentally a message-oriented protocol. Minimum supported sizes for various protocol elements have been suggested, to improve
     2983         interoperability. (<a href="#http.message" title="Message Format">Section&nbsp;3</a>)
     2984      </p>
     2985      <p id="rfc.section.A.2.p.6">Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability.
     2986         The ABNF productions defining header fields now only list the field value. (<a href="#header.fields" title="Header Fields">Section&nbsp;3.2</a>)
     2987      </p>
     2988      <p id="rfc.section.A.2.p.7">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed
    29982989         where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section&nbsp;3.2.3</a>)
    29992990      </p>
    3000       <p id="rfc.section.A.2.p.14">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been
    3001          clarified. (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
    3002       </p>
    3003       <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
    3004       </p>
    3005       <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
    3006       </p>
    3007       <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a>)
    3008       </p>
    3009       <p id="rfc.section.A.2.p.18">The "identity" transfer coding token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>)
    3010       </p>
    3011       <p id="rfc.section.A.2.p.19">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven
    3012          by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. (<a href="#message.body.length" title="Message Body Length">Section&nbsp;3.3.3</a>)
    3013       </p>
    3014       <p id="rfc.section.A.2.p.20">"multipart/byteranges" is no longer a way of determining message body length detection. (<a href="#message.body.length" title="Message Body Length">Section&nbsp;3.3.3</a>)
    3015       </p>
    3016       <p id="rfc.section.A.2.p.21">CONNECT is a new, special case in determining message body length. (<a href="#message.body.length" title="Message Body Length">Section&nbsp;3.3.3</a>)
    3017       </p>
    3018       <p id="rfc.section.A.2.p.22">Chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>)
    3019       </p>
    3020       <p id="rfc.section.A.2.p.23">Use of chunk extensions is deprecated, and line folding in them is disallowed. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>)
    3021       </p>
    3022       <p id="rfc.section.A.2.p.24">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808.
    3023          (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
    3024       </p>
    3025       <p id="rfc.section.A.2.p.25">The asterisk-form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
    3026       </p>
    3027       <p id="rfc.section.A.2.p.26">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>)
    3028       </p>
    3029       <p id="rfc.section.A.2.p.27">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>)
    3030       </p>
    3031       <p id="rfc.section.A.2.p.28">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop
    3032          in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.9" title="Connection">Section&nbsp;6.1</a>)
    3033       </p>
    3034       <p id="rfc.section.A.2.p.29">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    3035       </p>
    3036       <p id="rfc.section.A.2.p.30">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    3037       </p>
    3038       <p id="rfc.section.A.2.p.31">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed.
    3039          (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    3040       </p>
    3041       <p id="rfc.section.A.2.p.32">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
    3042       </p>
    3043       <p id="rfc.section.A.2.p.33">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;6.7</a>)
    3044       </p>
    3045       <p id="rfc.section.A.2.p.34">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;8.4</a>)
    3046       </p>
    3047       <p id="rfc.section.A.2.p.35">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>)
    3048       </p>
    3049       <p id="rfc.section.A.2.p.36">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.5</a>)
    3050       </p>
    3051       <p id="rfc.section.A.2.p.37">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged
     2991      <p id="rfc.section.A.2.p.8">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section&nbsp;3.2.4</a>)
     2992      </p>
     2993      <p id="rfc.section.A.2.p.9">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been
     2994         clarified. The quoted-pair rule no longer allows escaping control characters other than HTAB. Non-ASCII content in header
     2995         fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section&nbsp;3.2.6</a>)
     2996      </p>
     2997      <p id="rfc.section.A.2.p.10">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section&nbsp;3.3.2</a>)
     2998      </p>
     2999      <p id="rfc.section.A.2.p.11">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven
     3000         by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. CONNECT is a
     3001         new, special case in determining message body length. "multipart/byteranges" is no longer a way of determining message body
     3002         length detection. (<a href="#message.body.length" title="Message Body Length">Section&nbsp;3.3.3</a>)
     3003      </p>
     3004      <p id="rfc.section.A.2.p.12">The "identity" transfer coding token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>)
     3005      </p>
     3006      <p id="rfc.section.A.2.p.13">Chunk length does not include the count of the octets in the chunk header and trailer. Use of chunk extensions is deprecated,
     3007         and line folding in them is disallowed. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section&nbsp;4.1</a>)
     3008      </p>
     3009      <p id="rfc.section.A.2.p.14">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section&nbsp;4.2.2</a>)
     3010      </p>
     3011      <p id="rfc.section.A.2.p.15">The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808.
     3012         The asterisk-form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section&nbsp;5.3</a>)
     3013      </p>
     3014      <p id="rfc.section.A.2.p.16">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section&nbsp;5.5</a>)
     3015      </p>
     3016      <p id="rfc.section.A.2.p.17">Gateways do not need to generate <a href="#header.via" class="smpl">Via</a> header fields anymore. (<a href="#header.via" id="rfc.xref.header.via.2" title="Via">Section&nbsp;5.7.1</a>)
     3017      </p>
     3018      <p id="rfc.section.A.2.p.18">Exactly when "close" connection options have to be sent has been clarified. Also, "hop-by-hop" header fields are required
     3019         to appear in the Connection header field; just because they're defined as hop-by-hop in this specification doesn't exempt
     3020         them. (<a href="#header.connection" id="rfc.xref.header.connection.8" title="Connection">Section&nbsp;6.1</a>)
     3021      </p>
     3022      <p id="rfc.section.A.2.p.19">The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried.
     3023         The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed.
     3024         Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistence">Section&nbsp;6.3</a>)
     3025      </p>
     3026      <p id="rfc.section.A.2.p.20">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). Furthermore, the ordering in the field value is now significant. (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section&nbsp;6.7</a>)
     3027      </p>
     3028      <p id="rfc.section.A.2.p.21">Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section&nbsp;7</a>)
     3029      </p>
     3030      <p id="rfc.section.A.2.p.22">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;8.4</a>)
     3031      </p>
     3032      <p id="rfc.section.A.2.p.23">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;8.5</a>)
     3033      </p>
     3034      <p id="rfc.section.A.2.p.24">The expectation to support HTTP/0.9 requests has been removed. (<a href="#compatibility" title="HTTP Version History">Appendix&nbsp;A</a>)
     3035      </p>
     3036      <p id="rfc.section.A.2.p.25">Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged
    30523037         altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix&nbsp;A.1.2</a>)
    3053       </p>
    3054       <p id="rfc.section.A.2.p.38">Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Section&nbsp;7</a>)
    30553038      </p>
    30563039      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
     
    32963279                  <li>chunked (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.6">3.3.1</a>, <a href="#rfc.iref.c.8">3.3.3</a>, <a href="#rfc.iref.c.9"><b>4.1</b></a></li>
    32973280                  <li>client&nbsp;&nbsp;<a href="#rfc.iref.c.1"><b>2.1</b></a></li>
    3298                   <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a>, <a href="#rfc.xref.header.connection.9">A.2</a></li>
     3281                  <li>close&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.12"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.14">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a></li>
    32993282                  <li>compress (Coding Format)&nbsp;&nbsp;<a href="#rfc.iref.c.10">4.2.1</a></li>
    33003283                  <li>connection&nbsp;&nbsp;<a href="#rfc.iref.c.2"><b>2.1</b></a></li>
    3301                   <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a>, <a href="#rfc.xref.header.connection.9">A.2</a></li>
     3284                  <li>Connection header field&nbsp;&nbsp;<a href="#rfc.xref.header.connection.1">3.2.1</a>, <a href="#rfc.xref.header.connection.2">4.3</a>, <a href="#rfc.xref.header.connection.3">5.7</a>, <a href="#rfc.iref.c.11"><b>6.1</b></a>, <a href="#rfc.xref.persistent.tear-down.1">6.1</a>, <a href="#rfc.xref.persistent.tear-down.2">6.3.2</a>, <a href="#rfc.iref.c.13">6.6</a>, <a href="#rfc.xref.header.connection.4">6.6</a>, <a href="#rfc.xref.header.connection.5">6.7</a>, <a href="#rfc.xref.header.connection.6">8.1</a>, <a href="#rfc.xref.header.connection.7">8.1</a>, <a href="#rfc.xref.header.connection.8">A.2</a></li>
    33023285                  <li>Content-Length header field&nbsp;&nbsp;<a href="#rfc.iref.c.7"><b>3.3.2</b></a>, <a href="#rfc.xref.header.content-length.1">8.1</a>, <a href="#rfc.xref.header.content-length.2">A.2</a></li>
    33033286               </ul>
Note: See TracChangeset for help on using the changeset viewer.