Ignore:
Timestamp:
04/08/10 15:03:20 (12 years ago)
Author:
julian.reschke@…
Message:

regen HTML using latest version of xslt

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/orig/rfc2617.html

    r598 r978  
    3737}
    3838
    39 dl.empty dd {
     39ul.empty {
     40  list-style-type: none;
     41}
     42ul.empty li {
    4043  margin-top: .5em;
    4144}
    … …  
    118121}
    119122table.header {
     123  border-spacing: 1px;
    120124  width: 95%;
    121125  font-size: 10pt;
    … …  
    129133  white-space: nowrap;
    130134}
    131 td.header {
     135table.header td {
    132136  background-color: gray;
    133137  width: 50%;
    134138}
    135 td.header a {
     139table.header a {
    136140  color: white;
    137141}
    … …  
    188192  margin-left: 0em;
    189193  margin-right: 0em;
     194}
     195.avoidbreak {
     196  page-break-inside: avoid;
    190197}
    191198.bcp14 {
    … …  
    328335      <link rel="Alternate" title="Authorative ASCII Version" href="http://www.ietf.org/rfc/rfc2617.txt">
    329336      <link rel="Help" title="Additional Information on tools.ietf.org" href="http://tools.ietf.org/html/rfc2617">
    330       <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.438, 2009-05-27 13:34:05, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
    331       <link rel="schema.DC" href="http://purl.org/dc/elements/1.1/">
    332       <meta name="DC.Creator" content="Franks, J.">
    333       <meta name="DC.Creator" content="Hallam-Baker, P.M.">
    334       <meta name="DC.Creator" content="Hostetler, J.L.">
    335       <meta name="DC.Creator" content="Lawrence, S.D.">
    336       <meta name="DC.Creator" content="Leach, P.J.">
    337       <meta name="DC.Creator" content="Luotonen, A.">
    338       <meta name="DC.Creator" content="Stewart, L.">
    339       <meta name="DC.Identifier" content="urn:ietf:rfc:2617">
    340       <meta name="DC.Date.Issued" scheme="ISO8601" content="1999-06">
    341       <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2069">
    342       <meta name="DC.Description.Abstract" content="&#34;HTTP/1.0&#34;, includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL ), as the user name and password are passed over the network as cleartext. This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as &#34;Digest Access Authentication&#34;. It is therefore also intended to serve as a replacement for RFC 2069 . Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended. Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.">
    343       <meta name="DC.isPartOf" content="urn:ISSN:2070-1721">
     337      <meta name="generator" content="http://greenbytes.de/tech/webdav/rfc2629.xslt, Revision 1.520, 2010-07-14 12:36:35, XSLT vendor: SAXON 8.9 from Saxonica http://www.saxonica.com/">
     338      <link rel="schema.dct" href="http://purl.org/dc/terms/">
     339      <meta name="dct.creator" content="Franks, J.">
     340      <meta name="dct.creator" content="Hallam-Baker, P.M.">
     341      <meta name="dct.creator" content="Hostetler, J.L.">
     342      <meta name="dct.creator" content="Lawrence, S.D.">
     343      <meta name="dct.creator" content="Leach, P.J.">
     344      <meta name="dct.creator" content="Luotonen, A.">
     345      <meta name="dct.creator" content="Stewart, L.">
     346      <meta name="dct.identifier" content="urn:ietf:rfc:2617">
     347      <meta name="dct.issued" scheme="ISO8601" content="1999-06">
     348      <meta name="dct.replaces" content="urn:ietf:rfc:2069">
     349      <meta name="dct.abstract" content="&#34;HTTP/1.0&#34;, includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL ), as the user name and password are passed over the network as cleartext. This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as &#34;Digest Access Authentication&#34;. It is therefore also intended to serve as a replacement for RFC 2069 . Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended. Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.">
     350      <meta name="dct.isPartOf" content="urn:issn:2070-1721">
     351      <meta name="description" content="&#34;HTTP/1.0&#34;, includes the specification for a Basic Access Authentication scheme. This scheme is not considered to be a secure method of user authentication (unless used in conjunction with some external secure system such as SSL ), as the user name and password are passed over the network as cleartext. This document also provides the specification for HTTP's authentication framework, the original Basic authentication scheme and a scheme based on cryptographic hashes, referred to as &#34;Digest Access Authentication&#34;. It is therefore also intended to serve as a replacement for RFC 2069 . Some optional elements specified by RFC 2069 have been removed from this specification due to problems found since its publication; other new elements have been added for compatibility, those new elements have been made optional, but are strongly recommended. Like Basic, Digest access authentication verifies that both parties to a communication know a shared secret (a password); unlike Basic, this verification can be done without sending the password in the clear, which is Basic's biggest weakness. As with most other authentication protocols, the greatest sources of risks are usually found not in the core protocol itself but in policies and procedures surrounding its use.">
    344352   </head>
    345353   <body>
    346       <table summary="header information" class="header" border="0" cellpadding="1" cellspacing="1">
    347          <tr>
    348             <td class="header left">Network Working Group</td>
    349             <td class="header right">J. Franks</td>
    350          </tr>
    351          <tr>
    352             <td class="header left">Request for Comments: 2617</td>
    353             <td class="header right">Northwestern University, Department of Mathematics</td>
    354          </tr>
    355          <tr>
    356             <td class="header left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2069">2069</a></td>
    357             <td class="header right">P.M. Hallam-Baker</td>
    358          </tr>
    359          <tr>
    360             <td class="header left">Category: Standards Track</td>
    361             <td class="header right">Verisign Inc.</td>
    362          </tr>
    363          <tr>
    364             <td class="header left"></td>
    365             <td class="header right">J.L. Hostetler</td>
    366          </tr>
    367          <tr>
    368             <td class="header left"></td>
    369             <td class="header right">AbiSource, Inc.</td>
    370          </tr>
    371          <tr>
    372             <td class="header left"></td>
    373             <td class="header right">S.D. Lawrence</td>
    374          </tr>
    375          <tr>
    376             <td class="header left"></td>
    377             <td class="header right">Agranat Systems, Inc.</td>
    378          </tr>
    379          <tr>
    380             <td class="header left"></td>
    381             <td class="header right">P.J. Leach</td>
    382          </tr>
    383          <tr>
    384             <td class="header left"></td>
    385             <td class="header right">Microsoft Corporation</td>
    386          </tr>
    387          <tr>
    388             <td class="header left"></td>
    389             <td class="header right">A. Luotonen</td>
    390          </tr>
    391          <tr>
    392             <td class="header left"></td>
    393             <td class="header right">Netscape Communications Corporation</td>
    394          </tr>
    395          <tr>
    396             <td class="header left"></td>
    397             <td class="header right">L. Stewart</td>
    398          </tr>
    399          <tr>
    400             <td class="header left"></td>
    401             <td class="header right">Open Market, Inc.</td>
    402          </tr>
    403          <tr>
    404             <td class="header left"></td>
    405             <td class="header right">June 1999</td>
    406          </tr>
     354      <table class="header">
     355         <tbody>
     356            <tr>
     357               <td class="left">Network Working Group</td>
     358               <td class="right">J. Franks</td>
     359            </tr>
     360            <tr>
     361               <td class="left">Request for Comments: 2617</td>
     362               <td class="right">Northwestern University, Department of Mathematics</td>
     363            </tr>
     364            <tr>
     365               <td class="left">Obsoletes: <a href="http://tools.ietf.org/html/rfc2069">2069</a></td>
     366               <td class="right">P. Hallam-Baker</td>
     367            </tr>
     368            <tr>
     369               <td class="left">Category: Standards Track</td>
     370               <td class="right">Verisign Inc.</td>
     371            </tr>
     372            <tr>
     373               <td class="left"></td>
     374               <td class="right">J. Hostetler</td>
     375            </tr>
     376            <tr>
     377               <td class="left"></td>
     378               <td class="right">AbiSource, Inc.</td>
     379            </tr>
     380            <tr>
     381               <td class="left"></td>
     382               <td class="right">S. Lawrence</td>
     383            </tr>
     384            <tr>
     385               <td class="left"></td>
     386               <td class="right">Agranat Systems, Inc.</td>
     387            </tr>
     388            <tr>
     389               <td class="left"></td>
     390               <td class="right">P. Leach</td>
     391            </tr>
     392            <tr>
     393               <td class="left"></td>
     394               <td class="right">Microsoft Corporation</td>
     395            </tr>
     396            <tr>
     397               <td class="left"></td>
     398               <td class="right">A. Luotonen</td>
     399            </tr>
     400            <tr>
     401               <td class="left"></td>
     402               <td class="right">Netscape Communications Corporation</td>
     403            </tr>
     404            <tr>
     405               <td class="left"></td>
     406               <td class="right">L. Stewart</td>
     407            </tr>
     408            <tr>
     409               <td class="left"></td>
     410               <td class="right">Open Market, Inc.</td>
     411            </tr>
     412            <tr>
     413               <td class="left"></td>
     414               <td class="right">June 1999</td>
     415            </tr>
     416         </tbody>
    407417      </table>
    408418      <p class="title">HTTP Authentication: Basic and Digest Access Authentication</p>
    … …  
    485495         <li class="tocline0">7.&nbsp;&nbsp;&nbsp;<a href="#rfc.references">References</a></li>
    486496         <li class="tocline0"><a href="#rfc.authors">Authors' Addresses</a></li>
     497         <li class="tocline0"><a href="#rfc.index">Index</a></li>
    487498         <li class="tocline0"><a href="#rfc.ipr">Intellectual Property and Copyright Statements</a></li>
    488          <li class="tocline0"><a href="#rfc.index">Index</a></li>
    489499      </ul>
    490500      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;Access Authentication
    … …  
    529539      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.c.2"></span>   credentials = auth-scheme #auth-param
    530540</pre><p id="rfc.section.1.2.p.11"> </p>
    531       <dl class="empty">
    532          <dd>Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should
     541      <ul class="empty">
     542         <li>Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should
    533543            only include Basic if it is minimally acceptable.
    534          </dd>
    535       </dl>
     544         </li>
     545      </ul>
    536546      <p id="rfc.section.1.2.p.12">The protection space determines the domain over which credentials can be automatically applied. If a prior request has been
    537547         authorized, the same credentials <em class="bcp14">MAY</em> be reused for all other requests within that protection space for a period of time determined by the authentication scheme,
    … …  
    655665</pre><p id="rfc.section.3.2.1.p.3">The meanings of the values of the directives used above are as follows:</p>
    656666      <p id="rfc.section.3.2.1.p.4">realm </p>
    657       <dl class="empty">
    658          <dd>A string to be displayed to users so they know which username and password to use. This string should contain at least the
     667      <ul class="empty">
     668         <li>A string to be displayed to users so they know which username and password to use. This string should contain at least the
    659669            name of the host performing the authentication and might additionally indicate the collection of users who might have access.
    660670            An example might be "registered_users@gotham.news.com".
    661          </dd>
    662       </dl>
     671         </li>
     672      </ul>
    663673      <p id="rfc.section.3.2.1.p.5">domain </p>
    664       <dl class="empty">
    665          <dd>A quoted, space-separated list of URIs, as specified in RFC XURI <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[7]</cite></a>, that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL (see <a href="#access.authentication.framework" title="Access Authentication Framework">Section&nbsp;1.2</a> above) of the server being accessed. An absoluteURI in this list may refer to a different server than the one being accessed.
     674      <ul class="empty">
     675         <li>A quoted, space-separated list of URIs, as specified in RFC XURI <a href="#RFC2396" id="rfc.xref.RFC2396.2"><cite title="Uniform Resource Identifiers (URI): Generic Syntax">[7]</cite></a>, that define the protection space. If a URI is an abs_path, it is relative to the canonical root URL (see <a href="#access.authentication.framework" title="Access Authentication Framework">Section&nbsp;1.2</a> above) of the server being accessed. An absoluteURI in this list may refer to a different server than the one being accessed.
    666676            The client can use this list to determine the set of URIs for which the same authentication information may be sent: any URI
    667677            that has a URI in this list as a prefix (after both have been made absolute) may be assumed to be in the same protection space.
    … …  
    669679            on the responding server. This directive is not meaningful in Proxy-Authenticate headers, for which the protection space is
    670680            always the entire proxy; if present it should be ignored.
    671          </dd>
    672       </dl>
     681         </li>
     682      </ul>
    673683      <p id="rfc.section.3.2.1.p.6">nonce </p>
    674       <dl class="empty">
    675          <dd>A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that
     684      <ul class="empty">
     685         <li>A server-specified data string which should be uniquely generated each time a 401 response is made. It is recommended that
    676686            this string be base64 or hexadecimal data. Specifically, since the string is passed in the header lines as a quoted string,
    677687            the double-quote character is not allowed.
    678          </dd>
    679          <dd>The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. A nonce
     688         </li>
     689         <li>The contents of the nonce are implementation dependent. The quality of the implementation depends on a good choice. A nonce
    680690            might, for example, be constructed as the base 64 encoding of
    681          </dd>
    682          <dd>
     691         </li>
     692         <li>
    683693            <div id="rfc.figure.u.10"></div><pre class="text">         time-stamp H(time-stamp ":" ETag ":" private-key)
    684   </pre></dd>
    685          <dd>where time-stamp is a server-generated time or other non-repeating value, ETag is the value of the HTTP ETag header associated
     694  </pre></li>
     695         <li>where time-stamp is a server-generated time or other non-repeating value, ETag is the value of the HTTP ETag header associated
    686696            with the requested entity, and private-key is data known only to the server. With a nonce of this form a server would recalculate
    687697            the hash portion after receiving the client authentication header and reject the request if it did not match the nonce from
    … …  
    691701            that originally got it. However, that would break proxy farms, where requests from a single user often go through different
    692702            proxies in the farm. Also, IP address spoofing is not that hard.)
    693          </dd>
    694          <dd>An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against
     703         </li>
     704         <li>An implementation might choose not to accept a previously used nonce or a previously used digest, in order to protect against
    695705            a replay attack. Or, an implementation might choose to use one-time nonces or digests for POST or PUT requests and a time-stamp
    696706            for GET requests. For more details on the issues involved see <a href="#security.considerations" title="Security Considerations">Section&nbsp;4</a> of this document.
    697          </dd>
    698          <dd>The nonce is opaque to the client.</dd>
    699       </dl>
     707         </li>
     708         <li>The nonce is opaque to the client.</li>
     709      </ul>
    700710      <p id="rfc.section.3.2.1.p.7">opaque </p>
    701       <dl class="empty">
    702          <dd>A string of data, specified by the server, which should be returned by the client unchanged in the Authorization header of
     711      <ul class="empty">
     712         <li>A string of data, specified by the server, which should be returned by the client unchanged in the Authorization header of
    703713            subsequent requests with URIs in the same protection space. It is recommended that this string be base64 or hexadecimal data.
    704          </dd>
    705       </dl>
     714         </li>
     715      </ul>
    706716      <p id="rfc.section.3.2.1.p.8">stale </p>
    707       <dl class="empty">
    708          <dd>A flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE
     717      <ul class="empty">
     718         <li>A flag, indicating that the previous request from the client was rejected because the nonce value was stale. If stale is TRUE
    709719            (case-insensitive), the client may wish to simply retry the request with a new encrypted response, without reprompting the
    710720            user for a new username and password. The server should only set stale to TRUE if it receives a request for which the nonce
    … …  
    712722            is FALSE, or anything other than TRUE, or the stale directive is not present, the username and/or password are invalid, and
    713723            new values must be obtained.
    714          </dd>
    715       </dl>
     724         </li>
     725      </ul>
    716726      <p id="rfc.section.3.2.1.p.9">algorithm </p>
    717       <dl class="empty">
    718          <dd>A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to
     727      <ul class="empty">
     728         <li>A string indicating a pair of algorithms used to produce the digest and a checksum. If this is not present it is assumed to
    719729            be "MD5". If the algorithm is not understood, the challenge should be ignored (and a different one used, if there is more
    720730            than one).
    721          </dd>
    722          <dd>In this document the string obtained by applying the digest algorithm to the data "data" with secret "secret" will be denoted
     731         </li>
     732         <li>In this document the string obtained by applying the digest algorithm to the data "data" with secret "secret" will be denoted
    723733            by KD(secret, data), and the string obtained by applying the checksum algorithm to the data "data" will be denoted H(data).
    724734            The notation unq(X) means the value of the quoted-string X without the surrounding quotes.
    725          </dd>
    726          <dd>For the "MD5" and "MD5-sess" algorithms</dd>
    727          <dd>
     735         </li>
     736         <li>For the "MD5" and "MD5-sess" algorithms</li>
     737         <li>
    728738            <div id="rfc.figure.u.11"></div><pre class="text">         H(data) = MD5(data)
    729     </pre></dd>
    730          <dd>and</dd>
    731          <dd>
     739    </pre></li>
     740         <li>and</li>
     741         <li>
    732742            <div id="rfc.figure.u.12"></div><pre class="text">         KD(secret, data) = H(concat(secret, ":", data))
    733     </pre></dd>
    734          <dd>i.e., the digest is the MD5 of the secret concatenated with a colon concatenated with the data. The "MD5-sess" algorithm is
     743    </pre></li>
     744         <li>i.e., the digest is the MD5 of the secret concatenated with a colon concatenated with the data. The "MD5-sess" algorithm is
    735745            intended to allow efficient 3rd party authentication servers; for the difference in usage, see the description in <a href="#A1" title="A1">Section&nbsp;3.2.2.2</a>.
    736          </dd>
    737       </dl>
     746         </li>
     747      </ul>
    738748      <p id="rfc.section.3.2.1.p.10">qop-options </p>
    739       <dl class="empty">
    740          <dd>This directive is optional, but is made so only for backward compatibility with RFC 2069 <a href="#RFC2069" id="rfc.xref.RFC2069.2"><cite title="An Extension to HTTP : Digest Access Authentication">[6]</cite></a>; it <em class="bcp14">SHOULD</em> be used by all implementations compliant with this version of the Digest scheme. If present, it is a quoted string of one
     749      <ul class="empty">
     750         <li>This directive is optional, but is made so only for backward compatibility with RFC 2069 <a href="#RFC2069" id="rfc.xref.RFC2069.2"><cite title="An Extension to HTTP : Digest Access Authentication">[6]</cite></a>; it <em class="bcp14">SHOULD</em> be used by all implementations compliant with this version of the Digest scheme. If present, it is a quoted string of one
    741751            or more tokens indicating the "quality of protection" values supported by the server. The value "auth" indicates authentication;
    742752            the value "auth-int" indicates authentication with integrity protection; see the descriptions below for calculating the response
    743753            directive value for the application of this choice. Unrecognized options <em class="bcp14">MUST</em> be ignored.
    744          </dd>
    745       </dl>
     754         </li>
     755      </ul>
    746756      <p id="rfc.section.3.2.1.p.11">auth-param </p>
    747       <dl class="empty">
    748          <dd>This directive allows for future extensions. Any unrecognized directive <em class="bcp14">MUST</em> be ignored.
    749          </dd>
    750       </dl>
     757      <ul class="empty">
     758         <li>This directive allows for future extensions. Any unrecognized directive <em class="bcp14">MUST</em> be ignored.
     759         </li>
     760      </ul>
    751761      <div id="rfc.iref.h.2"></div>
    752762      <div id="rfc.iref.a.4"></div>
    … …  
    780790      </p>
    781791      <p id="rfc.section.3.2.2.p.4">response </p>
    782       <dl class="empty">
    783          <dd>A string of 32 hex digits computed as defined below, which proves that the user knows a password</dd>
    784       </dl>
     792      <ul class="empty">
     793         <li>A string of 32 hex digits computed as defined below, which proves that the user knows a password</li>
     794      </ul>
    785795      <p id="rfc.section.3.2.2.p.5">username </p>
    786       <dl class="empty">
    787          <dd>The user's name in the specified realm.</dd>
    788       </dl>
     796      <ul class="empty">
     797         <li>The user's name in the specified realm.</li>
     798      </ul>
    789799      <p id="rfc.section.3.2.2.p.6">digest-uri </p>
    790       <dl class="empty">
    791          <dd>The URI from Request-URI of the Request-Line; duplicated here because proxies are allowed to change the Request-Line in transit.</dd>
    792       </dl>
     800      <ul class="empty">
     801         <li>The URI from Request-URI of the Request-Line; duplicated here because proxies are allowed to change the Request-Line in transit.</li>
     802      </ul>
    793803      <p id="rfc.section.3.2.2.p.7">qop </p>
    794       <dl class="empty">
    795          <dd>Indicates what "quality of protection" the client has applied to the message. If present, its value <em class="bcp14">MUST</em> be one of the alternatives the server indicated it supports in the WWW-Authenticate header. These values affect the computation
     804      <ul class="empty">
     805         <li>Indicates what "quality of protection" the client has applied to the message. If present, its value <em class="bcp14">MUST</em> be one of the alternatives the server indicated it supports in the WWW-Authenticate header. These values affect the computation
    796806            of the request-digest. Note that this is a single token, not a quoted list of alternatives as in WWW-Authenticate. This directive
    797807            is optional in order to preserve backward compatibility with a minimal implementation of RFC 2069 <a href="#RFC2069" id="rfc.xref.RFC2069.3"><cite title="An Extension to HTTP : Digest Access Authentication">[6]</cite></a>, but <em class="bcp14">SHOULD</em> be used if the server indicated that qop is supported by providing a qop directive in the WWW-Authenticate header field.
    798          </dd>
    799       </dl>
     808         </li>
     809      </ul>
    800810      <p id="rfc.section.3.2.2.p.8">cnonce </p>
    801       <dl class="empty">
    802          <dd>This <em class="bcp14">MUST</em> be specified if a qop directive is sent (see above), and <em class="bcp14">MUST NOT</em> be specified if the server did not send a qop directive in the WWW-Authenticate header field. The cnonce-value is an opaque
     811      <ul class="empty">
     812         <li>This <em class="bcp14">MUST</em> be specified if a qop directive is sent (see above), and <em class="bcp14">MUST NOT</em> be specified if the server did not send a qop directive in the WWW-Authenticate header field. The cnonce-value is an opaque
    803813            quoted string value provided by the client and used by both client and server to avoid chosen plaintext attacks, to provide
    804814            mutual authentication, and to provide some message integrity protection. See the descriptions below of the calculation of
    805815            the response-digest and request-digest values.
    806          </dd>
    807       </dl>
     816         </li>
     817      </ul>
    808818      <p id="rfc.section.3.2.2.p.9">nonce-count </p>
    809       <dl class="empty">
    810          <dd>This <em class="bcp14">MUST</em> be specified if a qop directive is sent (see above), and <em class="bcp14">MUST NOT</em> be specified if the server did not send a qop directive in the WWW-Authenticate header field. The nc-value is the hexadecimal
     819      <ul class="empty">
     820         <li>This <em class="bcp14">MUST</em> be specified if a qop directive is sent (see above), and <em class="bcp14">MUST NOT</em> be specified if the server did not send a qop directive in the WWW-Authenticate header field. The nc-value is the hexadecimal
    811821            count of the number of requests (including the current request) that the client has sent with the nonce value in this request.
    812822            For example, in the first request sent in response to a given nonce value, the client sends "nc=00000001". The purpose of
    813823            this directive is to allow the server to detect request replays by maintaining its own copy of this count - if the same nc-value
    814824            is seen twice, then the request is a replay. See the description below of the construction of the request-digest value.
    815          </dd>
    816       </dl>
     825         </li>
     826      </ul>
    817827      <p id="rfc.section.3.2.2.p.10">auth-param </p>
    818       <dl class="empty">
    819          <dd>This directive allows for future extensions. Any unrecognized directive <em class="bcp14">MUST</em> be ignored.
    820          </dd>
    821       </dl>
     828      <ul class="empty">
     829         <li>This directive allows for future extensions. Any unrecognized directive <em class="bcp14">MUST</em> be ignored.
     830         </li>
     831      </ul>
    822832      <p id="rfc.section.3.2.2.p.11">If a directive or its value is improper, or required directives are missing, the proper response is 400 Bad Request. If the
    823833         request-digest is invalid, then a login failure should be logged, since repeated login failures from a single client may indicate
    … …  
    923933      </p>
    924934      <p id="rfc.section.3.2.3.p.4"> </p>
    925       <dl class="empty">
    926          <dd>Server implementations should carefully consider the performance implications of the use of this mechanism; pipelined requests
     935      <ul class="empty">
     936         <li>Server implementations should carefully consider the performance implications of the use of this mechanism; pipelined requests
    927937            will not be possible if every response includes a nextnonce directive that must be used on the next request received by the
    928938            server. Consideration should be given to the performance vs. security tradeoffs of allowing an old nonce value to be used
    929939            for a limited time to permit request pipelining. Use of the nonce-count can retain most of the security advantages of a new
    930940            server nonce without the deleterious affects on pipelining.
    931          </dd>
    932       </dl>
     941         </li>
     942      </ul>
    933943      <p id="rfc.section.3.2.3.p.5">message-qop</p>
    934       <dl class="empty">
    935          <dd>Indicates the "quality of protection" options applied to the response by the server. The value "auth" indicates authentication;
     944      <ul class="empty">
     945         <li>Indicates the "quality of protection" options applied to the response by the server. The value "auth" indicates authentication;
    936946            the value "auth-int" indicates authentication with integrity protection. The server <em class="bcp14">SHOULD</em> use the same value for the message-qop directive in the response as was sent by the client in the corresponding request.
    937          </dd>
    938       </dl>
     947         </li>
     948      </ul>
    939949      <p id="rfc.section.3.2.3.p.7">The optional response digest in the "response-auth" directive supports mutual authentication -- the server proves that it
    940950         knows the user's secret, and with qop=auth-int also provides limited integrity protection of the response. The "response-digest"
    … …  
    11381148      </p>
    11391149      <p id="rfc.section.4.6.p.2"> </p>
    1140       <dl class="empty">
    1141          <dd>Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should
     1150      <ul class="empty">
     1151         <li>Note that many browsers will only recognize Basic and will require that it be the first auth-scheme presented. Servers should
    11421152            only include Basic if it is minimally acceptable.
    1143          </dd>
    1144       </dl>
     1153         </li>
     1154      </ul>
    11451155      <p id="rfc.section.4.6.p.3">When the server offers choices of authentication schemes using the WWW-Authenticate header, the strength of the resulting
    11461156         authentication is only as good as that of the of the weakest of the authentication schemes. See <a href="#man.in.the.middle" title="Man in the Middle">Section&nbsp;4.8</a> below for discussion of particular attack scenarios that exploit multiple authentication schemes.
    … …  
    14301440      <h1 id="rfc.references"><a href="#rfc.section.7" id="rfc.section.7">7.</a> References
    14311441      </h1>
    1432       <table summary="References">
     1442      <table>
    14331443         <tr>
    14341444            <td class="reference"><b id="RFC1945">[1]</b></td>
    1435             <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.T.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H.F. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
     1445            <td class="top"><a href="mailto:timbl@w3.org" title="MIT, Laboratory for Computer Science">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:frystyk@w3.org" title="W3 Consortium, MIT Laboratory for Computer Science">H. Nielsen</a>, “<a href="http://tools.ietf.org/html/rfc1945">Hypertext Transfer Protocol -- HTTP/1.0</a>”, RFC&nbsp;1945, May&nbsp;1996.
    14361446            </td>
    14371447         </tr> 
    14381448         <tr>
    14391449            <td class="reference"><b id="RFC2616">[2]</b></td>
    1440             <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Information and Computer Science">Fielding, R.T.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium, MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation, Western Research Laboratory">Mogul, J.C.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium, MIT Laboratory for Computer Science">Nielsen, H.F.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.J.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium, MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
     1450            <td class="top"><a href="mailto:fielding@ics.uci.edu" title="University of California, Irvine, Information and Computer Science">Fielding, R.</a>, <a href="mailto:jg@w3.org" title="World Wide Web Consortium, MIT Laboratory for Computer Science">Gettys, J.</a>, <a href="mailto:mogul@wrl.dec.com" title="Compaq Computer Corporation, Western Research Laboratory">Mogul, J.</a>, <a href="mailto:frystyk@w3.org" title="World Wide Web Consortium, MIT Laboratory for Computer Science">Nielsen, H.</a>, <a href="mailto:masinter@parc.xerox.com" title="Xerox Corporation">Masinter, L.</a>, <a href="mailto:paulle@microsoft.com" title="Microsoft Corporation">Leach, P.</a>, and <a href="mailto:timbl@w3.org" title="World Wide Web Consortium, MIT Laboratory for Computer Science">T. Berners-Lee</a>, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>”, RFC&nbsp;2616, June&nbsp;1999.
    14411451            </td>
    14421452         </tr> 
    1443          <!--WARNING: unused reference 'RFC1321'-->
    14441453         <tr>
    14451454            <td class="reference"><b id="RFC1321">[3]</b></td>
    … …  
    14471456            </td>
    14481457         </tr> 
    1449          <!--WARNING: unused reference 'RFC2045'-->
    14501458         <tr>
    14511459            <td class="reference"><b id="RFC2045">[4]</b></td>
    1452             <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N.S. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
     1460            <td class="top"><a href="mailto:ned@innosoft.com" title="Innosoft International, Inc.">Freed, N.</a> and <a href="mailto:nsb@nsb.fv.com" title="First Virtual Holdings">N. Borenstein</a>, “<a href="http://tools.ietf.org/html/rfc2045">Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</a>”, RFC&nbsp;2045, November&nbsp;1996.
    14531461            </td>
    14541462         </tr> 
    … …  
    14651473         <tr>
    14661474            <td class="reference"><b id="RFC2396">[7]</b></td>
    1467             <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.T.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
     1475            <td class="top"><a href="mailto:timbl@w3.org" title="World Wide Web Consortium">Berners-Lee, T.</a>, <a href="mailto:fielding@ics.uci.edu" title="Department of Information and Computer Science">Fielding, R.</a>, and <a href="mailto:masinter@parc.xerox.com" title="Xerox PARC">L. Masinter</a>, “<a href="http://tools.ietf.org/html/rfc2396">Uniform Resource Identifiers (URI): Generic Syntax</a>”, RFC&nbsp;2396, August&nbsp;1998.
    14681476            </td>
    14691477         </tr> 
    … …  
    14751483         <tr>
    14761484            <td class="reference"><b id="RFC2195">[9]</b></td>
    1477             <td class="top"><a href="mailto:klensin@mci.net" title="MCI">Klensin, J.C.</a>, <a href="mailto:randy@mci.net" title="MCI">Catoe, R.</a>, and <a href="mailto:paul@mci.net" title="MCI">P. Krumviede</a>, “<a href="http://tools.ietf.org/html/rfc2195">IMAP/POP AUTHorize Extension for Simple Challenge/Response</a>”, RFC&nbsp;2195, September&nbsp;1997.
     1485            <td class="top"><a href="mailto:klensin@mci.net" title="MCI">Klensin, J.</a>, <a href="mailto:randy@mci.net" title="MCI">Catoe, R.</a>, and <a href="mailto:paul@mci.net" title="MCI">P. Krumviede</a>, “<a href="http://tools.ietf.org/html/rfc2195">IMAP/POP AUTHorize Extension for Simple Challenge/Response</a>”, RFC&nbsp;2195, September&nbsp;1997.
    14781486            </td>
    14791487         </tr> 
    … …  
    14841492         </tr>
    14851493      </table>
    1486       <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
    1487       <address class="vcard"><span class="vcardline"><span class="fn">John Franks</span><span class="n hidden"><span class="family-name">Franks</span><span class="given-name">John</span></span></span><span class="org vcardline">Northwestern University, Department of Mathematics</span><span class="adr"><span class="street-address vcardline">Northwestern University</span><span class="vcardline"><span class="locality">Evanston</span>, <span class="region">IL</span>&nbsp;<span class="postal-code">60208-2730</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:john@math.nwu.edu"><span class="email">john@math.nwu.edu</span></a></span></address>
    1488       <address class="vcard"><span class="vcardline"><span class="fn">Phillip M. Hallam-Baker</span><span class="n hidden"><span class="family-name">Hallam-Baker</span><span class="given-name">Phillip M.</span></span></span><span class="org vcardline">Verisign Inc.</span><span class="adr"><span class="street-address vcardline">301 Edgewater Place</span><span class="street-address vcardline">Suite 210</span><span class="vcardline"><span class="locality">Wakefield</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01880</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:pbaker@verisign.com"><span class="email">pbaker@verisign.com</span></a></span></address>
    1489       <address class="vcard"><span class="vcardline"><span class="fn">Jeffery L. Hostetler</span><span class="n hidden"><span class="family-name">Hostetler</span><span class="given-name">Jeffery L.</span></span></span><span class="org vcardline">AbiSource, Inc.</span><span class="adr"><span class="street-address vcardline">6 Dunlap Court</span><span class="vcardline"><span class="locality">Savoy</span>, <span class="region">IL</span>&nbsp;<span class="postal-code">61874</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:jeff@AbiSource.com"><span class="email">jeff@AbiSource.com</span></a></span></address>
    1490       <address class="vcard"><span class="vcardline"><span class="fn">Scott D. Lawrence</span><span class="n hidden"><span class="family-name">Lawrence</span><span class="given-name">Scott D.</span></span></span><span class="org vcardline">Agranat Systems, Inc.</span><span class="adr"><span class="street-address vcardline">5 Clocktower Place</span><span class="street-address vcardline">Suite 400</span><span class="vcardline"><span class="locality">Maynard</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01754</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:lawrence@agranat.com"><span class="email">lawrence@agranat.com</span></a></span></address>
    1491       <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address>
    1492       <address class="vcard"><span class="vcardline"><span class="fn">Ari Luotonen</span><span class="n hidden"><span class="family-name">Luotonen</span><span class="given-name">Ari</span></span></span><span class="org vcardline">Netscape Communications Corporation</span><span class="adr"><span class="street-address vcardline">501 East Middlefield Road</span><span class="vcardline"><span class="locality">Mountain View</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94043</span></span><span class="country-name vcardline">USA</span></span></address>
    1493       <address class="vcard"><span class="vcardline"><span class="fn">Lawrence C. Stewart</span><span class="n hidden"><span class="family-name">Stewart</span><span class="given-name">Lawrence C.</span></span></span><span class="org vcardline">Open Market, Inc.</span><span class="adr"><span class="street-address vcardline">215 First Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02142</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:stewart@OpenMarket.com"><span class="email">stewart@OpenMarket.com</span></a></span></address>
    1494       <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
    1495       <p>Copyright © The Internet Society (1999). All Rights Reserved.</p>
    1496       <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
    1497          explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
    1498          restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
    1499          works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
    1500          to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
    1501          in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
    1502          translate it into languages other than English.
    1503       </p>
    1504       <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.</p>
    1505       <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
    1506          ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
    1507          OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
    1508          PURPOSE.
    1509       </p>
    1510       <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
    1511       <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
    1512          to pertain to the implementation or use of the technology described in this document or the extent to which any license under
    1513          such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
    1514          Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
    1515          found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
    1516          or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
    1517          or users of this specification can be obtained from the IETF Secretariat.
    1518       </p>
    1519       <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
    1520          rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
    1521          Executive Director.
    1522       </p>
    1523       <h1>Acknowledgment</h1>
    1524       <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
     1494      <div class="avoidbreak">
     1495         <h1 id="rfc.authors"><a href="#rfc.authors">Authors' Addresses</a></h1>
     1496         <address class="vcard"><span class="vcardline"><span class="fn">John Franks</span><span class="n hidden"><span class="family-name">Franks</span><span class="given-name">John</span></span></span><span class="org vcardline">Northwestern University, Department of Mathematics</span><span class="adr"><span class="street-address vcardline">Northwestern University</span><span class="vcardline"><span class="locality">Evanston</span>, <span class="region">IL</span>&nbsp;<span class="postal-code">60208-2730</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:john@math.nwu.edu"><span class="email">john@math.nwu.edu</span></a></span></address>
     1497         <address class="vcard"><span class="vcardline"><span class="fn">Phillip M. Hallam-Baker</span><span class="n hidden"><span class="family-name">Hallam-Baker</span><span class="given-name">Phillip M.</span></span></span><span class="org vcardline">Verisign Inc.</span><span class="adr"><span class="street-address vcardline">301 Edgewater Place</span><span class="street-address vcardline">Suite 210</span><span class="vcardline"><span class="locality">Wakefield</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01880</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:pbaker@verisign.com"><span class="email">pbaker@verisign.com</span></a></span></address>
     1498         <address class="vcard"><span class="vcardline"><span class="fn">Jeffery L. Hostetler</span><span class="n hidden"><span class="family-name">Hostetler</span><span class="given-name">Jeffery L.</span></span></span><span class="org vcardline">AbiSource, Inc.</span><span class="adr"><span class="street-address vcardline">6 Dunlap Court</span><span class="vcardline"><span class="locality">Savoy</span>, <span class="region">IL</span>&nbsp;<span class="postal-code">61874</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:jeff@AbiSource.com"><span class="email">jeff@AbiSource.com</span></a></span></address>
     1499         <address class="vcard"><span class="vcardline"><span class="fn">Scott D. Lawrence</span><span class="n hidden"><span class="family-name">Lawrence</span><span class="given-name">Scott D.</span></span></span><span class="org vcardline">Agranat Systems, Inc.</span><span class="adr"><span class="street-address vcardline">5 Clocktower Place</span><span class="street-address vcardline">Suite 400</span><span class="vcardline"><span class="locality">Maynard</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">01754</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:lawrence@agranat.com"><span class="email">lawrence@agranat.com</span></a></span></address>
     1500         <address class="vcard"><span class="vcardline"><span class="fn">Paul J. Leach</span><span class="n hidden"><span class="family-name">Leach</span><span class="given-name">Paul J.</span></span></span><span class="org vcardline">Microsoft Corporation</span><span class="adr"><span class="street-address vcardline">1 Microsoft Way</span><span class="vcardline"><span class="locality">Redmond</span>, <span class="region">WA</span>&nbsp;<span class="postal-code">98052</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:paulle@microsoft.com"><span class="email">paulle@microsoft.com</span></a></span></address>
     1501         <address class="vcard"><span class="vcardline"><span class="fn">Ari Luotonen</span><span class="n hidden"><span class="family-name">Luotonen</span><span class="given-name">Ari</span></span></span><span class="org vcardline">Netscape Communications Corporation</span><span class="adr"><span class="street-address vcardline">501 East Middlefield Road</span><span class="vcardline"><span class="locality">Mountain View</span>, <span class="region">CA</span>&nbsp;<span class="postal-code">94043</span></span><span class="country-name vcardline">USA</span></span></address>
     1502         <address class="vcard"><span class="vcardline"><span class="fn">Lawrence C. Stewart</span><span class="n hidden"><span class="family-name">Stewart</span><span class="given-name">Lawrence C.</span></span></span><span class="org vcardline">Open Market, Inc.</span><span class="adr"><span class="street-address vcardline">215 First Street</span><span class="vcardline"><span class="locality">Cambridge</span>, <span class="region">MA</span>&nbsp;<span class="postal-code">02142</span></span><span class="country-name vcardline">USA</span></span><span class="vcardline">EMail: <a href="mailto:stewart@OpenMarket.com"><span class="email">stewart@OpenMarket.com</span></a></span></address>
     1503      </div>
    15251504      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    15261505      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.N">N</a> <a href="#rfc.index.O">O</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.Q">Q</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.S">S</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.W">W</a>
    … …  
    16471626         </ul>
    16481627      </div>
     1628      <h1><a id="rfc.copyright" href="#rfc.copyright">Full Copyright Statement</a></h1>
     1629      <p>Copyright © The Internet Society (1999). All Rights Reserved.</p>
     1630      <p>This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise
     1631         explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without
     1632         restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative
     1633         works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references
     1634         to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards
     1635         in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to
     1636         translate it into languages other than English.
     1637      </p>
     1638      <p>The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.</p>
     1639      <p>This document and the information contained herein is provided on an “AS IS” basis and THE INTERNET SOCIETY AND THE INTERNET
     1640         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
     1641         OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR
     1642         PURPOSE.
     1643      </p>
     1644      <h1><a id="rfc.ipr" href="#rfc.ipr">Intellectual Property</a></h1>
     1645      <p>The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed
     1646         to pertain to the implementation or use of the technology described in this document or the extent to which any license under
     1647         such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights.
     1648         Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be
     1649         found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available,
     1650         or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors
     1651         or users of this specification can be obtained from the IETF Secretariat.
     1652      </p>
     1653      <p>The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary
     1654         rights which may cover technology that may be required to practice this standard. Please address the information to the IETF
     1655         Executive Director.
     1656      </p>
     1657      <h1>Acknowledgment</h1>
     1658      <p>Funding for the RFC Editor function is currently provided by the Internet Society.</p>
    16491659   </body>
    16501660</html>
Note: See TracChangeset for help on using the changeset viewer.