Ignore:
Timestamp:
11/07/12 15:40:04 (10 years ago)
Author:
julian.reschke@…
Message:

Note changes/introductions to IANA registries as changes from RFC 2616 (see #368)

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r1756 r1760  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 11, 2013";
     451       content: "Expires January 12, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    497497      <meta name="dct.creator" content="Reschke, J. F.">
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-07-10">
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-07-11">
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    501501      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
    … …  
    528528            </tr>
    529529            <tr>
    530                <td class="left">Expires: January 11, 2013</td>
     530               <td class="left">Expires: January 12, 2013</td>
    531531               <td class="right">greenbytes</td>
    532532            </tr>
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">July 10, 2012</td>
     535               <td class="right">July 11, 2012</td>
    536536            </tr>
    537537         </tbody>
    … …  
    563563         in progress”.
    564564      </p>
    565       <p>This Internet-Draft will expire on January 11, 2013.</p>
     565      <p>This Internet-Draft will expire on January 12, 2013.</p>
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    39373937      </p>
    39383938      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1>
    3939       <p id="rfc.section.C.p.1">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;2.3.4</a>)
    3940       </p>
    3941       <p id="rfc.section.C.p.2">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;2.3.5</a>)
    3942       </p>
    3943       <p id="rfc.section.C.p.3">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;2.3.8</a>)
    3944       </p>
    3945       <p id="rfc.section.C.p.4">This document takes over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a>)
    3946       </p>
    3947       <p id="rfc.section.C.p.5">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.4.4</a>)
    3948       </p>
    3949       <p id="rfc.section.C.p.6">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;4.5</a>)
    3950       </p>
    3951       <p id="rfc.section.C.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
     3939      <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;2.2</a>)
     3940      </p>
     3941      <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.2" title="POST">Section&nbsp;2.3.4</a>)
     3942      </p>
     3943      <p id="rfc.section.C.p.3">Remove requirement to handle all Content-* header fields; ban use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> with PUT. (<a href="#PUT" id="rfc.xref.PUT.2" title="PUT">Section&nbsp;2.3.5</a>)
     3944      </p>
     3945      <p id="rfc.section.C.p.4">Take over definition of CONNECT method from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.2" title="CONNECT">Section&nbsp;2.3.8</a>)
     3946      </p>
     3947      <p id="rfc.section.C.p.5">Take over the Status Code Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.2</a>)
     3948      </p>
     3949      <p id="rfc.section.C.p.6">Broadened the definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;4.4.4</a>)
     3950      </p>
     3951      <p id="rfc.section.C.p.7">Status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a>: removed the normative requirements on both response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section&nbsp;4.5</a>)
     3952      </p>
     3953      <p id="rfc.section.C.p.8">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
    39523954         user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite
    39533955         the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">4.5.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">4.5.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">4.5.7</a>)
    39543956      </p>
    3955       <p id="rfc.section.C.p.8">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through
     3957      <p id="rfc.section.C.p.9">Deprecate <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code, because user agents did not implement it. It used to indicate that the target resource needs to be accessed through
    39563958         the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The Location field gave the URI of the proxy. The recipient was expected to repeat this single request via the proxy.
    39573959         (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;4.5.5</a>)
    39583960      </p>
    3959       <p id="rfc.section.C.p.9">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
    3960       </p>
    3961       <p id="rfc.section.C.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    3962       </p>
    3963       <p id="rfc.section.C.p.11">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents
     3961      <p id="rfc.section.C.p.10">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;4.6.15</a>)
     3962      </p>
     3963      <p id="rfc.section.C.p.11">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
     3964      </p>
     3965      <p id="rfc.section.C.p.12">Reclassify "<a href="#header.allow" class="smpl">Allow</a>" as response header field, removing the option to specify it in a PUT request. Relax the server requirement on the contents
    39643966         of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.5</a>)
    39653967      </p>
    3966       <p id="rfc.section.C.p.12">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing
     3968      <p id="rfc.section.C.p.13">The ABNF for the <a href="#header.expect" class="smpl">Expect</a> header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing
    39673969         semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.11</a>)
    39683970      </p>
    3969       <p id="rfc.section.C.p.13">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't
     3971      <p id="rfc.section.C.p.14">Correct syntax of <a href="#header.location" class="smpl">Location</a> header field to allow URI references (including relative references and fragments), as referred symbol "absoluteURI" wasn't
    39703972         what was expected, and add some clarifications as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.13</a>)
    39713973      </p>
    3972       <p id="rfc.section.C.p.14">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.14</a>)
    3973       </p>
    3974       <p id="rfc.section.C.p.15">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.15</a>)
    3975       </p>
    3976       <p id="rfc.section.C.p.16">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.17</a>)
    3977       </p>
    3978       <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;5.3</a>)
    3979       </p>
    3980       <p id="rfc.section.C.p.18">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;5.4.1</a>)
    3981       </p>
    3982       <p id="rfc.section.C.p.19">Remove the default character encoding of "ISO-8859-1" for text media types; the default now is whatever the media type definition
     3974      <p id="rfc.section.C.p.15">Restrict <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.14</a>)
     3975      </p>
     3976      <p id="rfc.section.C.p.16">Allow <a href="#header.referer" class="smpl">Referer</a> field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.15</a>)
     3977      </p>
     3978      <p id="rfc.section.C.p.17">In the description of the <a href="#header.server" class="smpl">Server</a> header field, the <a href="p1-messaging.html#header.via" class="smpl">Via</a> field was described as a SHOULD. The requirement was and is stated correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 6.2</a> of <a href="#Part1" id="rfc.xref.Part1.59"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.17</a>)
     3979      </p>
     3980      <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;5.3</a>)
     3981      </p>
     3982      <p id="rfc.section.C.p.19">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;5.4.1</a>)
     3983      </p>
     3984      <p id="rfc.section.C.p.20">Remove the default character encoding of "ISO-8859-1" for text media types; the default now is whatever the media type definition
    39833985         says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;5.5.1</a>)
    39843986      </p>
    3985       <p id="rfc.section.C.p.20">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    3986       </p>
    3987       <p id="rfc.section.C.p.21">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,
     3987      <p id="rfc.section.C.p.21">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
     3988      </p>
     3989      <p id="rfc.section.C.p.22">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,
    39883990         and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    39893991      </p>
    3990       <p id="rfc.section.C.p.22">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;9.2</a>)
    3991       </p>
    3992       <p id="rfc.section.C.p.23">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
     3992      <p id="rfc.section.C.p.23">Remove ISO-8859-1 special-casing in <a href="#header.accept-charset" class="smpl">Accept-Charset</a>. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section&nbsp;9.2</a>)
     3993      </p>
     3994      <p id="rfc.section.C.p.24">Remove base URI setting semantics for <a href="#header.content-location" class="smpl">Content-Location</a> due to poor implementation support, which was caused by too many broken servers emitting bogus Content-Location header fields,
    39933995         and also the potentially undesirable effect of potentially breaking relative links in content-negotiated resources. (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section&nbsp;9.8</a>)
    39943996      </p>
    3995       <p id="rfc.section.C.p.24">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
    3996       </p>
    3997       <p id="rfc.section.C.p.25">Remove discussion of Content-Disposition header field, it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix&nbsp;B</a>)
     3997      <p id="rfc.section.C.p.25">Remove reference to non-existant identity transfer-coding value tokens. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix&nbsp;A.5</a>)
     3998      </p>
     3999      <p id="rfc.section.C.p.26">Remove discussion of Content-Disposition header field, it is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix&nbsp;B</a>)
    39984000      </p>
    39994001      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    47134715         </li>
    47144716         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/364">http://tools.ietf.org/wg/httpbis/trac/ticket/364</a>&gt;: "Capturing more information in the method registry"
     4717         </li>
     4718         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>&gt;: "note introduction of new IANA registries as normative changes"
    47154719         </li>
    47164720      </ul>
Note: See TracChangeset for help on using the changeset viewer.