Ignore:
Timestamp:
13/09/12 11:44:49 (8 years ago)
Author:
julian.reschke@…
Message:

Cleanup "Changes from RFC 2616" sections.

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r1890 r1891  
    449449  }
    450450  @bottom-center {
    451        content: "Expires March 16, 2013";
     451       content: "Expires March 17, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2012-09-12">
     500      <meta name="dct.issued" scheme="ISO8601" content="2012-09-13">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
    … …  
    529529            </tr>
    530530            <tr>
    531                <td class="left">Expires: March 16, 2013</td>
     531               <td class="left">Expires: March 17, 2013</td>
    532532               <td class="right">greenbytes</td>
    533533            </tr>
    534534            <tr>
    535535               <td class="left"></td>
    536                <td class="right">September 12, 2012</td>
     536               <td class="right">September 13, 2012</td>
    537537            </tr>
    538538         </tbody>
    … …  
    561561         in progress”.
    562562      </p>
    563       <p>This Internet-Draft will expire on March 16, 2013.</p>
     563      <p>This Internet-Draft will expire on March 17, 2013.</p>
    564564      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    565565      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    42154215      </p>
    42164216      <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>
    4217       <p id="rfc.section.C.p.1">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;10.1</a>)
     4217      <p id="rfc.section.C.p.1">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,
     4218         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;3.2.4</a>)
    42184219      </p>
    42194220      <p id="rfc.section.C.p.2">Clarify definition of POST. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section&nbsp;5.3.3</a>)
    … …  
    42234224      <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.3" title="CONNECT">Section&nbsp;5.3.6</a>)
    42244225      </p>
    4225       <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;10.2</a>)
    4226       </p>
    4227       <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;7.3.4</a>)
    4228       </p>
    4229       <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;7.4</a>)
    4230       </p>
    4231       <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
     4226      <p id="rfc.section.C.p.5">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;6.1.1</a>)
     4227      </p>
     4228      <p id="rfc.section.C.p.6">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
     4229         semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;6.1.2</a>)
     4230      </p>
     4231      <p id="rfc.section.C.p.7">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;6.3.3</a>)
     4232      </p>
     4233      <p id="rfc.section.C.p.8">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;6.5.2</a>)
     4234      </p>
     4235      <p id="rfc.section.C.p.9">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;7.3.4</a>)
     4236      </p>
     4237      <p id="rfc.section.C.p.10">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;7.4</a>)
     4238      </p>
     4239      <p id="rfc.section.C.p.11">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
    42324240         user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite
    42334241         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">7.4.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.4.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.4.7</a>)
    42344242      </p>
    4235       <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
     4243      <p id="rfc.section.C.p.12">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
    42364244         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.
    42374245         (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;7.4.5</a>)
    42384246      </p>
    4239       <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;7.5.15</a>)
    4240       </p>
    4241       <p id="rfc.section.C.p.11">Change ABNF productions for header fields to only define the field value.</p>
    4242       <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
     4247      <p id="rfc.section.C.p.13">Define status <a href="#status.426" class="smpl">426 (Upgrade Required)</a> (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><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;7.5.15</a>)
     4248      </p>
     4249      <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
     4250         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;8.1.1</a>)
     4251      </p>
     4252      <p id="rfc.section.C.p.15">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
    42434253         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;8.4.1</a>)
    42444254      </p>
    4245       <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
    4246          semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;6.1.2</a>)
    4247       </p>
    4248       <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
    4249          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;8.1.1</a>)
    4250       </p>
    4251       <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;6.1.1</a>)
    4252       </p>
    4253       <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;6.5.2</a>)
    4254       </p>
    4255       <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 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
    4256       </p>
    4257       <p id="rfc.section.C.p.18">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;9.3</a>)
     4255      <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
     4256         in <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;8.4.2</a>)
     4257      </p>
     4258      <p id="rfc.section.C.p.17">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section&nbsp;9.3</a>)
     4259      </p>
     4260      <p id="rfc.section.C.p.18">Remove the default character encoding of "ISO-8859-1" for text media types; the default now is whatever the media type definition
     4261         says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;9.5.1</a>)
    42584262      </p>
    42594263      <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;10.4</a>)
    42604264      </p>
    4261       <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
    4262          says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;9.5.1</a>)
    4263       </p>
    4264       <p id="rfc.section.C.p.21">Change ABNF productions for header fields to only define the field value.</p>
    4265       <p id="rfc.section.C.p.22">Remove definition of Content-MD5 header field because it was inconsistently implemented with respect to partial responses,
     4265      <p id="rfc.section.C.p.20">Remove definition of "Content-MD5 header" field because it was inconsistently implemented with respect to partial responses,
    42664266         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).
    42674267      </p>
    4268       <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;6.3.3</a>)
    4269       </p>
    4270       <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,
    4271          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;3.2.4</a>)
    4272       </p>
    4273       <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>)
    4274       </p>
    4275       <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>)
     4268      <p id="rfc.section.C.p.21">Introduce Method Registry. (<a href="#method.registry" title="Method Registry">Section&nbsp;10.1</a>)
     4269      </p>
     4270      <p id="rfc.section.C.p.22">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.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section&nbsp;10.2</a>)
     4271      </p>
     4272      <p id="rfc.section.C.p.23">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>)
     4273      </p>
     4274      <p id="rfc.section.C.p.24">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>)
    42764275      </p>
    42774276      <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a>&nbsp;<a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1>
    … …  
    53875386                  </li>
    53885387                  <li><em>RFC2817</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#RFC2817"><b>13.2</b></a>, <a href="#rfc.xref.RFC2817.2">C</a>, <a href="#rfc.xref.RFC2817.3">C</a>, <a href="#rfc.xref.RFC2817.4">C</a><ul>
    5389                         <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#rfc.xref.RFC2817.3">C</a></li>
     5388                        <li><em>Section 7.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.1">10.2</a>, <a href="#rfc.xref.RFC2817.4">C</a></li>
    53905389                     </ul>
    53915390                  </li>
Note: See TracChangeset for help on using the changeset viewer.