Changeset 2074 for draft-ietf-httpbis

Timestamp:

31/12/12 11:51:04 (9 years ago)

Author:

fielding@…

Message:

(editorial) that vs which

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (4 diffs)
• p1-messaging.xml (modified) (4 diffs)
• p2-semantics.html (modified) (21 diffs)
• p2-semantics.xml (modified) (21 diffs)
• p4-conditional.html (modified) (6 diffs)
• p4-conditional.xml (modified) (2 diffs)
• p6-cache.html (modified) (1 diff)
• p6-cache.xml (modified) (1 diff)
• p7-auth.html (modified) (9 diffs)
• p7-auth.xml (modified) (6 diffs)

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

@@ -919 +919 @@
       <p id="rfc.section.2.4.p.2">The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached
          response applicable to that request. The following illustrates the resulting chain if B has a cached copy of an earlier response
-         from O (via C) for a request which has not been cached by UA or A.
+         from O (via C) for a request that has not been cached by UA or A.
       </p>
       <div id="rfc.figure.u.5"></div><pre class="drawing">            &gt;             &gt;
@@ -1881 +1881 @@
       <div id="rfc.figure.u.54"></div><pre class="text">  Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
 </pre><p id="rfc.section.5.7.1.p.14">Senders <em class="bcp14">SHOULD NOT</em> combine multiple entries unless they are all under the same organizational control and the hosts have already been replaced
-         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries which have different received-protocol values.
+         by pseudonyms. Senders <em class="bcp14">MUST NOT</em> combine entries that have different received-protocol values.
       </p>
       <h3 id="rfc.section.5.7.2"><a href="#rfc.section.5.7.2">5.7.2</a>&nbsp;<a id="message.transformations" href="#message.transformations">Transformations</a></h3>
@@ -1965 +1965 @@
       </p>
       <h2 id="rfc.section.6.3"><a href="#rfc.section.6.3">6.3</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistence</a></h2>
-      <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", which allow multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections.
+      <p id="rfc.section.6.3.p.1">HTTP/1.1 defaults to the use of "<dfn>persistent connections</dfn>", allowing multiple requests and responses to be carried over a single connection. The "<a href="#header.connection" class="smpl">close</a>" connection-option is used to signal that a connection will not persist after the current request/response. HTTP implementations <em class="bcp14">SHOULD</em> support persistent connections.
       </p>
       <p id="rfc.section.6.3.p.2">A recipient determines whether a connection is persistent or not based on the most recently received message's protocol version
@@ -1993 +1993 @@
       <p id="rfc.section.6.3.1.p.1">A client that supports persistent connections <em class="bcp14">MAY</em> "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server <em class="bcp14">MUST</em> send its responses to those requests in the same order that the requests were received.
       </p>
-      <p id="rfc.section.6.3.1.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
+      <p id="rfc.section.6.3.1.p.2">Clients that assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses.
       </p>
       <p id="rfc.section.6.3.1.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 4.2.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to

draft-ietf-httpbis/latest/p1-messaging.xml

@@ -575 +575 @@
    applicable to that request. The following illustrates the resulting
    chain if B has a cached copy of an earlier response from O (via C)
-   for a request which has not been cached by UA or A.
+   for a request that has not been cached by UA or A.
 </t>
 <figure><artwork type="drawing">
@@ -2596 +2596 @@
    Senders &SHOULD-NOT; combine multiple entries unless they are all
    under the same organizational control and the hosts have already been
-   replaced by pseudonyms. Senders &MUST-NOT; combine entries which
+   replaced by pseudonyms. Senders &MUST-NOT; combine entries that
    have different received-protocol values.
 </t>
@@ -2783 +2783 @@
 <t>
    HTTP/1.1 defaults to the use of "<x:dfn>persistent connections</x:dfn>",
-   which allow multiple requests and responses to be carried over a single
+   allowing multiple requests and responses to be carried over a single
    connection. The "<x:ref>close</x:ref>" connection-option is used to signal
    that a connection will not persist after the current request/response.
@@ -2847 +2847 @@
 </t>
 <t>
-   Clients which assume persistent connections and pipeline immediately
+   Clients that assume persistent connections and pipeline immediately
    after connection establishment &SHOULD; be prepared to retry their
    connection if the first pipelined attempt fails. If a client does

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

@@ -1437 +1437 @@
          the result.
       </p>
-      <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the response <em class="bcp14">SHOULD</em> be <a href="#status.201" class="smpl">201 (Created)</a>, contain a representation which describes the status of the request and refers to the new resource(s), and include a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (see <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.2</a>).
-      </p>
-      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cached POST response with a <a href="#header.content-location" class="smpl">Content-Location</a> header field (see <a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4.2</a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD (not POST) requests.
+      <p id="rfc.section.4.3.3.p.4">If one or more resources has been created on the origin server, the origin server <em class="bcp14">SHOULD</em> send a <a href="#status.201" class="smpl">201 (Created)</a> response containing a <a href="#header.location" class="smpl">Location</a> header field that provides an identifier for the primary resource created (<a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section&nbsp;7.1.2</a>) and a representation that describes the status of the request and refers to the new resource(s).
+      </p>
+      <p id="rfc.section.4.3.3.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 4.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.5"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>). A cache <em class="bcp14">MUST NOT</em> use a cached POST response to satisfy a subsequent GET or HEAD request unless the response contains a <a href="#header.content-location" class="smpl">Content-Location</a> header field with the same value as the POST's effective request URI (<a href="#header.content-location" id="rfc.xref.header.content-location.2" title="Content-Location">Section&nbsp;3.1.4.2</a>).
       </p>
       <p id="rfc.section.4.3.3.p.6">Note that POST caching is not widely implemented. However, the <a href="#status.303" class="smpl">303 (See Other)</a> response can be used to direct the user agent to retrieve a cacheable representation of the resource.
@@ -1457 +1457 @@
       <p id="rfc.section.4.3.4.p.3">An origin server <em class="bcp14">SHOULD</em> ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).
       </p>
-      <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints which the server has for the target resource that cannot
-         or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
+      <p id="rfc.section.4.3.4.p.4">An origin server <em class="bcp14">SHOULD</em> verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or
+         will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information
          related to the URI in order to set the values for representation metadata on GET responses. When a PUT representation is inconsistent
          with the target resource, the origin server <em class="bcp14">SHOULD</em> either make them consistent, by transforming the representation or changing the resource configuration, or respond with an
@@ -1493 +1493 @@
       </p>
       <p id="rfc.section.4.3.4.p.9">A PUT request applied to the target resource <em class="bcp14">MAY</em> have side-effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource)
-         which is separate from the URIs identifying each particular version (different resources that at one point shared the same
+         that is separate from the URIs identifying each particular version (different resources that at one point shared the same
          state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new
          version resource in addition to changing the state of the target resource, and might also cause links to be added between
@@ -1562 +1562 @@
          undelivered, that data will be discarded.
       </p>
-      <p id="rfc.section.4.3.6.p.11">An origin server which receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
+      <p id="rfc.section.4.3.6.p.11">An origin server that receives a CONNECT request for itself <em class="bcp14">MAY</em> respond with a <a href="#status.2xx" class="smpl">2xx</a> status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
       </p>
       <h3 id="rfc.section.4.3.7"><a href="#rfc.section.4.3.7">4.3.7</a>&nbsp;<a id="OPTIONS" href="#OPTIONS">OPTIONS</a></h3>
@@ -1642 +1642 @@
       <h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h3>
       <p id="rfc.section.5.1.1.p.1">The "Max-Forwards" header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section&nbsp;4.3.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section&nbsp;4.3.7</a>) methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting
-         to trace a request which appears to be failing or looping mid-chain.
+         to trace a request that appears to be failing or looping mid-chain.
       </p>
       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.17"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
@@ -1697 +1697 @@
       <p id="rfc.section.5.1.2.1.p.6">Requirements for HTTP/1.1 origin servers: </p>
       <ul>
-         <li>Upon receiving a request which includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request.
+         <li>Upon receiving a request that includes an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, an origin server <em class="bcp14">MUST</em> either respond with <a href="#status.100" class="smpl">100 (Continue)</a> status code and continue to read from the input stream, or respond with a final status code. The origin server <em class="bcp14">MUST NOT</em> wait for the payload body before sending the <a href="#status.100" class="smpl">100 (Continue)</a> response. If the origin server responds with a final status code, it <em class="bcp14">MUST NOT</em> have performed the request method and <em class="bcp14">MAY</em> either close the connection or continue to read and discard the rest of the request.
          </li>
          <li>An origin server <em class="bcp14">SHOULD NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if the request message does not include an <a href="#header.expect" class="smpl">Expect</a> header field with the "100-continue" expectation, and <em class="bcp14">MUST NOT</em> send a <a href="#status.100" class="smpl">100 (Continue)</a> response if such a request comes from an HTTP/1.0 (or earlier) client. There is an exception to this rule: for compatibility
@@ -1861 +1861 @@
       </ol>
       <p id="rfc.section.5.3.2.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence
-         which matches that type. For example,
+         that matches the type. For example,
       </p>
       <div id="rfc.figure.u.27"></div><pre class="text">  Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
@@ -1903 +1903 @@
       </div>
       <p id="rfc.section.5.3.2.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent
-         is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user.
+         is a closed system that cannot interact with other rendering agents, this default set ought to be configurable by the user.
       </p>
       <div id="rfc.iref.a.2"></div>
@@ -1909 +1909 @@
       <p id="rfc.section.5.3.3.p.1">The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in a selected representation.
          This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability
-         to an origin server which is capable of representing documents in those charsets.
+         to an origin server that is capable of representing documents in those charsets.
       </p>
       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.29"></span>  <a href="#header.accept-charset" class="smpl">Accept-Charset</a> = 1#( ( <a href="#charset" class="smpl">charset</a> / "*" ) [ <a href="#quality.values" class="smpl">weight</a> ] )
@@ -1915 +1915 @@
       </p>
       <div id="rfc.figure.u.29"></div><pre class="text">  Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
-</pre><p id="rfc.section.5.3.3.p.5">The special value "*", if present in the Accept-Charset field, matches every charset which is not mentioned elsewhere in the
+</pre><p id="rfc.section.5.3.3.p.5">The special value "*", if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the
          Accept-Charset field. If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field
          are considered "not acceptable" to the client.
@@ -1933 +1933 @@
       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span>  <a href="#header.accept-encoding" class="smpl">Accept-Encoding</a>  = #( <a href="#header.accept-encoding" class="smpl">codings</a> [ <a href="#quality.values" class="smpl">weight</a> ] )
   <a href="#header.accept-encoding" class="smpl">codings</a>          = <a href="#content.codings" class="smpl">content-coding</a> / "identity" / "*"
-</pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value which represents the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>.
+</pre><p id="rfc.section.5.3.4.p.3">Each codings value <em class="bcp14">MAY</em> be given an associated quality value representing the preference for that encoding, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>.
       </p>
       <p id="rfc.section.5.3.4.p.4">For example,</p>
@@ -1974 +1974 @@
   <a href="#header.accept-language" class="smpl">language-range</a>  = 
             &lt;language-range, defined in <a href="#RFC4647" id="rfc.xref.RFC4647.1"><cite title="Matching of Language Tags">[RFC4647]</cite></a>, <a href="http://tools.ietf.org/html/rfc4647#section-2.1">Section 2.1</a>&gt;
-</pre><p id="rfc.section.5.3.5.p.3">Each language-range can be given an associated quality value which represents an estimate of the user's preference for the
-         languages specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. For example,
+</pre><p id="rfc.section.5.3.5.p.3">Each language-range can be given an associated quality value representing an estimate of the user's preference for the languages
+         specified by that range, as defined in <a href="#quality.values" title="Quality Values">Section&nbsp;5.3.1</a>. For example,
       </p>
       <div id="rfc.figure.u.33"></div><pre class="text">  Accept-Language: da, en-gb;q=0.8, en;q=0.7
@@ -2394 +2394 @@
       <h3 id="rfc.section.6.2.2"><a href="#rfc.section.6.2.2">6.2.2</a>&nbsp;<a id="status.101" href="#status.101">101 Switching Protocols</a></h3>
       <p id="rfc.section.6.2.2.p.1">The <dfn>101 (Switching Protocols)</dfn> status code indicates that the server understands and is willing to comply with the client's request, via the <a href="p1-messaging.html#header.upgrade" class="smpl">Upgrade</a> header field (<a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 6.7</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>), for a change in the application protocol being used on this connection. The server will switch to the protocol(s) indicated
-         within the response's Upgrade header field immediately after the empty line which terminates the 101 response.
+         within the response's Upgrade header field immediately after the empty line that terminates the 101 response.
       </p>
       <p id="rfc.section.6.2.2.p.2">It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching
@@ -2644 +2644 @@
       <div id="rfc.iref.74"></div>
       <h3 id="rfc.section.6.5.6"><a href="#rfc.section.6.5.6">6.5.6</a>&nbsp;<a id="status.406" href="#status.406">406 Not Acceptable</a></h3>
-      <p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation which would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), and the server is unwilling to supply a default representation.
+      <p id="rfc.section.6.5.6.p.1">The <dfn>406 (Not Acceptable)</dfn> status code indicates that the <a href="#resources" class="smpl">target resource</a> does not have a current representation that would be acceptable to the user agent, according to the <a href="#proactive.negotiation" class="smpl">proactive negotiation</a> header fields received in the request (<a href="#request.conneg" title="Content Negotiation">Section&nbsp;5.3</a>), and the server is unwilling to supply a default representation.
       </p>
       <p id="rfc.section.6.5.6.p.2">The server <em class="bcp14">SHOULD</em> generate a payload containing a list of available representation characteristics and corresponding resource identifiers from
@@ -2664 +2664 @@
       </p>
       <p id="rfc.section.6.5.8.p.2">Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation
-         being PUT included changes to a resource which conflict with those made by an earlier (third-party) request, the origin server
+         being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server
          might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely
          contain information useful for merging the differences based on the revision history.
@@ -2731 +2731 @@
       <div id="rfc.iref.75"></div>
       <h3 id="rfc.section.6.6.1"><a href="#rfc.section.6.6.1">6.6.1</a>&nbsp;<a id="status.500" href="#status.500">500 Internal Server Error</a></h3>
-      <p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition which prevented it from fulfilling the request.
+      <p id="rfc.section.6.6.1.p.1">The <dfn>500 (Internal Server Error)</dfn> status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
       </p>
       <div id="rfc.iref.75"></div>
@@ -3799 +3799 @@
          of <a href="#header.from" class="smpl">From</a> and <a href="#header.referer" class="smpl">Referer</a> information.
       </p>
-      <p id="rfc.section.9.3.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields can sometimes be used to determine that a specific client or server has a particular security hole which might
-         be exploited. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
+      <p id="rfc.section.9.3.p.7">The <a href="#header.user-agent" class="smpl">User-Agent</a> (<a href="#header.user-agent" id="rfc.xref.header.user-agent.4" title="User-Agent">Section&nbsp;5.5.3</a>) or <a href="#header.server" class="smpl">Server</a> (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;7.4.2</a>) header fields can sometimes be used to determine if a specific client or server is more likely to be vulnerable to a known
+         security hole. Unfortunately, this same information is often used for other valuable purposes for which HTTP currently has
          no better mechanism.
       </p>
@@ -3835 +3835 @@
       </p>
       <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a>&nbsp;<a id="privacy.issues.connected.to.accept.header.fields" href="#privacy.issues.connected.to.accept.header.fields">Privacy Issues Connected to Accept Header Fields</a></h2>
-      <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers which are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
-         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents which offer
+      <p id="rfc.section.9.7.p.1">Accept header fields can reveal information about the user to all servers that are accessed. The <a href="#header.accept-language" class="smpl">Accept-Language</a> header field in particular can reveal information the user would consider to be of a private nature, because the understanding
+         of particular languages is often strongly correlated to the membership of a particular ethnic group. User agents that offer
          the option to configure the contents of an Accept-Language header field to be sent in every request are strongly encouraged
          to let the configuration process include a message which makes the user aware of the loss of privacy involved.
@@ -3850 +3850 @@
          also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
          be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies
-         could filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header
+         could filter the accept header fields in relayed requests. General purpose user agents that provide a high degree of header
          field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
       </p>
@@ -4090 +4090 @@
          over HTTP.
       </p>
-      <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, that this might be complicated by the presence of
-         a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some charsets which do not use octets 13 and 10 to represent CR and LF, respectively.
+      <p id="rfc.section.A.2.p.2">Where it is possible, a proxy or gateway from HTTP to a strict MIME environment <em class="bcp14">SHOULD</em> translate all line breaks within the text media types described in <a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section&nbsp;3.1.1.3</a> of this document to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a <a href="#header.content-encoding" class="smpl">Content-Encoding</a> and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.
       </p>
       <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
@@ -4114 +4113 @@
       </p>
       <h2 id="rfc.section.A.6"><a href="#rfc.section.A.6">A.6</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
-      <p id="rfc.section.A.6.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
+      <p id="rfc.section.A.6.p.1">HTTP implementations that share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
          fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
          and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;3.1.1.4</a>) and does not interpret the content or any MIME header lines that might be contained therein.

draft-ietf-httpbis/latest/p2-semantics.xml

@@ -1340 +1340 @@
 </t>
 <t>
-   If one or more resources has been created on the origin server, the response
-   &SHOULD; be <x:ref>201 (Created)</x:ref>, contain a representation which
-   describes the status of the request and refers to the new resource(s), and
-   include a <x:ref>Location</x:ref> header field that provides an identifier
-   for the primary resource created (see <xref target="header.location"/>).
+   If one or more resources has been created on the origin server, the origin
+   server &SHOULD; send a <x:ref>201 (Created)</x:ref> response containing a
+   <x:ref>Location</x:ref> header field that provides an identifier for the
+   primary resource created (<xref target="header.location"/>) and a
+   representation that describes the status of the request and refers to the
+   new resource(s).
 </t>
 <t>
    Responses to POST requests are only cacheable when they include explicit
-   freshness information (see &p6-explicit;). A cached POST response with a
-   <x:ref>Content-Location</x:ref> header field (see
-   &header-content-location;) whose value is the effective Request URI &MAY;
-   be used to satisfy subsequent GET and HEAD (not POST) requests.
+   freshness information (see &p6-explicit;). A cache &MUST-NOT; use a cached
+   POST response to satisfy a subsequent GET or HEAD request unless the
+   response contains a <x:ref>Content-Location</x:ref> header field with the
+   same value as the POST's effective request URI (&header-content-location;).
 </t>
 <t>
@@ -1393 +1394 @@
 <t>
    An origin server &SHOULD; verify that the PUT representation is
-   consistent with any constraints which the server has for the target
+   consistent with any constraints the server has for the target
    resource that cannot or will not be changed by the PUT.  This is
    particularly important when the origin server uses internal
@@ -1460 +1461 @@
    A PUT request applied to the target resource &MAY; have side-effects
    on other resources.  For example, an article might have a URI for
-   identifying "the current version" (a resource) which is separate
+   identifying "the current version" (a resource) that is separate
    from the URIs identifying each particular version (different
    resources that at one point shared the same state as the current version
@@ -1600 +1601 @@
 </t>
 <t>
-   An origin server which receives a CONNECT request for itself &MAY;
+   An origin server that receives a CONNECT request for itself &MAY;
    respond with a <x:ref>2xx</x:ref> status code to indicate that a connection
    is established.  However, most origin servers do not implement CONNECT.
@@ -1741 +1742 @@
    methods to limit the number of times that the request is forwarded by
    proxies. This can be useful when the client is attempting to
-   trace a request which appears to be failing or looping mid-chain.
+   trace a request that appears to be failing or looping mid-chain.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Max-Forwards"/>
@@ -1860 +1861 @@
    Requirements for HTTP/1.1 origin servers:
   <list style="symbols">
-    <t> Upon receiving a request which includes an <x:ref>Expect</x:ref> header
+    <t> Upon receiving a request that includes an <x:ref>Expect</x:ref> header
         field with the "100-continue" expectation, an origin server &MUST;
         either respond with <x:ref>100 (Continue)</x:ref> status code and
@@ -2099 +2100 @@
    The media type quality factor associated with a given type is
    determined by finding the media range with the highest precedence
-   which matches that type. For example,
+   that matches the type. For example,
 </t>
 <figure><artwork type="example">
@@ -2120 +2121 @@
    &Note; A user agent might be provided with a default set of quality
    values for certain media ranges. However, unless the user agent is
-   a closed system which cannot interact with other rendering agents,
+   a closed system that cannot interact with other rendering agents,
    this default set ought to be configurable by the user.
 </t>
@@ -2133 +2134 @@
    This field allows user agents capable of understanding more comprehensive
    or special-purpose charsets to signal that capability to an origin server
-   which is capable of representing documents in those charsets.
+   that is capable of representing documents in those charsets.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Accept-Charset"/>
@@ -2149 +2150 @@
 <t>
    The special value "*", if present in the Accept-Charset field,
-   matches every charset which is not mentioned elsewhere in the
+   matches every charset that is not mentioned elsewhere in the
    Accept-Charset field. If no "*" is present in an Accept-Charset field,
    then any charsets not explicitly mentioned in the field are
@@ -2187 +2188 @@
 </artwork></figure>
 <t>
-   Each codings value &MAY; be given an associated quality value which
-   represents the preference for that encoding, as defined in &qvalue;.
+   Each codings value &MAY; be given an associated quality value
+   representing the preference for that encoding, as defined in &qvalue;.
 </t>
 <t>
@@ -2258 +2259 @@
 </artwork></figure>
 <t>
-   Each language-range can be given an associated quality value which
-   represents an estimate of the user's preference for the languages
+   Each language-range can be given an associated quality value
+   representing an estimate of the user's preference for the languages
    specified by that range, as defined in &qvalue;. For example,
 </t>
@@ -2665 +2666 @@
    a change in the application protocol being used on this connection. The
    server will switch to the protocol(s) indicated within the response's
-   Upgrade header field immediately after the empty line which terminates the
+   Upgrade header field immediately after the empty line that terminates the
    101 response.
 </t>
@@ -3204 +3205 @@
 <t>
    The <x:dfn>406 (Not Acceptable)</x:dfn> status code indicates that the
-   <x:ref>target resource</x:ref> does not have a current representation which
+   <x:ref>target resource</x:ref> does not have a current representation that
    would be acceptable to the user agent, according to the
    <x:ref>proactive negotiation</x:ref> header fields received in the request
@@ -3252 +3253 @@
    Conflicts are most likely to occur in response to a PUT request. For
    example, if versioning were being used and the representation being PUT
-   included changes to a resource which conflict with those made by an
+   included changes to a resource that conflict with those made by an
    earlier (third-party) request, the origin server might use a 409 response
    to indicate that it can't complete the request. In this case, the response
@@ -3403 +3404 @@
 <t>
    The <x:dfn>500 (Internal Server Error)</x:dfn> status code indicates that
-   the server encountered an unexpected condition which prevented it from
+   the server encountered an unexpected condition that prevented it from
    fulfilling the request.
 </t>
@@ -4761 +4762 @@
    The <x:ref>User-Agent</x:ref> (<xref target="header.user-agent"/>) or
    <x:ref>Server</x:ref> (<xref target="header.server"/>) header fields can
-   sometimes be used to determine that a specific client or server has a
-   particular security hole which might be exploited. Unfortunately, this same
+   sometimes be used to determine if a specific client or server is more
+   likely to be vulnerable to a known security hole. Unfortunately, this same
    information is often used for other valuable purposes for which HTTP
    currently has no better mechanism.
@@ -4834 +4835 @@
 <t>
    Accept header fields can reveal information about the user to all
-   servers which are accessed. The <x:ref>Accept-Language</x:ref> header field
+   servers that are accessed. The <x:ref>Accept-Language</x:ref> header field
    in particular can reveal information the user would consider to be of a
    private nature, because the understanding of particular languages is often
    strongly correlated to the membership of a particular ethnic group.
-   User agents which offer the option to configure the contents of an
+   User agents that offer the option to configure the contents of an
    Accept-Language header field to be sent in every request are strongly
    encouraged to let the configuration process include a message which
@@ -4864 +4865 @@
    header field configuration options to end users. As an extreme privacy
    measure, proxies could filter the accept header fields in relayed requests.
-   General purpose user agents which provide a high degree of header field
+   General purpose user agents that provide a high degree of header field
    configurability &SHOULD; warn users about the loss of privacy which can
    be involved.
@@ -5648 +5649 @@
    environment &SHOULD; translate all line breaks within the text media
    types described in <xref target="canonicalization.and.text.defaults"/>
-   of this document to the RFC 2049 canonical form of CRLF. Note, however, that
+   of this document to the RFC 2049 canonical form of CRLF. Note, however,
    this might be complicated by the presence of a <x:ref>Content-Encoding</x:ref>
    and by the fact that HTTP allows the use of some charsets
-   which do not use octets 13 and 10 to represent CR and LF, respectively.
+   that do not use octets 13 and 10 to represent CR and LF, respectively.
 </t>
 <t>
@@ -5707 +5708 @@
 <section title="MHTML and Line Length Limitations" anchor="mhtml.line.length">
 <t>
-   HTTP implementations which share code with MHTML <xref target="RFC2557"/> implementations
+   HTTP implementations that share code with MHTML <xref target="RFC2557"/> implementations
    need to be aware of MIME line length limitations. Since HTTP does not
    have this limitation, HTTP does not fold long lines. MHTML messages

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 3, 2013"; 
+       content: "Expires July 4, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
@@ -517 +517 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 3, 2013</td>
-               <td class="right">December 30, 2012</td>
+               <td class="left">Expires: July 4, 2013</td>
+               <td class="right">December 31, 2012</td>
             </tr>
          </tbody>
@@ -545 +545 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 3, 2013.</p>
+      <p>This Internet-Draft will expire on July 4, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1012 +1012 @@
       <ol>
          <li>If the request would normally result in anything other than a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> status code, or if the passed If-Modified-Since date is invalid, the response is exactly the same as for a normal GET. A date
-            which is later than the server's current time is invalid.
+            that is later than the server's current time is invalid.
          </li>
          <li>If the selected representation has been modified since the If-Modified-Since date, the response is exactly the same as for
@@ -1057 +1057 @@
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="status.304" href="#status.304">304 Not Modified</a></h2>
       <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET request has been received and would have resulted in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response if it were not for the fact that the condition has evaluated to false. In other words, there is no need for the server
-         to transfer a representation of the target resource because the request indicates that the client which made the request conditional
-         already has a valid representation; the server is therefore redirecting that client to make use of that stored representation
-         as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
+         to transfer a representation of the target resource because the request indicates that the client, which made the request
+         conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored
+         representation as if it were the payload of a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response.
       </p>
       <p id="rfc.section.4.1.p.2">A 304 response cannot contain a message-body; it is always terminated by the first empty line after the header fields.</p>

draft-ietf-httpbis/latest/p4-conditional.xml

@@ -830 +830 @@
          <x:ref>200 (OK)</x:ref> status code, or if the passed If-Modified-Since date is
          invalid, the response is exactly the same as for a normal GET.
-         A date which is later than the server's current time is
+         A date that is later than the server's current time is
          invalid.</t>
 
@@ -934 +934 @@
    In other words, there is no need for the server to transfer a
    representation of the target resource because the request indicates that
-   the client which made the request conditional already has a valid
-   representation; the server is therefore redirecting that client to make
+   the client, which made the request conditional, already has a valid
+   representation; the server is therefore redirecting the client to make
    use of that stored representation as if it were the payload of a
    <x:ref>200 (OK)</x:ref> response.

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

@@ -1017 +1017 @@
       <p id="rfc.section.4.1.3.p.15"> </p>
       <ul>
-         <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date which appears to be more than 50 years in the future is in fact in the past (this helps solve
-            the "year 2000" problem).
+         <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date appearing to be more than 50 years in the future is in fact in the past (this helps solve the
+            "year 2000" problem).
          </li>
          <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.

draft-ietf-httpbis/latest/p6-cache.xml

@@ -767 +767 @@
   <list style="symbols">
      <t>Recipients &SHOULD; assume that an RFC-850 date
-        which appears to be more than 50 years in the future is in fact
+        appearing to be more than 50 years in the future is in fact
         in the past (this helps solve the "year 2000" problem).</t>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 3, 2013"; 
+       content: "Expires July 4, 2013"; 
   } 
   @bottom-right {
@@ -489 +489 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-12-30">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-12-31">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <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.">
@@ -517 +517 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">December 30, 2012</td>
+               <td class="right">December 31, 2012</td>
             </tr>
             <tr>
-               <td class="left">Expires: July 3, 2013</td>
+               <td class="left">Expires: July 4, 2013</td>
                <td class="right"></td>
             </tr>
@@ -546 +546 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 3, 2013.</p>
+      <p>This Internet-Draft will expire on July 4, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -623 +623 @@
          Authentication" (<a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>).
       </p>
-      <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
+      <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
          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>.
       </p>
@@ -699 +699 @@
       <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
          on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization
-         database. The realm value is a string, generally assigned by the origin server, which can have additional semantics specific
+         database. The realm value is a string, generally assigned by the origin server, that can have additional semantics specific
          to the authentication scheme. Note that there can be multiple challenges with the same auth-scheme but different realms.
       </p>
@@ -770 +770 @@
                response directive, within the scope of the request they appear in.
             </p>
-            <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
+            <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
                either Cache-Control request directives (e.g., "no-store") or response directives (e.g., "private").
             </p>
@@ -815 +815 @@
       <div id="rfc.iref.p.3"></div>
       <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>
-      <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.
+      <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.
          Its value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of
          the resource being requested.
@@ -942 +942 @@
       </p>
       <ul>
-         <li>Clients which have been idle for an extended period following which the server might wish to cause the client to reprompt
+         <li>Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt
             the user for credentials.
          </li>
-         <li>Applications which include a session termination indication (such as a "logout" or "commit" button on a page) after which
-            the server side of the application "knows" that there is no further reason for the client to retain the credentials.
+         <li>Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the
+            server side of the application "knows" that there is no further reason for the client to retain the credentials.
          </li>
       </ul>
       <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
-         use of password protection in screen savers, idle time-outs, and other methods which mitigate the security problems inherent
-         in this problem. In particular, user agents which cache credentials are encouraged to provide a readily accessible mechanism
+         use of password protection in screen savers, idle time-outs, and other methods that mitigate the security problems inherent
+         in this problem. In particular, user agents that cache credentials are encouraged to provide a readily accessible mechanism
          for discarding cached credentials under user control.
       </p>

draft-ietf-httpbis/latest/p7-auth.xml

@@ -120 +120 @@
 <t>
    HTTP provides several &OPTIONAL; challenge-response authentication
-   mechanisms which can be used by a server to challenge a client request and
+   mechanisms that can be used by a server to challenge a client request and
    by a client to provide authentication information. The "basic" and "digest"
    authentication schemes continue to be specified in
@@ -290 +290 @@
    partitioned into a set of protection spaces, each with its own
    authentication scheme and/or authorization database. The realm value
-   is a string, generally assigned by the origin server, which can have
+   is a string, generally assigned by the origin server, that can have
    additional semantics specific to the authentication scheme. Note that
    there can be multiple challenges with the same auth-scheme but
@@ -408 +408 @@
     </t>
     <t>
-      Therefore, new authentication schemes which choose not to carry
+      Therefore, new authentication schemes that choose not to carry
       credentials in the <x:ref>Authorization</x:ref> header field (e.g., using a newly defined
       header field) will need to explicitly disallow caching, by mandating the use of
@@ -524 +524 @@
 <t>
    The "Proxy-Authorization" header field allows the client to
-   identify itself (or its user) to a proxy which requires
+   identify itself (or its user) to a proxy that requires
    authentication. Its value consists of
    credentials containing the authentication information of the user
@@ -694 +694 @@
    application's security model include but are not limited to:
   <list style="symbols">
-     <t>Clients which have been idle for an extended period following
-        which the server might wish to cause the client to reprompt the
+     <t>Clients that have been idle for an extended period, following
+        which the server might wish to cause the client to re-prompt the
         user for credentials.</t>
 
-     <t>Applications which include a session termination indication
+     <t>Applications that include a session termination indication
         (such as a "logout" or "commit" button on a page) after which
         the server side of the application "knows" that there is no
@@ -708 +708 @@
    to parts of this problem, and we encourage the use of
    password protection in screen savers, idle time-outs, and other
-   methods which mitigate the security problems inherent in this
-   problem. In particular, user agents which cache credentials are
+   methods that mitigate the security problems inherent in this
+   problem. In particular, user agents that cache credentials are
    encouraged to provide a readily accessible mechanism for discarding
    cached credentials under user control.