Changeset 1760 for draft-ietf-httpbis
- Timestamp:
- 11/07/12 15:40:04 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1756 r1760 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 1, 2013";451 content: "Expires January 12, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 0">493 <meta name="dct.issued" scheme="ISO8601" content="2012-07-11"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: January 1 1, 2013</td>525 <td class="left">Expires: January 12, 2013</td> 526 526 <td class="right">greenbytes</td> 527 527 </tr> 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">July 1 0, 2012</td>530 <td class="right">July 11, 2012</td> 531 531 </tr> 532 532 </tbody> … … 561 561 in progress”. 562 562 </p> 563 <p>This Internet-Draft will expire on January 1 1, 2013.</p>563 <p>This Internet-Draft will expire on January 12, 2013.</p> 564 564 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 565 565 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 3004 3004 <p id="rfc.section.A.2.p.15">Define the semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field 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>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.2" title="Upgrade">Section 6.5</a>) 3005 3005 </p> 3006 <p id="rfc.section.A.2.p.16">Take over 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 7.6</a>) 3007 </p> 3006 3008 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 3007 3009 <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS … … 3534 3536 </li> 3535 3537 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 3538 </li> 3539 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>>: "note introduction of new IANA registries as normative changes" 3536 3540 </li> 3537 3541 </ul> … … 3813 3817 </ul> 3814 3818 </li> 3815 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a> <ul>3816 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7.6</a> </li>3819 <li><em>RFC2817</em> <a href="#rfc.xref.RFC2817.1">§</a>, <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#RFC2817"><b>10.2</b></a>, <a href="#rfc.xref.RFC2817.3">A.2</a>, <a href="#rfc.xref.RFC2817.4">A.2</a><ul> 3820 <li><em>Section 7.2</em> <a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#rfc.xref.RFC2817.4">A.2</a></li> 3817 3821 </ul> 3818 3822 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1750 r1760 5045 5045 (<xref target="header.upgrade"/>) 5046 5046 </t> 5047 <t> 5048 Take over the Upgrade Token Registry, previously defined in 5049 <xref target="RFC2817" x:fmt="of" x:sec="7.2"/>. 5050 (<xref target="upgrade.token.registry"/>) 5051 </t> 5047 5052 </section> 5048 5053 </section> … … 5983 5988 "ABNF requirements for recipients" 5984 5989 </t> 5990 <t> 5991 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>: 5992 "note introduction of new IANA registries as normative changes" 5993 </t> 5985 5994 </list> 5986 5995 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1756 r1760 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 1, 2013";451 content: "Expires January 12, 2013"; 452 452 } 453 453 @bottom-right { … … 497 497 <meta name="dct.creator" content="Reschke, J. F."> 498 498 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 0">499 <meta name="dct.issued" scheme="ISO8601" content="2012-07-11"> 500 500 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 501 501 <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 "HTTP/1.1" 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."> … … 528 528 </tr> 529 529 <tr> 530 <td class="left">Expires: January 1 1, 2013</td>530 <td class="left">Expires: January 12, 2013</td> 531 531 <td class="right">greenbytes</td> 532 532 </tr> 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">July 1 0, 2012</td>535 <td class="right">July 11, 2012</td> 536 536 </tr> 537 537 </tbody> … … 563 563 in progress”. 564 564 </p> 565 <p>This Internet-Draft will expire on January 1 1, 2013.</p>565 <p>This Internet-Draft will expire on January 12, 2013.</p> 566 566 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 567 567 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 3937 3937 </p> 3938 3938 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <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 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 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 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 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 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 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 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 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 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 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 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 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 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 3952 3954 user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite 3953 3955 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>) 3954 3956 </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 through3957 <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 3956 3958 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. 3957 3959 (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 4.5.5</a>) 3958 3960 </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 4.6.15</a>)3960 </p> 3961 <p id="rfc.section.C.p.1 0">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3962 </p> 3963 <p id="rfc.section.C.p.1 1">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 contents3961 <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 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 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 3964 3966 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 9.5</a>) 3965 3967 </p> 3966 <p id="rfc.section.C.p.1 2">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 trailing3968 <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 3967 3969 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 9.11</a>) 3968 3970 </p> 3969 <p id="rfc.section.C.p.1 3">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't3971 <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 3970 3972 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 9.13</a>) 3971 3973 </p> 3972 <p id="rfc.section.C.p.1 4">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 9.14</a>)3973 </p> 3974 <p id="rfc.section.C.p.1 5">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 9.15</a>)3975 </p> 3976 <p id="rfc.section.C.p.1 6">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 9.17</a>)3977 </p> 3978 <p id="rfc.section.C.p.1 7">Clarify contexts that charset is used in. (<a href="#character.sets" title="Character Encodings (charset)">Section 5.3</a>)3979 </p> 3980 <p id="rfc.section.C.p.1 8">Registration of Content Codings now requires IETF Review (<a href="#content.coding.registry" title="Content Coding Registry">Section 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 definition3974 <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 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 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 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 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 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 3983 3985 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 5.5.1</a>) 3984 3986 </p> 3985 <p id="rfc.section.C.p.2 0">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 9</a>)3986 </p> 3987 <p id="rfc.section.C.p.2 1">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 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, 3988 3990 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 9</a>) 3989 3991 </p> 3990 <p id="rfc.section.C.p.2 2">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 9.2</a>)3991 </p> 3992 <p id="rfc.section.C.p.2 3">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 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, 3993 3995 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 9.8</a>) 3994 3996 </p> 3995 <p id="rfc.section.C.p.2 4">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 A.5</a>)3996 </p> 3997 <p id="rfc.section.C.p.2 5">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 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 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 B</a>) 3998 4000 </p> 3999 4001 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 4713 4715 </li> 4714 4716 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/364">http://tools.ietf.org/wg/httpbis/trac/ticket/364</a>>: "Capturing more information in the method registry" 4717 </li> 4718 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>>: "note introduction of new IANA registries as normative changes" 4715 4719 </li> 4716 4720 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1742 r1760 5480 5480 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 5481 5481 <t> 5482 Introduce Method Registry. 5483 (<xref target="method.registry"/>) 5484 </t> 5485 <t> 5482 5486 Clarify definition of POST. 5483 5487 (<xref target="POST"/>) … … 5493 5497 </t> 5494 5498 <t> 5495 T his document takes over the Status Code Registry, previously defined5496 in<xref target="RFC2817" x:fmt="of" x:sec="7.1"/>.5499 Take over the Status Code Registry, previously defined in 5500 <xref target="RFC2817" x:fmt="of" x:sec="7.1"/>. 5497 5501 (<xref target="status.code.registry"/>) 5498 5502 </t> … … 6893 6897 "Capturing more information in the method registry" 6894 6898 </t> 6899 <t> 6900 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>: 6901 "note introduction of new IANA registries as normative changes" 6902 </t> 6895 6903 </list> 6896 6904 </t> -
draft-ietf-httpbis/latest/p5-range.html
r1756 r1760 449 449 } 450 450 @bottom-center { 451 content: "Expires January 1 1, 2013";451 content: "Expires January 12, 2013"; 452 452 } 453 453 @bottom-right { … … 492 492 <meta name="dct.creator" content="Reschke, J. F."> 493 493 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 0">494 <meta name="dct.issued" scheme="ISO8601" content="2012-07-11"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 496 496 <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 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests."> … … 518 518 </tr> 519 519 <tr> 520 <td class="left">Expires: January 1 1, 2013</td>520 <td class="left">Expires: January 12, 2013</td> 521 521 <td class="right">J. Reschke, Editor</td> 522 522 </tr> … … 527 527 <tr> 528 528 <td class="left"></td> 529 <td class="right">July 1 0, 2012</td>529 <td class="right">July 11, 2012</td> 530 530 </tr> 531 531 </tbody> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on January 1 1, 2013.</p>557 <p>This Internet-Draft will expire on January 12, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1282 1282 </ol> 1283 1283 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 1284 <p id="rfc.section.B.p.1">Clarify that it is not ok to use a weak validator in a <a href="#status.206" class="smpl">206</a> response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 3.1</a>) 1285 </p> 1286 <p id="rfc.section.B.p.2">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 5</a>) 1287 </p> 1288 <p id="rfc.section.B.p.3">Clarify that multipart/byteranges can consist of a single part. (<a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>) 1284 <p id="rfc.section.B.p.1">Introduce Range Specifier Registry. (<a href="#range.specifier.registry" title="Range Specifier Registry">Section 2.1</a>) 1285 </p> 1286 <p id="rfc.section.B.p.2">Clarify that it is not ok to use a weak validator in a <a href="#status.206" class="smpl">206</a> response. (<a href="#status.206" id="rfc.xref.status.206.2" title="206 Partial Content">Section 3.1</a>) 1287 </p> 1288 <p id="rfc.section.B.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 5</a>) 1289 </p> 1290 <p id="rfc.section.B.p.4">Clarify that multipart/byteranges can consist of a single part. (<a href="#internet.media.type.multipart.byteranges" title="Internet Media Type multipart/byteranges">Appendix A</a>) 1289 1291 </p> 1290 1292 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1492 1494 </li> 1493 1495 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/367">http://tools.ietf.org/wg/httpbis/trac/ticket/367</a>>: "reserve 'none' as byte range unit" 1496 </li> 1497 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>>: "note introduction of new IANA registries as normative changes" 1494 1498 </li> 1495 1499 </ul> -
draft-ietf-httpbis/latest/p5-range.xml
r1749 r1760 1386 1386 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 1387 1387 <t> 1388 Introduce Range Specifier Registry. 1389 (<xref target="range.specifier.registry"/>) 1390 </t> 1391 <t> 1388 1392 Clarify that it is not ok to use a weak validator in a <x:ref>206</x:ref> response. 1389 1393 (<xref target="status.206"/>) … … 1763 1767 "reserve 'none' as byte range unit" 1764 1768 </t> 1769 <t> 1770 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>: 1771 "note introduction of new IANA registries as normative changes" 1772 </t> 1765 1773 </list> 1766 1774 </t> -
draft-ietf-httpbis/latest/p6-cache.html
r1755 r1760 452 452 } 453 453 @bottom-center { 454 content: "Expires January 1 1, 2013";454 content: "Expires January 12, 2013"; 455 455 } 456 456 @bottom-right { … … 498 498 <meta name="dct.creator" content="Reschke, J. F."> 499 499 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 500 <meta name="dct.issued" scheme="ISO8601" content="2012-07-1 0">500 <meta name="dct.issued" scheme="ISO8601" content="2012-07-11"> 501 501 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 502 502 <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 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 524 524 </tr> 525 525 <tr> 526 <td class="left">Expires: January 1 1, 2013</td>526 <td class="left">Expires: January 12, 2013</td> 527 527 <td class="right">M. Nottingham, Editor</td> 528 528 </tr> … … 541 541 <tr> 542 542 <td class="left"></td> 543 <td class="right">July 1 0, 2012</td>543 <td class="right">July 11, 2012</td> 544 544 </tr> 545 545 </tbody> … … 571 571 in progress”. 572 572 </p> 573 <p>This Internet-Draft will expire on January 1 1, 2013.</p>573 <p>This Internet-Draft will expire on January 12, 2013.</p> 574 574 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 575 575 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1985 1985 <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in <a href="#header.warning" class="smpl">Warning</a> header fields anymore, as these aspects never were implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section 7.6</a>) 1986 1986 </p> 1987 <p id="rfc.section.A.p.6">Introduce Cache Directive and Warn Code Registries. (<a href="#cache.control.extensions" title="Cache Control Extensions">Section 7.2.3</a> and <a href="#warn.code.extensions" title="Warn Code Extensions">Section 7.6.8</a>) 1988 </p> 1987 1989 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> 1988 1990 <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds … … 2054 2056 </li> 2055 2057 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 2058 </li> 2059 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>>: "note introduction of new IANA registries as normative changes" 2056 2060 </li> 2057 2061 </ul> -
draft-ietf-httpbis/latest/p6-cache.xml
r1755 r1760 2578 2578 (<xref target="header.warning" />) 2579 2579 </t> 2580 <t> 2581 Introduce Cache Directive and Warn Code Registries. 2582 (<xref target="cache.control.extensions"/> and <xref target="warn.code.extensions"/>) 2583 </t> 2580 2584 </section> 2581 2585 … … 2674 2678 "ABNF requirements for recipients" 2675 2679 </t> 2680 <t> 2681 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>: 2682 "note introduction of new IANA registries as normative changes" 2683 </t> 2676 2684 </list> 2677 2685 </t> -
draft-ietf-httpbis/latest/p7-auth.html
r1759 r1760 1101 1101 (<a href="#access.authentication.framework" title="Access Authentication Framework">Section 2</a>) 1102 1102 </p> 1103 <p id="rfc.section.A.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 4</a>) 1103 <p id="rfc.section.A.p.3">Introduce Authentication Scheme Registry. (<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section 2.3</a>) 1104 </p> 1105 <p id="rfc.section.A.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 4</a>) 1104 1106 </p> 1105 1107 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 1149 1151 </li> 1150 1152 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>>: "ABNF requirements for recipients" 1153 </li> 1154 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/368">http://tools.ietf.org/wg/httpbis/trac/ticket/368</a>>: "note introduction of new IANA registries as normative changes" 1151 1155 </li> 1152 1156 </ul> -
draft-ietf-httpbis/latest/p7-auth.xml
r1759 r1760 1126 1126 </t> 1127 1127 <t> 1128 Introduce Authentication Scheme Registry. 1129 (<xref target="authentication.scheme.registry"/>) 1130 </t> 1131 <t> 1128 1132 Change ABNF productions for header fields to only define the field value. 1129 1133 (<xref target="header.field.definitions"/>) … … 1198 1202 "ABNF requirements for recipients" 1199 1203 </t> 1204 <t> 1205 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/368"/>: 1206 "note introduction of new IANA registries as normative changes" 1207 </t> 1200 1208 </list> 1201 1209 </t>
Note: See TracChangeset
for help on using the changeset viewer.