Changeset 2046 for draft-ietf-httpbis
- Timestamp:
- 09/12/12 15:44:14 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2045 r2046 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 1, 2013";451 content: "Expires June 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-12-0 8">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-09"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">December 8, 2012</td>522 <td class="right">December 9, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 1 1, 2013</td>525 <td class="left">Expires: June 12, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 1 1, 2013.</p>553 <p>This Internet-Draft will expire on June 12, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2102 2102 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1> 2103 2103 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 2104 <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry <a href="# RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a> maintained by IANA at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>.2104 <p id="rfc.section.7.1.p.1">HTTP header fields are registered within the Message Header Field Registry <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a> maintained by IANA at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>. 2105 2105 </p> 2106 2106 <p id="rfc.section.7.1.p.2">This document defines the following HTTP header fields, so their associated registry entries shall be updated according to … … 2204 2204 <p id="rfc.section.7.1.p.4">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p> 2205 2205 <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a> <a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2> 2206 <p id="rfc.section.7.2.p.1">IANA maintains the registry of URI Schemes <a href="# RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a> at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>>.2206 <p id="rfc.section.7.2.p.1">IANA maintains the registry of URI Schemes <a href="#BCP115" id="rfc.xref.BCP115.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[BCP115]</cite></a> at <<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>>. 2207 2207 </p> 2208 2208 <p id="rfc.section.7.2.p.2">This document defines the following URI schemes, so their associated registry entries shall be updated according to the permanent … … 2234 2234 <h2 id="rfc.section.7.3"><a href="#rfc.section.7.3">7.3</a> <a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registration</a></h2> 2235 2235 <p id="rfc.section.7.3.p.1">This document serves as the specification for the Internet media types "message/http" and "application/http". The following 2236 is to be registered with IANA (see <a href="# RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>).2236 is to be registered with IANA (see <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>). 2237 2237 </p> 2238 2238 <div id="rfc.iref.m.3"></div> … … 2641 2641 <table> 2642 2642 <tr> 2643 <td class="reference"><b id="BCP115">[BCP115]</b></td> 2644 <td class="top"><a href="mailto:tony+urireg@maillennium.att.com" title="AT&T Laboratories">Hansen, T.</a>, <a href="mailto:hardie@qualcomm.com" title="Qualcomm, Inc.">Hardie, T.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc4395">Guidelines and Registration Procedures for New URI Schemes</a>”, BCP 115, RFC 4395, February 2006. 2645 </td> 2646 </tr> 2647 <tr> 2648 <td class="reference"><b id="BCP13">[BCP13]</b></td> 2649 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005. 2650 </td> 2651 </tr> 2652 <tr> 2653 <td class="reference"><b id="BCP90">[BCP90]</b></td> 2654 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 2655 </td> 2656 </tr> 2657 <tr> 2643 2658 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> 2644 2659 <td class="top">International Organization for Standardization, “Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1”, ISO/IEC 8859-1:1998, 1998.</td> … … 2700 2715 </tr> 2701 2716 <tr> 2702 <td class="reference"><b id="RFC3864">[RFC3864]</b></td>2703 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004.2704 </td>2705 </tr>2706 <tr>2707 2717 <td class="reference"><b id="RFC4033">[RFC4033]</b></td> 2708 2718 <td class="top">Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “<a href="http://tools.ietf.org/html/rfc4033">DNS Security Introduction and Requirements</a>”, RFC 4033, March 2005. 2709 </td>2710 </tr>2711 <tr>2712 <td class="reference"><b id="RFC4288">[RFC4288]</b></td>2713 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005.2714 </td>2715 </tr>2716 <tr>2717 <td class="reference"><b id="RFC4395">[RFC4395]</b></td>2718 <td class="top"><a href="mailto:tony+urireg@maillennium.att.com" title="AT&T Laboratories">Hansen, T.</a>, <a href="mailto:hardie@qualcomm.com" title="Qualcomm, Inc.">Hardie, T.</a>, and <a href="mailto:LMM@acm.org" title="Adobe Systems">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc4395">Guidelines and Registration Procedures for New URI Schemes</a>”, BCP 115, RFC 4395, February 2006.2719 2719 </td> 2720 2720 </tr> … … 3100 3100 </li> 3101 3101 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 3102 <li><em>BCP115</em> <a href="#rfc.xref.BCP115.1">7.2</a>, <a href="#BCP115"><b>10.2</b></a></li> 3103 <li><em>BCP13</em> <a href="#rfc.xref.BCP13.1">7.3</a>, <a href="#BCP13"><b>10.2</b></a></li> 3104 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">7.1</a>, <a href="#BCP90"><b>10.2</b></a></li> 3102 3105 <li>browser <a href="#rfc.iref.b.1"><b>2.1</b></a></li> 3103 3106 </ul> … … 3342 3345 </li> 3343 3346 <li><em>RFC3040</em> <a href="#rfc.xref.RFC3040.1">2.3</a>, <a href="#RFC3040"><b>10.2</b></a></li> 3344 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">7.1</a>, <a href="#RFC3864"><b>10.2</b></a></li>3345 3347 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#rfc.xref.RFC3986.2">2.7</a>, <a href="#rfc.xref.RFC3986.3">2.7</a>, <a href="#rfc.xref.RFC3986.4">2.7</a>, <a href="#rfc.xref.RFC3986.5">2.7</a>, <a href="#rfc.xref.RFC3986.6">2.7</a>, <a href="#rfc.xref.RFC3986.7">2.7</a>, <a href="#rfc.xref.RFC3986.8">2.7</a>, <a href="#rfc.xref.RFC3986.9">2.7</a>, <a href="#rfc.xref.RFC3986.10">2.7</a>, <a href="#rfc.xref.RFC3986.11">2.7</a>, <a href="#rfc.xref.RFC3986.12">2.7.1</a>, <a href="#rfc.xref.RFC3986.13">2.7.1</a>, <a href="#rfc.xref.RFC3986.14">2.7.3</a>, <a href="#rfc.xref.RFC3986.15">2.7.3</a>, <a href="#rfc.xref.RFC3986.16">5.1</a>, <a href="#RFC3986"><b>10.1</b></a><ul> 3346 3348 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC3986.15">2.7.3</a></li> … … 3359 3361 </li> 3360 3362 <li><em>RFC4033</em> <a href="#rfc.xref.RFC4033.1">8.4</a>, <a href="#RFC4033"><b>10.2</b></a></li> 3361 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">7.3</a>, <a href="#RFC4288"><b>10.2</b></a></li>3362 <li><em>RFC4395</em> <a href="#rfc.xref.RFC4395.1">7.2</a>, <a href="#RFC4395"><b>10.2</b></a></li>3363 3363 <li><em>RFC4559</em> <a href="#rfc.xref.RFC4559.1">2.3</a>, <a href="#RFC4559"><b>10.2</b></a></li> 3364 3364 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">7.4</a>, <a href="#rfc.xref.RFC5226.2">7.6</a>, <a href="#RFC5226"><b>10.2</b></a><ul> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2045 r2046 3097 3097 <t> 3098 3098 HTTP header fields are registered within the Message Header Field Registry 3099 <xref target=" RFC3864"/> maintained by IANA at3099 <xref target="BCP90"/> maintained by IANA at 3100 3100 <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>. 3101 3101 </t> … … 3190 3190 <section title="URI Scheme Registration" anchor="uri.scheme.registration"> 3191 3191 <t> 3192 IANA maintains the registry of URI Schemes <xref target=" RFC4395"/> at3192 IANA maintains the registry of URI Schemes <xref target="BCP115"/> at 3193 3193 <eref target="http://www.iana.org/assignments/uri-schemes.html"/>. 3194 3194 </t> … … 3217 3217 This document serves as the specification for the Internet media types 3218 3218 "message/http" and "application/http". The following is to be registered with 3219 IANA (see <xref target=" RFC4288"/>).3219 IANA (see <xref target="BCP13"/>). 3220 3220 </t> 3221 3221 <section title="Internet Media Type message/http" anchor="internet.media.type.message.http"> … … 4407 4407 </reference> 4408 4408 4409 <reference anchor=' RFC3864'>4409 <reference anchor='BCP90'> 4410 4410 <front> 4411 4411 <title>Registration Procedures for Message Header Fields</title> … … 4441 4441 </reference> 4442 4442 4443 <reference anchor=" RFC4288">4443 <reference anchor="BCP13"> 4444 4444 <front> 4445 4445 <title>Media Type Specifications and Registration Procedures</title> … … 4461 4461 </reference> 4462 4462 4463 <reference anchor=' RFC4395'>4463 <reference anchor='BCP115'> 4464 4464 <front> 4465 4465 <title>Guidelines and Registration Procedures for New URI Schemes</title> -
draft-ietf-httpbis/latest/p2-semantics.html
r2045 r2046 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 1, 2013";451 content: "Expires June 12, 2013"; 452 452 } 453 453 @bottom-right { … … 496 496 <meta name="dct.creator" content="Reschke, J. F."> 497 497 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 8">498 <meta name="dct.issued" scheme="ISO8601" content="2012-12-09"> 499 499 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 500 500 <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."> … … 524 524 <tr> 525 525 <td class="left">Intended status: Standards Track</td> 526 <td class="right">December 8, 2012</td>526 <td class="right">December 9, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: June 1 1, 2013</td>529 <td class="left">Expires: June 12, 2013</td> 530 530 <td class="right"></td> 531 531 </tr> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on June 1 1, 2013.</p>557 <p>This Internet-Draft will expire on June 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> … … 581 581 <li><a href="#rfc.section.3">3.</a> <a href="#representations">Representations</a><ul> 582 582 <li><a href="#rfc.section.3.1">3.1</a> <a href="#representation.metadata">Representation Metadata</a><ul> 583 <li><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#data.type"> Data Type</a><ul>583 <li><a href="#rfc.section.3.1.1">3.1.1</a> <a href="#data.type">Processing the Data</a><ul> 584 584 <li><a href="#rfc.section.3.1.1.1">3.1.1.1</a> <a href="#media.type">Media Type</a></li> 585 585 <li><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a href="#charset">Charset</a></li> … … 589 589 </ul> 590 590 </li> 591 <li><a href="#rfc.section.3.1.2">3.1.2</a> <a href="#data.encoding"> Data Encoding</a><ul>591 <li><a href="#rfc.section.3.1.2">3.1.2</a> <a href="#data.encoding">Encoding for Compression or Integrity</a><ul> 592 592 <li><a href="#rfc.section.3.1.2.1">3.1.2.1</a> <a href="#content.codings">Content Codings</a></li> 593 593 <li><a href="#rfc.section.3.1.2.2">3.1.2.2</a> <a href="#header.content-encoding">Content-Encoding</a></li> … … 890 890 </table> 891 891 </div> 892 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="data.type" href="#data.type"> Data Type</a></h3>892 <h3 id="rfc.section.3.1.1"><a href="#rfc.section.3.1.1">3.1.1</a> <a id="data.type" href="#data.type">Processing the Data</a></h3> 893 893 <h4 id="rfc.section.3.1.1.1"><a href="#rfc.section.3.1.1.1">3.1.1.1</a> <a id="media.type" href="#media.type">Media Type</a></h4> 894 <p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. 894 <p id="rfc.section.3.1.1.1.p.1">HTTP uses Internet Media Types <a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a> in the <a href="#header.content-type" class="smpl">Content-Type</a> (<a href="#header.content-type" id="rfc.xref.header.content-type.2" title="Content-Type">Section 3.1.1.5</a>) and <a href="#header.accept" class="smpl">Accept</a> (<a href="#header.accept" id="rfc.xref.header.accept.1" title="Accept">Section 6.3.2</a>) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format 895 and various processing models: how to process that data in accordance with each context in which it is received. 895 896 </p> 896 897 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span> <a href="#media.type" class="smpl">media-type</a> = <a href="#media.type" class="smpl">type</a> "/" <a href="#media.type" class="smpl">subtype</a> *( <a href="#imported.abnf" class="smpl">OWS</a> ";" <a href="#imported.abnf" class="smpl">OWS</a> <a href="#rule.parameter" class="smpl">parameter</a> ) … … 916 917 text/html; charset="utf-8" 917 918 </pre><p id="rfc.section.3.1.1.1.p.8">Media-type values are registered with the Internet Assigned Number Authority (IANA). The media type registration process is 918 outlined in <a href="# RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>. Use of non-registered media types is discouraged.919 outlined in <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>. Use of non-registered media types is discouraged. 919 920 </p> 920 921 <h4 id="rfc.section.3.1.1.2"><a href="#rfc.section.3.1.1.2">3.1.1.2</a> <a id="charset" href="#charset">Charset</a></h4> … … 970 971 sniffing" when it is used. 971 972 </p> 972 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="data.encoding" href="#data.encoding"> Data Encoding</a></h3>973 <h3 id="rfc.section.3.1.2"><a href="#rfc.section.3.1.2">3.1.2</a> <a id="data.encoding" href="#data.encoding">Encoding for Compression or Integrity</a></h3> 973 974 <div id="rfc.iref.c.3"></div> 974 975 <div id="rfc.iref.c.4"></div> … … 3456 3457 </div> 3457 3458 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.field.registry" href="#header.field.registry">Header Field Registry</a></h2> 3458 <p id="rfc.section.9.3.p.1">HTTP header fields are registered within the Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>, as defined by <a href="# RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>.3459 <p id="rfc.section.9.3.p.1">HTTP header fields are registered within the Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>>, as defined by <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. 3459 3460 </p> 3460 3461 <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a> <a id="considerations.for.new.header.fields" href="#considerations.for.new.header.fields">Considerations for New Header Fields</a></h3> … … 3462 3463 or the connection (i.e., control data). See <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> for a general definition of header field syntax in HTTP messages. 3463 3464 </p> 3464 <p id="rfc.section.9.3.1.p.2">The requirements for header field names are defined in <a href=" http://tools.ietf.org/html/rfc3864#section-4.1">Section 4.1</a> of <a href="#RFC3864" id="rfc.xref.RFC3864.2"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them3465 <p id="rfc.section.9.3.1.p.2">The requirements for header field names are defined in <a href="#BCP90" id="rfc.xref.BCP90.2"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>. Authors of specifications defining new fields are advised to keep the name as short as practical, and not to prefix them 3465 3466 with "X-" if they are to be registered (either immediately or in the future). 3466 3467 </p> … … 3908 3909 <table> 3909 3910 <tr> 3911 <td class="reference"><b id="BCP13">[BCP13]</b></td> 3912 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005. 3913 </td> 3914 </tr> 3915 <tr> 3916 <td class="reference"><b id="BCP90">[BCP90]</b></td> 3917 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 3918 </td> 3919 </tr> 3920 <tr> 3910 3921 <td class="reference"><b id="REST">[REST]</b></td> 3911 3922 <td class="top">Fielding, R., “<a href="http://roy.gbiv.com/pubs/dissertation/top.htm">Architectural Styles and the Design of Network-based Software Architectures</a>”, Doctoral Dissertation, University of California, Irvine, September 2000, <<a href="http://roy.gbiv.com/pubs/dissertation/top.htm">http://roy.gbiv.com/pubs/dissertation/top.htm</a>>. … … 3968 3979 </tr> 3969 3980 <tr> 3970 <td class="reference"><b id="RFC3864">[RFC3864]</b></td>3971 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004.3972 </td>3973 </tr>3974 <tr>3975 <td class="reference"><b id="RFC4288">[RFC4288]</b></td>3976 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005.3977 </td>3978 </tr>3979 <tr>3980 3981 <td class="reference"><b id="RFC5226">[RFC5226]</b></td> 3981 3982 <td class="top"><a href="mailto:narten@us.ibm.com" title="IBM">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no" title="Google">H. Alvestrand</a>, “<a href="http://tools.ietf.org/html/rfc5226">Guidelines for Writing an IANA Considerations Section in RFCs</a>”, BCP 26, RFC 5226, May 2008. … … 4084 4085 </p> 4085 4086 <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> 4086 <p id="rfc.section.C.p.1">The term "representation" is introduced, replacing both "entity" and "variant." (<a href="#representations" title="Representations">Section 3</a>) 4087 </p> 4088 <p id="rfc.section.C.p.2">"Server-Driven" and "agent-driven" content negotiation are now called "proactive" and "reactive" content negotiation (respectively). 4087 <p id="rfc.section.C.p.1">Request semantics embedded in a URI should be disabled when those semantics are inconsistent with the request method, since 4088 this is a common cause of interoperability failure. 4089 </p> 4090 <p id="rfc.section.C.p.2">The term "representation" is introduced, replacing both "entity" and "variant." (<a href="#representations" title="Representations">Section 3</a>) 4091 </p> 4092 <p id="rfc.section.C.p.3">Rules for identifying the payload of a message have been defined. (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>) 4093 </p> 4094 <p id="rfc.section.C.p.4">"Server-Driven" and "agent-driven" content negotiation are now called "proactive" and "reactive" content negotiation (respectively). 4089 4095 (<a href="#content.negotiation" title="Content Negotiation">Section 3.4</a>) 4090 4096 </p> 4091 <p id="rfc.section.C.p. 3"> <a href="#header.content-location" class="smpl">Content-Location</a> no longer sets a base URI, due to poor implementation support (which was caused by too many broken servers emitting bogus4097 <p id="rfc.section.C.p.5"> <a href="#header.content-location" class="smpl">Content-Location</a> no longer sets a base URI, due to poor implementation support (which was caused by too many broken servers emitting bogus 4092 4098 Content-Location header fields, and also the potentially undesirable effect of potentially breaking relative links in content-negotiated 4093 4099 resources). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>) 4094 4100 </p> 4095 <p id="rfc.section.C.p.4">Rules for identifying the payload of a message have been defined. (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>) 4096 </p> 4097 <p id="rfc.section.C.p.5">GET requests can have a body; it just has no meaning. (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section 5.3.1</a>) 4098 </p> 4099 <p id="rfc.section.C.p.6">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4100 </p> 4101 <p id="rfc.section.C.p.7">Servers are no longer required to handle all Content-* header fields in requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 5.3.4</a>) 4102 </p> 4103 <p id="rfc.section.C.p.8">Use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> is explicitly banned on PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section 5.3.4</a>) 4104 </p> 4105 <p id="rfc.section.C.p.9">The CONNECT method is now defined by this specification, taking over 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 5.3.6</a>) 4106 </p> 4107 <p id="rfc.section.C.p.10">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section 5.3.6</a>) 4108 </p> 4109 <p id="rfc.section.C.p.11">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 5.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.5" title="TRACE">Section 5.3.8</a>) 4110 </p> 4111 <p id="rfc.section.C.p.12">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). 4101 <p id="rfc.section.C.p.6">GET requests can have a body; it just has no meaning. (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section 5.3.1</a>) 4102 </p> 4103 <p id="rfc.section.C.p.7">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4104 </p> 4105 <p id="rfc.section.C.p.8">Servers are no longer required to handle all Content-* header fields in requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 5.3.4</a>) 4106 </p> 4107 <p id="rfc.section.C.p.9">Use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> is explicitly banned on PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section 5.3.4</a>) 4108 </p> 4109 <p id="rfc.section.C.p.10">The CONNECT method is now defined by this specification, taking over 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 5.3.6</a>) 4110 </p> 4111 <p id="rfc.section.C.p.11">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section 5.3.6</a>) 4112 </p> 4113 <p id="rfc.section.C.p.12">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 5.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.5" title="TRACE">Section 5.3.8</a>) 4114 </p> 4115 <p id="rfc.section.C.p.13">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). 4112 4116 (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 6.1.1</a>) 4113 4117 </p> 4114 <p id="rfc.section.C.p.1 3">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 trailing4118 <p id="rfc.section.C.p.14">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 4115 4119 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 6.1.2</a>) 4116 4120 </p> 4117 <p id="rfc.section.C.p.1 4">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 6.3.3</a>)4118 </p> 4119 <p id="rfc.section.C.p.1 5">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section 8.1.1.2</a>)4120 </p> 4121 <p id="rfc.section.C.p.1 6">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 6.5.2</a>)4122 </p> 4123 <p id="rfc.section.C.p.1 7">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one).4124 </p> 4125 <p id="rfc.section.C.p.1 8">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 7.3.4</a>)4126 </p> 4127 <p id="rfc.section.C.p. 19">Redirect 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> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 7.4</a>)4128 </p> 4129 <p id="rfc.section.C.p.2 0">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination4121 <p id="rfc.section.C.p.15">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 6.3.3</a>) 4122 </p> 4123 <p id="rfc.section.C.p.16">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section 8.1.1.2</a>) 4124 </p> 4125 <p id="rfc.section.C.p.17">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 6.5.2</a>) 4126 </p> 4127 <p id="rfc.section.C.p.18">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one). 4128 </p> 4129 <p id="rfc.section.C.p.19">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 7.3.4</a>) 4130 </p> 4131 <p id="rfc.section.C.p.20">Redirect 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> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 7.4</a>) 4132 </p> 4133 <p id="rfc.section.C.p.21">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4130 4134 based upon the request method semantics. (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section 7.4</a>) 4131 4135 </p> 4132 <p id="rfc.section.C.p.2 1">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications4136 <p id="rfc.section.C.p.22">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications 4133 4137 as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 8.1.2</a>) 4134 4138 </p> 4135 <p id="rfc.section.C.p.2 2">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 7.4.4</a>)4136 </p> 4137 <p id="rfc.section.C.p.2 3">User agents are now allowed to rewrite 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>)4138 </p> 4139 <p id="rfc.section.C.p.2 4">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed4139 <p id="rfc.section.C.p.23">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 7.4.4</a>) 4140 </p> 4141 <p id="rfc.section.C.p.24">User agents are now allowed to rewrite 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>) 4142 </p> 4143 <p id="rfc.section.C.p.25">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed 4140 4144 to be accessed through the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The recipient was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.4.5</a>) 4141 4145 </p> 4142 <p id="rfc.section.C.p.2 5">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been made more generic; it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 7.5.1</a>)4143 </p> 4144 <p id="rfc.section.C.p.2 6">The <a href="#status.403" class="smpl">403 (Forbidden)</a> status code has been clarified, especially with regards to authentication. (<a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">Section 7.5.3</a>)4145 </p> 4146 <p id="rfc.section.C.p.2 7">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been 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 7.5.15</a>)4147 </p> 4148 <p id="rfc.section.C.p.2 8"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.4.1</a>)4149 </p> 4150 <p id="rfc.section.C.p. 29">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always4146 <p id="rfc.section.C.p.26">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been made more generic; it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 7.5.1</a>) 4147 </p> 4148 <p id="rfc.section.C.p.27">The <a href="#status.403" class="smpl">403 (Forbidden)</a> status code has been clarified, especially with regards to authentication. (<a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">Section 7.5.3</a>) 4149 </p> 4150 <p id="rfc.section.C.p.28">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been 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 7.5.15</a>) 4151 </p> 4152 <p id="rfc.section.C.p.29"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.4.1</a>) 4153 </p> 4154 <p id="rfc.section.C.p.30">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always 4151 4155 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4152 4156 </p> 4153 <p id="rfc.section.C.p.3 0">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</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 8.4.2</a>)4154 </p> 4155 <p id="rfc.section.C.p.3 1">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>)4156 </p> 4157 <p id="rfc.section.C.p.3 2">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition4157 <p id="rfc.section.C.p.31">The requirement to generate a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7.1</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 8.4.2</a>) 4158 </p> 4159 <p id="rfc.section.C.p.32">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) 4160 </p> 4161 <p id="rfc.section.C.p.33">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition 4158 4162 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>) 4159 4163 </p> 4160 <p id="rfc.section.C.p.3 3">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>)4161 </p> 4162 <p id="rfc.section.C.p.3 4">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses,4164 <p id="rfc.section.C.p.34">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>) 4165 </p> 4166 <p id="rfc.section.C.p.35">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses, 4163 4167 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). 4164 4168 </p> 4165 <p id="rfc.section.C.p.3 5">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>)4166 </p> 4167 <p id="rfc.section.C.p.3 6">The Status Code Registry is now defined by this specification; previously, it was 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 9.2</a>)4168 </p> 4169 <p id="rfc.section.C.p.3 7">References to the "identity" transfer coding token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>)4170 </p> 4171 <p id="rfc.section.C.p.3 8">The Content-Disposition header field 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>)4169 <p id="rfc.section.C.p.36">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>) 4170 </p> 4171 <p id="rfc.section.C.p.37">The Status Code Registry is now defined by this specification; previously, it was 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 9.2</a>) 4172 </p> 4173 <p id="rfc.section.C.p.38">References to the "identity" transfer coding token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) 4174 </p> 4175 <p id="rfc.section.C.p.39">The Content-Disposition header field 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>) 4172 4176 </p> 4173 4177 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 4343 4347 </ul> 4344 4348 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 4345 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index. C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.X">X</a>4349 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.5">5</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.X">X</a> 4346 4350 </p> 4347 4351 <div class="print2col"> … … 4410 4414 <li>Accept-Language header field <a href="#rfc.xref.header.accept-language.1">3.4.1</a>, <a href="#rfc.xref.header.accept-language.2">6.3</a>, <a href="#rfc.iref.a.4"><b>6.3.5</b></a>, <a href="#rfc.xref.header.accept-language.3">9.3.2</a></li> 4411 4415 <li>Allow header field <a href="#rfc.xref.header.allow.1">5.1</a>, <a href="#rfc.xref.header.allow.2">8.4</a>, <a href="#rfc.iref.a.5"><b>8.4.1</b></a>, <a href="#rfc.xref.header.allow.3">9.3.2</a>, <a href="#rfc.xref.header.allow.4">C</a>, <a href="#rfc.xref.header.allow.5">C</a></li> 4416 </ul> 4417 </li> 4418 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 4419 <li><em>BCP13</em> <a href="#rfc.xref.BCP13.1">3.1.1.1</a>, <a href="#BCP13"><b>12.2</b></a></li> 4420 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">9.3</a>, <a href="#rfc.xref.BCP90.2">9.3.1</a>, <a href="#BCP90"><b>12.2</b></a></li> 4412 4421 </ul> 4413 4422 </li> … … 4662 4671 </li> 4663 4672 <li><em>RFC2978</em> <a href="#rfc.xref.RFC2978.1">3.1.1.2</a>, <a href="#RFC2978"><b>12.2</b></a></li> 4664 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.3</a>, <a href="#rfc.xref.RFC3864.2">9.3.1</a>, <a href="#RFC3864"><b>12.2</b></a><ul>4665 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC3864.2">9.3.1</a></li>4666 </ul>4667 </li>4668 4673 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">8.1.2</a>, <a href="#rfc.xref.RFC3986.2">8.1.2</a>, <a href="#RFC3986"><b>12.1</b></a><ul> 4669 4674 <li><em>Section 4.2</em> <a href="#rfc.xref.RFC3986.1">8.1.2</a></li> … … 4671 4676 </ul> 4672 4677 </li> 4673 <li><em>RFC4288</em> <a href="#rfc.xref.RFC4288.1">3.1.1.1</a>, <a href="#RFC4288"><b>12.2</b></a></li>4674 4678 <li><em>RFC4647</em> <a href="#rfc.xref.RFC4647.1">6.3.5</a>, <a href="#rfc.xref.RFC4647.2">6.3.5</a>, <a href="#rfc.xref.RFC4647.3">6.3.5</a>, <a href="#rfc.xref.RFC4647.4">6.3.5</a>, <a href="#RFC4647"><b>12.1</b></a><ul> 4675 4679 <li><em>Section 2.1</em> <a href="#rfc.xref.RFC4647.1">6.3.5</a></li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2045 r2046 328 328 </texttable> 329 329 330 <section title=" Data Type" anchor="data.type">330 <section title="Processing the Data" anchor="data.type"> 331 331 332 332 <section title="Media Type" anchor="media.type"> … … 339 339 and <x:ref>Accept</x:ref> (<xref target="header.accept"/>) header fields in 340 340 order to provide open and extensible data typing and type negotiation. 341 Media types define both a data format and various processing models: 342 how to process that data in accordance with each context in which it 343 is received. 341 344 </t> 342 345 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="media-type"/><iref primary="true" item="Grammar" subitem="type"/><iref primary="true" item="Grammar" subitem="subtype"/> … … 379 382 Media-type values are registered with the Internet Assigned Number 380 383 Authority (IANA). The media type registration process is 381 outlined in <xref target=" RFC4288"/>. Use of non-registered media types is384 outlined in <xref target="BCP13"/>. Use of non-registered media types is 382 385 discouraged. 383 386 </t> … … 508 511 </section> 509 512 510 <section title=" Data Encoding" anchor="data.encoding">513 <section title="Encoding for Compression or Integrity" anchor="data.encoding"> 511 514 512 515 <section title="Content Codings" anchor="content.codings"> … … 4330 4333 HTTP header fields are registered within the Message Header Field Registry 4331 4334 located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/>, 4332 as defined by <xref target=" RFC3864"/>.4335 as defined by <xref target="BCP90"/>. 4333 4336 </t> 4334 4337 … … 4342 4345 <t> 4343 4346 The requirements for header field names are defined in 4344 <xref target=" RFC3864" x:fmt="of" x:sec="4.1"/>. Authors of specifications4347 <xref target="BCP90"/>. Authors of specifications 4345 4348 defining new fields are advised to keep the name as short as practical, and 4346 4349 not to prefix them with "X-" if they are to be registered (either … … 5355 5358 </reference> 5356 5359 5357 <reference anchor=' RFC3864'>5360 <reference anchor='BCP90'> 5358 5361 <front> 5359 5362 <title>Registration Procedures for Message Header Fields</title> … … 5376 5379 </reference> 5377 5380 5378 <reference anchor=" RFC4288">5381 <reference anchor="BCP13"> 5379 5382 <front> 5380 5383 <title>Media Type Specifications and Registration Procedures</title> … … 5647 5650 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 5648 5651 <t> 5652 Request semantics embedded in a URI should be disabled when those 5653 semantics are inconsistent with the request method, since this is a 5654 common cause of interoperability failure. 5655 </t> 5656 <t> 5649 5657 The term "representation" is introduced, replacing both "entity" and 5650 5658 "variant." 5651 5659 (<xref target="representations" />) 5660 </t> 5661 <t> 5662 Rules for identifying the payload of a message have been defined. 5663 (<xref target="identifying.payload" />) 5652 5664 </t> 5653 5665 <t> … … 5663 5675 resources). 5664 5676 (<xref target="header.content-location"/>) 5665 </t>5666 <t>5667 Rules for identifying the payload of a message have been defined.5668 (<xref target="identifying.payload" />)5669 5677 </t> 5670 5678 <t> -
draft-ietf-httpbis/latest/p4-conditional.html
r2045 r2046 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 1, 2013";451 content: "Expires June 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-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 8">493 <meta name="dct.issued" scheme="ISO8601" content="2012-12-09"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 517 517 </tr> 518 518 <tr> 519 <td class="left">Expires: June 1 1, 2013</td>520 <td class="right">December 8, 2012</td>519 <td class="left">Expires: June 12, 2013</td> 520 <td class="right">December 9, 2012</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on June 1 1, 2013.</p>547 <p>This Internet-Draft will expire on June 12, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1160 1160 </div> 1161 1161 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1162 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="# RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1162 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1163 1163 </p> 1164 1164 <div id="rfc.table.2"> … … 1271 1271 <table> 1272 1272 <tr> 1273 <td class="reference"><b id=" RFC2616">[RFC2616]</b></td>1274 <td class="top"><a href="mailto: fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999.1273 <td class="reference"><b id="BCP90">[BCP90]</b></td> 1274 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 1275 1275 </td> 1276 1276 </tr> 1277 1277 <tr> 1278 <td class="reference"><b id="RFC 3864">[RFC3864]</b></td>1279 <td class="top"><a href="mailto: GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004.1278 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1279 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 1280 1280 </td> 1281 1281 </tr> … … 1379 1379 </ul> 1380 1380 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1381 <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index. E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a>1381 <p class="noprint"><a href="#rfc.index.3">3</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> 1382 1382 </p> 1383 1383 <div class="print2col"> … … 1389 1389 <li><a id="rfc.index.4" href="#rfc.index.4"><b>4</b></a><ul> 1390 1390 <li>412 Precondition Failed (status code) <a href="#rfc.iref.21"><b>4.2</b></a>, <a href="#rfc.xref.status.412.1">6.1</a></li> 1391 </ul> 1392 </li> 1393 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 1394 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">6.2</a>, <a href="#BCP90"><b>9.2</b></a></li> 1391 1395 </ul> 1392 1396 </li> … … 1458 1462 </ul> 1459 1463 </li> 1460 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">6.2</a>, <a href="#RFC3864"><b>9.2</b></a></li>1461 1464 <li><em>RFC4918</em> <a href="#rfc.xref.RFC4918.1">2</a>, <a href="#RFC4918"><b>9.2</b></a></li> 1462 1465 <li><em>RFC5234</em> <a href="#rfc.xref.RFC5234.1">1.2</a>, <a href="#RFC5234"><b>9.1</b></a>, <a href="#rfc.xref.RFC5234.2">B</a><ul> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2045 r2046 1087 1087 <t> 1088 1088 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 1089 with the permanent registrations below (see <xref target=" RFC3864"/>):1089 with the permanent registrations below (see <xref target="BCP90"/>): 1090 1090 </t> 1091 1091 <?BEGININC p4-conditional.iana-headers ?> … … 1334 1334 </reference> 1335 1335 1336 <reference anchor=' RFC3864'>1336 <reference anchor='BCP90'> 1337 1337 <front> 1338 1338 <title>Registration Procedures for Message Header Fields</title> -
draft-ietf-httpbis/latest/p5-range.html
r2045 r2046 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 1, 2013";451 content: "Expires June 12, 2013"; 452 452 } 453 453 @bottom-right { … … 493 493 <meta name="dct.creator" content="Reschke, J. F."> 494 494 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 495 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 8">495 <meta name="dct.issued" scheme="ISO8601" content="2012-12-09"> 496 496 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 497 497 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests."> … … 519 519 </tr> 520 520 <tr> 521 <td class="left">Expires: June 1 1, 2013</td>521 <td class="left">Expires: June 12, 2013</td> 522 522 <td class="right">J. Reschke, Editor</td> 523 523 </tr> … … 528 528 <tr> 529 529 <td class="left"></td> 530 <td class="right">December 8, 2012</td>530 <td class="right">December 9, 2012</td> 531 531 </tr> 532 532 </tbody> … … 553 553 in progress”. 554 554 </p> 555 <p>This Internet-Draft will expire on June 1 1, 2013.</p>555 <p>This Internet-Draft will expire on June 12, 2013.</p> 556 556 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 557 557 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 967 967 </div> 968 968 <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 969 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="# RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):969 <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 970 970 </p> 971 971 <div id="rfc.table.2"> … … 1100 1100 <table> 1101 1101 <tr> 1102 <td class="reference"><b id=" RFC2616">[RFC2616]</b></td>1103 <td class="top"><a href="mailto: fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999.1102 <td class="reference"><b id="BCP13">[BCP13]</b></td> 1103 <td class="top"><a href="mailto:ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005. 1104 1104 </td> 1105 1105 </tr> 1106 1106 <tr> 1107 <td class="reference"><b id=" RFC3864">[RFC3864]</b></td>1107 <td class="reference"><b id="BCP90">[BCP90]</b></td> 1108 1108 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 1109 1109 </td> 1110 1110 </tr> 1111 1111 <tr> 1112 <td class="reference"><b id="RFC 4288">[RFC4288]</b></td>1113 <td class="top"><a href="mailto: ned.freed@mrochek.com" title="Sun Microsystems">Freed, N.</a> and <a href="mailto:klensin+ietf@jck.com">J. Klensin</a>, “<a href="http://tools.ietf.org/html/rfc4288">Media Type Specifications and Registration Procedures</a>”, BCP 13, RFC 4288, December 2005.1112 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1113 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 1114 1114 </td> 1115 1115 </tr> … … 1136 1136 <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a> <a id="internet.media.type.multipart.byteranges" href="#internet.media.type.multipart.byteranges">Internet Media Type multipart/byteranges</a></h1> 1137 1137 <p id="rfc.section.A.p.1">When an HTTP <a href="#status.206" class="smpl">206 (Partial Content)</a> response message includes the content of multiple ranges (a response to a request for multiple non-overlapping ranges), these 1138 are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="# RFC4288" id="rfc.xref.RFC4288.1"><cite title="Media Type Specifications and Registration Procedures">[RFC4288]</cite></a>.1138 are transmitted as a multipart message body (<a href="#RFC2046" id="rfc.xref.RFC2046.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, <a href="http://tools.ietf.org/html/rfc2046#section-5.1">Section 5.1</a>). The media type for this purpose is called "multipart/byteranges". The following is to be registered with IANA <a href="#BCP13" id="rfc.xref.BCP13.1"><cite title="Media Type Specifications and Registration Procedures">[BCP13]</cite></a>. 1139 1139 </p> 1140 1140 <p id="rfc.section.A.p.2">The multipart/byteranges media type includes one or more parts, each with its own <a href="p2-semantics.html#header.content-type" class="smpl">Content-Type</a> and <a href="#header.content-range" class="smpl">Content-Range</a> fields. The required boundary parameter specifies the boundary string used to separate each body-part. … … 1323 1323 <p id="rfc.section.E.3.p.1">None yet.</p> 1324 1324 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1325 <p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index. C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a>1325 <p class="noprint"><a href="#rfc.index.2">2</a> <a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> 1326 1326 </p> 1327 1327 <div class="print2col"> … … 1337 1337 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 1338 1338 <li>Accept-Ranges header field <a href="#rfc.iref.a.1"><b>5.1</b></a>, <a href="#rfc.xref.header.accept-ranges.1">6.2</a>, <a href="#rfc.xref.header.accept-ranges.2">6.3</a></li> 1339 </ul> 1340 </li> 1341 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 1342 <li><em>BCP13</em> <a href="#BCP13"><b>9.2</b></a>, <a href="#rfc.xref.BCP13.1">A</a></li> 1343 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">6.2</a>, <a href="#BCP90"><b>9.2</b></a></li> 1339 1344 </ul> 1340 1345 </li> … … 1416 1421 <li><em>RFC2119</em> <a href="#rfc.xref.RFC2119.1">1.1</a>, <a href="#RFC2119"><b>9.1</b></a></li> 1417 1422 <li><em>RFC2616</em> <a href="#RFC2616"><b>9.2</b></a></li> 1418 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">6.2</a>, <a href="#RFC3864"><b>9.2</b></a></li>1419 <li><em>RFC4288</em> <a href="#RFC4288"><b>9.2</b></a>, <a href="#rfc.xref.RFC4288.1">A</a></li>1420 1423 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">2.1</a>, <a href="#RFC5226"><b>9.2</b></a><ul> 1421 1424 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">2.1</a></li> -
draft-ietf-httpbis/latest/p5-range.xml
r2045 r2046 826 826 <t> 827 827 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 828 with the permanent registrations below (see <xref target=" RFC3864"/>):828 with the permanent registrations below (see <xref target="BCP90"/>): 829 829 </t> 830 830 <?BEGININC p5-range.iana-headers ?> … … 1105 1105 </reference> 1106 1106 1107 <reference anchor=' RFC3864'>1107 <reference anchor='BCP90'> 1108 1108 <front> 1109 1109 <title>Registration Procedures for Message Header Fields</title> … … 1126 1126 </reference> 1127 1127 1128 <reference anchor=" RFC4288">1128 <reference anchor="BCP13"> 1129 1129 <front> 1130 1130 <title>Media Type Specifications and Registration Procedures</title> … … 1173 1173 non-overlapping ranges), these are transmitted as a multipart 1174 1174 message body (<xref target="RFC2046" x:fmt="," x:sec="5.1"/>). The media type for this purpose is called 1175 "multipart/byteranges". The following is to be registered with IANA <xref target=" RFC4288"/>.1175 "multipart/byteranges". The following is to be registered with IANA <xref target="BCP13"/>. 1176 1176 </t> 1177 1177 <t> -
draft-ietf-httpbis/latest/p6-cache.html
r2045 r2046 452 452 } 453 453 @bottom-center { 454 content: "Expires June 1 1, 2013";454 content: "Expires June 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-12-0 8">500 <meta name="dct.issued" scheme="ISO8601" content="2012-12-09"> 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. This document 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: June 1 1, 2013</td>526 <td class="left">Expires: June 12, 2013</td> 527 527 <td class="right">J. Reschke, Editor</td> 528 528 </tr> … … 533 533 <tr> 534 534 <td class="left"></td> 535 <td class="right">December 8, 2012</td>535 <td class="right">December 9, 2012</td> 536 536 </tr> 537 537 </tbody> … … 559 559 in progress”. 560 560 </p> 561 <p>This Internet-Draft will expire on June 1 1, 2013.</p>561 <p>This Internet-Draft will expire on June 12, 2013.</p> 562 562 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 563 563 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1727 1727 </div> 1728 1728 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 1729 <p id="rfc.section.9.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="# RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):1729 <p id="rfc.section.9.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 1730 1730 </p> 1731 1731 <div id="rfc.table.3"> … … 1848 1848 <table> 1849 1849 <tr> 1850 <td class="reference"><b id="BCP90">[BCP90]</b></td> 1851 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 1852 </td> 1853 </tr> 1854 <tr> 1850 1855 <td class="reference"><b id="RFC1305">[RFC1305]</b></td> 1851 1856 <td class="top"><a href="mailto:mills@udel.edu" title="University of Delaware, Electrical Engineering Department">Mills, D.</a>, “<a href="http://tools.ietf.org/html/rfc1305">Network Time Protocol (Version 3) Specification, Implementation</a>”, RFC 1305, March 1992. … … 1855 1860 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1856 1861 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. 1857 </td>1858 </tr>1859 <tr>1860 <td class="reference"><b id="RFC3864">[RFC3864]</b></td>1861 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004.1862 1862 </td> 1863 1863 </tr> … … 2040 2040 </ul> 2041 2041 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 2042 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index. C">C</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a>2042 <p class="noprint"><a href="#rfc.index.1">1</a> <a href="#rfc.index.2">2</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.F">F</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.V">V</a> <a href="#rfc.index.W">W</a> 2043 2043 </p> 2044 2044 <div class="print2col"> … … 2060 2060 <li>age <a href="#rfc.iref.a.1">1.2</a></li> 2061 2061 <li>Age header field <a href="#rfc.xref.header.age.1">4</a>, <a href="#rfc.xref.header.age.2">4.1.3</a>, <a href="#rfc.iref.a.2"><b>7.1</b></a>, <a href="#rfc.xref.header.age.3">9.3</a></li> 2062 </ul> 2063 </li> 2064 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 2065 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">9.3</a>, <a href="#BCP90"><b>12.2</b></a></li> 2062 2066 </ul> 2063 2067 </li> … … 2174 2178 </ul> 2175 2179 </li> 2176 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">9.3</a>, <a href="#RFC3864"><b>12.2</b></a></li>2177 2180 <li><em>RFC5226</em> <a href="#rfc.xref.RFC5226.1">7.2.3</a>, <a href="#rfc.xref.RFC5226.2">7.5.8</a>, <a href="#RFC5226"><b>12.2</b></a><ul> 2178 2181 <li><em>Section 4.1</em> <a href="#rfc.xref.RFC5226.1">7.2.3</a>, <a href="#rfc.xref.RFC5226.2">7.5.8</a></li> -
draft-ietf-httpbis/latest/p6-cache.xml
r2045 r2046 2026 2026 The Message Header Field Registry located at <eref 2027 2027 target="http://www.iana.org/assignments/message-headers/message-header-index.html" /> 2028 shall be updated with the permanent registrations below (see <xref target=" RFC3864" />):2028 shall be updated with the permanent registrations below (see <xref target="BCP90" />): 2029 2029 </t> 2030 2030 <?BEGININC p6-cache.iana-headers ?> … … 2331 2331 </reference> 2332 2332 2333 <reference anchor=" RFC3864">2333 <reference anchor="BCP90"> 2334 2334 <front> 2335 2335 <title>Registration Procedures for Message Header Fields</title> -
draft-ietf-httpbis/latest/p7-auth.html
r2045 r2046 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 1, 2013";451 content: "Expires June 12, 2013"; 452 452 } 453 453 @bottom-right { … … 489 489 <meta name="dct.creator" content="Reschke, J. F."> 490 490 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 491 <meta name="dct.issued" scheme="ISO8601" content="2012-12-0 8">491 <meta name="dct.issued" scheme="ISO8601" content="2012-12-09"> 492 492 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 493 493 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework."> … … 517 517 <tr> 518 518 <td class="left">Intended status: Standards Track</td> 519 <td class="right">December 8, 2012</td>519 <td class="right">December 9, 2012</td> 520 520 </tr> 521 521 <tr> 522 <td class="left">Expires: June 1 1, 2013</td>522 <td class="left">Expires: June 12, 2013</td> 523 523 <td class="right"></td> 524 524 </tr> … … 546 546 in progress”. 547 547 </p> 548 <p>This Internet-Draft will expire on June 1 1, 2013.</p>548 <p>This Internet-Draft will expire on June 12, 2013.</p> 549 549 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 550 550 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 885 885 </div> 886 886 <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a> <a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2> 887 <p id="rfc.section.5.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="# RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):887 <p id="rfc.section.5.3.p.1">The Message Header Field Registry located at <<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>> shall be updated with the permanent registrations below (see <a href="#BCP90" id="rfc.xref.BCP90.1"><cite title="Registration Procedures for Message Header Fields">[BCP90]</cite></a>): 888 888 </p> 889 889 <div id="rfc.table.2"> … … 1005 1005 <table> 1006 1006 <tr> 1007 <td class="reference"><b id="BCP90">[BCP90]</b></td> 1008 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004. 1009 </td> 1010 </tr> 1011 <tr> 1007 1012 <td class="reference"><b id="RFC2616">[RFC2616]</b></td> 1008 1013 <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="W3C">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="MIT Laboratory for Computer Science">Frystyk, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="W3C">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC 2616, June 1999. … … 1012 1017 <td class="reference"><b id="RFC2617">[RFC2617]</b></td> 1013 1018 <td class="top"><a href="mailto:john@math.nwu.edu" title="Northwestern University, Department of Mathematics">Franks, J.</a>, <a href="mailto:pbaker@verisign.com" title="Verisign Inc.">Hallam-Baker, P.</a>, <a href="mailto:jeff@AbiSource.com" title="AbiSource, Inc.">Hostetler, J.</a>, <a href="mailto:lawrence@agranat.com" title="Agranat Systems, Inc.">Lawrence, S.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, Luotonen, A., and <a href="mailto:stewart@OpenMarket.com" title="Open Market, Inc.">L. Stewart</a>, “<a href="http://tools.ietf.org/html/rfc2617">HTTP Authentication: Basic and Digest Access Authentication</a>”, RFC 2617, June 1999. 1014 </td>1015 </tr>1016 <tr>1017 <td class="reference"><b id="RFC3864">[RFC3864]</b></td>1018 <td class="top"><a href="mailto:GK-IETF@ninebynine.org" title="Nine by Nine">Klyne, G.</a>, <a href="mailto:mnot@pobox.com" title="BEA Systems">Nottingham, M.</a>, and <a href="mailto:JeffMogul@acm.org" title="HP Labs">J. Mogul</a>, “<a href="http://tools.ietf.org/html/rfc3864">Registration Procedures for Message Header Fields</a>”, BCP 90, RFC 3864, September 2004.1019 1019 </td> 1020 1020 </tr> … … 1127 1127 </ul> 1128 1128 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 1129 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index. C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.W">W</a>1129 <p class="noprint"><a href="#rfc.index.4">4</a> <a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.W">W</a> 1130 1130 </p> 1131 1131 <div class="print2col"> … … 1138 1138 <li><a id="rfc.index.A" href="#rfc.index.A"><b>A</b></a><ul> 1139 1139 <li>Authorization header field <a href="#rfc.xref.header.authorization.1">2.1</a>, <a href="#rfc.xref.header.authorization.2">3.1</a>, <a href="#rfc.iref.a.1"><b>4.1</b></a>, <a href="#rfc.xref.header.authorization.3">5.3</a></li> 1140 </ul> 1141 </li> 1142 <li><a id="rfc.index.B" href="#rfc.index.B"><b>B</b></a><ul> 1143 <li><em>BCP90</em> <a href="#rfc.xref.BCP90.1">5.3</a>, <a href="#BCP90"><b>8.2</b></a></li> 1140 1144 </ul> 1141 1145 </li> … … 1192 1196 </ul> 1193 1197 </li> 1194 <li><em>RFC3864</em> <a href="#rfc.xref.RFC3864.1">5.3</a>, <a href="#RFC3864"><b>8.2</b></a></li>1195 1198 <li><em>RFC3986</em> <a href="#rfc.xref.RFC3986.1">2.1</a>, <a href="#RFC3986"><b>8.2</b></a></li> 1196 1199 <li><em>RFC4648</em> <a href="#rfc.xref.RFC4648.1">2.1</a>, <a href="#RFC4648"><b>8.2</b></a></li> -
draft-ietf-httpbis/latest/p7-auth.xml
r2045 r2046 629 629 <t> 630 630 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 631 with the permanent registrations below (see <xref target=" RFC3864"/>):631 with the permanent registrations below (see <xref target="BCP90"/>): 632 632 </t> 633 633 <?BEGININC p7-auth.iana-headers ?> … … 917 917 </reference> 918 918 919 <reference anchor=' RFC3864'>919 <reference anchor='BCP90'> 920 920 <front> 921 921 <title>Registration Procedures for Message Header Fields</title>
Note: See TracChangeset
for help on using the changeset viewer.