Changeset 2671 for draft-ietf-httpbis

Timestamp:

14/05/14 12:58:12 (7 years ago)

Author:

julian.reschke@…

Message:

grammar (#553)

Location:

draft-ietf-httpbis/latest

Files:

• p4-conditional.html (modified) (24 diffs)
• p4-conditional.xml (modified) (19 diffs)

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

@@ -463 +463 @@
   }
   @bottom-center {
-       content: "Expires November 13, 2014";
+       content: "Expires November 15, 2014";
   }
   @bottom-right {
@@ -506 +506 @@
       <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="2014-05-12">
+      <meta name="dct.issued" scheme="ISO8601" content="2014-05-14">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is a stateless 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.">
@@ -532 +532 @@
             </tr>
             <tr>
-               <td class="left">Expires: November 13, 2014</td>
-               <td class="right">May 12, 2014</td>
+               <td class="left">Expires: November 15, 2014</td>
+               <td class="right">May 14, 2014</td>
             </tr>
          </tbody>
@@ -561 +561 @@
             in progress”.
          </p>
-         <p>This Internet-Draft will expire on November 13, 2014.</p>
+         <p>This Internet-Draft will expire on November 15, 2014.</p>
       </div>
       <div id="rfc.copyrightnotice">
@@ -597 +597 @@
                      <li><a href="#rfc.section.2.3.1">2.3.1</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.generation">Generation</a></li>
                      <li><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;&nbsp;&nbsp;<a href="#entity.tag.comparison">Comparison</a></li>
-                     <li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-tags Varying on Content-Negotiated Resources</a></li>
+                     <li><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;&nbsp;&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></li>
                   </ul>
                </li>
-               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></li>
+               <li><a href="#rfc.section.2.4">2.4</a>&nbsp;&nbsp;&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></li>
             </ul>
          </li>
@@ -674 +674 @@
          <h1 id="rfc.section.2"><a href="#rfc.section.2">2.</a>&nbsp;<a href="#validators">Validators</a></h1>
          <p id="rfc.section.2.p.1">This specification defines two forms of metadata that are commonly used to observe resource state and test for preconditions:
-            modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as WebDAV <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>, that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.
+            modification dates (<a href="#header.last-modified" id="rfc.xref.header.last-modified.1" title="Last-Modified">Section&nbsp;2.2</a>) and opaque entity tags (<a href="#header.etag" id="rfc.xref.header.etag.1" title="ETag">Section&nbsp;2.3</a>). Additional metadata that reflects resource state has been defined by various extensions of HTTP, such as Web Distributed
+            Authoring and Versioning (WebDAV, <a href="#RFC4918" id="rfc.xref.RFC4918.1"><cite title="HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)">[RFC4918]</cite></a>), that are beyond the scope of this specification. A resource metadata value is referred to as a "<dfn>validator</dfn>" when it is used within a precondition.
          </p>
          <div id="weak.and.strong.validators">
@@ -707 +708 @@
             </p>
             <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data.
-               This weakness might be due to limitations in how the value is calculated, such as clock resolution or an inability to ensure
-               uniqueness for all possible representations of the resource, or due to a desire by the resource owner to group representations
-               by some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation.
+               This weakness might be due to limitations in how the value is calculated, such as clock resolution, an inability to ensure
+               uniqueness for all possible representations of the resource, or a desire of the resource owner to group representations by
+               some self-determined set of equivalency rather than unique sequences of data. An origin server <em class="bcp14">SHOULD</em> change a weak entity-tag whenever it considers prior representations to be unacceptable as a substitute for the current representation.
                In other words, a weak entity-tag ought to change whenever the origin server wants caches to invalidate old responses.
             </p>
@@ -791 +792 @@
                <p id="rfc.section.2.2.2.p.4">This method relies on the fact that if two different responses were sent by the origin server during the same second, but
                   both had the same Last-Modified time, then at least one of those responses would have a <a href="p2-semantics.html#header.date" class="smpl">Date</a> value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified
-                  values are generated from different clocks, or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
+                  values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation <em class="bcp14">MAY</em> use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
                </p>
             </div>
@@ -812 +813 @@
              ; <a href="#imported.abnf" class="smpl">VCHAR</a> except double quotes, plus obs-text
 </pre><div class="note" id="rfc.section.2.3.p.3">
-               <p><b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>), thus some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity
+               <p><b>Note:</b> Previously, opaque-tag was defined to be a quoted-string (<a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>, <a href="http://tools.ietf.org/html/rfc2616#section-3.11">Section 3.11</a>); thus, some recipients might perform backslash unescaping. Servers therefore ought to avoid backslash characters in entity
                   tags.
                </p> 
@@ -840 +841 @@
                   or a modification timestamp that has sub-second resolution.
                </p>
-               <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send ETag for any selected representation for which detection of changes can be reasonably and consistently determined, since
-                  the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
+               <p id="rfc.section.2.3.1.p.3">An origin server <em class="bcp14">SHOULD</em> send an ETag for any selected representation for which detection of changes can be reasonably and consistently determined,
+                  since the entity-tag's use in conditional requests and evaluating cache freshness (<a href="#RFC7234" id="rfc.xref.RFC7234.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>) can result in a substantial reduction of HTTP network traffic and can be a significant factor in improving service scalability
                   and reliability.
                </p>
@@ -847 +848 @@
             <div id="entity.tag.comparison">
                <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a href="#entity.tag.comparison">Comparison</a></h3>
-               <p id="rfc.section.2.3.2.p.1">There are two entity-tag comparison functions, depending on whether the comparison context allows the use of weak validators
-                  or not: 
-               </p>
+               <p id="rfc.section.2.3.2.p.1">There are two entity-tag comparison functions, depending on whether or not the comparison context allows the use of weak validators: </p>
                <ul>
                   <li><dfn>Strong comparison</dfn>: two entity-tags are equivalent if both are not weak and their opaque-tags match character-by-character.
@@ -857 +856 @@
                   </li>
                </ul>
-               <p id="rfc.section.2.3.2.p.2">The example below shows the results for a set of entity-tag pairs, and both the weak and strong comparison function results:</p>
+               <p id="rfc.section.2.3.2.p.2">The example below shows the results for a set of entity-tag pairs and both the weak and strong comparison function results:</p>
                <div id="rfc.table.u.1">
                   <table class="tt full left" cellpadding="3" cellspacing="0">
@@ -898 +897 @@
             </div>
             <div id="example.entity.tag.vs.conneg">
-               <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-tags Varying on Content-Negotiated Resources</a></h3>
+               <h3 id="rfc.section.2.3.3"><a href="#rfc.section.2.3.3">2.3.3</a>&nbsp;<a href="#example.entity.tag.vs.conneg">Example: Entity-Tags Varying on Content-Negotiated Resources</a></h3>
                <p id="rfc.section.2.3.3.p.1">Consider a resource that is subject to content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.3"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>), and where the representations sent in response to a GET request vary based on the <a href="p2-semantics.html#header.accept-encoding" class="smpl">Accept-Encoding</a> request header field (<a href="p2-semantics.html#header.accept-encoding" title="Accept-Encoding">Section 5.3.4</a> of <a href="#RFC7231" id="rfc.xref.RFC7231.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[RFC7231]</cite></a>):
                </p>
@@ -939 +938 @@
          </div>
          <div id="when.to.use.entity.tags.and.last-modified.dates">
-            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-tags and Last-Modified Dates</a></h2>
+            <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a href="#when.to.use.entity.tags.and.last-modified.dates">When to Use Entity-Tags and Last-Modified Dates</a></h2>
             <p id="rfc.section.2.4.p.1">In <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> responses to GET or HEAD, an origin server: 
             </p>
@@ -993 +992 @@
                of the selected representation.
             </p>
-            <p id="rfc.section.3.1.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if a received If-Match condition evaluates to false; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
+            <p id="rfc.section.3.1.p.8">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if a received If-Match condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code or b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
                in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
                agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other
@@ -1030 +1029 @@
                selected representation.
             </p>
-            <p id="rfc.section.3.2.p.9">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD; or, b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods.
+            <p id="rfc.section.3.2.p.9">An origin server <em class="bcp14">MUST NOT</em> perform the requested method if the condition evaluates to false; instead, the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.304" class="smpl">304 (Not Modified)</a> status code if the request method is GET or HEAD or b) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code for all other request methods.
             </p>
             <p id="rfc.section.3.2.p.10">Requirements on cache handling of a received If-None-Match header field are defined in <a href="p6-cache.html#validation.received" title="Handling a Received Validation Request">Section 4.3.2</a> of <a href="#RFC7234" id="rfc.xref.RFC7234.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>.
@@ -1045 +1044 @@
 </pre><p id="rfc.section.3.3.p.3">An example of the field is:</p>
             <div id="rfc.figure.u.13"></div><pre class="text">  If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-</pre><p id="rfc.section.3.3.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Modified-Since if the request contains an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field; the condition in <a href="#header.if-none-match" class="smpl">If-None-Match</a> is considered to be a more accurate replacement for the condition in If-Modified-Since and the two are only combined for the
-               sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.
+</pre><p id="rfc.section.3.3.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Modified-Since if the request contains an <a href="#header.if-none-match" class="smpl">If-None-Match</a> header field; the condition in <a href="#header.if-none-match" class="smpl">If-None-Match</a> is considered to be a more accurate replacement for the condition in If-Modified-Since, and the two are only combined for
+               the sake of interoperating with older intermediaries that might not implement <a href="#header.if-none-match" class="smpl">If-None-Match</a>.
             </p>
             <p id="rfc.section.3.3.p.6">A recipient <em class="bcp14">MUST</em> ignore the If-Modified-Since header field if the received field-value is not a valid HTTP-date, or if the request method is
@@ -1054 +1053 @@
             </p>
             <p id="rfc.section.3.3.p.8">If-Modified-Since is typically used for two distinct purposes: 1) to allow efficient updates of a cached representation that
-               does not have an entity-tag; and, 2) to limit the scope of a web traversal to resources that have recently changed.
+               does not have an entity-tag and 2) to limit the scope of a web traversal to resources that have recently changed.
             </p>
             <p id="rfc.section.3.3.p.9">When used for cache updates, a cache will typically use the value of the cached message's <a href="#header.last-modified" class="smpl">Last-Modified</a> field to generate the field value of If-Modified-Since. This behavior is most interoperable for cases where clocks are poorly
@@ -1081 +1080 @@
 </pre><p id="rfc.section.3.4.p.3">An example of the field is:</p>
             <div id="rfc.figure.u.15"></div><pre class="text">  If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
-</pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since and the two are only combined for
+</pre><p id="rfc.section.3.4.p.5">A recipient <em class="bcp14">MUST</em> ignore If-Unmodified-Since if the request contains an <a href="#header.if-match" class="smpl">If-Match</a> header field; the condition in <a href="#header.if-match" class="smpl">If-Match</a> is considered to be a more accurate replacement for the condition in If-Unmodified-Since, and the two are only combined for
                the sake of interoperating with older intermediaries that might not implement <a href="#header.if-match" class="smpl">If-Match</a>.
             </p>
@@ -1093 +1092 @@
             </p>
             <p id="rfc.section.3.4.p.9">An origin server that receives an If-Unmodified-Since header field <em class="bcp14">MUST</em> evaluate the condition prior to performing the method (<a href="#evaluation" title="Evaluation">Section&nbsp;5</a>). The origin server <em class="bcp14">MUST NOT</em> perform the requested method if the selected representation's last modification date is more recent than the date provided
-               in the field-value; instead the origin server <em class="bcp14">MUST</em> respond with either: a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code; or, b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
+               in the field-value; instead the origin server <em class="bcp14">MUST</em> respond with either a) the <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code or b) one of the <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> status codes if the origin server has verified that a state change is being requested and the final state is already reflected
                in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user
                agent might not be aware of that because the prior response message was lost or a compatible change was made by some other
@@ -1105 +1104 @@
          <div id="header.if-range">
             <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a href="#header.if-range">If-Range</a></h2>
-            <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but instructs the recipient to ignore the <a href="p5-range.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 response.
+            <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to the <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header fields but that instructs the recipient to ignore the <a href="p5-range.html#header.range" class="smpl">Range</a> header field if the validator doesn't match, resulting in transfer of the new selected representation instead of a 412 response.
                If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 3.2</a> of <a href="#RFC7233" id="rfc.xref.RFC7233.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>.
             </p>
@@ -1115 +1114 @@
             <div id="rfc.iref.21"></div>
             <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a 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 or HEAD 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
+            <p id="rfc.section.4.1.p.1">The <dfn>304 (Not Modified)</dfn> status code indicates that a conditional GET or HEAD 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 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 the client to make use of that stored
@@ -1136 +1135 @@
             <p id="rfc.section.4.2.p.1">The <dfn>412 (Precondition Failed)</dfn> status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the
                server. This response code allows the client to place preconditions on the current resource state (its current representations
-               and metadata) and thus prevent the request method from being applied if the target resource is in an unexpected state.
+               and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.
             </p>
          </div>
@@ -1146 +1145 @@
             other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx</a> or <a href="#status.412" class="smpl">412 (Precondition Failed)</a>. In other words, redirects and failures take precedence over the evaluation of preconditions in conditional requests.
          </p>
-         <p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can
+         <p id="rfc.section.5.p.2">A server that is not the origin server for the target resource and cannot act as a cache for requests on the target resource <em class="bcp14">MUST NOT</em> evaluate the conditional request header fields defined by this specification, and it <em class="bcp14">MUST</em> forward them if the request is forwarded, since the generating client intends that they be evaluated by a server that can
             provide a current representation. Likewise, a server <em class="bcp14">MUST</em> ignore the conditional request header fields defined by this specification when received with a request method that does not
             involve the selection or modification of a <a href="p2-semantics.html#representations" class="smpl">selected representation</a>, such as CONNECT, OPTIONS, or TRACE.

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

@@ -200 +200 @@
    (<xref target="header.last-modified"/>) and opaque entity tags
    (<xref target="header.etag"/>).  Additional metadata that reflects resource state
-   has been defined by various extensions of HTTP, such as WebDAV
-   <xref target="RFC4918"/>, that are beyond the scope of this specification.
+   has been defined by various extensions of HTTP, such as Web Distributed
+   Authoring and Versioning (WebDAV, <xref target="RFC4918"/>), that are beyond the scope of this specification.
    A resource metadata value is referred to as a "<x:dfn>validator</x:dfn>"
    when it is used within a precondition.
@@ -260 +260 @@
    might not change for every change to the representation data.  This
    weakness might be due to limitations in how the value is calculated, such
-   as clock resolution or an inability to ensure uniqueness for all possible
-   representations of the resource, or due to a desire by the resource owner
+   as clock resolution, an inability to ensure uniqueness for all possible
+   representations of the resource, or a desire of the resource owner
    to group representations by some self-determined set of equivalency
    rather than unique sequences of data.  An origin server &SHOULD; change a
@@ -406 +406 @@
    have a <x:ref>Date</x:ref> value equal to its Last-Modified time. The
    arbitrary 60-second limit guards against the possibility that the Date and
-   Last-Modified values are generated from different clocks, or at somewhat
+   Last-Modified values are generated from different clocks or at somewhat
    different times during the preparation of the response. An
    implementation &MAY; use a value larger than 60 seconds, if it is
@@ -444 +444 @@
   <t>
     &Note; Previously, opaque-tag was defined to be a quoted-string
-    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>), thus some recipients
+    (<xref target="RFC2616" x:fmt="," x:sec="3.11"/>); thus, some recipients
     might perform backslash unescaping. Servers therefore ought to avoid
     backslash characters in entity tags.
@@ -492 +492 @@
 </t>
 <t>
-   An origin server &SHOULD; send ETag for any selected representation
+   An origin server &SHOULD; send an ETag for any selected representation
    for which detection of changes can be reasonably and consistently
    determined, since the entity-tag's use in conditional requests and
@@ -506 +506 @@
   <x:anchor-alias value="weak comparison"/>
 <t>
-   There are two entity-tag comparison functions, depending
-   on whether the comparison context allows the use of weak validators
-   or not:
+   There are two entity-tag comparison functions, depending on whether or not
+   the comparison context allows the use of weak validators:
   <list style="symbols">
      <t><x:dfn>Strong comparison</x:dfn>: two entity-tags are equivalent if both
@@ -518 +517 @@
 </t>
 <t>
-   The example below shows the results for a set of entity-tag pairs,
-   and both the weak and strong comparison function results:
+   The example below shows the results for a set of entity-tag pairs and both
+   the weak and strong comparison function results:
 </t>
 <texttable align="left">
@@ -549 +548 @@
 </section>
 
-<section title="Example: Entity-tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
+<section title="Example: Entity-Tags Varying on Content-Negotiated Resources" anchor="example.entity.tag.vs.conneg">
 <t>
    Consider a resource that is subject to content negotiation
@@ -606 +605 @@
 </section>
 
-<section title="When to Use Entity-tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
+<section title="When to Use Entity-Tags and Last-Modified Dates" anchor="when.to.use.entity.tags.and.last-modified.dates">
 <t>
    In <x:ref>200 (OK)</x:ref> responses to GET or HEAD, an origin server:
@@ -707 +706 @@
 <t>
    An origin server &MUST-NOT; perform the requested method if a received
-   If-Match condition evaluates to false; instead the origin server &MUST;
-   respond with either:
-   a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or,
+   If-Match condition evaluates to false; instead, the origin server &MUST;
+   respond with either
+   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
    b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
    server has verified that a state change is being requested and the final
@@ -787 +786 @@
    evaluates to false; instead, the origin server &MUST; respond with either
    a) the <x:ref>304 (Not Modified)</x:ref> status code if the request method
-   is GET or HEAD; or,
-   b) the <x:ref>412 (Precondition Failed)</x:ref> status code for all other
-   request methods.
+   is GET or HEAD or b) the <x:ref>412 (Precondition Failed)</x:ref> status
+   code for all other request methods.
 </t>
 <t>
@@ -819 +817 @@
    <x:ref>If-None-Match</x:ref> header field; the condition in
    <x:ref>If-None-Match</x:ref> is considered to be a more accurate
-   replacement for the condition in If-Modified-Since and the two are only
+   replacement for the condition in If-Modified-Since, and the two are only
    combined for the sake of interoperating with older intermediaries that
    might not implement <x:ref>If-None-Match</x:ref>.
@@ -835 +833 @@
    If-Modified-Since is typically used for two distinct purposes:
    1) to allow efficient updates of a cached representation that does not
-   have an entity-tag; and,
-   2) to limit the scope of a web traversal to resources that have recently
-   changed.
+   have an entity-tag and 2) to limit the scope of a web traversal to resources 
+   that have recently changed.
 </t>
 <t>
@@ -901 +898 @@
    <x:ref>If-Match</x:ref> header field; the condition in
    <x:ref>If-Match</x:ref> is considered to be a more accurate replacement for
-   the condition in If-Unmodified-Since and the two are only combined for the
+   the condition in If-Unmodified-Since, and the two are only combined for the
    sake of interoperating with older intermediaries that might not implement
    <x:ref>If-Match</x:ref>.
@@ -928 +925 @@
    The origin server &MUST-NOT; perform the requested method if the selected
    representation's last modification date is more recent than the date
-   provided in the field-value; instead the
-   origin server &MUST; respond with either:
-   a) the <x:ref>412 (Precondition Failed)</x:ref> status code; or,
+   provided in the field-value; instead the origin server &MUST; respond with either
+   a) the <x:ref>412 (Precondition Failed)</x:ref> status code or
    b) one of the <x:ref>2xx (Successful)</x:ref> status codes if the origin
    server has verified that a state change is being requested and the final
@@ -951 +947 @@
    The "If-Range" header field provides a special conditional request
    mechanism that is similar to the <x:ref>If-Match</x:ref> and
-   <x:ref>If-Unmodified-Since</x:ref> header fields but instructs the
+   <x:ref>If-Unmodified-Since</x:ref> header fields but that instructs the
    recipient to ignore the <x:ref>Range</x:ref> header field if the validator
    doesn't match, resulting in transfer of the new selected representation
@@ -968 +964 @@
    conditional GET or HEAD request has been
    received and would have resulted in a <x:ref>200 (OK)</x:ref> response
-   if it were not for the fact that the condition has evaluated to false.
+   if it were not for the fact that the condition 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
@@ -1016 +1012 @@
    when tested on the server. This response code allows the client to place
    preconditions on the current resource state (its current representations
-   and metadata) and thus prevent the request method from being applied if the
+   and metadata) and, thus, prevent the request method from being applied if the
    target resource is in an unexpected state.
 </t>
@@ -1037 +1033 @@
    A server that is not the origin server for the target resource and cannot
    act as a cache for requests on the target resource &MUST-NOT; evaluate the
-   conditional request header fields defined by this specification, and
+   conditional request header fields defined by this specification, and it
    &MUST; forward them if the request is forwarded, since the generating
    client intends that they be evaluated by a server that can provide a