Changeset 1737 for draft-ietf-httpbis

Timestamp:

08/07/12 13:02:45 (10 years ago)

Author:

julian.reschke@…

Message:

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

Location:

draft-ietf-httpbis/latest

Files:

• p1-messaging.html (modified) (8 diffs)
• p1-messaging.xml (modified) (3 diffs)
• p2-semantics.html (modified) (6 diffs)
• p2-semantics.xml (modified) (3 diffs)
• p4-conditional.html (modified) (6 diffs)
• p4-conditional.xml (modified) (2 diffs)
• p5-range.html (modified) (6 diffs)
• p5-range.xml (modified) (2 diffs)
• p6-cache.html (modified) (23 diffs)
• p6-cache.xml (modified) (25 diffs)

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 7, 2013"; 
+       content: "Expires January 9, 2013"; 
   } 
   @bottom-right {
@@ -491 +491 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2145">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
@@ -523 +523 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 7, 2013</td>
+               <td class="left">Expires: January 9, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 6, 2012</td>
+               <td class="right">July 8, 2012</td>
             </tr>
          </tbody>
@@ -561 +561 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 7, 2013.</p>
+      <p>This Internet-Draft will expire on January 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1947 +1947 @@
       </p>
       <ul>
-         <li>Expires</li>
-      </ul>
-      <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an Expires header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
+         <li><a href="p6-cache.html#header.expires" class="smpl">Expires</a> (<a href="p6-cache.html#header.expires" title="Expires">Section 3.3</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>)
+         </li>
+      </ul>
+      <p id="rfc.section.5.6.2.p.4">but it <em class="bcp14">MAY</em> add any of these fields if not already present. If an <a href="p6-cache.html#header.expires" class="smpl">Expires</a> header field is added, it <em class="bcp14">MUST</em> be given a field-value identical to that of the Date header field in that response.
       </p>
       <p id="rfc.section.5.6.2.p.5">A proxy <em class="bcp14">MUST NOT</em> modify or add any of the following fields in a message that contains the no-transform cache-control directive, or in any request: 
@@ -1958 +1959 @@
          <li>Content-Type</li>
       </ul>
-      <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.6"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+      <p id="rfc.section.5.6.2.p.6">A transforming proxy <em class="bcp14">MAY</em> modify or add these fields to a message that does not include no-transform, but if it does so, it <em class="bcp14">MUST</em> add a Warning 214 (Transformation applied) if one does not already appear in the message (see <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
       <div class="note" id="rfc.section.5.6.2.p.7"> 
@@ -1994 +1995 @@
       </p>
       <p id="rfc.section.6.1.p.6">A sender <em class="bcp14">MUST NOT</em> include field-names in the Connection header field-value for fields that are defined as expressing constraints for all recipients
-         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+         in the request or response chain, such as the Cache-Control header field (<a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
       </p>
       <p id="rfc.section.6.1.p.7">The connection options do not have to correspond to a header field present in the message, since a connection-specific header
@@ -3756 +3757 @@
                      </ul>
                   </li>
-                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
+                  <li><em>Part6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.2">2.4</a>, <a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.4">3.4</a>, <a href="#rfc.xref.Part6.5">5.2</a>, <a href="#rfc.xref.Part6.6">5.6.2</a>, <a href="#rfc.xref.Part6.7">5.6.2</a>, <a href="#rfc.xref.Part6.8">6.1</a>, <a href="#Part6"><b>10.1</b></a><ul>
                         <li><em>Section 2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.2">2.4</a></li>
                         <li><em>Section 2.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.4">3.4</a></li>
-                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.7">6.1</a></li>
-                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.6">5.6.2</a></li>
+                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.3">2.7.2</a>, <a href="#rfc.xref.Part6.8">6.1</a></li>
+                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.6">5.6.2</a></li>
+                        <li><em>Section 3.6</em>&nbsp;&nbsp;<a href="#rfc.xref.Part6.1">2.3</a>, <a href="#rfc.xref.Part6.7">5.6.2</a></li>
                      </ul>
                   </li>

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

@@ -29 +29 @@
   <!ENTITY header-date            "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-expect          "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
+  <!ENTITY header-expires         "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-mime-version    "<xref target='Part2' x:rel='#mime-version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
   <!ENTITY header-pragma          "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
@@ -2614 +2615 @@
    response:
   <list style="symbols">
-    <t>Expires</t>
+    <t><x:ref>Expires</x:ref> (&header-expires;)</t>
   </list>
 </t>
 <t>
    but it &MAY; add any of these fields if not already present. If an
-   Expires header field is added, it &MUST; be given a field-value identical to
-   that of the Date header field in that response.
+   <x:ref>Expires</x:ref> header field is added, it &MUST; be given a
+   field-value identical to that of the Date header field in that response.
 </t>
 <t>
@@ -4181 +4182 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
-  <x:source href="p6-cache.xml" basename="p6-cache"/>
+  <x:source href="p6-cache.xml" basename="p6-cache">
+    <x:defines>Expires</x:defines>
+  </x:source>
 </reference>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 7, 2013"; 
+       content: "Expires January 9, 2013"; 
   } 
   @bottom-right {
@@ -497 +497 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
@@ -528 +528 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 7, 2013</td>
+               <td class="left">Expires: January 9, 2013</td>
                <td class="right">greenbytes</td>
             </tr>
             <tr>
                <td class="left"></td>
-               <td class="right">July 6, 2012</td>
+               <td class="right">July 8, 2012</td>
             </tr>
          </tbody>
@@ -563 +563 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 7, 2013.</p>
+      <p>This Internet-Draft will expire on January 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -2553 +2553 @@
          </p> 
       </div>
-      <p id="rfc.section.8.1.p.8">The Vary header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
+      <p id="rfc.section.8.1.p.8">The <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header field (<a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> of <a href="#Part6" id="rfc.xref.Part6.19"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) can be used to express the parameters the server uses to select a representation that is subject to server-driven negotiation.
       </p>
       <h2 id="rfc.section.8.2"><a href="#rfc.section.8.2">8.2</a>&nbsp;<a id="agent-driven.negotiation" href="#agent-driven.negotiation">Agent-driven Negotiation</a></h2>
@@ -3673 +3673 @@
       <p id="rfc.section.11.5.p.2">An approach that limits the loss of privacy would be for a user agent to omit the sending of Accept-Language header fields
          by default, and to ask the user whether or not to start sending Accept-Language header fields to a server if it detects, by
-         looking for any Vary header fields generated by the server, that such sending could improve the quality of service.
+         looking for any <a href="p6-cache.html#header.vary" class="smpl">Vary</a> header fields generated by the server, that such sending could improve the quality of service.
       </p>
       <p id="rfc.section.11.5.p.3">Elaborate user-customized accept header fields sent in every request, in particular if these include quality values, can be

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

@@ -2944 +2944 @@
 </x:note>
 <t>
-   The Vary header field (&header-vary;) can be used to express the parameters the
-   server uses to select a representation that is subject to server-driven
-   negotiation.
+   The <x:ref>Vary</x:ref> header field (&header-vary;) can be used to express
+   the parameters the server uses to select a representation that is subject to
+   server-driven negotiation.
 </t>
 </section>
@@ -4572 +4572 @@
    to omit the sending of Accept-Language header fields by default, and to ask
    the user whether or not to start sending Accept-Language header fields to a
-   server if it detects, by looking for any Vary header fields
+   server if it detects, by looking for any <x:ref>Vary</x:ref> header fields
    generated by the server, that such sending could improve the quality
    of service.
@@ -4697 +4697 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
-  <x:source href="p6-cache.xml" basename="p6-cache"/>
+  <x:source href="p6-cache.xml" basename="p6-cache">
+    <x:defines>Vary</x:defines>
+  </x:source>
 </reference>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 7, 2013"; 
+       content: "Expires January 9, 2013"; 
   } 
   @bottom-right {
@@ -490 +490 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 4 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests.">
@@ -516 +516 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 7, 2013</td>
+               <td class="left">Expires: January 9, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -525 +525 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 6, 2012</td>
+               <td class="right">July 8, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 7, 2013.</p>
+      <p>This Internet-Draft will expire on January 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -1107 +1107 @@
          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 200
-         response to the same request would have included any of the header fields Cache-Control, Content-Location, ETag, Expires,
-         or Vary, 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 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>
       <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,

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

@@ -1012 +1012 @@
    A 304 response &MUST; include a Date header field (&header-date;)
    unless the origin server does not have a clock that can provide a
-   reasonable approximation of the current time.  If a 200 response
-   to the same request would have included any of the header fields
-   Cache-Control, Content-Location, ETag, Expires, or Vary, then
-   those same header fields &MUST; be sent in a 304 response.
+   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.
 </t>
 <t>
@@ -1248 +1249 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
-  <x:source href="p6-cache.xml" basename="p6-cache"/>
+  <x:source href="p6-cache.xml" basename="p6-cache">
+    <x:defines>Expires</x:defines>
+    <x:defines>Vary</x:defines>
+  </x:source>
 </reference>
 

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires January 7, 2013"; 
+       content: "Expires January 9, 2013"; 
   } 
   @bottom-right {
@@ -492 +492 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-06">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-08">
       <meta name="dct.replaces" content="urn:ietf:rfc:2616">
       <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 5 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range requests and the rules for constructing and combining responses to those requests.">
@@ -518 +518 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 7, 2013</td>
+               <td class="left">Expires: January 9, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -527 +527 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 6, 2012</td>
+               <td class="right">July 8, 2012</td>
             </tr>
          </tbody>
@@ -555 +555 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 7, 2013.</p>
+      <p>This Internet-Draft will expire on January 9, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -742 +742 @@
          </li>
          <li>Date</li>
-         <li>Cache-Control, ETag, Expires, 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>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>
       </ul>

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

@@ -335 +335 @@
     </t>
     <t>
-        Cache-Control, ETag, Expires, 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
+        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
     </t>
   </list>
@@ -1072 +1072 @@
   </front>
   <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p6-cache-&ID-VERSION;"/>
-  <x:source href="p6-cache.xml" basename="p6-cache"/>
+  <x:source href="p6-cache.xml" basename="p6-cache">
+    <x:defines>Expires</x:defines>
+  </x:source>
 </reference>
 

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

@@ -856 +856 @@
          <li>the response either: 
             <ul>
-               <li>contains an Expires header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
+               <li>contains an <a href="#header.expires" class="smpl">Expires</a> header field (see <a href="#header.expires" id="rfc.xref.header.expires.1" title="Expires">Section&nbsp;3.3</a>), or
                </li>
                <li>contains a max-age response cache directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), or
@@ -908 +908 @@
       <p id="rfc.section.2.2.p.2">Note that any of the requirements listed above can be overridden by a cache-control extension; see <a href="#cache.control.extensions" title="Cache Control Extensions">Section&nbsp;3.2.3</a>.
       </p>
-      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single Age header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
+      <p id="rfc.section.2.2.p.3">When a stored response is used to satisfy a request without validation, a cache <em class="bcp14">MUST</em> include a single <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.1" title="Age">Section&nbsp;3.1</a>) in the response with a value equal to the stored response's current_age; see <a href="#age.calculations" title="Calculating Age">Section&nbsp;2.3.2</a>.
       </p>
       <p id="rfc.section.2.2.p.4">A cache <em class="bcp14">MUST</em> write through requests with methods that are unsafe (<a href="p2-semantics.html#safe.methods" title="Safe Methods">Section 2.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a>) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request
@@ -925 +925 @@
       </p>
       <p id="rfc.section.2.3.p.2">The primary mechanism for determining freshness is for an origin server to provide an explicit expiration time in the future,
-         using either the Expires header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
+         using either the <a href="#header.expires" class="smpl">Expires</a> header field (<a href="#header.expires" id="rfc.xref.header.expires.2" title="Expires">Section&nbsp;3.3</a>) or the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>). Generally, origin servers will assign future explicit expiration times to responses in the belief that the representation
          is not likely to change in a semantically significant way before the expiration time is reached.
       </p>
@@ -953 +953 @@
          <li>If the max-age response cache directive (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) is present, use its value, or
          </li>
-         <li>If the Expires response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header field, or
+         <li>If the <a href="#header.expires" class="smpl">Expires</a> response header field (<a href="#header.expires" id="rfc.xref.header.expires.3" title="Expires">Section&nbsp;3.3</a>) is present, use its value minus the value of the Date response header field, or
          </li>
          <li>Otherwise, no explicit expiration time is present in the response. A heuristic freshness lifetime might be applicable; see <a href="#heuristic.freshness" title="Calculating Heuristic Freshness">Section&nbsp;2.3.1.1</a>.
@@ -959 +959 @@
       </ul>
       <p id="rfc.section.2.3.1.p.2">Note that this calculation is not vulnerable to clock skew, since all of the information comes from the origin server.</p>
-      <p id="rfc.section.2.3.1.p.3">When there is more than one value present for a given directive (e.g., two Expires header fields, multiple Cache-Control:
-         max-age directives), it is considered invalid. Caches are encouraged to consider responses that have invalid freshness information
-         to be stale.
+      <p id="rfc.section.2.3.1.p.3">When there is more than one value present for a given directive (e.g., two <a href="#header.expires" class="smpl">Expires</a> header fields, multiple Cache-Control: max-age directives), it is considered invalid. Caches are encouraged to consider responses
+         that have invalid freshness information to be stale.
       </p>
       <h4 id="rfc.section.2.3.1.1"><a href="#rfc.section.2.3.1.1">2.3.1.1</a>&nbsp;<a id="heuristic.freshness" href="#heuristic.freshness">Calculating Heuristic Freshness</a></h4>
@@ -968 +967 @@
             (Non-Authoritative Information)</a>, <a href="p5-range.html#status.206" class="smpl">206 (Partial Content)</a>, <a href="p2-semantics.html#status.300" class="smpl">300 (Multiple Choices)</a>, <a href="p2-semantics.html#status.301" class="smpl">301 (Moved Permanently)</a> and <a href="p2-semantics.html#status.410" class="smpl">410 (Gone)</a>), a cache <em class="bcp14">MAY</em> calculate a heuristic expiration time. A cache <em class="bcp14">MUST NOT</em> use heuristics to determine freshness for responses with status codes that do not explicitly allow it.
       </p>
-      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a Warning header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning
-         is not already present.
+      <p id="rfc.section.2.3.1.1.p.2">When a heuristic is used to calculate freshness lifetime, a cache <em class="bcp14">SHOULD</em> attach a <a href="#header.warning" class="smpl">Warning</a> header field with a 113 warn-code to the response if its current_age is more than 24 hours and such a warning is not already
+         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
@@ -981 +980 @@
       </div>
       <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
-      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the Age header field to convey the estimated age of the response message when obtained from a cache. The Age
-         field value is the cache's estimate of the amount of time since the response was generated or validated by the origin server.
-         In essence, the Age value is the sum of the time that the response has been resident in each of the caches along the path
-         from the origin server, plus the amount of time it has been in transit along network paths.
+      <p id="rfc.section.2.3.2.p.1">HTTP/1.1 uses the <a href="#header.age" class="smpl">Age</a> header field to convey the estimated age of the response message when obtained from a cache. The Age field value is the cache's
+         estimate of the amount of time since the response was generated or validated by the origin server. In essence, the Age value
+         is the sum of the time that the response has been resident in each of the caches along the path from the origin server, plus
+         the amount of time it has been in transit along network paths.
       </p>
       <p id="rfc.section.2.3.2.p.2">The following data is used for the age calculation:</p>
@@ -990 +989 @@
       </p>
       <ul class="empty">
-         <li>The term "age_value" denotes the value of the Age header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
+         <li>The term "age_value" denotes the value of the <a href="#header.age" class="smpl">Age</a> header field (<a href="#header.age" id="rfc.xref.header.age.2" title="Age">Section&nbsp;3.1</a>), in a form appropriate for arithmetic operation; or 0, if not available.
          </li>
       </ul>
@@ -1032 +1031 @@
       <p>These <em class="bcp14">SHOULD</em> be combined as
       </p>  <pre class="text">  corrected_initial_age = max(apparent_age, corrected_age_value);
-</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the Age header (e.g., because there are no HTTP/1.0 hops in the Via header),
-         in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
+</pre><p id="rfc.section.2.3.2.p.11">unless the cache is confident in the value of the <a href="#header.age" class="smpl">Age</a> header field (e.g., because there are no HTTP/1.0 hops in the Via header field), in which case the corrected_age_value <em class="bcp14">MAY</em> be used as the corrected_initial_age.
       </p>
       <p id="rfc.section.2.3.2.p.12">The current_age of a stored response can then be calculated by adding the amount of time (in seconds) since the stored response
@@ -1048 +1046 @@
          <li>Although all date formats are specified to be case-sensitive, recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
          </li>
-         <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed Expires date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
+         <li>An HTTP/1.1 implementation <em class="bcp14">MAY</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as earlier than the proper value, but <em class="bcp14">MUST NOT</em> internally represent a parsed Expires date as later than the proper value.
          </li>
          <li>All expiration-related calculations <em class="bcp14">MUST</em> be done in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
@@ -1066 +1064 @@
          or doing so is explicitly allowed (e.g., by the max-stale request directive; see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
       </p>
-      <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a Warning header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
+      <p id="rfc.section.2.3.3.p.4">A cache <em class="bcp14">SHOULD</em> append a <a href="#header.warning" class="smpl">Warning</a> header field with the 110 warn-code (see <a href="#header.warning" id="rfc.xref.header.warning.1" title="Warning">Section&nbsp;3.6</a>) to stale responses. Likewise, a cache <em class="bcp14">SHOULD</em> add the 112 warn-code to stale responses if the cache is disconnected.
       </p>
       <p id="rfc.section.2.3.3.p.5">If a cache receives a first-hand response (either an entire response, or a <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response) that it would normally forward to the requesting client, and the received response is no longer fresh, the cache
-         can forward it to the requesting client without adding a new Warning (but without removing any existing Warning header fields).
-         A cache shouldn't attempt to validate a response simply because that response became stale in transit.
+         can forward it to the requesting client without adding a new <a href="#header.warning" class="smpl">Warning</a> (but without removing any existing Warning header fields). A cache shouldn't attempt to validate a response simply because
+         that response became stale in transit.
       </p>
       <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a>&nbsp;<a id="validation.model" href="#validation.model">Validation Model</a></h2>
@@ -1116 +1114 @@
       </p>
       <ul>
-         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>);
-         </li>
-         <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
+         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.2" title="Warning">Section&nbsp;3.6</a>);
+         </li>
+         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
+         </li>
          <li>use other header fields provided in the <a href="p4-conditional.html#status.304" class="smpl">304 (Not Modified)</a> response to replace all instances of the corresponding header fields in the stored response.
          </li>
@@ -1133 +1132 @@
       </p>
       <ul>
-         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>);
-         </li>
-         <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
+         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.3" title="Warning">Section&nbsp;3.6</a>);
+         </li>
+         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
+         </li>
          <li>use other header fields provided in the response to replace all instances of the corresponding header fields in the stored
             response.
@@ -1162 +1162 @@
       <p id="rfc.section.2.7.p.1">A shared cache <em class="bcp14">MUST NOT</em> use a cached response to a request with an <a href="p7-auth.html#header.authorization" class="smpl">Authorization</a> header field (<a href="p7-auth.html#header.authorization" title="Authorization">Section 4.1</a> of <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>) to satisfy any subsequent request unless a cache directive that allows such responses to be stored is present in the response.
       </p>
-      <p id="rfc.section.2.7.p.2">In this specification, the following Cache-Control response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
+      <p id="rfc.section.2.7.p.2">In this specification, the following <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives (<a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>) have such an effect: must-revalidate, public, s-maxage.
       </p>
       <p id="rfc.section.2.7.p.3">Note that cached responses that contain the "must-revalidate" and/or "s-maxage" response directives are not allowed to be
@@ -1169 +1169 @@
       </p>
       <h2 id="rfc.section.2.8"><a href="#rfc.section.2.8">2.8</a>&nbsp;<a id="caching.negotiated.responses" href="#caching.negotiated.responses">Caching Negotiated Responses</a></h2>
-      <p id="rfc.section.2.8.p.1">When a cache receives a request that can be satisfied by a stored response that has a Vary header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
+      <p id="rfc.section.2.8.p.1">When a cache receives a request that can be satisfied by a stored response that has a <a href="#header.vary" class="smpl">Vary</a> header field (<a href="#header.vary" id="rfc.xref.header.vary.1" title="Vary">Section&nbsp;3.5</a>), it <em class="bcp14">MUST NOT</em> use that response unless all of the selecting header fields nominated by the Vary header field match in both the original
          request (i.e., that associated with the stored response), and the presented request.
       </p>
@@ -1186 +1186 @@
          if it is also absent there.
       </p>
-      <p id="rfc.section.2.8.p.4">A Vary header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
+      <p id="rfc.section.2.8.p.4">A <a href="#header.vary" class="smpl">Vary</a> header field-value of "*" always fails to match, and subsequent requests to that resource can only be properly interpreted
          by the origin server.
       </p>
@@ -1203 +1203 @@
       </p>
       <ul>
-         <li>delete any Warning header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>);
-         </li>
-         <li>retain any Warning header fields in the stored response with warn-code 2xx; and,</li>
+         <li>delete any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 1xx (see <a href="#header.warning" id="rfc.xref.header.warning.4" title="Warning">Section&nbsp;3.6</a>);
+         </li>
+         <li>retain any <a href="#header.warning" class="smpl">Warning</a> header fields in the stored response with warn-code 2xx; and,
+         </li>
          <li>use other header fields provided in the new response, aside from Content-Range, to replace all instances of the corresponding
             header fields in the stored response.
@@ -1420 +1421 @@
       </ul>
       <p id="rfc.section.3.2.2.8.p.2">The s-maxage response directive indicates that, in shared caches, the maximum age specified by this directive overrides the
-         maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the
-         semantics of the proxy-revalidate response directive.
+         maximum age specified by either the max-age directive or the <a href="#header.expires" class="smpl">Expires</a> header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.
       </p>
       <p id="rfc.section.3.2.2.8.p.3"> <b>Note:</b> This directive uses the token form of the argument syntax; e.g., 's-maxage=10', not 's-maxage="10"'. Senders <em class="bcp14">SHOULD NOT</em> use the quoted-string form.
@@ -1489 +1489 @@
       </p>
       <div class="note" id="rfc.section.3.3.p.7"> 
-         <p> <b>Note:</b> If a response includes a Cache-Control field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
+         <p> <b>Note:</b> If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (see <a href="#cache-response-directive" title="Response Cache-Control Directives">Section&nbsp;3.2.2</a>), that directive overrides the Expires field. Likewise, the s-maxage directive overrides Expires in shared caches.
          </p> 
       </div>
@@ -1505 +1505 @@
       <h2 id="rfc.section.3.4"><a href="#rfc.section.3.4">3.4</a>&nbsp;<a id="header.pragma" href="#header.pragma">Pragma</a></h2>
       <p id="rfc.section.3.4.p.1">The "Pragma" header field allows backwards compatibility with HTTP/1.0 caches, so that clients can specify a "no-cache" request
-         that they will understand (as Cache-Control was not defined until HTTP/1.1). When the Cache-Control header is also present
-         and understood in a request, Pragma is ignored.
+         that they will understand (as <a href="#header.cache-control" class="smpl">Cache-Control</a> was not defined until HTTP/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is
+         ignored.
       </p>
       <p id="rfc.section.3.4.p.2">In HTTP/1.0, Pragma was defined as an extensible field for implementation-specified directives for recipients. This specification
@@ -1514 +1514 @@
   <a href="#header.pragma" class="smpl">pragma-directive</a> = "no-cache" / <a href="#header.pragma" class="smpl">extension-pragma</a>
   <a href="#header.pragma" class="smpl">extension-pragma</a> = <a href="#core.rules" class="smpl">token</a> [ "=" ( <a href="#core.rules" class="smpl">token</a> / <a href="#core.rules" class="smpl">quoted-string</a> ) ]
-</pre><p id="rfc.section.3.4.p.4">When the Cache-Control header is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
+</pre><p id="rfc.section.3.4.p.4">When the <a href="#header.cache-control" class="smpl">Cache-Control</a> header field is not present in a request, the no-cache request pragma-directive <em class="bcp14">MUST</em> have the same effect on caches as if "Cache-Control: no-cache" were present (see <a href="#cache-request-directive" title="Request Cache-Control Directives">Section&nbsp;3.2.1</a>).
       </p>
       <p id="rfc.section.3.4.p.5">When sending a no-cache request, a client ought to include both the pragma and cache-control directives, unless Cache-Control:
-         no-cache is purposefully omitted to target other Cache-Control response directives at HTTP/1.1 caches. For example:
+         no-cache is purposefully omitted to target other <a href="#header.cache-control" class="smpl">Cache-Control</a> response directives at HTTP/1.1 caches. For example:
       </p>
       <div id="rfc.figure.u.14"></div> <pre class="text">GET / HTTP/1.1
@@ -1525 +1525 @@
 
 </pre> <p id="rfc.section.3.4.p.7">will constrain HTTP/1.1 caches to serve a response no older than 30 seconds, while precluding implementations that do not
-         understand Cache-Control from serving a cached response.
+         understand <a href="#header.cache-control" class="smpl">Cache-Control</a> from serving a cached response.
       </p>
       <div class="note" id="rfc.section.3.4.p.8"> 
@@ -1984 +1984 @@
       <p id="rfc.section.A.p.4">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;3</a>)
       </p>
-      <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in Warning header fields anymore, as these aspects never were implemented.
-         (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;3.6</a>)
+      <p id="rfc.section.A.p.5">Do not mention RFC 2047 encoding and multiple languages in <a href="#header.warning" class="smpl">Warning</a> header fields anymore, as these aspects never were implemented. (<a href="#header.warning" id="rfc.xref.header.warning.6" title="Warning">Section&nbsp;3.6</a>)
       </p>
       <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;<a id="collected.abnf" href="#collected.abnf">Collected ABNF</a></h1>

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

@@ -471 +471 @@
       <t>the response either:
          <list style="symbols">
-            <t>contains an Expires header field (see <xref target="header.expires"
-            />), or</t>
+            <t>contains an <x:ref>Expires</x:ref> header field (see
+            <xref target="header.expires"/>), or</t>
             <t>contains a max-age response cache directive (see <xref
             target="cache-response-directive" />), or</t>
@@ -564 +564 @@
 <t>
    When a stored response is used to satisfy a request without validation,
-   a cache &MUST; include a single Age header field (<xref target="header.age"
-   />) in the response with a value equal to the stored response's
-   current_age; see <xref target="age.calculations" />.
+   a cache &MUST; include a single <x:ref>Age</x:ref> header field
+   (<xref target="header.age"/>) in the response with a value equal to the
+   stored response's current_age; see <xref target="age.calculations" />.
 </t>
 <t>
@@ -601 +601 @@
 <t>
    The primary mechanism for determining freshness is for an origin server to
-   provide an explicit expiration time in the future, using either the Expires
+   provide an explicit expiration time in the future, using either the <x:ref>Expires</x:ref>
    header field (<xref target="header.expires" />) or the max-age response cache
    directive (<xref target="cache-response-directive" />). Generally, origin
@@ -660 +660 @@
       <t>If the max-age response cache directive (<xref
       target="cache-response-directive" />) is present, use its value, or</t>
-      <t>If the Expires response header field (<xref target="header.expires" />) is
-      present, use its value minus the value of the Date response header field,
-      or</t>
+      <t>If the <x:ref>Expires</x:ref> response header field
+      (<xref target="header.expires" />) is present, use its value minus the
+      value of the Date response header field, or</t>
       <t>Otherwise, no explicit expiration time is present in the response. A
       heuristic freshness lifetime might be applicable; see <xref
@@ -674 +674 @@
 <t>
    When there is more than one value present for a given directive (e.g., two
-   Expires header fields, multiple Cache-Control: max-age directives), it is
-   considered invalid. Caches are encouraged to consider responses that have
-   invalid freshness information to be stale.
+   <x:ref>Expires</x:ref> header fields, multiple Cache-Control: max-age
+   directives), it is considered invalid. Caches are encouraged to consider
+   responses that have invalid freshness information to be stale.
 </t>
 
@@ -691 +691 @@
 </t>
 <t>
-   When a heuristic is used to calculate freshness lifetime, a cache
-   &SHOULD; attach a Warning header field with a 113 warn-code to the response if
-   its current_age is more than 24 hours and such a warning is not already
-   present.
+   When a heuristic is used to calculate freshness lifetime, a cache &SHOULD;
+   attach a <x:ref>Warning</x:ref> header field with a 113 warn-code to the
+   response if its current_age is more than 24 hours and such a warning is not
+   already present.
 </t>
 <t>
@@ -717 +717 @@
 <section anchor="age.calculations" title="Calculating Age">
 <t>
-   HTTP/1.1 uses the Age header field to convey the estimated age of the
-   response message when obtained from a cache. The Age field value is the
-   cache's estimate of the amount of time since the response was generated or
+   HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
+   age of the response message when obtained from a cache. The Age field value
+   is the cache's estimate of the amount of time since the response was generated or
    validated by the origin server. In essence, the Age value is the sum of the
    time that the response has been resident in each of the caches along the
@@ -732 +732 @@
    <list>
       <t>
-         The term "age_value" denotes the value of the Age header field (<xref
-         target="header.age"/>), in a form appropriate for arithmetic
-         operation; or 0, if not available.
+         The term "age_value" denotes the value of the <x:ref>Age</x:ref>
+         header field (<xref target="header.age"/>), in a form appropriate for
+         arithmetic operation; or 0, if not available.
       </t>
    </list>
@@ -806 +806 @@
 </artwork></figure>
 <t>
-   unless the cache is confident in the value of the Age header (e.g., because
-   there are no HTTP/1.0 hops in the Via header), in which case the
-   corrected_age_value &MAY; be used as the corrected_initial_age.</t>
+   unless the cache is confident in the value of the <x:ref>Age</x:ref> header
+   field (e.g., because there are no HTTP/1.0 hops in the Via header field), in
+   which case the corrected_age_value &MAY; be used as the
+   corrected_initial_age.</t>
 <t>
    The current_age of a stored response can then be calculated by adding the
@@ -832 +833 @@
              
      <t>An HTTP/1.1 implementation &MAY; internally represent a parsed
-        Expires date as earlier than the proper value, but &MUST-NOT;
-        internally represent a parsed Expires date as later than the
+        <x:ref>Expires</x:ref> date as earlier than the proper value, but
+        &MUST-NOT; internally represent a parsed Expires date as later than the
         proper value.</t>
 
@@ -867 +868 @@
 </t>
 <t>
-   A cache &SHOULD; append a Warning header field with the 110 warn-code (see
-   <xref target="header.warning" />) to stale responses. Likewise, a cache
-   &SHOULD; add the 112 warn-code to stale responses if the cache is 
-   disconnected.
+   A cache &SHOULD; append a <x:ref>Warning</x:ref> header field with the 110
+   warn-code (see <xref target="header.warning"/>) to stale responses.
+   Likewise, a cache &SHOULD; add the 112 warn-code to stale responses if the
+   cache is disconnected.
 </t>
 <t>
@@ -876 +877 @@
    <x:ref>304 (Not Modified)</x:ref> response) that it would normally forward to the
    requesting client, and the received response is no longer fresh, the cache
-   can forward it to the requesting client without adding a new Warning (but
-   without removing any existing Warning header fields). A cache shouldn't
+   can forward it to the requesting client without adding a new <x:ref>Warning</x:ref>
+   (but without removing any existing Warning header fields). A cache shouldn't
    attempt to validate a response simply because that response became stale in
    transit.
@@ -965 +966 @@
    If a stored response is selected for update, the cache &MUST;:
    <list style="symbols">
-      <t>delete any Warning header fields in the stored response with
-         warn-code 1xx (see <xref target="header.warning" />);</t>
-      <t>retain any Warning header fields in the stored response with
-         warn-code 2xx; and,</t>
+      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
+         with warn-code 1xx (see <xref target="header.warning" />);</t>
+      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
+         with warn-code 2xx; and,</t>
       <t>use other header fields provided in the <x:ref>304 (Not Modified)</x:ref>
          response to replace all instances of the corresponding header
@@ -998 +999 @@
    remaining headers in the stored response using the following rules:
    <list style="symbols">
-      <t>delete any Warning header fields in the stored response with
-         warn-code 1xx (see <xref target="header.warning" />);</t>
-      <t>retain any Warning header fields in the stored response with
-         warn-code 2xx; and,</t>
+      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
+         with warn-code 1xx (see <xref target="header.warning" />);</t>
+      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
+         with warn-code 2xx; and,</t>
       <t>use other header fields provided in the response to replace
          all instances of the corresponding header fields in the stored
@@ -1059 +1060 @@
 
 <t>
-   In this specification, the following Cache-Control response directives
-   (<xref target="cache-response-directive"/>) have such an effect:
+   In this specification, the following <x:ref>Cache-Control</x:ref> response
+   directives (<xref target="cache-response-directive"/>) have such an effect:
    must-revalidate, public, s-maxage.
 </t>
@@ -1078 +1079 @@
 <t>
    When a cache receives a request that can be satisfied by a stored response
-   that has a Vary header field (<xref target="header.vary"/>), it &MUST-NOT;
-   use that response unless all of the selecting header fields nominated by
-   the Vary header field match in both the original request (i.e., that associated
-   with the stored response), and the presented request.
+   that has a <x:ref>Vary</x:ref> header field (<xref target="header.vary"/>),
+   it &MUST-NOT; use that response unless all of the selecting header fields
+   nominated by the Vary header field match in both the original request (i.e.,
+   that associated with the stored response), and the presented request.
 </t>
 <t>
@@ -1109 +1110 @@
 </t>
 <t>
-   A Vary header field-value of "*" always fails to match, and subsequent
-   requests to that resource can only be properly interpreted by the origin
-   server.
+   A <x:ref>Vary</x:ref> header field-value of "*" always fails to match, and
+   subsequent requests to that resource can only be properly interpreted by the
+   origin server.
 </t>
 <t>
@@ -1143 +1144 @@
    cache &MUST;:
    <list style="symbols">
-      <t>delete any Warning header fields in the stored response with
-         warn-code 1xx (see <xref target="header.warning" />);</t>
-      <t>retain any Warning header fields in the stored response with
-         warn-code 2xx; and,</t>
+      <t>delete any <x:ref>Warning</x:ref> header fields in the stored response
+         with warn-code 1xx (see <xref target="header.warning" />);</t>
+      <t>retain any <x:ref>Warning</x:ref> header fields in the stored response
+         with warn-code 2xx; and,</t>
       <t>use other header fields provided in the new response, aside
          from Content-Range, to replace all instances of the corresponding
@@ -1569 +1570 @@
    The s-maxage response directive indicates that, in shared caches, the
    maximum age specified by this directive overrides the maximum age
-   specified by either the max-age directive or the Expires header field. The
-   s-maxage directive also implies the semantics of the proxy-revalidate
-   response directive.
+   specified by either the max-age directive or the <x:ref>Expires</x:ref>
+   header field. The s-maxage directive also implies the semantics of the
+   proxy-revalidate response directive.
 </t>
 <t>
@@ -1705 +1706 @@
 <x:note>
    <t>
-       &Note; If a response includes a Cache-Control field with the
-       max-age directive (see <xref target="cache-response-directive" />),
+       &Note; If a response includes a <x:ref>Cache-Control</x:ref> field with
+       the max-age directive (see <xref target="cache-response-directive" />),
        that directive overrides the Expires field. Likewise, the s-maxage
        directive overrides Expires in shared caches.
@@ -1739 +1740 @@
    The "Pragma" header field allows backwards compatibility with HTTP/1.0
    caches, so that clients can specify a "no-cache" request that they will
-   understand (as Cache-Control was not defined until HTTP/1.1). When the
-   Cache-Control header is also present and understood in a request, Pragma is
-   ignored.
+   understand (as <x:ref>Cache-Control</x:ref> was not defined until HTTP/1.1).
+   When the Cache-Control header field is also present and understood in a
+   request, Pragma is ignored.
 </t>
 <t>
@@ -1754 +1755 @@
 </artwork></figure>
 <t>
-   When the Cache-Control header is not present in a request, the no-cache
-   request pragma-directive &MUST; have the same effect on caches as if
-   "Cache-Control: no-cache" were present (see <xref
+   When the <x:ref>Cache-Control</x:ref> header field is not present in a
+   request, the no-cache request pragma-directive &MUST; have the same effect
+   on caches as if "Cache-Control: no-cache" were present (see <xref
    target="cache-request-directive" />).
 </t>
@@ -1762 +1763 @@
    When sending a no-cache request, a client ought to include both the pragma
    and cache-control directives, unless Cache-Control: no-cache is
-   purposefully omitted to target other Cache-Control response directives at
-   HTTP/1.1 caches. For example:
+   purposefully omitted to target other <x:ref>Cache-Control</x:ref> response
+   directives at HTTP/1.1 caches. For example:
 </t>
 <figure>
@@ -1777 +1778 @@
    will constrain HTTP/1.1 caches to serve a response no older than 30
    seconds, while precluding implementations that do not understand
-   Cache-Control from serving a cached response.
+   <x:ref>Cache-Control</x:ref> from serving a cached response.
 </t>
 <x:note>
@@ -2536 +2537 @@
 </t>
 <t>
-  Do not mention RFC 2047 encoding and multiple languages in Warning header fields
-  anymore, as these aspects never were implemented. 
+  Do not mention RFC 2047 encoding and multiple languages in <x:ref>Warning</x:ref>
+  header fields anymore, as these aspects never were implemented. 
   (<xref target="header.warning" />)
 </t>