Ignore:
Timestamp:
May 26, 2010, 10:25:13 AM (10 years ago)
Author:
julian.reschke@…
Message:

Introduce term "effective request URI" and use it throughout; may require some more fine-tuning (see #196)

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r818 r823  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-05-07">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-05-26">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: November 8, 2010</td>
     436               <td class="left">Expires: November 27, 2010</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">May 7, 2010</td>
     489               <td class="right">May 26, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in November 8, 2010.</p>
     516      <p>This Internet-Draft will expire in November 27, 2010.</p>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    753753             &lt;WWW-Authenticate, defined in <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a>&gt;
    754754</pre><h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a id="method" href="#method">Method</a></h1>
    755       <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the request-target. The method is case-sensitive.</p>
     755      <p id="rfc.section.2.p.1">The Method token indicates the method to be performed on the resource identified by the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The method is case-sensitive.
     756      </p>
    756757      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span>  <a href="#method" class="smpl">Method</a>         = %x4F.50.54.49.4F.4E.53   ; "OPTIONS", <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section&nbsp;7.2</a>
    757758                 / %x47.45.54               ; "GET", <a href="#GET" id="rfc.xref.GET.1" title="GET">Section&nbsp;7.3</a>
    … …  
    796797                 / <a href="#header.expect" class="smpl">Expect</a>                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;9.2</a>
    797798                 / <a href="#header.from" class="smpl">From</a>                     ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;9.3</a>
    798                  / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.17"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a>
     799                 / <a href="#abnf.dependencies" class="smpl">Host</a>                     ; <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 9.4</a>
    799800                 / <a href="#abnf.dependencies" class="smpl">If-Match</a>                 ; <a href="#Part4" id="rfc.xref.Part4.6"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>
    800801                 / <a href="#abnf.dependencies" class="smpl">If-Modified-Since</a>        ; <a href="#Part4" id="rfc.xref.Part4.7"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a>
    … …  
    806807                 / <a href="#abnf.dependencies" class="smpl">Range</a>                    ; <a href="#Part5" id="rfc.xref.Part5.5"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a>
    807808                 / <a href="#header.referer" class="smpl">Referer</a>                  ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;9.6</a>
    808                  / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.18"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a>
     809                 / <a href="#abnf.dependencies" class="smpl">TE</a>                       ; <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 9.8</a>
    809810                 / <a href="#header.user-agent" class="smpl">User-Agent</a>               ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;9.9</a>
    810811</pre><p id="rfc.section.3.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    … …  
    880881      <p id="rfc.section.5.p.1">The response-header fields allow the server to pass additional information about the response which cannot be placed in the
    881882         Status-Line. These header fields give information about the server and about further access to the resource identified by
    882          the request-target.
     883         the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    883884      </p>
    884885      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.7"></span>  <a href="#response.header.fields" class="smpl">response-header</a> = <a href="#abnf.dependencies" class="smpl">Accept-Ranges</a>           ; <a href="#Part5" id="rfc.xref.Part5.7"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a>
    … …  
    901902         fields are defined in <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    902903      </p>
    903       <p id="rfc.section.6.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     904      <p id="rfc.section.6.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.3</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    904905         safe and proper transfer of the message.
    905906      </p>
    … …  
    907908      <p id="rfc.section.6.1.p.1">It is sometimes necessary to determine the identity of the resource associated with a representation.</p>
    908909      <p id="rfc.section.6.1.p.2">An HTTP request representation, when present, is always associated with an anonymous (i.e., unidentified) resource.</p>
    909       <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the request-URI. However, this is not
    910          always the case. To determine the URI of the resource a response is associated with, the following rules are used (with the
    911          first applicable one being selected):
     910      <p id="rfc.section.6.1.p.3">In the common case, an HTTP response is a representation of the resource located at the Effective Request URI (see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). However, this is not always the case. To determine the URI of the resource a response is associated with, the following
     911         rules are used (with the first applicable one being selected):
    912912      </p>
    913913      <ol>
    914914         <li>If the response status code is 200 or 203 and the request method was GET, the response is a representation of the resource
    915             at the request-URI.
     915            at the Effective Request URI.
    916916         </li>
    917917         <li>If the response status is 204, 206, or 304 and the request method was GET or HEAD, the response is a partial representation
    918             of the resource at the request-URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
    919          </li>
    920          <li>If the response has a Content-Location header, and that URI is the same as the request-URI <span class="comment" id="TODO-missref-requri">[<a href="#TODO-missref-requri" class="smpl">TODO-missref-requri</a>: (see [ref])]</span>, the response is a representation of the resource at the request-URI.
    921          </li>
    922          <li>If the response has a Content-Location header, and that URI is not the same as the request-URI, the response asserts that
    923             it is a representation of the resource at the Content-Location URI (but it may not be).
     918            of the resource at the Effective Request URI (see <a href="p6-cache.html#combining.headers" title="Combining Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
     919         </li>
     920         <li>If the response has a Content-Location header, and that URI is the same as the Effective Request URI, the response is a representation
     921            of the resource at the Effective Request URI.
     922         </li>
     923         <li>If the response has a Content-Location header, and that URI is not the same as the Effective Request URI, the response asserts
     924            that it is a representation of the resource at the Content-Location URI (but it may not be).
    924925         </li>
    925926         <li>Otherwise, the response is a representation of an anonymous (i.e., unidentified) resource.</li>
    926927      </ol>
    927       <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: Note that "request-URI" is used here; however, we need to come up with a term to denote "the URI that can be inferred from
    928             examining the request-target and the Host header." (see &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;). Also, the comparison function is going to have to be defined somewhere, because we already need to compare URIs for things
    929             like cache invalidation.]</span>
     928      <p id="rfc.section.6.1.p.5"> <span class="comment" id="TODO-req-uri">[<a href="#TODO-req-uri" class="smpl">TODO-req-uri</a>: The comparison function is going to have to be defined somewhere, because we already need to compare URIs for things like
     929            cache invalidation.]</span>
    930930      </p>
    931931      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
    … …  
    958958      <div id="rfc.iref.m.1"></div>
    959959      <p id="rfc.section.7.2.p.1">The OPTIONS method represents a request for information about the communication options available on the request/response
    960          chain identified by the request-target. This method allows the client to determine the options and/or requirements associated
    961          with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
     960         chain identified by the Effective Request URI. This method allows the client to determine the options and/or requirements
     961         associated with a resource, or the capabilities of a server, without implying a resource action or initiating a resource retrieval.
    962962      </p>
    963963      <p id="rfc.section.7.2.p.2">Responses to this method are not cacheable.</p>
    … …  
    986986      <div id="rfc.iref.m.2"></div>
    987987      <p id="rfc.section.7.3.p.1">The GET method means retrieve whatever information (in the form of an entity) currently corresponds to the resource identified
    988          by the request-target.
    989       </p>
    990       <p id="rfc.section.7.3.p.2">If the request-target identifies a data-producing process, it is the produced data which shall be returned as the entity in
    991          the response and not the source text of the process, unless that text happens to be the output of the process.
     988         by the Effective Request URI.
     989      </p>
     990      <p id="rfc.section.7.3.p.2">If the Effective Request URI identifies a data-producing process, it is the produced data which shall be returned as the entity
     991         in the response and not the source text of the process, unless that text happens to be the output of the process.
    992992      </p>
    993993      <p id="rfc.section.7.3.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
    … …  
    10201020      <h2 id="rfc.section.7.5"><a href="#rfc.section.7.5">7.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    10211021      <p id="rfc.section.7.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed
    1022          by the resource identified by the request-target in the Request-Line. POST is designed to allow a uniform method to cover
    1023          the following functions:
     1022         by the resource identified by the Effective Request URI. POST is designed to allow a uniform method to cover the following
     1023         functions:
    10241024      </p>
    10251025      <ul>
    … …  
    10291029         <li>Extending a database through an append operation.</li>
    10301030      </ul>
    1031       <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the request-target.</p>
     1031      <p id="rfc.section.7.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Effective Request
     1032         URI.
     1033      </p>
    10321034      <p id="rfc.section.7.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
    10331035         200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity
    … …  
    10431045      <div id="rfc.iref.m.5"></div>
    10441046      <h2 id="rfc.section.7.6"><a href="#rfc.section.7.6">7.6</a>&nbsp;<a id="PUT" href="#PUT">PUT</a></h2>
    1045       <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the supplied request-target. If the request-target refers to
    1046          an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. If the request-target does not point to an existing
    1047          resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create
    1048          the resource with that URI. If a new resource is created at the request-target, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
    1049          Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request. If the resource could not be created or modified with the request-target,
    1050          an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
    1051       </p>
    1052       <p id="rfc.section.7.6.p.2">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
    1053       </p>
    1054       <p id="rfc.section.7.6.p.3">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the request-target.
    1055          The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting
     1047      <p id="rfc.section.7.6.p.1">The PUT method requests that the enclosed entity be stored at the Effective Request URI. If the Effective Request URI refers
     1048         to an already existing resource, the enclosed entity <em class="bcp14">SHOULD</em> be considered as a modified version of the one residing on the origin server. Otherwise, if the Effective Request URI does
     1049         not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent,
     1050         the origin server can create the resource with that URI.
     1051      </p>
     1052      <p id="rfc.section.7.6.p.2">If a new resource is created at the Effective Request URI, the origin server <em class="bcp14">MUST</em> inform the user agent via the 201 (Created) response. If an existing resource is modified, either the 200 (OK) or 204 (No
     1053         Content) response codes <em class="bcp14">SHOULD</em> be sent to indicate successful completion of the request.
     1054      </p>
     1055      <p id="rfc.section.7.6.p.3">If the resource could not be created or modified with the Effective Request URI, an appropriate error response <em class="bcp14">SHOULD</em> be given that reflects the nature of the problem. The recipient of the entity <em class="bcp14">MUST NOT</em> ignore any Content-* headers (headers starting with the prefix "Content-") that it does not understand or implement and <em class="bcp14">MUST</em> return a 501 (Not Implemented) response in such cases.
     1056      </p>
     1057      <p id="rfc.section.7.6.p.4">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those
     1058         entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
     1059      </p>
     1060      <p id="rfc.section.7.6.p.5">The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Effective Request
     1061         URI. The URI in a POST request identifies the resource that will handle the enclosed entity. That resource might be a data-accepting
    10561062         process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request
    10571063         identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server <em class="bcp14">MUST NOT</em> attempt to apply the request to some other resource. If the server desires that the request be applied to a different URI,
    10581064         it <em class="bcp14">MUST</em> send a 301 (Moved Permanently) response; the user agent <em class="bcp14">MAY</em> then make its own decision regarding whether or not to redirect the request.
    10591065      </p>
    1060       <p id="rfc.section.7.6.p.4">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which
     1066      <p id="rfc.section.7.6.p.6">A single resource <em class="bcp14">MAY</em> be identified by many different URIs. For example, an article might have a URI for identifying "the current version" which
    10611067         is separate from the URI identifying each particular version. In this case, a PUT request on a general URI might result in
    10621068         several other URIs being defined by the origin server.
    10631069      </p>
    1064       <p id="rfc.section.7.6.p.5">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
    1065       <p id="rfc.section.7.6.p.6">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
     1070      <p id="rfc.section.7.6.p.7">HTTP/1.1 does not define how a PUT method affects the state of an origin server.</p>
     1071      <p id="rfc.section.7.6.p.8">Unless otherwise specified for a particular entity-header, the entity-headers in the PUT request <em class="bcp14">SHOULD</em> be applied to the resource created or modified by the PUT.
    10661072      </p>
    10671073      <div id="rfc.iref.d.1"></div>
    10681074      <div id="rfc.iref.m.6"></div>
    10691075      <h2 id="rfc.section.7.7"><a href="#rfc.section.7.7">7.7</a>&nbsp;<a id="DELETE" href="#DELETE">DELETE</a></h2>
    1070       <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the request-target. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
     1076      <p id="rfc.section.7.7.p.1">The DELETE method requests that the origin server delete the resource identified by the Effective Request URI. This method <em class="bcp14">MAY</em> be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation
    10711077         has been carried out, even if the status code returned from the origin server indicates that the action has been completed
    10721078         successfully. However, the server <em class="bcp14">SHOULD NOT</em> indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible
    … …  
    10761082         or 204 (No Content) if the action has been enacted but the response does not include an entity.
    10771083      </p>
    1078       <p id="rfc.section.7.7.p.3">If the request passes through a cache and the request-target identifies one or more currently cached entities, those entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
     1084      <p id="rfc.section.7.7.p.3">If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those
     1085         entries <em class="bcp14">SHOULD</em> be treated as stale. Responses to this method are not cacheable.
    10791086      </p>
    10801087      <h2 id="rfc.section.7.8"><a href="#rfc.section.7.8">7.8</a>&nbsp;<a id="TRACE" href="#TRACE">TRACE</a></h2>
    … …  
    10861093      </p>
    10871094      <p id="rfc.section.7.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    1088          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     1095         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    10891096         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    10901097         infinite loop.
    10911098      </p>
    1092       <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.
     1099      <p id="rfc.section.7.8.p.3">If the request is valid, the response <em class="bcp14">SHOULD</em> contain the entire request message in the entity-body, with a Content-Type of "message/http" (see <a href="p1-messaging.html#internet.media.type.message.http" title="Internet Media Type message/http">Section 10.3.1</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). Responses to this method <em class="bcp14">MUST NOT</em> be cached.
    10931100      </p>
    10941101      <div id="rfc.iref.c.1"></div>
    … …  
    11171124      <p id="rfc.section.8.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    11181125         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    1119          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     1126         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    11201127      </p>
    11211128      <div id="rfc.iref.26"></div>
    … …  
    12281235      <div id="rfc.iref.s.12"></div>
    12291236      <h3 id="rfc.section.8.3.2"><a href="#rfc.section.8.3.2">8.3.2</a>&nbsp;<a id="status.301" href="#status.301">301 Moved Permanently</a></h3>
    1230       <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the request-target
    1231          to one or more of the new references returned by the server, where possible. This response is cacheable unless indicated otherwise.
     1237      <p id="rfc.section.8.3.2.p.1">The requested resource has been assigned a new permanent URI and any future references to this resource <em class="bcp14">SHOULD</em> use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Effective
     1238         Request URI to one or more of the new references returned by the server, where possible. This response is cacheable unless
     1239         indicated otherwise.
    12321240      </p>
    12331241      <p id="rfc.section.8.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    … …  
    12451253      <h3 id="rfc.section.8.3.3"><a href="#rfc.section.8.3.3">8.3.3</a>&nbsp;<a id="status.302" href="#status.302">302 Found</a></h3>
    12461254      <p id="rfc.section.8.3.3.p.1">The requested resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the
    1247          client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or
    1248          Expires header field.
     1255         client <em class="bcp14">SHOULD</em> continue to use the Effectice Request URI for future requests. This response is only cacheable if indicated by a Cache-Control
     1256         or Expires header field.
    12491257      </p>
    12501258      <p id="rfc.section.8.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    … …  
    12981306      <div id="rfc.iref.s.18"></div>
    12991307      <h3 id="rfc.section.8.3.8"><a href="#rfc.section.8.3.8">8.3.8</a>&nbsp;<a id="status.307" href="#status.307">307 Temporary Redirect</a></h3>
    1300       <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the request-target for future requests. This response is only cacheable if indicated by a Cache-Control or
    1301          Expires header field.
     1308      <p id="rfc.section.8.3.8.p.1">The requested resource resides temporarily under a different URI. Since the redirection <em class="bcp14">MAY</em> be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the Effective Request URI for future requests. This response is only cacheable if indicated by a Cache-Control
     1309         or Expires header field.
    13021310      </p>
    13031311      <p id="rfc.section.8.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s) , since many pre-HTTP/1.1 user agents do not understand
    … …  
    13411349      <div id="rfc.iref.s.23"></div>
    13421350      <h3 id="rfc.section.8.4.5"><a href="#rfc.section.8.4.5">8.4.5</a>&nbsp;<a id="status.404" href="#status.404">404 Not Found</a></h3>
    1343       <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the request-target. No indication is given of whether the condition is temporary
     1351      <p id="rfc.section.8.4.5.p.1">The server has not found anything matching the Effective Request URI. No indication is given of whether the condition is temporary
    13441352         or permanent. The 410 (Gone) status code <em class="bcp14">SHOULD</em> be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable
    13451353         and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request
    … …  
    13491357      <div id="rfc.iref.s.24"></div>
    13501358      <h3 id="rfc.section.8.4.6"><a href="#rfc.section.8.4.6">8.4.6</a>&nbsp;<a id="status.405" href="#status.405">405 Method Not Allowed</a></h3>
    1351       <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the request-target. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
     1359      <p id="rfc.section.8.4.6.p.1">The method specified in the Request-Line is not allowed for the resource identified by the Effective Request URI. The response <em class="bcp14">MUST</em> include an Allow header containing a list of valid methods for the requested resource.
    13521360      </p>
    13531361      <div id="rfc.iref.48"></div>
    … …  
    13961404      <h3 id="rfc.section.8.4.11"><a href="#rfc.section.8.4.11">8.4.11</a>&nbsp;<a id="status.410" href="#status.410">410 Gone</a></h3>
    13971405      <p id="rfc.section.8.4.11.p.1">The requested resource is no longer available at the server and no forwarding address is known. This condition is expected
    1398          to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the request-target after user approval. If the server does not know, or has no facility to determine,
     1406         to be considered permanent. Clients with link editing capabilities <em class="bcp14">SHOULD</em> delete references to the Effective Request URI after user approval. If the server does not know, or has no facility to determine,
    13991407         whether or not the condition is permanent, the status code 404 (Not Found) <em class="bcp14">SHOULD</em> be used instead. This response is cacheable unless indicated otherwise.
    14001408      </p>
    … …  
    14281436      <div id="rfc.iref.s.33"></div>
    14291437      <h3 id="rfc.section.8.4.15"><a href="#rfc.section.8.4.15">8.4.15</a>&nbsp;<a id="status.414" href="#status.414">414 URI Too Long</a></h3>
    1430       <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the request-target is longer than the server is willing to interpret.
     1438      <p id="rfc.section.8.4.15.p.1">The server is refusing to service the request because the Effective Request URI is longer than the server is willing to interpret.
    14311439         This rare condition is only likely to occur when a client has improperly converted a POST request to a GET request with long
    14321440         query information, when the client has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that
    14331441         points to a suffix of itself), or when the server is under attack by a client attempting to exploit security holes present
    1434          in some servers using fixed-length buffers for reading or manipulating the request-target.
     1442         in some servers using fixed-length buffers for reading or manipulating the Effective Request URI.
    14351443      </p>
    14361444      <div id="rfc.iref.57"></div>
    … …  
    14981506      <p id="rfc.section.8.5.6.p.1">The server does not support, or refuses to support, the protocol version that was used in the request message. The server
    14991507         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    1500          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.23"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
     1508         in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 2.5</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
    15011509      </p>
    15021510      <h1 id="rfc.section.9"><a href="#rfc.section.9">9.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    15081516      <div id="rfc.iref.h.2"></div>
    15091517      <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a>&nbsp;<a id="header.allow" href="#header.allow">Allow</a></h2>
    1510       <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target.
    1511          The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
     1518      <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the Effective
     1519         Request URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource.
    15121520      </p>
    15131521      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span>  <a href="#header.allow" class="smpl">Allow</a>   = "Allow" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.allow" class="smpl">Allow-v</a>
    … …  
    15431551      </p>
    15441552      <p id="rfc.section.9.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
    1545       <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.24"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.
     1553      <p id="rfc.section.9.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.
    15461554      </p>
    15471555      <div id="rfc.iref.f.1"></div>
    … …  
    16151623      <div id="rfc.iref.h.7"></div>
    16161624      <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a>&nbsp;<a id="header.referer" href="#header.referer">Referer</a></h2>
    1617       <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the request-target
    1618          was obtained (the "referrer", although the header field is misspelled.).
     1625      <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify the URI of the resource from which the Effective Request
     1626         URI was obtained (the "referrer", although the header field is misspelled.).
    16191627      </p>
    16201628      <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc.
    … …  
    16231631         contain a Referer header field.
    16241632      </p>
    1625       <p id="rfc.section.9.6.p.3">If the request-target was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the
    1626          Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
     1633      <p id="rfc.section.9.6.p.3">If the Effective Request URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard),
     1634         the Referer field <em class="bcp14">MUST</em> either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not apply to sources with
    16271635         non-HTTP URIs (e.g., FTP).
    16281636      </p>
    … …  
    16311639</pre><p id="rfc.section.9.6.p.5">Example:</p>
    16321640      <div id="rfc.figure.u.22"></div><pre class="text">  Referer: http://www.example.org/hypertext/Overview.html
    1633 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
     1641</pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Effective Request URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section&nbsp;11.2</a> for security considerations.
    16341642      </p>
    16351643      <div id="rfc.iref.r.2"></div>
    … …  
    16551663      <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a>&nbsp;<a id="header.server" href="#header.server">Server</a></h2>
    16561664      <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request.</p>
    1657       <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
     1665      <p id="rfc.section.9.8.p.2">The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the server and any significant subproducts. The product tokens are listed in order of their significance for
    16581666         identifying the application.
    16591667      </p>
    … …  
    16631671</pre><p id="rfc.section.9.8.p.4">Example:</p>
    16641672      <div id="rfc.figure.u.27"></div><pre class="text">  Server: CERN/3.0 libwww/2.17
    1665 </pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1673</pre><p id="rfc.section.9.8.p.6">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    16661674      </p>
    16671675      <div class="note" id="rfc.section.9.8.p.7">
    … …  
    16781686         to avoid particular user agent limitations.
    16791687      </p>
    1680       <p id="rfc.section.9.9.p.2">User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.28"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.29"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens
     1688      <p id="rfc.section.9.9.p.2">User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.31"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments (<a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.32"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens
    16811689         are listed in order of their significance for identifying the application.
    16821690      </p>
    … …  
    21142122      </p>
    21152123      <p id="rfc.section.11.2.p.3">Authors of services should not use GET-based forms for the submission of sensitive data because that data will be encoded
    2116          in the Request-target. Many existing servers, proxies, and user agents log or display the Request-target in places where it
     2124         in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it
    21172125         might be visible to third parties. Such services can use POST-based form submission instead.
    21182126      </p>
    … …  
    22822290      </p>
    22832291      <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly
    2284          in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.30"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
     2292         in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 9.9</a> of <a href="#Part1" id="rfc.xref.Part1.33"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.8</a>)
    22852293      </p>
    22862294      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    … …  
    25652573      <ul>
    25662574         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header payload handling"
     2575         </li>
     2576         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI"
    25672577         </li>
    25682578      </ul>
    … …  
    27352745            </li>
    27362746            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    2737                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">3</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">6</a>, <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.21">7.8</a>, <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a><ul class="ind">
     2747                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">1.2</a>, <a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.21">6</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a>, <a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.24">7.8</a>, <a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.26">8.5.6</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a>, <a class="iref" href="#Part1"><b>13.1</b></a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a><ul class="ind">
    27382748                        <li class="indline1"><em>Section 1.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">1.2</a></li>
    27392749                        <li class="indline1"><em>Section 1.2.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.4">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.5">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.6">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.7">1.2.1</a>, <a class="iref" href="#rfc.xref.Part1.8">1.2.1</a></li>
    2740                         <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">8.5.6</a></li>
     2750                        <li class="indline1"><em>Section 2.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.26">8.5.6</a></li>
    27412751                        <li class="indline1"><em>Section 2.6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.9">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.11">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li>
    2742                         <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.29">9.9</a></li>
    2743                         <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.19">6</a></li>
     2752                        <li class="indline1"><em>Section 3.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.10">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.29">9.8</a>, <a class="iref" href="#rfc.xref.Part1.32">9.9</a></li>
     2753                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">6</a></li>
     2754                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">2</a>, <a class="iref" href="#rfc.xref.Part1.20">5</a>, <a class="iref" href="#rfc.xref.Part1.22">6.1</a></li>
    27442755                        <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li>
    2745                         <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.25">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">9.9</a></li>
    2746                         <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li>
    2747                         <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.17">3</a></li>
    2748                         <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a></li>
    2749                         <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.27">9.8</a>, <a class="iref" href="#rfc.xref.Part1.30">A.2</a></li>
    2750                         <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.21">7.8</a></li>
     2756                        <li class="indline1"><em>Section 6.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.14">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.28">9.8</a>, <a class="iref" href="#rfc.xref.Part1.31">9.9</a></li>
     2757                        <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.25">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.27">9.2</a></li>
     2758                        <li class="indline1"><em>Section 9.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.18">3</a></li>
     2759                        <li class="indline1"><em>Section 9.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.19">3</a></li>
     2760                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.23">7.8</a>, <a class="iref" href="#rfc.xref.Part1.30">9.8</a>, <a class="iref" href="#rfc.xref.Part1.33">A.2</a></li>
     2761                        <li class="indline1"><em>Section 10.3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.24">7.8</a></li>
    27512762                     </ul>
    27522763                  </li>
Note: See TracChangeset for help on using the changeset viewer.