Changeset 1760 for draft-ietf-httpbis


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

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

Location:
draft-ietf-httpbis/latest
Files:
10 edited

Legend:

Unmodified
Added
Removed

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

    r1756 r1760  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 11, 2013";
     451       content: "Expires January 12, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2012-07-10">
     493      <meta name="dct.issued" scheme="ISO8601" content="2012-07-11">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    … …  
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: January 11, 2013</td>
     525               <td class="left">Expires: January 12, 2013</td>
    526526               <td class="right">greenbytes</td>
    527527            </tr>
    528528            <tr>
    529529               <td class="left"></td>
    530                <td class="right">July 10, 2012</td>
     530               <td class="right">July 11, 2012</td>
    531531            </tr>
    532532         </tbody>
    … …  
    561561         in progress”.
    562562      </p>
    563       <p>This Internet-Draft will expire on January 11, 2013.</p>
     563      <p>This Internet-Draft will expire on January 12, 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>
    … …  
    30043004      <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&nbsp;6.5</a>)
    30053005      </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&nbsp;7.6</a>)
     3007      </p>
    30063008      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    30073009      <div id="rfc.figure.u.67"></div> <pre class="inline"><a href="#rule.whitespace" class="smpl">BWS</a> = OWS
    … …  
    35343536         </li>
    35353537         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>&gt;: "ABNF requirements for recipients"
     3538         </li>
     3539         <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"
    35363540         </li>
    35373541      </ul>
    … …  
    38133817                     </ul>
    38143818                  </li>
    3815                   <li><em>RFC2817</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">7.6</a></li>
     3819                  <li><em>RFC2817</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a href="#rfc.xref.RFC2817.2">7.6</a>, <a href="#rfc.xref.RFC2817.4">A.2</a></li>
    38173821                     </ul>
    38183822                  </li>

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

    r1750 r1760  
    50455045  (<xref target="header.upgrade"/>)
    50465046</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>
    50475052</section>
    50485053</section>
    … …  
    59835988      "ABNF requirements for recipients"
    59845989    </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>
    59855994  </list>
    59865995</t>

  • 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>

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

    r1742 r1760  
    54805480<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    54815481<t>
     5482  Introduce Method Registry.
     5483  (<xref target="method.registry"/>)
     5484</t>
     5485<t>
    54825486  Clarify definition of POST.
    54835487  (<xref target="POST"/>)
    … …  
    54935497</t>
    54945498<t>
    5495   This document takes over the Status Code Registry, previously defined
    5496   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"/>.
    54975501  (<xref target="status.code.registry"/>)
    54985502</t>
    … …  
    68936897      "Capturing more information in the method registry"
    68946898    </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>
    68956903  </list>
    68966904</t>

  • draft-ietf-httpbis/latest/p5-range.html

    r1756 r1760  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 11, 2013";
     451       content: "Expires January 12, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    492492      <meta name="dct.creator" content="Reschke, J. F.">
    493493      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    494       <meta name="dct.issued" scheme="ISO8601" content="2012-07-10">
     494      <meta name="dct.issued" scheme="ISO8601" content="2012-07-11">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    496496      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
    … …  
    518518            </tr>
    519519            <tr>
    520                <td class="left">Expires: January 11, 2013</td>
     520               <td class="left">Expires: January 12, 2013</td>
    521521               <td class="right">J. Reschke, Editor</td>
    522522            </tr>
    … …  
    527527            <tr>
    528528               <td class="left"></td>
    529                <td class="right">July 10, 2012</td>
     529               <td class="right">July 11, 2012</td>
    530530            </tr>
    531531         </tbody>
    … …  
    555555         in progress”.
    556556      </p>
    557       <p>This Internet-Draft will expire on January 11, 2013.</p>
     557      <p>This Internet-Draft will expire on January 12, 2013.</p>
    558558      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    559559      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    12821282      </ol>
    12831283      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<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&nbsp;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&nbsp;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&nbsp;A</a>)
     1284      <p id="rfc.section.B.p.1">Introduce Range Specifier Registry. (<a href="#range.specifier.registry" title="Range Specifier Registry">Section&nbsp;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&nbsp;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&nbsp;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&nbsp;A</a>)
    12891291      </p>
    12901292      <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    14921494         </li>
    14931495         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/367">http://tools.ietf.org/wg/httpbis/trac/ticket/367</a>&gt;: "reserve 'none' as byte range unit"
     1496         </li>
     1497         <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"
    14941498         </li>
    14951499      </ul>

  • draft-ietf-httpbis/latest/p5-range.xml

    r1749 r1760  
    13861386<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    13871387<t>
     1388  Introduce Range Specifier Registry.
     1389  (<xref target="range.specifier.registry"/>)
     1390</t>
     1391<t>
    13881392  Clarify that it is not ok to use a weak validator in a <x:ref>206</x:ref> response.
    13891393  (<xref target="status.206"/>)
    … …  
    17631767      "reserve 'none' as byte range unit"
    17641768    </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>
    17651773  </list>
    17661774</t>

  • draft-ietf-httpbis/latest/p6-cache.html

    r1755 r1760  
    452452  }
    453453  @bottom-center {
    454        content: "Expires January 11, 2013";
     454       content: "Expires January 12, 2013";
    455455  }
    456456  @bottom-right {
    … …  
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2012-07-10">
     500      <meta name="dct.issued" scheme="ISO8601" content="2012-07-11">
    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. 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 &#34;HTTP/1.1&#34; 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.">
    … …  
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: January 11, 2013</td>
     526               <td class="left">Expires: January 12, 2013</td>
    527527               <td class="right">M. Nottingham, Editor</td>
    528528            </tr>
    … …  
    541541            <tr>
    542542               <td class="left"></td>
    543                <td class="right">July 10, 2012</td>
     543               <td class="right">July 11, 2012</td>
    544544            </tr>
    545545         </tbody>
    … …  
    571571         in progress”.
    572572      </p>
    573       <p>This Internet-Draft will expire on January 11, 2013.</p>
     573      <p>This Internet-Draft will expire on January 12, 2013.</p>
    574574      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    575575      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    19851985      <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&nbsp;7.6</a>)
    19861986      </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&nbsp;7.2.3</a> and <a href="#warn.code.extensions" title="Warn Code Extensions">Section&nbsp;7.6.8</a>)
     1988      </p>
    19871989      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    19881990      <div id="rfc.figure.u.17"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds
    … …  
    20542056         </li>
    20552057         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>&gt;: "ABNF requirements for recipients"
     2058         </li>
     2059         <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"
    20562060         </li>
    20572061      </ul>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r1755 r1760  
    25782578  (<xref target="header.warning" />)
    25792579</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>
    25802584</section>
    25812585
    … …  
    26742678      "ABNF requirements for recipients"
    26752679    </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>
    26762684  </list>
    26772685</t>

  • draft-ietf-httpbis/latest/p7-auth.html

    r1759 r1760  
    11011101         (<a href="#access.authentication.framework" title="Access Authentication Framework">Section&nbsp;2</a>)
    11021102      </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&nbsp;4</a>)
     1103      <p id="rfc.section.A.p.3">Introduce Authentication Scheme Registry. (<a href="#authentication.scheme.registry" title="Authentication Scheme Registry">Section&nbsp;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&nbsp;4</a>)
    11041106      </p>
    11051107      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    11491151         </li>
    11501152         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/361">http://tools.ietf.org/wg/httpbis/trac/ticket/361</a>&gt;: "ABNF requirements for recipients"
     1153         </li>
     1154         <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"
    11511155         </li>
    11521156      </ul>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r1759 r1760  
    11261126</t>
    11271127<t>
     1128  Introduce Authentication Scheme Registry.
     1129  (<xref target="authentication.scheme.registry"/>)
     1130</t>
     1131<t>
    11281132  Change ABNF productions for header fields to only define the field value.
    11291133  (<xref target="header.field.definitions"/>)
    … …  
    11981202      "ABNF requirements for recipients"
    11991203    </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>
    12001208  </list>
    12011209</t>
Note: See TracChangeset for help on using the changeset viewer.