Ignore:
Timestamp:
Dec 31, 2012, 3:51:04 AM (7 years ago)
Author:
fielding@…
Message:

(editorial) that vs which

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p7-auth.html

    r2069 r2074  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 3, 2013";
     451       content: "Expires July 4, 2013";
    452452  }
    453453  @bottom-right {
     
    489489      <meta name="dct.creator" content="Reschke, J. F.">
    490490      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    491       <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
     491      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
    492492      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    493493      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.">
     
    517517            <tr>
    518518               <td class="left">Intended status: Standards Track</td>
    519                <td class="right">December 30, 2012</td>
     519               <td class="right">December 31, 2012</td>
    520520            </tr>
    521521            <tr>
    522                <td class="left">Expires: July 3, 2013</td>
     522               <td class="left">Expires: July 4, 2013</td>
    523523               <td class="right"></td>
    524524            </tr>
     
    546546         in progress”.
    547547      </p>
    548       <p>This Internet-Draft will expire on July 3, 2013.</p>
     548      <p>This Internet-Draft will expire on July 4, 2013.</p>
    549549      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    550550      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    623623         Authentication" (<a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>).
    624624      </p>
    625       <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to
     625      <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms that can be used by a server to challenge a client request and by a client to
    626626         provide authentication information. The "basic" and "digest" authentication schemes continue to be specified in <cite title="HTTP Authentication: Basic and Digest Access Authentication" id="rfc.xref.RFC2617.2">RFC 2617</cite>.
    627627      </p>
     
    699699      <p id="rfc.section.2.2.p.2">A <dfn>protection space</dfn> is defined by the canonical root URI (the scheme and authority components of the effective request URI; see <a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 5.5</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>) of the server being accessed, in combination with the realm value if present. These realms allow the protected resources
    700700         on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
    701          database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific
     701         database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific
    702702         to the authentication scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
    703703      </p>
     
    770770               response directive, within the scope of the request they appear in.
    771771            </p>
    772             <p>Therefore, new authentication schemes which choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
     772            <p>Therefore, new authentication schemes that choose not to carry credentials in the <a href="#header.authorization" class="smpl">Authorization</a> header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of
    773773               either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
    774774            </p>
     
    815815      <div id="rfc.iref.p.3"></div>
    816816      <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a>&nbsp;<a id="header.proxy-authorization" href="#header.proxy-authorization">Proxy-Authorization</a></h2>
    817       <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy which requires authentication.
     817      <p id="rfc.section.4.3.p.1">The "Proxy-Authorization" header field allows the client to identify itself (or its user) to a proxy that requires authentication.
    818818         Its value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of
    819819         the resource being requested.
     
    942942      </p>
    943943      <ul>
    944          <li>Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt
     944         <li>Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt
    945945            the user for credentials.
    946946         </li>
    947          <li>Applications which include a session termination indication (such as a "logout" or "commit" button on a page) after which
    948             the server side of the application "knows" that there is no further reason for the client to retain the credentials.
     947         <li>Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the
     948            server side of the application "knows" that there is no further reason for the client to retain the credentials.
    949949         </li>
    950950      </ul>
    951951      <p id="rfc.section.6.1.p.2">This is currently under separate study. There are a number of work-arounds to parts of this problem, and we encourage the
    952          use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent
    953          in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism
     952         use of password protection in screen savers, idle time-outs, and other methods that mitigate the security problems inherent
     953         in this problem. In particular, user agents that cache credentials are encouraged to provide a readily accessible mechanism
    954954         for discarding cached credentials under user control.
    955955      </p>
Note: See TracChangeset for help on using the changeset viewer.