Changeset 1739

Timestamp:

08/07/12 14:50:41 (11 years ago)

Author:

julian.reschke@…

Message:

Work-in-progress: hyperlink header field definitions(P4)

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (3 diffs)
• p2-semantics.xml (modified) (4 diffs)
• p4-conditional.html (modified) (9 diffs)
• p4-conditional.xml (modified) (15 diffs)
• p5-range.html (modified) (5 diffs)
• p5-range.xml (modified) (7 diffs)
• p6-cache.html (modified) (6 diffs)
• p6-cache.xml (modified) (7 diffs)

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

@@ -979 +979 @@
          in the response and not the source text of the process, unless that text happens to be the output of the process.
       </p>
-      <p id="rfc.section.2.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an If-Modified-Since, If-Unmodified-Since,
-         If-Match, If-None-Match, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
+      <p id="rfc.section.2.3.2.p.3">The semantics of the GET method change to a "conditional GET" if the request message includes an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>, <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>, <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field (<a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). A conditional GET requests that the representation be transferred only under the circumstances described by the conditional
          header field(s). The conditional GET request is intended to reduce unnecessary network usage by allowing cached representations
          to be refreshed without requiring multiple requests or transferring data already held by the client.
@@ -1711 +1710 @@
       <p id="rfc.section.4.4.2.p.3">The origin server <em class="bcp14">MUST</em> create the resource(s) before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with <a href="#status.202" class="smpl">202 (Accepted)</a> response instead.
       </p>
-      <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity-tag for the representation of the resource
-         identified by the Location header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
+      <p id="rfc.section.4.4.2.p.4">A 201 response <em class="bcp14">MAY</em> contain an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> response header field indicating the current value of the entity-tag for the representation of the resource identified by
+         the Location header field or, in case the Location header field was omitted, by the Effective Request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>).
       </p>
       <div id="rfc.iref.27"></div>
@@ -1743 +1742 @@
          current representation after the requested action.
       </p>
-      <p id="rfc.section.4.4.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field,
-         then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.
+      <p id="rfc.section.4.4.5.p.2">For example, if a 204 status code is received in response to a PUT request and the response contains an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that
+         target resource.
       </p>
       <p id="rfc.section.4.4.5.p.3">The 204 response allows a server to indicate that the action has been successfully applied to the target resource while implying

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

@@ -580 +580 @@
 <t>
    The semantics of the GET method change to a "conditional GET" if the
-   request message includes an If-Modified-Since, If-Unmodified-Since,
-   If-Match, If-None-Match, or <x:ref>If-Range</x:ref> header field
+   request message includes an <x:ref>If-Modified-Since</x:ref>,
+   <x:ref>If-Unmodified-Since</x:ref>, <x:ref>If-Match</x:ref>,
+   <x:ref>If-None-Match</x:ref>, or <x:ref>If-Range</x:ref> header field
    (<xref target="Part4"/>). A conditional GET requests that the representation
    be transferred only under the circumstances described by the conditional
@@ -1418 +1419 @@
 </t>
 <t>
-   A 201 response &MAY; contain an ETag response header field indicating
-   the current value of the entity-tag for the representation of the resource
-   identified by the Location header field or, in case the Location header
-   field was omitted, by the Effective Request URI (see &header-etag;).
+   A 201 response &MAY; contain an <x:ref>ETag</x:ref> response header field
+   indicating the current value of the entity-tag for the representation of the
+   resource identified by the Location header field or, in case the Location
+   header field was omitted, by the Effective Request URI (see &header-etag;).
 </t>
 </section>
@@ -1483 +1484 @@
 <t>
    For example, if a 204 status code is received in response to a PUT
-   request and the response contains an ETag header field, then the PUT
-   was successful and the ETag field-value contains the entity-tag for
+   request and the response contains an <x:ref>ETag</x:ref> header field, then
+   the PUT was successful and the ETag field-value contains the entity-tag for
    the new representation of that target resource.
 </t>
@@ -4649 +4650 @@
   <x:source basename="p4-conditional" href="p4-conditional.xml">
     <x:defines>304 (Not Modified)</x:defines>
+    <x:defines>ETag</x:defines>
+    <x:defines>If-Match</x:defines>
+    <x:defines>If-Modified-Since</x:defines>
+    <x:defines>If-None-Match</x:defines>
+    <x:defines>If-Unmodified-Since</x:defines>
   </x:source>
 </reference>

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

@@ -769 +769 @@
       <p id="rfc.section.2.2.2.p.2">or </p>
       <ul>
-         <li>The validator is about to be used by a client in an If-Modified-Since, If-Unmodified-Since header field, because the client
-            has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and
+         <li>The validator is about to be used by a client in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>, <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field, because the client has a cache entry, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> for the associated representation, and
          </li>
          <li>That cache entry includes a Date value, which gives the time when the origin server sent the original response, and</li>
@@ -932 +931 @@
             or if it is unfeasible to send a strong entity-tag.
          </li>
-         <li><em class="bcp14">SHOULD</em> send a Last-Modified value if it is feasible to send one.
+         <li><em class="bcp14">SHOULD</em> send a <a href="#header.last-modified" class="smpl">Last-Modified</a> value if it is feasible to send one.
          </li>
       </ul>
-      <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a Last-Modified
-         value.
+      <p id="rfc.section.2.4.p.3">In other words, the preferred behavior for an HTTP/1.1 origin server is to send both a strong entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value.
       </p>
       <p id="rfc.section.2.4.p.4">HTTP/1.1 clients: </p>
       <ul>
-         <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using If-Match or If-None-Match) if an entity-tag has been provided
-            by the origin server.
-         </li>
-         <li><em class="bcp14">SHOULD</em> use the Last-Modified value in non-subrange cache-conditional requests (using If-Modified-Since) if only a Last-Modified value
-            has been provided by the origin server.
-         </li>
-         <li><em class="bcp14">MAY</em> use the Last-Modified value in subrange cache-conditional requests (using If-Unmodified-Since) if only a Last-Modified value
-            has been provided by an HTTP/1.0 origin server. The user agent <em class="bcp14">SHOULD</em> provide a way to disable this, in case of difficulty.
-         </li>
-         <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity-tag and a Last-Modified value have been provided by the
-            origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
+         <li><em class="bcp14">MUST</em> use that entity-tag in any cache-conditional request (using <a href="#header.if-match" class="smpl">If-Match</a> or <a href="#header.if-none-match" class="smpl">If-None-Match</a>) if an entity-tag has been provided by the origin server.
+         </li>
+         <li><em class="bcp14">SHOULD</em> use the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in non-subrange cache-conditional requests (using <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a>) if only a Last-Modified value has been provided by the origin server.
+         </li>
+         <li><em class="bcp14">MAY</em> use the <a href="#header.last-modified" class="smpl">Last-Modified</a> value in subrange cache-conditional requests (using <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a>) if only a Last-Modified value has been provided by an HTTP/1.0 origin server. The user agent <em class="bcp14">SHOULD</em> provide a way to disable this, in case of difficulty.
+         </li>
+         <li><em class="bcp14">SHOULD</em> use both validators in cache-conditional requests if both an entity-tag and a <a href="#header.last-modified" class="smpl">Last-Modified</a> value have been provided by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond appropriately.
          </li>
       </ul>
-      <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since
-         or If-Unmodified-Since header field) and one or more entity-tags (e.g., in an If-Match, If-None-Match, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
+      <p id="rfc.section.2.4.p.5">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> or <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field) and one or more entity-tags (e.g., in an <a href="#header.if-match" class="smpl">If-Match</a>, <a href="#header.if-none-match" class="smpl">If-None-Match</a>, or <a href="p5-range.html#header.if-range" class="smpl">If-Range</a> header field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status code of <a href="#status.304" class="smpl">304 (Not Modified)</a> unless doing so is consistent with all of the conditional header fields in the request.
       </p>
       <p id="rfc.section.2.4.p.6">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity-tags
@@ -996 +989 @@
   If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
   If-Match: *
-</pre><p id="rfc.section.3.1.p.9">The result of a request having both an If-Match header field and either an If-None-Match or an If-Modified-Since header field
-         is undefined by this specification.
+</pre><p id="rfc.section.3.1.p.9">The result of a request having both an If-Match header field and either an <a href="#header.if-none-match" class="smpl">If-None-Match</a> or an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field is undefined by this specification.
       </p>
       <div id="rfc.iref.i.2"></div>
@@ -1015 +1007 @@
       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.8"></span>  <a href="#header.if-none-match" class="smpl">If-None-Match</a> = "*" / 1#<a href="#header.etag" class="smpl">entity-tag</a>
 </pre><p id="rfc.section.3.2.p.4">If any of the entity-tags listed in the If-None-Match field-value match (as per <a href="#entity.tag.comparison" title="Comparison">Section&nbsp;2.3.2</a>) the entity-tag of the selected representation, or if "*" is given and any current representation exists for that resource,
-         then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly ETag) of the selected representation that has a matching
-         entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
-      </p>
-      <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any If-Modified-Since header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
-      </p>
-      <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;2.4</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
+         then the server <em class="bcp14">MUST NOT</em> perform the requested method. Instead, if the request method was GET or HEAD, the server <em class="bcp14">SHOULD</em> respond with a <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, including the cache-related header fields (particularly <a href="#header.etag" class="smpl">ETag</a>) of the selected representation that has a matching entity-tag. For all other request methods, the server <em class="bcp14">MUST</em> respond with a <a href="#status.412" class="smpl">412 (Precondition Failed)</a> status code.
+      </p>
+      <p id="rfc.section.3.2.p.5">If none of the entity-tags match, then the server <em class="bcp14">MAY</em> perform the requested method as if the If-None-Match header field did not exist, but <em class="bcp14">MUST</em> also ignore any <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field(s) in the request. That is, if no entity-tags match, then the server <em class="bcp14">MUST NOT</em> return a <a href="#status.304" class="smpl">304 (Not Modified)</a> response.
+      </p>
+      <p id="rfc.section.3.2.p.6">If the request would, without the If-None-Match header field, result in anything other than a <a href="p2-semantics.html#status.2xx" class="smpl">2xx (Successful)</a> or <a href="#status.304" class="smpl">304 (Not Modified)</a> status code, then the If-None-Match header field <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity-tags and Last-Modified Dates">Section&nbsp;2.4</a> for a discussion of server behavior when both <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> and If-None-Match appear in the same request.)
       </p>
       <p id="rfc.section.3.2.p.7">Examples:</p>
@@ -1028 +1019 @@
   If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
   If-None-Match: *
-</pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an If-Match or an If-Unmodified-Since header
-         field is undefined by this specification.
+</pre><p id="rfc.section.3.2.p.9">The result of a request having both an If-None-Match header field and either an <a href="#header.if-match" class="smpl">If-Match</a> or an <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field is undefined by this specification.
       </p>
       <div id="rfc.iref.i.3"></div>
@@ -1062 +1052 @@
          <li> <b>Note:</b> When handling an If-Modified-Since header field, some servers will use an exact date comparison function, rather than a less-than
             function, for deciding whether to send a <a href="#status.304" class="smpl">304 (Not Modified)</a> response. To get best results when sending an If-Modified-Since header field for cache validation, clients are advised to
-            use the exact date string received in a previous Last-Modified header field whenever possible.
-         </li>
-         <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the Last-Modified header
-            field for the same request, the client needs to be aware that this date is interpreted in the server's understanding of time.
-            Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server, are concerns.
-            This includes the possibility of race conditions if the document has changed between the time it was first requested and the
-            If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
+            use the exact date string received in a previous <a href="#header.last-modified" class="smpl">Last-Modified</a> header field whenever possible.
+         </li>
+         <li> <b>Note:</b> If a client uses an arbitrary date in the If-Modified-Since header field instead of a date taken from the <a href="#header.last-modified" class="smpl">Last-Modified</a> header field for the same request, the client needs to be aware that this date is interpreted in the server's understanding
+            of time. Unsynchronized clocks and rounding problems, due to the different encodings of time between the client and server,
+            are concerns. This includes the possibility of race conditions if the document has changed between the time it was first requested
+            and the If-Modified-Since date of a subsequent request, and the possibility of clock-skew-related problems if the If-Modified-Since
             date is derived from the client's clock without correction to the server's clock. Corrections for different time bases between
             client and server are at best approximate due to network latency.
          </li>
       </ul>
-      <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an If-Match or an If-Unmodified-Since header
-         field is undefined by this specification.
+      <p id="rfc.section.3.3.p.7">The result of a request having both an If-Modified-Since header field and either an <a href="#header.if-match" class="smpl">If-Match</a> or an <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> header field is undefined by this specification.
       </p>
       <div id="rfc.iref.i.4"></div>
@@ -1089 +1077 @@
       <p id="rfc.section.3.4.p.6">If the specified date is invalid, the header field <em class="bcp14">MUST</em> be ignored.
       </p>
-      <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an If-None-Match or an If-Modified-Since
-         header field is undefined by this specification.
+      <p id="rfc.section.3.4.p.7">The result of a request having both an If-Unmodified-Since header field and either an <a href="#header.if-none-match" class="smpl">If-None-Match</a> or an <a href="#header.if-modified-since" class="smpl">If-Modified-Since</a> header field is undefined by this specification.
       </p>
       <h2 id="rfc.section.3.5"><a href="#rfc.section.3.5">3.5</a>&nbsp;<a id="header.if-range" 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 If-Match and If-Unmodified-Since
-         but specific to HTTP range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
+      <p id="rfc.section.3.5.p.1">The "If-Range" header field provides a special conditional request mechanism that is similar to <a href="#header.if-match" class="smpl">If-Match</a> and <a href="#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> but specific to HTTP range requests. If-Range is defined in <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> of <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>.
       </p>
       <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a>&nbsp;<a id="status.code.definitions" href="#status.code.definitions">Status Code Definitions</a></h1>
@@ -1105 +1091 @@
          as if it were the payload of a 200 response. The 304 response <em class="bcp14">MUST NOT</em> contain a message-body, and thus is always terminated by the first empty line after the header fields.
       </p>
-      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
+      <p id="rfc.section.4.1.p.2">A 304 response <em class="bcp14">MUST</em> include a Date header field (<a href="p2-semantics.html#header.date" title="Date">Section 9.10</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) unless the origin server does not have a clock that can provide a reasonable approximation of the current time. If a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request would have included any of the header fields <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, Content-Location, <a href="#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, then those same header fields <em class="bcp14">MUST</em> be sent in a 304 response.
       </p>
       <p id="rfc.section.4.1.p.3">Since the goal of a 304 response is to minimize information transfer when the recipient already has one or more cached representations,
@@ -1291 +1277 @@
       <p id="rfc.section.A.p.1">Allow weak entity-tags in all requests except range requests (Sections <a href="#weak.and.strong.validators" title="Weak versus Strong">2.1</a> and <a href="#header.if-none-match" id="rfc.xref.header.if-none-match.2" title="If-None-Match">3.2</a>).
       </p>
-      <p id="rfc.section.A.p.2">Change ETag header field ABNF not to use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section&nbsp;2.3</a>)
+      <p id="rfc.section.A.p.2">Change <a href="#header.etag" class="smpl">ETag</a> header field ABNF not to use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section&nbsp;2.3</a>)
       </p>
       <p id="rfc.section.A.p.3">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Precondition Header Fields">Section&nbsp;3</a>)

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

@@ -422 +422 @@
    or
   <list style="symbols">
-     <t>The validator is about to be used by a client in an If-Modified-Since,
-        If-Unmodified-Since header field, because the client has a cache entry,
-        or <x:ref>If-Range</x:ref> for the associated representation, and</t>
+     <t>The validator is about to be used by a client in an <x:ref>If-Modified-Since</x:ref>,
+        <x:ref>If-Unmodified-Since</x:ref> header field, because the client has
+        a cache entry, or <x:ref>If-Range</x:ref> for the associated
+        representation, and</t>
      <t>That cache entry includes a Date value, which gives the time
         when the origin server sent the original response, and</t>
@@ -663 +664 @@
         or if it is unfeasible to send a strong entity-tag.</t>
 
-     <t>&SHOULD; send a Last-Modified value if it is feasible to send one.</t>
+     <t>&SHOULD; send a <x:ref>Last-Modified</x:ref> value if it is feasible to
+        send one.</t>
   </list>
 </t>
 <t>
    In other words, the preferred behavior for an HTTP/1.1 origin server
-   is to send both a strong entity-tag and a Last-Modified value.
+   is to send both a strong entity-tag and a <x:ref>Last-Modified</x:ref> value.
 </t>
 <t>
@@ -674 +676 @@
   <list style="symbols">
      <t>&MUST; use that entity-tag in any cache-conditional request (using
-        If-Match or If-None-Match) if an entity-tag has been provided by the
-        origin server.</t>
-
-     <t>&SHOULD; use the Last-Modified value in non-subrange cache-conditional
-        requests (using If-Modified-Since) if only a Last-Modified value has
-        been provided by the origin server. </t>
-
-     <t>&MAY; use the Last-Modified value in subrange cache-conditional
-        requests (using If-Unmodified-Since) if only a Last-Modified value has
-        been provided by an HTTP/1.0 origin server. The user agent &SHOULD;
-        provide a way to disable this, in case of difficulty.</t>
+        <x:ref>If-Match</x:ref> or <x:ref>If-None-Match</x:ref>) if an
+        entity-tag has been provided by the origin server.</t>
+
+     <t>&SHOULD; use the <x:ref>Last-Modified</x:ref> value in non-subrange
+        cache-conditional requests (using <x:ref>If-Modified-Since</x:ref>)
+        if only a Last-Modified value has been provided by the origin server.</t>
+
+     <t>&MAY; use the <x:ref>Last-Modified</x:ref> value in subrange
+        cache-conditional requests (using <x:ref>If-Unmodified-Since</x:ref>)
+        if only a Last-Modified value has been provided by an HTTP/1.0 origin
+        server. The user agent &SHOULD; provide a way to disable this, in case
+        of difficulty.</t>
 
      <t>&SHOULD; use both validators in cache-conditional requests if both an
-        entity-tag and a Last-Modified value have been provided by the origin
-        server. This allows both HTTP/1.0 and HTTP/1.1 caches to respond
-        appropriately.</t>
+        entity-tag and a <x:ref>Last-Modified</x:ref> value have been provided
+        by the origin server. This allows both HTTP/1.0 and HTTP/1.1 caches to
+        respond appropriately.</t>
   </list>
 </t>
 <t>
    An HTTP/1.1 origin server, upon receiving a conditional request that
-   includes both a Last-Modified date (e.g., in an If-Modified-Since or
-   If-Unmodified-Since header field) and one or more entity-tags (e.g.,
-   in an If-Match, If-None-Match, or <x:ref>If-Range</x:ref> header field) as
-   cache validators, &MUST-NOT; return a response status code of
-   <x:ref>304 (Not Modified)</x:ref> unless doing so is consistent with all of
-   the conditional header fields in the request.
+   includes both a Last-Modified date (e.g., in an <x:ref>If-Modified-Since</x:ref>
+   or <x:ref>If-Unmodified-Since</x:ref> header field) and one or more
+   entity-tags (e.g., in an <x:ref>If-Match</x:ref>, <x:ref>If-None-Match</x:ref>,
+   or <x:ref>If-Range</x:ref> header field) as cache validators, &MUST-NOT;
+   return a response status code of <x:ref>304 (Not Modified)</x:ref> unless
+   doing so is consistent with all of the conditional header fields in the
+   request.
 </t>
 <t>
@@ -782 +786 @@
 <t>
    The result of a request having both an If-Match header field and
-   either an If-None-Match or an If-Modified-Since header field is
-   undefined by this specification.
+   either an <x:ref>If-None-Match</x:ref> or an <x:ref>If-Modified-Since</x:ref>
+   header field is undefined by this specification.
 </t>
 </section>
@@ -822 +826 @@
    Instead, if the request method was GET or HEAD, the server &SHOULD;
    respond with a <x:ref>304 (Not Modified)</x:ref> status code, including the cache-related
-   header fields (particularly ETag) of the selected representation that has
+   header fields (particularly <x:ref>ETag</x:ref>) of the selected representation that has
    a matching entity-tag.  For all other request methods, the server &MUST;
    respond with a <x:ref>412 (Precondition Failed)</x:ref> status code.
@@ -829 +833 @@
    If none of the entity-tags match, then the server &MAY; perform the
    requested method as if the If-None-Match header field did not exist,
-   but &MUST; also ignore any If-Modified-Since header field(s) in the
-   request. That is, if no entity-tags match, then the server &MUST-NOT;
+   but &MUST; also ignore any <x:ref>If-Modified-Since</x:ref> header field(s)
+   in the request. That is, if no entity-tags match, then the server &MUST-NOT;
    return a <x:ref>304 (Not Modified)</x:ref> response.
 </t>
@@ -839 +843 @@
    header field &MUST; be ignored. (See <xref
    target="rules.for.when.to.use.entity.tags.and.last-modified.dates"/> for
-   a discussion of server behavior when both If-Modified-Since and
-   If-None-Match appear in the same request.)
+   a discussion of server behavior when both <x:ref>If-Modified-Since</x:ref>
+   and If-None-Match appear in the same request.)
 </t>
 <t>
@@ -854 +858 @@
 <t>
    The result of a request having both an If-None-Match header field and
-   either an If-Match or an If-Unmodified-Since header field is
-   undefined by this specification.
+   either an <x:ref>If-Match</x:ref> or an <x:ref>If-Unmodified-Since</x:ref>
+   header field is undefined by this specification.
 </t>
 </section>
@@ -915 +919 @@
       response. To get best results when sending an If-Modified-Since
       header field for cache validation, clients are
-      advised to use the exact date string received in a previous Last-Modified
-      header field whenever possible.
+      advised to use the exact date string received in a previous
+      <x:ref>Last-Modified</x:ref> header field whenever possible.
     </t><t>
       &Note; If a client uses an arbitrary date in the If-Modified-Since
-      header field instead of a date taken from the Last-Modified header field for
-      the same request, the client needs to be aware that this
+      header field instead of a date taken from the <x:ref>Last-Modified</x:ref>
+      header field for the same request, the client needs to be aware that this
       date is interpreted in the server's understanding of time.
       Unsynchronized clocks and rounding problems, due to the different
@@ -937 +941 @@
 <t>
    The result of a request having both an If-Modified-Since header field
-   and either an If-Match or an If-Unmodified-Since header field is
-   undefined by this specification.
+   and either an <x:ref>If-Match</x:ref> or an <x:ref>If-Unmodified-Since</x:ref>
+   header field is undefined by this specification.
 </t>
 </section>
@@ -976 +980 @@
 <t>
    The result of a request having both an If-Unmodified-Since header
-   field and either an If-None-Match or an If-Modified-Since header
-   field is undefined by this specification.
+   field and either an <x:ref>If-None-Match</x:ref> or an <x:ref>If-Modified-Since</x:ref>
+   header field is undefined by this specification.
 </t>
 </section>
@@ -984 +988 @@
 <t>
    The "If-Range" header field provides a special conditional request
-   mechanism that is similar to If-Match and If-Unmodified-Since but
-   specific to HTTP range requests. If-Range is defined in &header-if-range;.
+   mechanism that is similar to <x:ref>If-Match</x:ref> and
+   <x:ref>If-Unmodified-Since</x:ref> but specific to HTTP range requests.
+   If-Range is defined in &header-if-range;.
 </t>
 </section>
@@ -1014 +1019 @@
    reasonable approximation of the current time.  If a <x:ref>200 (OK)</x:ref>
    response to the same request would have included any of the header fields
-   Cache-Control, Content-Location, ETag, <x:ref>Expires</x:ref>, or
-   <x:ref>Vary</x:ref>, then those same header fields &MUST; be sent in a 304
-   response.
+   <x:ref>Cache-Control</x:ref>, Content-Location, <x:ref>ETag</x:ref>,
+   <x:ref>Expires</x:ref>, or <x:ref>Vary</x:ref>, then those same header
+   fields &MUST; be sent in a 304 response.
 </t>
 <t>
@@ -1253 +1258 @@
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
   <x:source href="p6-cache.xml" basename="p6-cache">
+    <x:defines>Cache-Control</x:defines>
     <x:defines>Expires</x:defines>
     <x:defines>Vary</x:defines>
@@ -1373 +1379 @@
 </t>
 <t>
-  Change ETag header field ABNF not to use quoted-string, thus avoiding
-  escaping issues.
+  Change <x:ref>ETag</x:ref> header field ABNF not to use quoted-string, thus
+  avoiding escaping issues.
   (<xref target="header.etag"/>)
 </t>

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

@@ -742 +742 @@
          </li>
          <li>Date</li>
-         <li>Cache-Control, ETag, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Location and/or Vary, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
+         <li> <a href="p6-cache.html#header.cache-control" class="smpl">Cache-Control</a>, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a>, <a href="p6-cache.html#header.expires" class="smpl">Expires</a>, Content-Location and/or <a href="p6-cache.html#header.vary" class="smpl">Vary</a>, if the header field would have been sent in a <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> response to the same request
          </li>
       </ul>
@@ -794 +794 @@
          one or more Range specifications. After several such transfers, a client might have received several ranges of the same representation.
          These ranges can only be safely combined if they all have in common the same strong validator, where "strong validator" is
-         defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
+         defined to be either an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
       </p>
       <p id="rfc.section.4.2.p.2">When a client receives an incomplete <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a> or <a href="#status.206" class="smpl">206 (Partial Content)</a> response and already has one or more stored responses for the same method and effective request URI, all of the stored responses
@@ -888 +888 @@
       <h2 id="rfc.section.5.3"><a href="#rfc.section.5.3">5.3</a>&nbsp;<a id="header.if-range" href="#header.if-range">If-Range</a></h2>
       <p id="rfc.section.5.3.p.1">If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it
-         could use the <a href="#range.retrieval.requests" class="smpl">Range</a> header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the condition
-         fails because the representation has been modified, the client would then have to make a second request to obtain the entire
-         current representation.
+         could use the <a href="#range.retrieval.requests" class="smpl">Range</a> header field with a conditional GET (using either or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>.) However, if the condition fails because the representation has been modified, the client would then have to make a second
+         request to obtain the entire current representation.
       </p>
       <p id="rfc.section.5.3.p.2">The "If-Range" header field allows a client to "short-circuit" the second request. Informally, its meaning is "if the representation
@@ -896 +895 @@
       </p>
       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.10"></span>  <a href="#header.if-range" class="smpl">If-Range</a> = <a href="#abnf.dependencies" class="smpl">entity-tag</a> / <a href="#core.rules" class="smpl">HTTP-date</a>
-</pre><p id="rfc.section.5.3.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a Last-Modified date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified
-         date it does have for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
+</pre><p id="rfc.section.5.3.p.4">Clients <em class="bcp14">MUST NOT</em> use an entity-tag marked as weak in an If-Range field value and <em class="bcp14">MUST NOT</em> use a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> date in an If-Range field value unless it has no entity-tag for the representation and the Last-Modified date it does have
+         for the representation is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
       </p>
       <p id="rfc.section.5.3.p.5">A server that evaluates a conditional range request that is applicable to one of its representations <em class="bcp14">MUST</em> evaluate the condition as false if the entity-tag used as a validator is marked as weak or, when an HTTP-date is used as the
@@ -983 +982 @@
             In other words, the response carries a status code of <a href="#status.206" class="smpl">206 (Partial Content)</a> instead of <a href="p2-semantics.html#status.200" class="smpl">200 (OK)</a>.
          </li>
-         <li>The presence of a Range header field in a conditional GET (a request using one or both of If-Modified-Since and If-None-Match,
-            or one or both of If-Unmodified-Since and If-Match) modifies what is returned if the GET is otherwise successful and the condition
-            is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response returned if the conditional is false.
+         <li>The presence of a Range header field in a conditional GET (a request using one or both of <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> and <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a>, or one or both of <a href="p4-conditional.html#header.if-unmodified-since" class="smpl">If-Unmodified-Since</a> and <a href="p4-conditional.html#header.if-match" class="smpl">If-Match</a>) modifies what is returned if the GET is otherwise successful and the condition is true. It does not affect the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response returned if the conditional is false.
          </li>
       </ul>

draft-ietf-httpbis/latest/p5-range.xml

@@ -338 +338 @@
     </t>
     <t>
-        Cache-Control, ETag, <x:ref>Expires</x:ref>, Content-Location and/or
-        Vary, if the header field would have been sent in a <x:ref>200 (OK)</x:ref>
-        response to the same request
+        <x:ref>Cache-Control</x:ref>, <x:ref>ETag</x:ref>,
+        <x:ref>Expires</x:ref>, Content-Location and/or
+        <x:ref>Vary</x:ref>, if the header field would have been sent in a
+        <x:ref>200 (OK)</x:ref> response to the same request
     </t>
   </list>
@@ -447 +448 @@
    where "strong validator" is defined to be either an entity-tag that is
    not marked as weak (&entity-tags;) or, if no entity-tag is provided, a
-   Last-Modified value that is strong in the sense defined by
+   <x:ref>Last-Modified</x:ref> value that is strong in the sense defined by
    &lastmod-comparison;.
 </t>
@@ -646 +647 @@
    to have an up-to-date copy of the entire representation, it could use the
    <x:ref>Range</x:ref> header field with a conditional GET (using
-   either or both of If-Unmodified-Since and If-Match.) However, if the
-   condition fails because the representation has been modified, the client
-   would then have to make a second request to obtain the entire current
-   representation.
+   either or both of <x:ref>If-Unmodified-Since</x:ref> and
+   <x:ref>If-Match</x:ref>.) However, if the condition fails because the
+   representation has been modified, the client would then have to make a
+   second request to obtain the entire current representation.
 </t>
 <t>
@@ -662 +663 @@
 <t>
    Clients &MUST-NOT; use an entity-tag marked as weak in an If-Range
-   field value and &MUST-NOT; use a Last-Modified date in an If-Range
-   field value unless it has no entity-tag for the representation and
+   field value and &MUST-NOT; use a <x:ref>Last-Modified</x:ref> date in an
+   If-Range field value unless it has no entity-tag for the representation and
    the Last-Modified date it does have for the representation is strong
    in the sense defined by &lastmod-comparison;.
@@ -843 +844 @@
 
      <t>The presence of a Range header field in a conditional GET (a request
-        using one or both of If-Modified-Since and If-None-Match, or
-        one or both of If-Unmodified-Since and If-Match) modifies what
-        is returned if the GET is otherwise successful and the
+        using one or both of <x:ref>If-Modified-Since</x:ref> and
+        <x:ref>If-None-Match</x:ref>, or one or both of
+        <x:ref>If-Unmodified-Since</x:ref> and <x:ref>If-Match</x:ref>) modifies
+        what is returned if the GET is otherwise successful and the
         condition is true. It does not affect the <x:ref>304 (Not Modified)</x:ref>
         response returned if the conditional is false.</t>
@@ -1053 +1055 @@
   <x:source href="p4-conditional.xml" basename="p4-conditional">
     <x:defines>304 (Not Modified)</x:defines>
+    <x:defines>ETag</x:defines>
+    <x:defines>If-Match</x:defines>
+    <x:defines>If-Modified-Since</x:defines>
+    <x:defines>If-None-Match</x:defines>
+    <x:defines>If-Unmodified-Since</x:defines>
+    <x:defines>Last-Modified</x:defines>
   </x:source>
 </reference>
@@ -1079 +1087 @@
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
   <x:source href="p6-cache.xml" basename="p6-cache">
+    <x:defines>Cache-Control</x:defines>
     <x:defines>Expires</x:defines>
+    <x:defines>Vary</x:defines>
   </x:source>
 </reference>

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

@@ -769 +769 @@
       </p>
       <ul class="empty">
-         <li>A protocol element (e.g., an entity-tag or a Last-Modified time) that is used to find out whether a stored response is an
-            equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
+         <li>A protocol element (e.g., an entity-tag or a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) that is used to find out whether a stored response is an equivalent copy of a representation. See <a href="p4-conditional.html#weak.and.strong.validators" title="Weak versus Strong">Section 2.1</a> of <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
          </li>
       </ul>
@@ -777 +776 @@
       <ul class="empty">
          <li>A validator that is defined by the origin server such that its current value will change if the representation body changes;
-            i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a Last-Modified value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
+            i.e., an entity-tag that is not marked as weak (<a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>) or, if no entity-tag is provided, a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value that is strong in the sense defined by <a href="p4-conditional.html#lastmod.comparison" title="Comparison">Section 2.2.2</a> of <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.
          </li>
       </ul>
@@ -932 +931 @@
       </p>
       <p id="rfc.section.2.3.p.4">Since origin servers do not always provide explicit expiration times, a cache <em class="bcp14">MAY</em> assign a heuristic expiration time when an explicit time is not specified, employing algorithms that use other header field
-         values (such as the Last-Modified time) to estimate a plausible expiration time. This specification does not provide specific
-         algorithms, but does impose worst-case constraints on their results.
+         values (such as the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> time) to estimate a plausible expiration time. This specification does not provide specific algorithms, but does impose worst-case
+         constraints on their results.
       </p>
       <div id="rfc.figure.u.4"></div> 
@@ -969 +968 @@
          present.
       </p>
-      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a Last-Modified header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
+      <p id="rfc.section.2.3.1.1.p.3">Also, if the response has a <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field (<a href="p4-conditional.html#header.last-modified" title="Last-Modified">Section 2.2</a> of <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that
          time. A typical setting of this fraction might be 10%.
       </p>
@@ -1074 +1073 @@
          update it. This process is known as "validating" or "revalidating" the stored response.
       </p>
-      <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache adds an If-Modified-Since header field whose value is that of the Last-Modified
-         header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) stored response, if available.
-      </p>
-      <p id="rfc.section.2.4.p.3">Additionally, a cache can add an If-None-Match header field whose value is that of the ETag header field(s) from all responses
-         stored for the requested URI, if present. However, if any of the stored responses contains only partial content, the cache
-         shouldn't include its entity-tag in the If-None-Match header field unless the request is for a range that would be fully satisfied
-         by that stored response.
+      <p id="rfc.section.2.4.p.2">When sending such a conditional request, a cache adds an <a href="p4-conditional.html#header.if-modified-since" class="smpl">If-Modified-Since</a> header field whose value is that of the <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> header field from the selected (see <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) stored response, if available.
+      </p>
+      <p id="rfc.section.2.4.p.3">Additionally, a cache can add an <a href="p4-conditional.html#header.if-none-match" class="smpl">If-None-Match</a> header field whose value is that of the <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field(s) from all responses stored for the requested URI, if present. However, if any of the stored responses contains
+         only partial content, the cache shouldn't include its entity-tag in the If-None-Match header field unless the request is for
+         a range that would be fully satisfied by that stored response.
       </p>
       <p id="rfc.section.2.4.p.4">Cache handling of a response to a conditional request is dependent upon its status code:</p>
@@ -1124 +1121 @@
          a body. This property of HEAD responses is used to both invalidate and update cached GET responses.
       </p>
-      <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the Content-Length, ETag or Last-Modified value of a HEAD response differs from that in a selected
-         GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
-      </p>
-      <p id="rfc.section.2.5.p.3">If the Content-Length, ETag and Last-Modified values of a HEAD response (when present) are the same as that in a selected
-         GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 
+      <p id="rfc.section.2.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>) for a HEAD request, and the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> or <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> value of a HEAD response differs from that in a selected GET response, the cache <em class="bcp14">MUST</em> consider that selected response to be stale.
+      </p>
+      <p id="rfc.section.2.5.p.3">If the Content-Length, <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and <a href="p4-conditional.html#header.last-modified" class="smpl">Last-Modified</a> values of a HEAD response (when present) are the same as that in a selected GET response (as per <a href="#caching.negotiated.responses" title="Caching Negotiated Responses">Section&nbsp;2.8</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 
       </p>
       <ul>

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

@@ -284 +284 @@
    <x:dfn>validator</x:dfn>
    <list>
-      <t>A protocol element (e.g., an entity-tag or a Last-Modified time) that
-      is used to find out whether a stored response is an equivalent copy of
-      a representation. See &weak-and-strong;.</t>
+      <t>A protocol element (e.g., an entity-tag or a <x:ref>Last-Modified</x:ref>
+      time) that is used to find out whether a stored response is an equivalent
+      copy of a representation. See &weak-and-strong;.</t>
    </list>
 </t>
@@ -297 +297 @@
          current value will change if the representation body changes; i.e.,
          an entity-tag that is not marked as weak (&entity-tags;) or,
-         if no entity-tag is provided, a Last-Modified value that is strong
-         in the sense defined by &lastmod-comparison;.</t>
+         if no entity-tag is provided, a <x:ref>Last-Modified</x:ref> value
+         that is strong in the sense defined by &lastmod-comparison;.</t>
    </list>
 </t>
@@ -619 +619 @@
    a cache &MAY; assign a heuristic expiration time when an explicit time is not
    specified, employing algorithms that use other header field values (such as the
-   Last-Modified time) to estimate a plausible expiration time. This
-   specification does not provide specific algorithms, but does impose
+   <x:ref>Last-Modified</x:ref> time) to estimate a plausible expiration time.
+   This specification does not provide specific algorithms, but does impose
    worst-case constraints on their results.
 </t>
@@ -697 +697 @@
 </t>
 <t>
-   Also, if the response has a Last-Modified header field
+   Also, if the response has a <x:ref>Last-Modified</x:ref> header field
    (&header-last-modified;), caches are encouraged to use a heuristic
    expiration value that is no more than some fraction of the interval since
@@ -896 +896 @@
 </t>
 <t>
-   When sending such a conditional request, a cache adds an If-Modified-Since
-   header field whose value is that of the Last-Modified header field from the
-   selected (see <xref target="caching.negotiated.responses"/>) stored
-   response, if available.
-</t>
-<t>
-   Additionally, a cache can add an If-None-Match header field whose value is
-   that of the ETag header field(s) from all responses stored for the
-   requested URI, if present. However, if any of the stored responses contains
-   only partial content, the cache shouldn't include its entity-tag in the
-   If-None-Match header field unless the request is for a range that would be
-   fully satisfied by that stored response.
+   When sending such a conditional request, a cache adds an
+   <x:ref>If-Modified-Since</x:ref> header field whose value is that of the
+   <x:ref>Last-Modified</x:ref> header field from the selected
+   (see <xref target="caching.negotiated.responses"/>) stored response, if
+   available.
+</t>
+<t>
+   Additionally, a cache can add an <x:ref>If-None-Match</x:ref> header field
+   whose value is that of the <x:ref>ETag</x:ref> header field(s) from all
+   responses stored for the requested URI, if present. However, if any of the
+   stored responses contains only partial content, the cache shouldn't
+   include its entity-tag in the If-None-Match header field unless the request
+   is for a range that would be fully satisfied by that stored response.
 </t>
 
@@ -989 +990 @@
    If one or more stored GET responses can be selected (as per <xref
    target="caching.negotiated.responses"/>) for a HEAD request, and the
-   Content-Length, ETag or Last-Modified value of a HEAD response differs from
-   that in a selected GET response, the cache &MUST; consider that selected
-   response to be stale.
-</t>
-<t>
-   If the Content-Length, ETag and Last-Modified values of a HEAD response
-   (when present) are the same as that in a selected GET response (as per
-   <xref target="caching.negotiated.responses"/>), the cache &SHOULD; update the
-   remaining headers in the stored response using the following rules:
+   Content-Length, <x:ref>ETag</x:ref> or <x:ref>Last-Modified</x:ref> value of
+   a HEAD response differs from that in a selected GET response, the cache
+   &MUST; consider that selected response to be stale.
+</t>
+<t>
+   If the Content-Length, <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>
+   values of a HEAD response (when present) are the same as that in a selected
+   GET response (as per <xref target="caching.negotiated.responses"/>), the
+   cache &SHOULD; update the remaining headers in the stored response using the
+   following rules:
    <list style="symbols">
       <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
@@ -2331 +2333 @@
       <x:defines>304</x:defines>
       <x:defines>304 (Not Modified)</x:defines>
+      <x:defines>ETag</x:defines>
+      <x:defines>If-Modified-Since</x:defines>
+      <x:defines>If-None-Match</x:defines>
+      <x:defines>Last-Modified</x:defines>
     </x:source>
   </reference>