Changeset 1567 for draft-ietf-httpbis/latest/p1-messaging.html
- Timestamp:
- 08/03/12 10:01:34 (10 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1566 r1567 460 460 } 461 461 @bottom-center { 462 content: "Expires September 8, 2012";462 content: "Expires September 9, 2012"; 463 463 } 464 464 @bottom-right { … … 510 510 <meta name="dct.creator" content="Reschke, J. F."> 511 511 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 512 <meta name="dct.issued" scheme="ISO8601" content="2012-03-0 7">512 <meta name="dct.issued" scheme="ISO8601" content="2012-03-08"> 513 513 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 514 514 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 542 542 </tr> 543 543 <tr> 544 <td class="left">Expires: September 8, 2012</td>544 <td class="left">Expires: September 9, 2012</td> 545 545 <td class="right">HP</td> 546 546 </tr> … … 595 595 <tr> 596 596 <td class="left"></td> 597 <td class="right">March 7, 2012</td>597 <td class="right">March 8, 2012</td> 598 598 </tr> 599 599 </tbody> … … 628 628 in progress”. 629 629 </p> 630 <p>This Internet-Draft will expire on September 8, 2012.</p>630 <p>This Internet-Draft will expire on September 9, 2012.</p> 631 631 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 632 632 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 801 801 </li> 802 802 <li>A.2 <a href="#changes.from.rfc.2616">Changes from RFC 2616</a></li> 803 <li>A.3 <a href="#changes.from.rfc.2817">Changes from RFC 2817</a></li> 803 804 </ul> 804 805 </li> … … 1880 1881 <p id="rfc.section.5.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="Content Codings">Section 2.2</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 5.2</a>). 1881 1882 </p> 1882 <p id="rfc.section.5.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in<a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section.1883 <p id="rfc.section.5.3.p.4">Values to be added to this name space require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. 1883 1884 </p> 1884 1885 <p id="rfc.section.5.3.p.5">The registry itself is maintained at <<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>>. … … 2365 2366 details how the connection will be processed after it has been upgraded. 2366 2367 </p> 2367 <p id="rfc.section.8.3.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrationsare subject to the following rules:2368 <p id="rfc.section.8.3.1.p.2">Registrations require IETF Review (see <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>) and are subject to the following rules: 2368 2369 </p> 2369 2370 <ol> … … 3091 3092 disallowed line folding in chunk extensions, and deprecate their use. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 5.1</a>) 3092 3093 </p> 3093 <p id="rfc.section.A.2.p.10">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent. 3094 <p id="rfc.section.A.2.p.10">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 5.3</a>) 3095 </p> 3096 <p id="rfc.section.A.2.p.11">Remove hard limit of two connections per server. Remove requirement to retry a sequence of requests as long it was idempotent. 3094 3097 Remove requirements about when servers are allowed to close connections prematurely. (<a href="#persistent.practical" title="Practical Considerations">Section 6.1.4</a>) 3095 3098 </p> 3096 <p id="rfc.section.A.2.p.11">Remove requirement to retry requests under certain cirumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section 6.2</a>) 3097 </p> 3098 <p id="rfc.section.A.2.p.12">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 8</a>) 3099 </p> 3100 <p id="rfc.section.A.2.p.13">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 8.1</a>) 3101 </p> 3102 <p id="rfc.section.A.2.p.14">Define the semantics of the "Upgrade" 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.3" title="Upgrade">Section 8.3</a>) 3099 <p id="rfc.section.A.2.p.12">Remove requirement to retry requests under certain cirumstances when the server prematurely closes the connection. (<a href="#message.transmission.requirements" title="Message Transmission Requirements">Section 6.2</a>) 3100 </p> 3101 <p id="rfc.section.A.2.p.13">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section 8</a>) 3102 </p> 3103 <p id="rfc.section.A.2.p.14">Clarify exactly when close connection options must be sent. (<a href="#header.connection" id="rfc.xref.header.connection.12" title="Connection">Section 8.1</a>) 3104 </p> 3105 <p id="rfc.section.A.2.p.15">Define the semantics of the "Upgrade" 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.3" title="Upgrade">Section 8.3</a>) 3106 </p> 3107 <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a> <a id="changes.from.rfc.2817" href="#changes.from.rfc.2817">Changes from RFC 2817</a></h2> 3108 <p id="rfc.section.A.3.p.1">Registration of Upgrade tokens now requires IETF Review (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 8.3.1</a>) 3103 3109 </p> 3104 3110 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 3614 3620 </li> 3615 3621 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/343">http://tools.ietf.org/wg/httpbis/trac/ticket/343</a>>: "chunk-extensions" 3622 </li> 3623 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/346">http://tools.ietf.org/wg/httpbis/trac/ticket/346</a>>: "make IANA policy definitions consistent" 3616 3624 </li> 3617 3625 </ul>
Note: See TracChangeset
for help on using the changeset viewer.