Changeset 2180


Ignore:
Timestamp:
11/02/13 09:14:49 (7 years ago)
Author:
julian.reschke@…
Message:

re-gen HTML

Location:
draft-ietf-httpbis/latest
Files:
3 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r2178 r2180  
    449449  }
    450450  @bottom-center {
    451        content: "Expires August 10, 2013";
     451       content: "Expires August 15, 2013";
    452452  }
    453453  @bottom-right {
     
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-02-06">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-02-11">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2145">
    495495      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
     
    520520            <tr>
    521521               <td class="left">Intended status: Standards Track</td>
    522                <td class="right">February 6, 2013</td>
     522               <td class="right">February 11, 2013</td>
    523523            </tr>
    524524            <tr>
    525                <td class="left">Expires: August 10, 2013</td>
     525               <td class="left">Expires: August 15, 2013</td>
    526526               <td class="right"></td>
    527527            </tr>
     
    551551         in progress”.
    552552      </p>
    553       <p>This Internet-Draft will expire on August 10, 2013.</p>
     553      <p>This Internet-Draft will expire on August 15, 2013.</p>
    554554      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    555555      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2177 r2180  
    449449  }
    450450  @bottom-center {
    451        content: "Expires August 5, 2013";
     451       content: "Expires August 15, 2013";
    452452  }
    453453  @bottom-right {
     
    494494      <meta name="dct.creator" content="Reschke, J. F.">
    495495      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    496       <meta name="dct.issued" scheme="ISO8601" content="2013-02-01">
     496      <meta name="dct.issued" scheme="ISO8601" content="2013-02-11">
    497497      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    498498      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    522522            <tr>
    523523               <td class="left">Intended status: Standards Track</td>
    524                <td class="right">February 1, 2013</td>
     524               <td class="right">February 11, 2013</td>
    525525            </tr>
    526526            <tr>
    527                <td class="left">Expires: August 5, 2013</td>
     527               <td class="left">Expires: August 15, 2013</td>
    528528               <td class="right"></td>
    529529            </tr>
     
    553553         in progress”.
    554554      </p>
    555       <p>This Internet-Draft will expire on August 5, 2013.</p>
     555      <p>This Internet-Draft will expire on August 15, 2013.</p>
    556556      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    557557      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    33023302         to indicate the class of the proposed status code(s) without consuming a number prematurely.
    33033303      </p>
    3304       <p id="rfc.section.8.2.2.p.4">A definition for a new status code ought to explain the request conditions that would cause a response containing that status
     3304      <p id="rfc.section.8.2.2.p.4">The definition of a new status code ought to explain the request conditions that would cause a response containing that status
    33053305         code (e.g., combinations of request header fields and/or method(s)) along with any dependencies on response header fields
    33063306         (e.g., what fields are required, what fields can modify the semantics, and what header field semantics are further refined
    33073307         when used with the new status code).
    33083308      </p>
    3309       <p id="rfc.section.8.2.2.p.5">A response that can transfer a payload ought to specify expected cache behavior (e.g., cacheability and freshness criteria,
    3310          as described in <a href="#Part6" id="rfc.xref.Part6.23"><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&nbsp;3.1.4.1</a>).
     3309      <p id="rfc.section.8.2.2.p.5">The definition of a new status code ought to specify whether or not it is cacheable. Note that all status codes can be cached
     3310         if the response they occur in has explicit freshness information; however, status codes that are defined as being cacheable
     3311         are allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints
     3312         upon cache behaviour. See <a href="#Part6" id="rfc.xref.Part6.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for more information.
     3313      </p>
     3314      <p id="rfc.section.8.2.2.p.6">Finally, the definition of a new status code ought to indicate whether the payload has any implied association with an identified
     3315         resource (<a href="#identifying.payload" title="Identifying a Representation">Section&nbsp;3.1.4.1</a>).
    33113316      </p>
    33123317      <h3 id="rfc.section.8.2.3"><a href="#rfc.section.8.2.3">8.2.3</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Registrations</a></h3>
  • draft-ietf-httpbis/latest/p6-cache.html

    r2177 r2180  
    452452  }
    453453  @bottom-center {
    454        content: "Expires August 5, 2013";
     454       content: "Expires August 15, 2013";
    455455  }
    456456  @bottom-right {
     
    498498      <meta name="dct.creator" content="Reschke, J. F.">
    499499      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    500       <meta name="dct.issued" scheme="ISO8601" content="2013-02-01">
     500      <meta name="dct.issued" scheme="ISO8601" content="2013-02-11">
    501501      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    502502      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
     
    524524            </tr>
    525525            <tr>
    526                <td class="left">Expires: August 5, 2013</td>
     526               <td class="left">Expires: August 15, 2013</td>
    527527               <td class="right">J. Reschke, Editor</td>
    528528            </tr>
     
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">February 1, 2013</td>
     535               <td class="right">February 11, 2013</td>
    536536            </tr>
    537537         </tbody>
     
    559559         in progress”.
    560560      </p>
    561       <p>This Internet-Draft will expire on August 5, 2013.</p>
     561      <p>This Internet-Draft will expire on August 15, 2013.</p>
    562562      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    563563      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    825825               <li>contains a Cache Control Extension (see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;7.2.3</a>) that allows it to be cached, or
    826826               </li>
    827                <li>has a status code that can be served with heuristic freshness (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>).
     827               <li>has a status code that is defined as cacheable (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>), or
    828828               </li>
     829               <li>contains a public response cache directive.</li>
    829830            </ul>
    830831         </li>
     
    905906         it for subsequent requests (see <a href="#serving.stale.responses" title="Serving Stale Responses">Section&nbsp;4.1.4</a>).
    906907      </p>
    907       <p id="rfc.section.4.1.p.4">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
    908          values (such as the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case
    909          constraints on their results.
     908      <p id="rfc.section.4.1.p.4">Since origin servers do not always provide explicit expiration times, caches are also allowed to use a heuristic to determine
     909         an expiration time under certain circumstances (see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;4.1.2</a>).
    910910      </p>
    911911      <div id="rfc.figure.u.2"></div>
     
    936936      </p>
    937937      <h3 id="rfc.section.4.1.2"><a href="#rfc.section.4.1.2">4.1.2</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h3>
    938       <p id="rfc.section.4.1.2.p.1">A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness unless no explicit expiration time is present in a stored response and either the status
    939          code is defined as cacheable by default (including the following in <a href="p2-semantics.html#status.codes" title="Response Status Codes">Section 6</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>: <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>, <a href="p2-semantics.html#status.203" class="smpl">203 (Non-Authoritative
    940             Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300
    941             (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>) or the response has been explicitly marked as cacheable (e.g., by using the public directive without a max-age).
    942       </p>
    943       <p id="rfc.section.4.1.2.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already
     938      <p id="rfc.section.4.1.2.p.1">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
     939         values (such as the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case
     940         constraints on their results.
     941      </p>
     942      <p id="rfc.section.4.1.2.p.2">A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness when an explicit expiration time is present in the stored response. Because of the requirements
     943         in <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a>, this means that, effectively, heuristics can only be used on responses without explicit freshness whose status codes are
     944         defined as cacheable, and responses without explicit freshness that have been marked as explicitly cacheable (e.g., with a
     945         "public" response cache directive).
     946      </p>
     947      <p id="rfc.section.4.1.2.p.3">If the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
     948         time. A typical setting of this fraction might be 10%.
     949      </p>
     950      <p id="rfc.section.4.1.2.p.4">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already
    944951         present.
    945952      </p>
    946       <p id="rfc.section.4.1.2.p.3">Also, if the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
    947          time. A typical setting of this fraction might be 10%.
    948       </p>
    949       <div class="note" id="rfc.section.4.1.2.p.4">
     953      <div class="note" id="rfc.section.4.1.2.p.5">
    950954         <p> <b>Note:</b>  <a href="http://tools.ietf.org/html/rfc2616#section-13.9">Section 13.9</a> of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a> prohibited caches from calculating heuristic freshness for URIs with query components (i.e., those containing '?'). In practice,
    951955            this has not been widely implemented. Therefore, servers are encouraged to send explicit directives (e.g., Cache-Control:
     
    969973      </p>
    970974      <ul class="empty">
    971          <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
     975         <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
    972976         </li>
    973977      </ul>
     
    10911095      </ul>
    10921096      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Using Negotiated Responses</a></h2>
    1093       <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
     1097      <p id="rfc.section.4.3.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="p2-semantics.html#header.vary" class="smpl">Vary</a> header field (<a href="p2-semantics.html#header.vary" title="Vary">Section 7.1.4</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
    10941098         request (i.e., that associated with the stored response), and the presented request.
    10951099      </p>
     
    11501154      </ul>
    11511155      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="invalidation.after.updates.or.deletions" href="#invalidation.after.updates.or.deletions">Request Methods that Invalidate</a></h1>
    1152       <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
     1156      <p id="rfc.section.6.p.1">Because unsafe request methods (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 4.2.1</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) such as PUT, POST or DELETE have the potential for changing state on the origin server, intervening caches can use them
    11531157         to keep their contents up-to-date.
    11541158      </p>
     
    12711275      <div id="rfc.iref.p.2"></div>
    12721276      <h4 id="rfc.section.7.2.2.1"><a href="#rfc.section.7.2.2.1">7.2.2.1</a>&nbsp;<a id="cache-response-directive.public" href="#cache-response-directive.public">public</a></h4>
    1273       <p id="rfc.section.7.2.2.1.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response and reuse it for later requests, even if the response would normally be non-cacheable or cacheable only
    1274          within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>.)
     1277      <p id="rfc.section.7.2.2.1.p.1">The "public" response directive indicates that any cache <em class="bcp14">MAY</em> store the response, even if the response would normally be non-cacheable or cacheable only within a non-shared cache. (See <a href="#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section&nbsp;3.2</a> for additional details related to the use of public in response to a request containing <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a>, and <a href="#response.cacheability" title="Storing Responses in Caches">Section&nbsp;3</a> for details of how public affects responses that would normally not be stored, due to their status codes not being defined
     1278         as cacheable.)
    12751279      </p>
    12761280      <div id="rfc.iref.p.3"></div>
     
    14191423         that time.
    14201424      </p>
    1421       <p id="rfc.section.7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     1425      <p id="rfc.section.7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    14221426      </p>
    14231427      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
     
    17761780      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="security.considerations" href="#security.considerations">Security Considerations</a></h1>
    17771781      <p id="rfc.section.10.p.1">This section is meant to inform developers, information providers, and users of known security concerns specific to HTTP/1.1
    1778          caching. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
     1782         caching. More general security considerations are addressed in HTTP messaging <a href="#Part1" id="rfc.xref.Part1.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a> and semantics <a href="#Part2" id="rfc.xref.Part2.8"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
    17791783      </p>
    17801784      <p id="rfc.section.10.p.2">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
     
    19501954  <a href="#imported.abnf" class="smpl">uri-host</a>      = &lt;uri-host, defined in <a href="#Part1" id="rfc.xref.Part1.20"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>, <a href="p1-messaging.html#uri" title="Uniform Resource Identifiers">Section 2.7</a>&gt;
    19511955</pre><p id="rfc.section.B.p.4">The rules below are defined in other parts:</p>
    1952       <div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
     1956      <div id="rfc.figure.u.15"></div><pre class="inline">  <a href="#imported.abnf" class="smpl">HTTP-date</a>     = &lt;HTTP-date, defined in <a href="#Part2" id="rfc.xref.Part2.9"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>, <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a>&gt;
    19531957</pre><h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>
    19541958      <div id="rfc.figure.u.16"></div> <pre class="inline"><a href="#header.age" class="smpl">Age</a> = delta-seconds
     
    21422146                     </ul>
    21432147                  </li>
    2144                   <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1.2</a>, <a href="#rfc.xref.Part2.5">4.1.3</a>, <a href="#rfc.xref.Part2.6">4.3</a>, <a href="#rfc.xref.Part2.7">6</a>, <a href="#rfc.xref.Part2.8">7.3</a>, <a href="#rfc.xref.Part2.9">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.10">B</a><ul>
    2145                         <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.7">6</a></li>
     2148                  <li><em>Part2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.1">2</a>, <a href="#rfc.xref.Part2.2">2</a>, <a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.4">4.1.3</a>, <a href="#rfc.xref.Part2.5">4.3</a>, <a href="#rfc.xref.Part2.6">6</a>, <a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.8">10</a>, <a href="#Part2"><b>12.1</b></a>, <a href="#rfc.xref.Part2.9">B</a><ul>
     2149                        <li><em>Section 4.2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.3">4</a>, <a href="#rfc.xref.Part2.6">6</a></li>
    21462150                        <li><em>Section 4.3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.2">2</a></li>
    2147                         <li><em>Section 6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.2</a></li>
    2148                         <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.8">7.3</a>, <a href="#rfc.xref.Part2.10">B</a></li>
    2149                         <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.1.3</a></li>
    2150                         <li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.6">4.3</a></li>
     2151                        <li><em>Section 7.1.1.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.7">7.3</a>, <a href="#rfc.xref.Part2.9">B</a></li>
     2152                        <li><em>Section 7.1.1.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.4">4.1.3</a></li>
     2153                        <li><em>Section 7.1.4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part2.5">4.3</a></li>
    21512154                     </ul>
    21522155                  </li>
Note: See TracChangeset for help on using the changeset viewer.