Changeset 2067 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 30/12/12 00:22:16 (8 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2065 r2067 1112 1112 </p> 1113 1113 <ul> 1114 <li>For a response to a GET or HEAD request, this is an indication that the effective request URI identifiesa resource that is1114 <li>For a response to a GET or HEAD request, this is an indication that the effective request URI refers to a resource that is 1115 1115 subject to content negotiation and the Content-Location field-value is a more specific identifier for the selected representation. 1116 1116 </li> … … 1122 1122 </li> 1123 1123 </ul> 1124 <p id="rfc.section.3.1.4.2.p.6"> If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed1125 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is1126 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated1127 resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected1128 to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse1129 content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the1130 latter semantics, it would have applied the PUT directly to the Content-Location URI.1131 </p> 1132 <p id="rfc.section.3.1.4.2.p. 7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use1133 in other contexts, such as within source links or other metadata.1134 </p>1135 <p id="rfc.section.3.1.4.2.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used1136 to respond to later requests on that Content-LocationURI.1124 <p id="rfc.section.3.1.4.2.p.6">A user agent that sends Content-Location in a request message is stating that its value refers to where the user agent originally 1125 obtained the content of the enclosed representation (prior to any modifications made by that user agent). In other words, 1126 the user agent is providing a back link to the source of the original representation. 1127 </p> 1128 <p id="rfc.section.3.1.4.2.p.7">An origin server that receives a Content-Location field in a request message <em class="bcp14">MUST</em> treat the information as transitory request context rather than as metadata to be saved verbatim as part of the representation. 1129 An origin server <em class="bcp14">MAY</em> use that context to guide in processing the request or to save it for other uses, such as within source links or versioning 1130 metadata. However, an origin server <em class="bcp14">MUST NOT</em> use such context information to alter the request semantics. 1131 </p> 1132 <p id="rfc.section.3.1.4.2.p.8">For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), 1133 then the new set of values for that resource is expected to be consistent with the one representation supplied in that PUT; 1134 the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated 1135 representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location 1136 URI. 1137 1137 </p> 1138 1138 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="representation.data" href="#representation.data">Representation Data</a></h2> … … 2564 2564 can be separately identified, bookmarked, and cached independent of the original request. 2565 2565 </p> 2566 <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the <a href="#resources" class="smpl">target resource</a> does not have a representation of its own that can be transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> URI identifies a resource that is descriptive of the target resource, such that the follow-on representation might be useful2567 to recipients without implying that it adequately represents the target resource. Note that answers to the questions of what2568 can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP2569 and thus entirely determined by the URI owner(s).2566 <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the <a href="#resources" class="smpl">target resource</a> does not have a representation of its own that can be transferred by the server over HTTP. The <a href="#header.location" class="smpl">Location</a> field value refers to a resource that is descriptive of the target resource, such that the follow-on representation might 2567 be useful to recipients without implying that it adequately represents the target resource. Note that answers to the questions 2568 of what can be represented, what representations are adequate, and what might be a useful description are outside the scope 2569 of HTTP. 2570 2570 </p> 2571 2571 <p id="rfc.section.6.4.4.p.4">Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with … … 2751 2751 </p> 2752 2752 <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a> <a id="response.header.fields" href="#response.header.fields">Response Header Fields</a></h1> 2753 <p id="rfc.section.7.p.1">The response header fields allow the server to pass additional information about the response which cannot be placed in the 2754 status-line. These header fields give information about the server and about further access to the <a href="#resources" class="smpl">target resource</a>. 2753 <p id="rfc.section.7.p.1">The response header fields allow the server to pass additional information about the response beyond what is placed in the 2754 status-line. These header fields give information about the server, about further access to the <a href="#resources" class="smpl">target resource</a>, or about related resources. 2755 </p> 2756 <p id="rfc.section.7.p.2">Although each response header field has a defined meaning, in general, the precise semantics might be further refined by the 2757 semantics of the request method and/or response status code. 2755 2758 </p> 2756 2759 <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a> <a id="response.control.data" href="#response.control.data">Control Data</a></h2> … … 2895 2898 <div id="rfc.iref.l.1"></div> 2896 2899 <h3 id="rfc.section.7.1.2"><a href="#rfc.section.7.1.2">7.1.2</a> <a id="header.location" href="#header.location">Location</a></h3> 2897 <p id="rfc.section.7.1.2.p.1">The "Location" header field <em class="bcp14">MAY</em> be sent in responses to refer to a specific resource in accordance with the semantics of the status code. 2900 <p id="rfc.section.7.1.2.p.1">The "Location" header field is used in some responses to refer to a specific resource in relation to the response. The type 2901 of relationship is defined by the combination of request method and status code semantics. 2898 2902 </p> 2899 2903 <div id="rfc.figure.u.51"></div><pre class="inline"><span id="rfc.iref.g.56"></span> <a href="#header.location" class="smpl">Location</a> = <a href="#imported.abnf" class="smpl">URI-reference</a> 2900 </pre><p id="rfc.section.7.1.2.p.3"> For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location is the URI of the new resource which was created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource.2901 </p>2902 < p id="rfc.section.7.1.2.p.4">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, did contain a fragment identifier, and the final value does not,2903 then the original URI's fragment identifier is added to the final value.2904 </pre><p id="rfc.section.7.1.2.p.3">The field value consists of a single URI-reference. When it has the form of a relative reference (<a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-4.2">Section 4.2</a>), the final value is computed by resolving it against the effective request URI (<a href="#RFC3986" id="rfc.xref.RFC3986.2"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-5">Section 5</a>). If the original URI, as navigated to by the user agent, contains a fragment identifier, and the Location value does not, 2905 then the original URI's fragment identifier is appended to the Location value. 2906 </p> 2907 <p id="rfc.section.7.1.2.p.4">For <a href="#status.201" class="smpl">201 (Created)</a> responses, the Location value refers to the primary resource created by the request. For <a href="#status.3xx" class="smpl">3xx (Redirection)</a> responses, the Location value refers to the preferred target resource for automatically redirecting the request. 2904 2908 </p> 2905 2909 <div id="rfc.figure.u.52"></div> 2906 <p>For example, the original URI "http://www.example.org/~tim", combined with a field value given as:</p> <pre class="text"> Location: /pub/WWW/People.html#tim 2907 </pre> <p>would result in a final value of "http://www.example.org/pub/WWW/People.html#tim"</p> 2910 <p>For example, a GET request for the URI reference "http://www.example.org/~tim" might result in a <a href="#status.303" class="smpl">303 (See Other)</a> response containing the header field: 2911 </p> <pre class="text"> Location: /pub/WWW/People.html#tim 2912 </pre> <p>which suggests that the user agent redirect to "http://www.example.org/pub/WWW/People.html#tim"</p> 2908 2913 <div id="rfc.figure.u.53"></div> 2909 <p>An original URI "http://www.example.org/index.html#larry", combined with a field value given as:</p> <pre class="text"> Location: http://www.example.net/index.html 2910 </pre> <p>would result in a final value of "http://www.example.net/index.html#larry", preserving the original fragment identifier.</p> 2911 <div class="note" id="rfc.section.7.1.2.p.7"> 2914 <p>Likewise, a GET request for the URI reference "http://www.example.org/index.html#larry" might result in a <a href="#status.301" class="smpl">301 (Moved Permanently)</a> response containing the header field: 2915 </p> <pre class="text"> Location: http://www.example.net/index.html 2916 </pre> <p>which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment 2917 identifier. 2918 </p> 2919 <p id="rfc.section.7.1.2.p.7">There are circumstances in which a fragment identifier in a Location value would not be appropriate. For example, the Location 2920 header field in a <a href="#status.201" class="smpl">201 (Created)</a> response is supposed to provide a URI that is specific to the created resource. 2921 </p> 2922 <div class="note" id="rfc.section.7.1.2.p.8"> 2912 2923 <p> <b>Note:</b> Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate 2913 or define such processing, but does allow it .2924 or define such processing, but does allow it for the sake of robustness. 2914 2925 </p> 2915 2926 </div> 2916 <p id="rfc.section.7.1.2.p.8">There are circumstances in which a fragment identifier in a Location URI would not be appropriate. For instance, when it appears2917 in a <a href="#status.201" class="smpl">2012918 (Created)</a> response, where the Location header field specifies the URI for the entire created resource.2919 </p>2920 2927 <div class="note" id="rfc.section.7.1.2.p.9"> 2921 <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 3.1.4.2</a>) differs from Location in that the Content-Location identifiesthe most specific resource corresponding to the enclosed representation.2922 It is therefore possible for a response to contain header fields for both Location and Content-Location.2928 <p> <b>Note:</b> The <a href="#header.content-location" class="smpl">Content-Location</a> header field (<a href="#header.content-location" id="rfc.xref.header.content-location.3" title="Content-Location">Section 3.1.4.2</a>) differs from Location in that the Content-Location refers to the most specific resource corresponding to the enclosed representation. 2929 It is therefore possible for a response to contain both the Location and Content-Location header fields. 2923 2930 </p> 2924 2931 </div> … … 3099 3106 value of "0". 3100 3107 </p> 3101 <p id="rfc.section.8.1.2.p.3">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section 4.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a>), cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section 4.2.3</a>), and what semantics are to be associated with the payload body if any is present in the request. If a method is cacheable, 3102 the method definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy 3103 a subsequent request. 3108 <p id="rfc.section.8.1.2.p.3">A new method definition needs to indicate whether it is safe (<a href="#safe.methods" title="Safe Methods">Section 4.2.1</a>), idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a>), cacheable (<a href="#cacheable.methods" title="Cacheable Methods">Section 4.2.3</a>), what semantics are to be associated with the payload body if any is present in the request, and what refinements the method 3109 makes to header field or status code semantics. If the new method is cacheable, its definition ought to describe how, and 3110 under what conditions, a cache can store a response and use it to satisfy a subsequent request. If the new method can be made 3111 conditional (<a href="#Part4" id="rfc.xref.Part4.14"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), the definition ought to describe how to respond when the condition is false. Likewise, if the new method might have some 3112 use for partial response semantics (<a href="#Part5" id="rfc.xref.Part5.12"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[Part5]</cite></a>), it ought to document this too. 3104 3113 </p> 3105 3114 <h3 id="rfc.section.8.1.3"><a href="#rfc.section.8.1.3">8.1.3</a> <a id="method.registration" href="#method.registration">Registrations</a></h3> … … 3186 3195 <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a> <a id="considerations.for.new.status.codes" href="#considerations.for.new.status.codes">Considerations for New Status Codes</a></h3> 3187 3196 <p id="rfc.section.8.2.2.p.1">When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can 3188 be registered. HTTP status codes are generic; they are potentially applicable to any resource, not just one particular media3189 type, "type" of resource, or application. As such, it is preferred that new status codes be registered in a document that3197 be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, 3198 kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that 3190 3199 isn't specific to a single application. 3191 3200 </p> 3192 <p id="rfc.section.8.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section 6</a>. To allow existing parsers to pro perly handle them, new status codes cannot disallow a payload, although they can mandate3193 a zero-length payload body.3201 <p id="rfc.section.8.2.2.p.2">New status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Response Status Codes">Section 6</a>. To allow existing parsers to process the response message, new status codes cannot disallow a payload, although they can 3202 mandate a zero-length payload body. 3194 3203 </p> 3195 3204 <p id="rfc.section.8.2.2.p.3">A definition for a new status code ought to explain the request conditions that would cause a response containing that status 3196 3205 code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields 3197 (e.g., what fields are required and what fields can modify the semantics). A response that can transfer a payload ought to 3198 specify expected cache behavior (e.g., cacheability and freshness criteria, as described in <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>). 3206 (e.g., what fields are required, what fields can modify the semantics, and what header field semantics are further refined 3207 when used with the new status code). 3208 </p> 3209 <p id="rfc.section.8.2.2.p.4">A response that can transfer a payload ought to specify expected cache behavior (e.g., cacheability and freshness criteria, 3210 as described in <a href="#Part6" id="rfc.xref.Part6.15"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) and whether the payload has any implied association with an identified resource (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>). 3199 3211 </p> 3200 3212 <h3 id="rfc.section.8.2.3"><a href="#rfc.section.8.2.3">8.2.3</a> <a id="status.code.registration" href="#status.code.registration">Registrations</a></h3> … … 3467 3479 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.34"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>). 3468 3480 </p> 3469 <p>If it does not use the list syntax, document how to treat messages where the header field occurs multiple times (a sensible3470 default would be to ignore the headerfield, but this might not always be the right choice).3481 <p>If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default 3482 would be to ignore the field, but this might not always be the right choice). 3471 3483 </p> 3472 3484 <p>Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the 3473 header field not allowing this. A robust format enables recipients to discover these situations (good example: "Content-Type", 3474 as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a URI). 3485 field's definition not allowing the list syntax. A robust format enables recipients to discover these situations (good example: 3486 "Content-Type", as the comma can only appear inside quoted strings; bad example: "Location", as a comma can occur inside a 3487 URI). 3475 3488 </p> 3476 3489 </li> 3477 3490 <li> 3478 3491 <p>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses 3479 to a particular request method .3492 to a particular request method, etc. 3480 3493 </p> 3494 </li> 3495 <li> 3496 <p>Whether the field semantics are further refined by the context, such as by existing request methods or status codes.</p> 3481 3497 </li> 3482 3498 <li> … … 3485 3501 </li> 3486 3502 <li> 3487 <p>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</p>3503 <p>Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.</p> 3488 3504 </li> 3489 3505 <li> … … 3722 3738 <p id="rfc.section.9.1.p.1">Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any 3723 3739 a priori method of determining the sensitivity of any particular piece of information within the context of any given request. 3724 Therefore, applications <em class="bcp14">SHOULD</em> supply as much control over this information as possible to the provider of that information. Four header fields are worth3725 special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>.3740 Therefore, applications ought to supply as much control over this information as possible to the provider of that information. 3741 Four header fields are worth special mention in this context: <a href="#header.server" class="smpl">Server</a>, <a href="p1-messaging.html#header.via" class="smpl">Via</a>, <a href="#header.referer" class="smpl">Referer</a> and <a href="#header.from" class="smpl">From</a>. 3726 3742 </p> 3727 3743 <p id="rfc.section.9.1.p.2">Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 3728 3744 against software that is known to contain security holes. Implementers <em class="bcp14">SHOULD</em> make the <a href="#header.server" class="smpl">Server</a> header field a configurable option. 3729 3745 </p> 3730 <p id="rfc.section.9.1.p.3">Proxies which serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that identifies thehosts behind the firewall. In particular,3746 <p id="rfc.section.9.1.p.3">Proxies that serve as a portal through a network firewall <em class="bcp14">SHOULD</em> take special precautions regarding the transfer of header information that might identify hosts behind the firewall. In particular, 3731 3747 they <em class="bcp14">SHOULD</em> remove, or replace with sanitized versions, any <a href="p1-messaging.html#header.via" class="smpl">Via</a> fields generated behind the firewall. 3732 3748 </p> … … 4550 4566 </ul> 4551 4567 </li> 4552 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">6.4</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">7.2</a>, <a href="# Part4"><b>11.1</b></a><ul>4568 <li><em>Part4</em> <a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">6.4</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">7.2</a>, <a href="#rfc.xref.Part4.14">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul> 4553 4569 <li><em>Section 2.2</em> <a href="#rfc.xref.Part4.13">7.2</a></li> 4554 4570 <li><em>Section 2.3</em> <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.12">7.2</a></li> … … 4562 4578 </ul> 4563 4579 </li> 4564 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.5">4.3.4</a>, <a href="#rfc.xref.Part5.6">5.1</a>, <a href="#rfc.xref.Part5.7">5.2</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">6.1</a>, <a href="#rfc.xref.Part5.11">7.4</a>, <a href="# Part5"><b>11.1</b></a><ul>4580 <li><em>Part5</em> <a href="#rfc.xref.Part5.1">3.1.1.4</a>, <a href="#rfc.xref.Part5.2">3.3</a>, <a href="#rfc.xref.Part5.3">4.3.1</a>, <a href="#rfc.xref.Part5.4">4.3.1</a>, <a href="#rfc.xref.Part5.5">4.3.4</a>, <a href="#rfc.xref.Part5.6">5.1</a>, <a href="#rfc.xref.Part5.7">5.2</a>, <a href="#rfc.xref.Part5.8">6.1</a>, <a href="#rfc.xref.Part5.9">6.1</a>, <a href="#rfc.xref.Part5.10">6.1</a>, <a href="#rfc.xref.Part5.11">7.4</a>, <a href="#rfc.xref.Part5.12">8.1.2</a>, <a href="#Part5"><b>11.1</b></a><ul> 4565 4581 <li><em>Section 3</em> <a href="#rfc.xref.Part5.8">6.1</a></li> 4566 4582 <li><em>Section 3.1</em> <a href="#rfc.xref.Part5.9">6.1</a></li>
Note: See TracChangeset
for help on using the changeset viewer.