Changeset 970


Ignore:
Timestamp:
31/07/10 08:54:31 (12 years ago)
Author:
julian.reschke@…
Message:

regen HTML

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r968 r970  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 1 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: January 31, 2011</td>
     437               <td class="left">Expires: February 1, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 30, 2010</td>
     490               <td class="right">July 31, 2010</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </p>
    518       <p>This Internet-Draft will expire in January 31, 2011.</p>
     518      <p>This Internet-Draft will expire in February 1, 2011.</p>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    724724      <p id="rfc.section.1.p.4">One consequence of HTTP flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead,
    725725         we are limited to defining the syntax of communication, the intent of received communication, and the expected behavior of
    726          recipients. If the communication is considered in isolation, then successful actions should be reflected in corresponding
     726         recipients. If the communication is considered in isolation, then successful actions ought to be reflected in corresponding
    727727         changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps
    728728         at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
    … …  
    11441144      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="message.robustness" href="#message.robustness">Message Parsing Robustness</a></h2>
    11451145      <p id="rfc.section.3.1.p.1">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a Request-Line is expected. In other words, if the server is reading the protocol
    1146          stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
     1146         stream at the beginning of a message and receives a CRLF first, it <em class="bcp14">SHOULD</em> ignore the CRLF.
    11471147      </p>
    11481148      <p id="rfc.section.3.1.p.2">Some old HTTP/1.0 client implementations generate an extra CRLF after a POST request as a lame workaround for some early server
    … …  
    12491249            <p>If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the Transfer-Encoding
    12501250               overrides the Content-Length. Such a message might indicate an attempt to perform request or response smuggling (bypass of
    1251                security-related checks on message routing or content) and thus should be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding
     1251               security-related checks on message routing or content) and thus ought to be handled as an error. The provided Content-Length <em class="bcp14">MUST</em> be removed, prior to forwarding the message downstream, or replaced with the real message-body length after the transfer-coding
    12521252               is decoded.
    12531253            </p>
    … …  
    13791379      <div class="note" id="rfc.section.4.1.2.p.18">
    13801380         <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using
    1381             a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been
     1381            a non-reserved URI character for a reserved purpose. Implementors need to be aware that some pre-HTTP/1.1 proxies have been
    13821382            known to rewrite the request-target.
    13831383         </p>
    … …  
    22222222      <h3 id="rfc.section.9.8.1"><a href="#rfc.section.9.8.1">9.8.1</a>&nbsp;<a id="upgrade.token.registry" href="#upgrade.token.registry">Upgrade Token Registry</a></h3>
    22232223      <p id="rfc.section.9.8.1.p.1">The HTTP Upgrade Token Registry defines the name space for product tokens used to identify protocols in the Upgrade header
    2224          field. Each registered token should be associated with one or a set of specifications, and with contact information.
    2225       </p>
    2226       <p id="rfc.section.9.8.1.p.2">Registrations should be allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. These specifications need not be IETF documents or be subject to IESG review, but should obey the following rules:
     2224         field. Each registered token is associated with contact information and an optional set of specifications that details how
     2225         the connection will be processed after it has been upgraded.
     2226      </p>
     2227      <p id="rfc.section.9.8.1.p.2">Registrations are allowed on a First Come First Served basis as described in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.2"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>. The specifications need not be IETF documents or be subject to IESG review. Registrations are subject to the following rules:
    22272228      </p>
    22282229      <ol>
    … …  
    22322233         <li>The registration <em class="bcp14">MUST</em> name a point of contact.
    22332234         </li>
    2234          <li>The registration <em class="bcp14">MAY</em> name the documentation required for the token.
     2235         <li>The registration <em class="bcp14">MAY</em> name a set of specifications associated with that token. Such specifications need not be publicly available.
    22352236         </li>
    22362237         <li>The responsible party <em class="bcp14">MAY</em> change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
    … …  
    22412242         </li>
    22422243      </ol>
    2243       <p id="rfc.section.9.8.1.p.3">It is not required that specifications for upgrade tokens be made publicly available, but the contact information for the
    2244          registration should be.
    2245       </p>
    22462244      <div id="rfc.iref.v.1"></div>
    22472245      <div id="rfc.iref.h.15"></div>
    … …  
    22902288      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    22912289      <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2292       <p id="rfc.section.10.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2290      <p id="rfc.section.10.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    22932291      </p>
    22942292      <div id="rfc.table.1">
    … …  
    23722370      <p id="rfc.section.10.1.p.2">The change controller is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".</p>
    23732371      <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a>&nbsp;<a id="uri.scheme.registration" href="#uri.scheme.registration">URI Scheme Registration</a></h2>
    2374       <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; should be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
     2372      <p id="rfc.section.10.2.p.1">The entries for the "http" and "https" URI Schemes in the registry located at &lt;<a href="http://www.iana.org/assignments/uri-schemes.html">http://www.iana.org/assignments/uri-schemes.html</a>&gt; shall be updated to point to Sections <a href="#http.uri" title="http URI scheme">2.6.1</a> and <a href="#https.uri" title="https URI scheme">2.6.2</a> of this document (see <a href="#RFC4395" id="rfc.xref.RFC4395.1"><cite title="Guidelines and Registration Procedures for New URI Schemes">[RFC4395]</cite></a>).
    23752373      </p>
    23762374      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="internet.media.type.http" href="#internet.media.type.http">Internet Media Type Registrations</a></h2>
    … …  
    24912489      <p id="rfc.section.10.4.p.1">The registration procedure for HTTP Transfer Codings is now defined by <a href="#transfer.coding.registry" title="Transfer Coding Registry">Section&nbsp;6.2.3</a> of this document.
    24922490      </p>
    2493       <p id="rfc.section.10.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registrations below:
     2491      <p id="rfc.section.10.4.p.2">The HTTP Transfer Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registrations below:
    24942492      </p>
    24952493      <div id="rfc.table.2">
    … …  
    25352533      <p id="rfc.section.10.5.p.1">The registration procedure for HTTP Upgrade Tokens -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section&nbsp;9.8.1</a> of this document.
    25362534      </p>
    2537       <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; should be updated with the registration below:
     2535      <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>&gt; shall be updated with the registration below:
    25382536      </p>
    25392537      <div id="rfc.table.u.1">
    … …  
    26072605         might be used in the commission of a wide range of potential attacks.
    26082606      </p>
    2609       <p id="rfc.section.11.5.p.2">Proxy operators should protect the systems on which proxies run as they would protect any system that contains or transports
     2607      <p id="rfc.section.11.5.p.2">Proxy operators need to protect the systems on which proxies run as they would protect any system that contains or transports
    26102608         sensitive information. In particular, log information gathered at proxies often contains highly sensitive personal information,
    2611          and/or information about organizations. Log information should be carefully guarded, and appropriate guidelines for use should
    2612          be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
    2613       </p>
    2614       <p id="rfc.section.11.5.p.3">Proxy implementors should consider the privacy and security implications of their design and coding decisions, and of the
     2609         and/or information about organizations. Log information needs to be carefully guarded, and appropriate guidelines for use
     2610         need to be developed and followed. (<a href="#abuse.of.server.log.information" title="Abuse of Server Log Information">Section&nbsp;11.2</a>).
     2611      </p>
     2612      <p id="rfc.section.11.5.p.3">Proxy implementors need to consider the privacy and security implications of their design and coding decisions, and of the
    26152613         configuration options they provide to proxy operators (especially the default configuration).
    26162614      </p>

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

    r968 r970  
    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-07-30">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    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: January 31, 2011</td>
     436               <td class="left">Expires: February 1, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 30, 2010</td>
     489               <td class="right">July 31, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </p>
    516       <p>This Internet-Draft will expire in January 31, 2011.</p>
     516      <p>This Internet-Draft will expire in February 1, 2011.</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>
    … …  
    938938      <div id="rfc.iref.s.1"></div>
    939939      <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="safe.methods" href="#safe.methods">Safe Methods</a></h3>
    940       <p id="rfc.section.7.1.1.p.1">Implementors should be aware that the software represents the user in their interactions over the Internet, and should be
    941          careful to allow the user to be aware of any actions they take which might have an unexpected significance to themselves or
    942          others.
     940      <p id="rfc.section.7.1.1.p.1">Implementors need to be aware that the software represents the user in their interactions over the Internet, and need to allow
     941         the user to be aware of any actions they take which might have an unexpected significance to themselves or others.
    943942      </p>
    944943      <p id="rfc.section.7.1.1.p.2">In particular, the convention has been established that the GET, HEAD, OPTIONS, and TRACE methods <em class="bcp14">SHOULD NOT</em> have the significance of taking an action other than retrieval. These methods ought to be considered "<dfn id="safe">safe</dfn>". This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is
    … …  
    12251224      </p>
    12261225      <div class="note" id="rfc.section.8.3.p.2">
    1227          <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers should be aware that there might be clients that implement such a fixed limitation.
     1226         <p> <b>Note:</b> An earlier version of this specification recommended a maximum of five redirections (<a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, <a href="http://tools.ietf.org/html/rfc2068#section-10.3">Section 10.3</a>). Content developers need to be aware that some clients might implement such a fixed limitation.
    12281227         </p>
    12291228      </div>
    … …  
    16351634      <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.
    16361635         It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling
    1637          where they allow links from (so-called "deep linking"), but it should be noted that legitimate requests are not required to
    1638          contain a Referer header field.
     1636         where they allow links from (so-called "deep linking"), but legitimate requests do not always contain a Referer header field.
    16391637      </p>
    16401638      <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),
    … …  
    17051703      <p id="rfc.section.10.1.p.1">The registration procedure for HTTP Methods is defined by <a href="#method.registry" title="Method Registry">Section&nbsp;2.1</a> of this document.
    17061704      </p>
    1707       <p id="rfc.section.10.1.p.2">The HTTP Method Registry should be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
     1705      <p id="rfc.section.10.1.p.2">The HTTP Method Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-methods">http://www.iana.org/assignments/http-methods</a>&gt; and be populated with the registrations below:
    17081706      </p>
    17091707      <div id="rfc.table.1">
    … …  
    17721770      <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> -- is now defined by <a href="#status.code.registry" title="Status Code Registry">Section&nbsp;4.1</a> of this document.
    17731771      </p>
    1774       <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; should be updated with the registrations below:
     1772      <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    17751773      </p>
    17761774      <div id="rfc.table.2">
    … …  
    20052003      </div>
    20062004      <h2 id="rfc.section.10.3"><a href="#rfc.section.10.3">10.3</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    2007       <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     2005      <p id="rfc.section.10.3.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    20082006      </p>
    20092007      <div id="rfc.table.3">
    … …  
    21282126      <p id="rfc.section.11.2.p.2">Clients <em class="bcp14">SHOULD NOT</em> include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol.
    21292127      </p>
    2130       <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
    2131          in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it
    2132          might be visible to third parties. Such services can use POST-based form submission instead.
     2128      <p id="rfc.section.11.2.p.3">Authors of services <em class="bcp14">SHOULD NOT</em> use GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing
     2129         servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties.
     2130         Such services can use POST-based form submission instead.
    21332131      </p>
    21342132      <h2 id="rfc.section.11.3"><a href="#rfc.section.11.3">11.3</a>&nbsp;<a id="location.spoofing" href="#location.spoofing">Location Headers and Spoofing</a></h2>

  • draft-ietf-httpbis/latest/p3-payload.html

    r968 r970  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <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 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 31, 2011</td>
     430               <td class="left">Expires: February 1, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    485485            <tr>
    486486               <td class="left"></td>
    487                <td class="right">July 30, 2010</td>
     487               <td class="right">July 31, 2010</td>
    488488            </tr>
    489489         </tbody>
    … …  
    511511         in progress”.
    512512      </p>
    513       <p>This Internet-Draft will expire in January 31, 2011.</p>
     513      <p>This Internet-Draft will expire in February 1, 2011.</p>
    514514      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    515515      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    715715         of the charset parameter can be quoted.
    716716      </p>
    717       <p id="rfc.section.2.1.p.8">Implementors should be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
     717      <p id="rfc.section.2.1.p.8">Implementors need to be aware of IETF character set requirements <a href="#RFC3629" id="rfc.xref.RFC3629.1"><cite title="UTF-8, a transformation format of ISO 10646">[RFC3629]</cite></a>  <a href="#RFC2277" id="rfc.xref.RFC2277.1"><cite title="IETF Policy on Character Sets and Languages">[RFC2277]</cite></a>.
    718718      </p>
    719719      <h3 id="rfc.section.2.1.1"><a href="#rfc.section.2.1.1">2.1.1</a>&nbsp;<a id="missing.charset" href="#missing.charset">Missing Charset</a></h3>
    … …  
    12061206      <div class="note" id="rfc.section.6.4.p.10">
    12071207         <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not
    1208             familiar with the details of language matching as described above, and should provide appropriate guidance. As an example,
     1208            familiar with the details of language matching as described above, and ought to be provided appropriate guidance. As an example,
    12091209            users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available.
    12101210            A user agent might suggest in such a case to add "en" to get the best matching behavior.
    … …  
    13551355      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    13561356      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1357       <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1357      <p id="rfc.section.7.1.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    13581358      </p>
    13591359      <div id="rfc.table.1">
    … …  
    14531453      <p id="rfc.section.7.2.p.1">The registration procedure for HTTP Content Codings is now defined by <a href="#content.coding.registry" title="Content Coding Registry">Section&nbsp;2.2.1</a> of this document.
    14541454      </p>
    1455       <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; should be updated with the registration below:
     1455      <p id="rfc.section.7.2.p.2">The HTTP Content Codings Registry located at &lt;<a href="http://www.iana.org/assignments/http-parameters">http://www.iana.org/assignments/http-parameters</a>&gt; shall be updated with the registration below:
    14561456      </p>
    14571457      <div id="rfc.table.2">
    … …  
    17441744         CR and LF, as is the case for some multi-byte character sets.
    17451745      </p>
    1746       <p id="rfc.section.A.2.p.3">Implementors should note that conversion will break any cryptographic checksums applied to the original content unless the
    1747          original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such
    1748          checksums in HTTP.
     1746      <p id="rfc.section.A.2.p.3">Conversion will break any cryptographic checksums applied to the original content unless the original content is already in
     1747         canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
    17491748      </p>
    17501749      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="conversion.of.date.formats" href="#conversion.of.date.formats">Conversion of Date Formats</a></h2>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r968 r970  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <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 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 31, 2011</td>
     428               <td class="left">Expires: February 1, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 30, 2010</td>
     485               <td class="right">July 31, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 31, 2011.</p>
     511      <p>This Internet-Draft will expire in February 1, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    881881      </p>
    882882      <ul class="empty">
    883          <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients should transmit as much non-redundant information
     883         <li> <b>Note:</b> The general principle behind these rules is that HTTP/1.1 servers and clients ought to transmit as much non-redundant information
    884884            as is available in their responses and requests. HTTP/1.1 systems receiving this information will make the most conservative
    885885            assumptions about the validators they receive.
    … …  
    989989         </li>
    990990         <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header instead of a date taken from the Last-Modified header for
    991             the same request, the client should be aware of the fact that this date is interpreted in the server's understanding of time.
    992             The client should consider unsynchronized clocks and rounding problems due to the different encodings of time between the
    993             client and server. This includes the possibility of race conditions if the document has changed between the time it was first
    994             requested and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the
    995             If-Modified-Since date is derived from the client's clock without correction to the server's clock. Corrections for different
    996             time bases between client and server are at best approximate due to network latency.
     991            the same request, the client needs to be aware that this date is interpreted in the server's understanding of time. Unsynchronized
     992            clocks and rounding problems, due to the different encodings of time between the client and server, are concerns. This includes
     993            the possibility of race conditions if the document has changed between the time it was first requested and the If-Modified-Since
     994            date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since date is derived
     995            from the client's clock without correction to the server's clock. Corrections for different time bases between client and
     996            server are at best approximate due to network latency.
    997997         </li>
    998998      </ul>
    … …  
    10861086      <h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    10871087      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
    1088       <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; should be updated with the registrations below:
     1088      <p id="rfc.section.7.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    10891089      </p>
    10901090      <div id="rfc.table.1">
    … …  
    11151115      </div>
    11161116      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1117       <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1117      <p id="rfc.section.7.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    11181118      </p>
    11191119      <div id="rfc.table.2">

  • draft-ietf-httpbis/latest/p5-range.html

    r968 r970  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <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 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 31, 2011</td>
     428               <td class="left">Expires: February 1, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 30, 2010</td>
     485               <td class="right">July 31, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </p>
    511       <p>This Internet-Draft will expire in January 31, 2011.</p>
     511      <p>This Internet-Draft will expire in February 1, 2011.</p>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    730730      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.content-range" href="#header.content-range">Content-Range</a></h2>
    731731      <p id="rfc.section.5.2.p.1">The "Content-Range" header field is sent with a partial representation to specify where in the full representation the payload
    732          body should be applied.
     732         body is intended to be applied.
    733733      </p>
    734734      <p id="rfc.section.5.2.p.2">Range units are defined in <a href="#range.units" title="Range Units">Section&nbsp;2</a>.
    … …  
    916916      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    917917      <h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
    918       <p id="rfc.section.6.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; should be updated with the registrations below:
     918      <p id="rfc.section.6.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    919919      </p>
    920920      <div id="rfc.table.1">
    … …  
    945945      </div>
    946946      <h2 id="rfc.section.6.2"><a href="#rfc.section.6.2">6.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    947       <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     947      <p id="rfc.section.6.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    948948      </p>
    949949      <div id="rfc.table.2">
    … …  
    994994      <p id="rfc.section.6.3.p.1">The registration procedure for HTTP Range Specifiers is defined by <a href="#range.specifier.registry" title="Range Specifier Registry">Section&nbsp;2.1</a> of this document.
    995995      </p>
    996       <p id="rfc.section.6.3.p.2">The HTTP Range Specifier Registry should be created at &lt;<a href="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>&gt; and be populated with the registrations below:
     996      <p id="rfc.section.6.3.p.2">The HTTP Range Specifier Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-range-specifiers">http://www.iana.org/assignments/http-range-specifiers</a>&gt; and be populated with the registrations below:
    997997      </p>
    998998      <div id="rfc.table.3">

  • draft-ietf-httpbis/latest/p6-cache.html

    r968 r970  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 31, 2011</td>
     430               <td class="left">Expires: February 1, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">July 30, 2010</td>
     491               <td class="right">July 31, 2010</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </p>
    517       <p>This Internet-Draft will expire in January 31, 2011.</p>
     517      <p>This Internet-Draft will expire in February 1, 2011.</p>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    641641      </p>
    642642      <ul class="empty">
    643          <li>The time at which the origin server intends that a representation should no longer be returned by a cache without further
    644             validation.
    645          </li>
     643         <li>The time at which the origin server intends that a representation no longer be returned by a cache without further validation.</li>
    646644      </ul>
    647645      <p id="rfc.section.1.2.p.4"> <span id="rfc.iref.h.1"></span>  <dfn>heuristic expiration time</dfn> 
    … …  
    798796         is not likely to change in a semantically significant way before the expiration time is reached.
    799797      </p>
    800       <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past.
    801          This means that the response is always stale, so that caches should validate it before using it for subsequent requests. <span class="comment" id="TODO-response-stale">[<a href="#TODO-response-stale" class="smpl">TODO-response-stale</a>: This wording might cause confusion, because the response might still be served stale.]</span>
     798      <p id="rfc.section.2.3.p.3">If an origin server wishes to force a cache to validate every request, it can assign an explicit expiration time in the past
     799         to indicate that the response is already stale. Compliant caches will validate the cached response before reusing it for subsequent
     800         requests.
    802801      </p>
    803802      <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, HTTP caches <em class="bcp14">MAY</em> assign heuristic expiration times when explicit times are not specified, employing algorithms that use other header values
    … …  
    14221421      <p id="rfc.section.5.1.p.1">The registration procedure for HTTP Cache Directives is defined by <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;3.2.3</a> of this document.
    14231422      </p>
    1424       <p id="rfc.section.5.1.p.2">The HTTP Cache Directive Registry should be created at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt; and be populated with the registrations below:
     1423      <p id="rfc.section.5.1.p.2">The HTTP Cache Directive Registry shall be created at &lt;<a href="http://www.iana.org/assignments/http-cache-directives">http://www.iana.org/assignments/http-cache-directives</a>&gt; and be populated with the registrations below:
    14251424      </p>
    14261425      <div id="rfc.table.1">
    … …  
    15081507      </div>
    15091508      <h2 id="rfc.section.5.2"><a href="#rfc.section.5.2">5.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    1510       <p id="rfc.section.5.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     1509      <p id="rfc.section.5.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    15111510      </p>
    15121511      <div id="rfc.table.2">
    … …  
    15711570      <p id="rfc.section.6.p.1">Caches expose additional potential vulnerabilities, since the contents of the cache represent an attractive target for malicious
    15721571         exploitation. Because cache contents persist after an HTTP request is complete, an attack on the cache can reveal information
    1573          long after a user believes that the information has been removed from the network. Therefore, cache contents should be protected
     1572         long after a user believes that the information has been removed from the network. Therefore, cache contents need to be protected
    15741573         as sensitive information.
    15751574      </p>

  • draft-ietf-httpbis/latest/p7-auth.html

    r968 r970  
    393393      <meta name="dct.creator" content="Reschke, J. F.">
    394394      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    395       <meta name="dct.issued" scheme="ISO8601" content="2010-07-30">
     395      <meta name="dct.issued" scheme="ISO8601" content="2010-07-31">
    396396      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    397397      <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 7 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    424424            </tr>
    425425            <tr>
    426                <td class="left">Expires: January 31, 2011</td>
     426               <td class="left">Expires: February 1, 2011</td>
    427427               <td class="right">HP</td>
    428428            </tr>
    … …  
    477477            <tr>
    478478               <td class="left"></td>
    479                <td class="right">July 30, 2010</td>
     479               <td class="right">July 31, 2010</td>
    480480            </tr>
    481481         </tbody>
    … …  
    503503         in progress”.
    504504      </p>
    505       <p>This Internet-Draft will expire in January 31, 2011.</p>
     505      <p>This Internet-Draft will expire in February 1, 2011.</p>
    506506      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    507507      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    693693      <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="IANA.considerations" href="#IANA.considerations">IANA Considerations</a></h1>
    694694      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.code.registration" href="#status.code.registration">Status Code Registration</a></h2>
    695       <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; should be updated with the registrations below:
     695      <p id="rfc.section.4.1.p.1">The HTTP Status Code Registry located at &lt;<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>&gt; shall be updated with the registrations below:
    696696      </p>
    697697      <div id="rfc.table.1">
    … …  
    722722      </div>
    723723      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="header.field.registration" href="#header.field.registration">Header Field Registration</a></h2>
    724       <p id="rfc.section.4.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; should be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
     724      <p id="rfc.section.4.2.p.1">The Message Header Field Registry located at &lt;<a href="http://www.iana.org/assignments/message-headers/message-header-index.html">http://www.iana.org/assignments/message-headers/message-header-index.html</a>&gt; shall be updated with the permanent registrations below (see <a href="#RFC3864" id="rfc.xref.RFC3864.1"><cite title="Registration Procedures for Message Header Fields">[RFC3864]</cite></a>):
    725725      </p>
    726726      <div id="rfc.table.2">
Note: See TracChangeset for help on using the changeset viewer.