![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 678 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- Aug 13, 2009, 1:19:31 AM (10 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p2-semantics.html (modified) (19 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r675 r678 399 399 <meta name="DC.Creator" content="Reschke, J. F."> 400 400 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-08-1 2">401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-08-13"> 402 402 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 403 403 <meta name="DC.Description.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 "HTTP/1.1" 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."> … … 435 435 </tr> 436 436 <tr> 437 <td class="header left">Expires: February 1 3, 2010</td>437 <td class="header left">Expires: February 14, 2010</td> 438 438 <td class="header right">H. Frystyk</td> 439 439 </tr> … … 484 484 <tr> 485 485 <td class="header left"></td> 486 <td class="header right">August 1 2, 2009</td>486 <td class="header right">August 13, 2009</td> 487 487 </tr> 488 488 </table> … … 508 508 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 509 509 </p> 510 <p>This Internet-Draft will expire in February 1 3, 2010.</p>510 <p>This Internet-Draft will expire in February 14, 2010.</p> 511 511 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 512 512 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 714 714 <div id="rfc.figure.u.2"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">absolute-URI</a> = <absolute-URI, defined in <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 715 715 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 716 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 2.10.1</a>>716 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#date.time.formats.full.date" title="Date/Time Formats: Full Date">Section 6.1</a>> 717 717 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in <a href="#Part1" id="rfc.xref.Part1.13"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 718 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 2.10.3</a>>719 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><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 3.8</a>>718 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a>> 719 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in <a href="#Part1" id="rfc.xref.Part1.15"><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>> 720 720 <a href="#abnf.dependencies" class="smpl">URI</a> = <URI, defined in <a href="#Part1" id="rfc.xref.Part1.16"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.6</a>> 721 721 </pre><div id="rfc.figure.u.3"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Accept</a> = <Accept, defined in <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>> … … 789 789 / <a href="#header.expect" class="smpl">Expect</a> ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 9.2</a> 790 790 / <a href="#header.from" class="smpl">From</a> ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 9.3</a> 791 / <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 3.4</a>791 / <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> 792 792 / <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> 793 793 / <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> … … 799 799 / <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> 800 800 / <a href="#header.referer" class="smpl">Referer</a> ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 9.6</a> 801 / <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 3.8</a>801 / <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> 802 802 / <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 9.9</a> 803 803 </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 … … 894 894 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>. 895 895 </p> 896 <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 2.7.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 ensure896 <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 897 897 safe and proper transfer of the message. 898 898 </p> … … 1052 1052 </p> 1053 1053 <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 1054 or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 3.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 the1054 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 1055 1055 client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an 1056 1056 infinite loop. 1057 1057 </p> 1058 <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 4.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.1058 <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. 1059 1059 </p> 1060 1060 <div id="rfc.iref.c.1"></div> … … 1083 1083 <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 1084 1084 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 1085 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 2.11.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.1085 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. 1086 1086 </p> 1087 1087 <div id="rfc.iref.26"></div> … … 1510 1510 </p> 1511 1511 <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> 1512 <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 2.11.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.1512 <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. 1513 1513 </p> 1514 1514 <div id="rfc.iref.f.1"></div> … … 1612 1612 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1613 1613 <p id="rfc.section.9.8.p.1">The response-header field "Server" contains information about the software used by the origin server to handle the request. 1614 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 2.10.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 identifying the server and any significant subproducts. The product tokens are listed in order of their significance1614 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 identifying the server and any significant subproducts. The product tokens are listed in order of their significance 1615 1615 for identifying the application. 1616 1616 </p> … … 1620 1620 </pre><p id="rfc.section.9.8.p.3">Example:</p> 1621 1621 <div id="rfc.figure.u.26"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1622 </pre><p id="rfc.section.9.8.p.5">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 3.9</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>).1622 </pre><p id="rfc.section.9.8.p.5">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.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1623 1623 </p> 1624 1624 <div class="note"> … … 1633 1633 <p id="rfc.section.9.9.p.1">The request-header field "User-Agent" contains information about the user agent originating the request. This is for statistical 1634 1634 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1635 to avoid particular user agent limitations. 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 2.10.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>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the1635 to avoid particular user agent limitations. 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.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the 1636 1636 product tokens are listed in order of their significance for identifying the application. 1637 1637 </p> … … 2261 2261 </p> 2262 2262 <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 2263 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 3.9</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>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 9.8</a>)2263 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.28"><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 9.8</a>) 2264 2264 </p> 2265 2265 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1> … … 2281 2281 <a href="#header.from" class="smpl">From-v</a> = mailbox 2282 2282 2283 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part1], Section 2.10.1>2283 <a href="#abnf.dependencies" class="smpl">HTTP-date</a> = <HTTP-date, defined in [Part1], Section 6.1> 2284 2284 <a href="#abnf.dependencies" class="smpl">Host</a> = <Host, defined in [Part1], Section 2.6> 2285 2285 … … 2331 2331 "505" / extension-code 2332 2332 2333 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in [Part1], Section 3.8>2333 <a href="#abnf.dependencies" class="smpl">TE</a> = <TE, defined in [Part1], Section 9.8> 2334 2334 2335 2335 <a href="#abnf.dependencies" class="smpl">URI</a> = <URI, defined in [Part1], Section 2.6> … … 2360 2360 2361 2361 <a href="#abnf.dependencies" class="smpl">partial-URI</a> = <partial-URI, defined in [Part1], Section 2.6> 2362 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in [Part1], Section 2.10.3>2362 <a href="#abnf.dependencies" class="smpl">product</a> = <product, defined in [Part1], Section 6.3> 2363 2363 2364 2364 <a href="#core.rules" class="smpl">quoted-string</a> = <quoted-string, defined in [Part1], Section 1.2.2> … … 2693 2693 <li class="indline1"><em>Section 2.5</em> <a class="iref" href="#rfc.xref.Part1.23">8.5.6</a></li> 2694 2694 <li class="indline1"><em>Section 2.6</em> <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.13">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.16">1.2.2</a></li> 2695 <li class="indline1"><em>Section 2.7.3</em> <a class="iref" href="#rfc.xref.Part1.19">6</a></li>2696 <li class="indline1"><em>Section 2.10.1</em> <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li>2697 <li class="indline1"><em>Section 2.10.3</em> <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.27">9.9</a></li>2698 <li class="indline1"><em>Section 2.11.2.3</em> <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li>2699 <li class="indline1"><em>Section 3.4</em> <a class="iref" href="#rfc.xref.Part1.17">3</a></li>2700 <li class="indline1"><em>Section 3.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a></li>2701 <li class="indline1"><em>Section 3.9</em> <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a></li>2702 <li class="indline1"><em>Section 4.3.1</em> <a class="iref" href="#rfc.xref.Part1.21">7.8</a></li>2695 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part1.19">6</a></li> 2696 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part1.12">1.2.2</a></li> 2697 <li class="indline1"><em>Section 6.3</em> <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.27">9.9</a></li> 2698 <li class="indline1"><em>Section 7.2.3</em> <a class="iref" href="#rfc.xref.Part1.22">8.1.1</a>, <a class="iref" href="#rfc.xref.Part1.24">9.2</a></li> 2699 <li class="indline1"><em>Section 9.4</em> <a class="iref" href="#rfc.xref.Part1.17">3</a></li> 2700 <li class="indline1"><em>Section 9.8</em> <a class="iref" href="#rfc.xref.Part1.15">1.2.2</a>, <a class="iref" href="#rfc.xref.Part1.18">3</a></li> 2701 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part1.20">7.8</a>, <a class="iref" href="#rfc.xref.Part1.26">9.8</a>, <a class="iref" href="#rfc.xref.Part1.28">A.2</a></li> 2702 <li class="indline1"><em>Section 10.3.1</em> <a class="iref" href="#rfc.xref.Part1.21">7.8</a></li> 2703 2703 </ul> 2704 2704 </li>
Note: See TracChangeset
for help on using the changeset viewer.
