Changeset 1772

Timestamp:

14/07/12 14:09:09 (10 years ago)

Author:

julian.reschke@…

Message:

header -> header field (#234)

Location:

draft-ietf-httpbis/latest

Files:

• p0-introduction.html (modified) (6 diffs)
• p0-introduction.xml (modified) (1 diff)
• p1-messaging.html (modified) (13 diffs)
• p1-messaging.xml (modified) (14 diffs)
• p2-semantics.html (modified) (16 diffs)
• p2-semantics.xml (modified) (17 diffs)
• p4-conditional.html (modified) (1 diff)
• p4-conditional.xml (modified) (1 diff)
• p5-range.xml (modified) (3 diffs)
• p6-cache.html (modified) (3 diffs)
• p6-cache.xml (modified) (3 diffs)

draft-ietf-httpbis/latest/p0-introduction.html

@@ -393 +393 @@
   } 
   @bottom-center {
-       content: "Expires January 14, 2013"; 
+       content: "Expires January 15, 2013"; 
   } 
   @bottom-right {
@@ -426 +426 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p0-introduction-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2012-07-13">
+      <meta name="dct.issued" scheme="ISO8601" content="2012-07-14">
       <meta name="dct.abstract" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
       <meta name="description" content="This document is the first in a series that, collectively, define the HyperText Transfer Protocol, version 1.1; otherwise known as HTTP/1.1.">
@@ -446 +446 @@
             </tr>
             <tr>
-               <td class="left">Expires: January 14, 2013</td>
+               <td class="left">Expires: January 15, 2013</td>
                <td class="right">W3C</td>
             </tr>
@@ -467 +467 @@
             <tr>
                <td class="left"></td>
-               <td class="right">July 13, 2012</td>
+               <td class="right">July 14, 2012</td>
             </tr>
          </tbody>
@@ -490 +490 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on January 14, 2013.</p>
+      <p>This Internet-Draft will expire on January 15, 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>
@@ -529 +529 @@
             protocols. Also includes the HTTP and HTTPS URI schemes.
          </li>
-         <li><a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> HTTP/1.1 Core Semantics - Protocol elements such as methods, status codes, and payload-specific headers. Also includes content
-            negotiation mechanisms.
+         <li><a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics, Payload and Content Negotiation">[Part2]</cite></a> HTTP/1.1 Core Semantics - Protocol elements such as methods, status codes, and payload-specific header fields. Also includes
+            content negotiation mechanisms.
          </li>
          <li><a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a> HTTP/1.1 Conditional Requests - An extension to make requests contingent upon their current state.

draft-ietf-httpbis/latest/p0-introduction.xml

@@ -136 +136 @@
    schemes.</t>
    <t><xref target="Part2"/> HTTP/1.1 Core Semantics - Protocol elements such
-   as methods, status codes, and payload-specific headers. Also includes
+   as methods, status codes, and payload-specific header fields. Also includes
    content negotiation mechanisms.</t>
    <t><xref target="Part4"/> HTTP/1.1 Conditional Requests - An extension to

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

@@ -1301 +1301 @@
             (Client Error)</a> status code if the received header field(s) would be longer than the server wishes to handle.
       </p>
-      <p id="rfc.section.3.2.3.p.2">A client that receives response headers that are longer than it wishes to handle can only treat it as a server error.</p>
-      <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.
+      <p id="rfc.section.3.2.3.p.2">A client that receives response header fields that are longer than it wishes to handle can only treat it as a server error.</p>
+      <p id="rfc.section.3.2.3.p.3">Various ad-hoc limitations on header field length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support messages whose combined header fields have 4000 or more octets.
       </p>
       <h3 id="rfc.section.3.2.4"><a href="#rfc.section.3.2.4">3.2.4</a>&nbsp;<a id="field.components" href="#field.components">Field value components</a></h3>
@@ -1609 +1609 @@
          </li>
          <li>the trailer fields consist entirely of optional metadata, and the recipient could use the message (in a manner acceptable
-            to the server where the field originated) without receiving it. In other words, the server that generated the header (often
-            but not always the origin server) is willing to accept the possibility that the trailer fields might be silently discarded
+            to the server where the field originated) without receiving it. In other words, the server that generated the header field
+            (often but not always the origin server) is willing to accept the possibility that the trailer fields might be silently discarded
             along the path to the client.
          </li>
@@ -2976 +2976 @@
       <p id="rfc.section.A.1.2.p.2">Some clients and servers might wish to be compatible with these previous approaches to persistent connections, by explicitly
          negotiating for them with a "Connection: keep-alive" request header field. However, some experimental implementations of HTTP/1.0
-         persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header to the next inbound server, which would result in a hung connection.
-      </p>
-      <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header, targeted specifically at proxies. In practice, this
-         was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed above.
-      </p>
-      <p id="rfc.section.A.1.2.p.4">As a result, clients are encouraged not to send the Proxy-Connection header in any requests.</p>
+         persistent connections are faulty; for example, if a HTTP/1.0 proxy server doesn't understand <a href="#header.connection" class="smpl">Connection</a>, it will erroneously forward that header field to the next inbound server, which would result in a hung connection.
+      </p>
+      <p id="rfc.section.A.1.2.p.3">One attempted solution was the introduction of a Proxy-Connection header field, targeted specifically at proxies. In practice,
+         this was also unworkable, because proxies are often deployed in multiple layers, bringing about the same problem discussed
+         above.
+      </p>
+      <p id="rfc.section.A.1.2.p.4">As a result, clients are encouraged not to send the Proxy-Connection header field in any requests.</p>
       <p id="rfc.section.A.1.2.p.5">Clients are also encouraged to consider the use of Connection: keep-alive in requests carefully; while they can enable persistent
          connections with HTTP/1.0 servers, clients using them need will need to monitor the connection for "hung" requests (which
-         indicate that the client ought stop sending the header), and this mechanism ought not be used by clients at all when a proxy
-         is being used.
+         indicate that the client ought stop sending the header field), and this mechanism ought not be used by clients at all when
+         a proxy is being used.
       </p>
       <h3 id="rfc.section.A.1.3"><a href="#rfc.section.A.1.3">A.1.3</a>&nbsp;<a id="introduction.of.transfer-encoding" href="#introduction.of.transfer-encoding">Introduction of Transfer-Encoding</a></h3>
@@ -3258 +3259 @@
       </p>
       <ul>
-         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
+         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
       </ul>
       <p id="rfc.section.C.4.p.3">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;): 
@@ -3278 +3279 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/128">http://tools.ietf.org/wg/httpbis/trac/ticket/128</a>&gt;: "Cite HTTPS URI scheme definition"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/129">http://tools.ietf.org/wg/httpbis/trac/ticket/129</a>&gt;: "List-type headers vs Set-Cookie"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/129">http://tools.ietf.org/wg/httpbis/trac/ticket/129</a>&gt;: "List-type header fields vs Set-Cookie"
          </li>
       </ul>
@@ -3359 +3360 @@
       <p id="rfc.section.C.9.p.1">Closed issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/93">http://tools.ietf.org/wg/httpbis/trac/ticket/93</a>&gt;: "Repeating single-value headers"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/93">http://tools.ietf.org/wg/httpbis/trac/ticket/93</a>&gt;: "Repeating single-value header fields"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/131">http://tools.ietf.org/wg/httpbis/trac/ticket/131</a>&gt;: "increase connection limit"
@@ -3393 +3394 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/60">http://tools.ietf.org/wg/httpbis/trac/ticket/60</a>&gt;: "Placement of 13.5.1 and 13.5.2"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header field structure"
          </li>
       </ul>
@@ -3409 +3410 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/165">http://tools.ietf.org/wg/httpbis/trac/ticket/165</a>&gt;: "Case-sensitivity of HTTP-date"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header field structure"
          </li>
       </ul>
@@ -3424 +3425 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/90">http://tools.ietf.org/wg/httpbis/trac/ticket/90</a>&gt;: "Delimiting messages with multipart/byteranges"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length headers"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length header fields"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/109">http://tools.ietf.org/wg/httpbis/trac/ticket/109</a>&gt;: "Clarify entity / representation / variant terminology"
@@ -3450 +3451 @@
       <p id="rfc.section.C.13.p.2">Partly resolved issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length headers"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length header fields"
          </li>
       </ul>
@@ -3462 +3463 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/210">http://tools.ietf.org/wg/httpbis/trac/ticket/210</a>&gt;: "define 'transparent' proxy"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Classification"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Field Classification"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/233">http://tools.ietf.org/wg/httpbis/trac/ticket/233</a>&gt;: "Is * usable as a request-uri for new methods?"
@@ -3478 +3479 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/53">http://tools.ietf.org/wg/httpbis/trac/ticket/53</a>&gt;: "Allow is not in 13.5.2"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length headers"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/95">http://tools.ietf.org/wg/httpbis/trac/ticket/95</a>&gt;: "Handling multiple Content-Length header fields"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
@@ -3514 +3515 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>&gt;: "Document HTTP's error-handling philosophy"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>&gt;: "Explain header registration"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/215">http://tools.ietf.org/wg/httpbis/trac/ticket/215</a>&gt;: "Explain header field registration"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/219">http://tools.ietf.org/wg/httpbis/trac/ticket/219</a>&gt;: "Revise Acknowledgements Sections"

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

@@ -1352 +1352 @@
 </t>
 <t>
-   A client that receives response headers that are longer than it wishes to
-   handle can only treat it as a server error.
-</t>
-<t>
-   Various ad-hoc limitations on header length are found in practice. It is
-   &RECOMMENDED; that all HTTP senders and recipients support messages whose
+   A client that receives response header fields that are longer than it wishes
+   to handle can only treat it as a server error.
+</t>
+<t>
+   Various ad-hoc limitations on header field length are found in practice. It
+   is &RECOMMENDED; that all HTTP senders and recipients support messages whose
    combined header fields have 4000 or more octets.
 </t>
@@ -1996 +1996 @@
     recipient could use the message (in a manner acceptable to the server where
     the field originated) without receiving it. In other words, the server that
-    generated the header (often but not always the origin server) is willing to
-    accept the possibility that the trailer fields might be silently discarded
-    along the path to the client.</t>
+    generated the header field (often but not always the origin server) is
+    willing to accept the possibility that the trailer fields might be silently
+    discarded along the path to the client.</t>
   </list>
 </t>
@@ -4974 +4974 @@
    experimental implementations of HTTP/1.0 persistent connections are faulty;
    for example, if a HTTP/1.0 proxy server doesn't understand
-   <x:ref>Connection</x:ref>, it will erroneously forward that header to the
-   next inbound server, which would result in a hung connection.
-</t>
-<t>
-   One attempted solution was the introduction of a Proxy-Connection header,
-   targeted specifically at proxies. In practice, this was also unworkable,
-   because proxies are often deployed in multiple layers, bringing about the
-   same problem discussed above.
+   <x:ref>Connection</x:ref>, it will erroneously forward that header field
+   to the next inbound server, which would result in a hung connection.
+</t>
+<t>
+   One attempted solution was the introduction of a Proxy-Connection header
+   field, targeted specifically at proxies. In practice, this was also
+   unworkable, because proxies are often deployed in multiple layers, bringing
+   about the same problem discussed above.
 </t>
 <t>
    As a result, clients are encouraged not to send the Proxy-Connection header 
-   in any requests.
+   field in any requests.
 </t>
 <t>
@@ -4992 +4992 @@
    HTTP/1.0 servers, clients using them need will need to monitor the
    connection for "hung" requests (which indicate that the client ought stop
-   sending the header), and this mechanism ought not be used by clients at all
-   when a proxy is being used.
+   sending the header field), and this mechanism ought not be used by clients
+   at all when a proxy is being used.
 </t>
 </section>
@@ -5431 +5431 @@
   <list style="symbols"> 
     <t>
-      Reference RFC 3984, and update header field registrations for headers defined
-      in this document.
+      Reference RFC 3984, and update header field registrations for header
+      fields defined in this document.
     </t>
   </list>
@@ -5472 +5472 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/129"/>:
-      "List-type headers vs Set-Cookie"
+      "List-type header fields vs Set-Cookie"
     </t>
   </list>
@@ -5634 +5634 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/93"/>:
-      "Repeating single-value headers"
+      "Repeating single-value header fields"
     </t>
     <t>
@@ -5701 +5701 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
-      "use of term "word" when talking about header structure"
+      "use of term "word" when talking about header field structure"
     </t>
   </list>
@@ -5733 +5733 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
-      "use of term "word" when talking about header structure"
+      "use of term "word" when talking about header field structure"
     </t>
   </list>
@@ -5762 +5762 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>:
-      "Handling multiple Content-Length headers"
+      "Handling multiple Content-Length header fields"
     </t>
     <t>
@@ -5812 +5812 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>:
-      "Handling multiple Content-Length headers"
+      "Handling multiple Content-Length header fields"
     </t>
   </list>
@@ -5836 +5836 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
-      "Header Classification"
+      "Header Field Classification"
     </t>
     <t>
@@ -5868 +5868 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/95"/>:
-      "Handling multiple Content-Length headers"
+      "Handling multiple Content-Length header fields"
     </t>
     <t>
@@ -5940 +5940 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/215"/>:
-      "Explain header registration"
+      "Explain header field registration"
     </t>
     <t>

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

@@ -1219 +1219 @@
          </li>
          <li>
-            <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
+            <p>How the header field might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.7"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>).
             </p>
          </li>
@@ -1646 +1646 @@
       </p>
       <p id="rfc.section.4.2.1.p.3">Definitions of new HTTP status codes typically explain the request conditions that produce a response containing the status
-         code (e.g., combinations of request headers and/or method(s)), along with any interactions with response headers (e.g., those
-         that are required, those that modify the semantics of the response).
+         code (e.g., combinations of request header fields and/or method(s)), along with any interactions with response header fields
+         (e.g., those that are required, those that modify the semantics of the response).
       </p>
       <p id="rfc.section.4.2.1.p.4">New HTTP status codes are required to fall under one of the categories defined in <a href="#status.codes" title="Status Codes">Section&nbsp;4</a>. To allow existing parsers to properly handle them, new status codes cannot disallow a response body, although they can mandate
-         a zero-length response body. They can require the presence of one or more particular HTTP response header(s).
+         a zero-length response body. They can require the presence of one or more particular HTTP response header field(s).
       </p>
       <p id="rfc.section.4.2.1.p.5">Likewise, their definitions can specify that caches are allowed to use heuristics to determine their freshness (see <a href="#Part6" id="rfc.xref.Part6.10"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>; by default, it is not allowed), and can define how to determine the resource which they carry a representation for (see <a href="#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section&nbsp;7.1</a>; by default, it is anonymous).
@@ -3668 +3668 @@
          of individual users. Note that for many users not behind a proxy, the network address of the host running the user agent will
          also serve as a long-lived user identifier. In environments where proxies are used to enhance privacy, user agents ought to
-         be conservative in offering accept header configuration options to end users. As an extreme privacy measure, proxies could
-         filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
+         be conservative in offering accept header field configuration options to end users. As an extreme privacy measure, proxies
+         could filter the accept header fields in relayed requests. General purpose user agents which provide a high degree of header
+         field configurability <em class="bcp14">SHOULD</em> warn users about the loss of privacy which can be involved.
       </p>
       <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a>&nbsp;<a id="acks" href="#acks">Acknowledgments</a></h1>
@@ -4253 +4254 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/76">http://tools.ietf.org/wg/httpbis/trac/ticket/76</a>&gt;: "305 Use Proxy"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>&gt;: "Classification for Allow header"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>&gt;: "Classification for Allow header field"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/112">http://tools.ietf.org/wg/httpbis/trac/ticket/112</a>&gt;: "PUT - 'store under' vs 'store at'"
@@ -4261 +4262 @@
       </p>
       <ul>
-         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
+         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
       </ul>
       <p id="rfc.section.E.6.p.3">Ongoing work on ABNF conversion (&lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/36">http://tools.ietf.org/wg/httpbis/trac/ticket/36</a>&gt;): 
@@ -4273 +4274 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/67">http://tools.ietf.org/wg/httpbis/trac/ticket/67</a>&gt;: "Quoting Charsets"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>&gt;: "Classification for Allow header"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/105">http://tools.ietf.org/wg/httpbis/trac/ticket/105</a>&gt;: "Classification for Allow header field"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/115">http://tools.ietf.org/wg/httpbis/trac/ticket/115</a>&gt;: "missing default for qvalue in description of Accept-Encoding"
@@ -4281 +4282 @@
       </p>
       <ul>
-         <li>Reference RFC 3984, and update header field registrations for headers defined in this document.</li>
+         <li>Reference RFC 3984, and update header field registrations for header fields defined in this document.</li>
       </ul>
       <h2 id="rfc.section.E.8"><a href="#rfc.section.E.8">E.8</a>&nbsp;<a id="changes.since.03" href="#changes.since.03">Since draft-ietf-httpbis-p2-semantics-03</a></h2>
@@ -4398 +4399 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/182">http://tools.ietf.org/wg/httpbis/trac/ticket/182</a>&gt;: "update note about redirect limit"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/191">http://tools.ietf.org/wg/httpbis/trac/ticket/191</a>&gt;: "Location header ABNF should use 'URI'"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/191">http://tools.ietf.org/wg/httpbis/trac/ticket/191</a>&gt;: "Location header field ABNF should use 'URI'"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/192">http://tools.ietf.org/wg/httpbis/trac/ticket/192</a>&gt;: "fragments in Location vs status 303"
@@ -4455 +4456 @@
       <p id="rfc.section.E.20.p.2">Partly resolved issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header payload handling"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header field payload handling"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/196">http://tools.ietf.org/wg/httpbis/trac/ticket/196</a>&gt;: "Term for the requested resource's URI"
@@ -4469 +4470 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/155">http://tools.ietf.org/wg/httpbis/trac/ticket/155</a>&gt;: "Content Sniffing"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header structure"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/200">http://tools.ietf.org/wg/httpbis/trac/ticket/200</a>&gt;: "use of term "word" when talking about header field structure"
          </li>
       </ul>
@@ -4548 +4549 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/103">http://tools.ietf.org/wg/httpbis/trac/ticket/103</a>&gt;: "Content-*"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/104">http://tools.ietf.org/wg/httpbis/trac/ticket/104</a>&gt;: "Header type defaulting"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/104">http://tools.ietf.org/wg/httpbis/trac/ticket/104</a>&gt;: "Header field type defaulting"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/112">http://tools.ietf.org/wg/httpbis/trac/ticket/112</a>&gt;: "PUT - 'store under' vs 'store at'"
@@ -4554 +4555 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/137">http://tools.ietf.org/wg/httpbis/trac/ticket/137</a>&gt;: "duplicate ABNF for reason-phrase"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/180">http://tools.ietf.org/wg/httpbis/trac/ticket/180</a>&gt;: "Note special status of Content-* prefix in header registration procedures"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/180">http://tools.ietf.org/wg/httpbis/trac/ticket/180</a>&gt;: "Note special status of Content-* prefix in header field registration procedures"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/203">http://tools.ietf.org/wg/httpbis/trac/ticket/203</a>&gt;: "Max-Forwards vs extension methods"
@@ -4560 +4561 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/213">http://tools.ietf.org/wg/httpbis/trac/ticket/213</a>&gt;: "What is the value space of HTTP status codes?" (actually fixed in draft-ietf-httpbis-p2-semantics-11)
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Classification"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Field Classification"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/225">http://tools.ietf.org/wg/httpbis/trac/ticket/225</a>&gt;: "PUT side effect: invalidation or just stale?"
@@ -4580 +4581 @@
       <p id="rfc.section.E.27.p.1">Closed issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Classification"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/224">http://tools.ietf.org/wg/httpbis/trac/ticket/224</a>&gt;: "Header Field Classification"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/276">http://tools.ietf.org/wg/httpbis/trac/ticket/276</a>&gt;: "untangle ABNFs for header fields"
@@ -4642 +4643 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/186">http://tools.ietf.org/wg/httpbis/trac/ticket/186</a>&gt;: "Document HTTP's error-handling philosophy"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/231">http://tools.ietf.org/wg/httpbis/trac/ticket/231</a>&gt;: "Considerations for new headers"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/231">http://tools.ietf.org/wg/httpbis/trac/ticket/231</a>&gt;: "Considerations for new header fields"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/310">http://tools.ietf.org/wg/httpbis/trac/ticket/310</a>&gt;: "clarify 303 redirect on HEAD"
@@ -4656 +4657 @@
       <p id="rfc.section.E.36.p.1">Closed issues: </p>
       <ul>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header payload handling"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/185">http://tools.ietf.org/wg/httpbis/trac/ticket/185</a>&gt;: "Location header field payload handling"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/255">http://tools.ietf.org/wg/httpbis/trac/ticket/255</a>&gt;: "Clarify status code for rate limiting" (change backed out because a new status code is being defined for this purpose)

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

@@ -1075 +1075 @@
     <x:lt><t>Under what conditions intermediaries are allowed to modify the header
     field's value, insert or delete it.</t></x:lt>
-    <x:lt><t>How the header might interact with caching (see <xref target="Part6"/>).</t></x:lt>
+    <x:lt><t>How the header field might interact with caching (see
+    <xref target="Part6"/>).</t></x:lt>
     <x:lt><t>Whether the header field is useful or allowable in trailers (see
     &chunked-encoding;).</t></x:lt>
@@ -1290 +1291 @@
    Definitions of new HTTP status codes typically explain the request
    conditions that produce a response containing the status code (e.g.,
-   combinations of request headers and/or method(s)), along with any 
-   interactions with response headers (e.g., those that are required, those
-   that modify the semantics of the response).
+   combinations of request header fields and/or method(s)), along with any 
+   interactions with response header fields (e.g., those that are required,
+   those that modify the semantics of the response).
 </t>
 <t>
@@ -1299 +1300 @@
    properly handle them, new status codes cannot disallow a response body,
    although they can mandate a zero-length response body. They can require the
-   presence of one or more particular HTTP response header(s).
+   presence of one or more particular HTTP response header field(s).
 </t>
 <t>
@@ -4621 +4622 @@
    identifier. In environments where proxies are used to enhance
    privacy, user agents ought to be conservative in offering accept
-   header configuration options to end users. As an extreme privacy
+   header field configuration options to end users. As an extreme privacy
    measure, proxies could filter the accept header fields in relayed requests.
-   General purpose user agents which provide a high degree of header
+   General purpose user agents which provide a high degree of header field
    configurability &SHOULD; warn users about the loss of privacy which can
    be involved.
@@ -5980 +5981 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>:
-      "Classification for Allow header"
+      "Classification for Allow header field"
     </t>
     <t>
@@ -5992 +5993 @@
   <list style="symbols"> 
     <t>
-      Reference RFC 3984, and update header field registrations for headers defined
-      in this document.
+      Reference RFC 3984, and update header field registrations for header
+      fields defined in this document.
     </t>
   </list>
@@ -6017 +6018 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/105"/>:
-      "Classification for Allow header"
+      "Classification for Allow header field"
     </t>
     <t>
@@ -6029 +6030 @@
   <list style="symbols"> 
     <t>
-      Reference RFC 3984, and update header field registrations for headers defined
-      in this document.
+      Reference RFC 3984, and update header field registrations for header
+      fields defined in this document.
     </t>
   </list>
@@ -6265 +6266 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/191"/>:
-      "Location header ABNF should use 'URI'"
+      "Location header field ABNF should use 'URI'"
     </t>
     <t>
@@ -6379 +6380 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>:
-      "Location header payload handling"
+      "Location header field payload handling"
     </t>
     <t>
@@ -6407 +6408 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/200"/>:
-      "use of term "word" when talking about header structure"
+      "use of term "word" when talking about header field structure"
     </t>
   </list>
@@ -6563 +6564 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/104"/>:
-      "Header type defaulting"
+      "Header field type defaulting"
     </t>
     <t>
@@ -6575 +6576 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/180"/>:
-      "Note special status of Content-* prefix in header registration procedures"
+      "Note special status of Content-* prefix in header field registration procedures"
     </t>
     <t>
@@ -6588 +6589 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
-      "Header Classification"
+      "Header Field Classification"
     </t>
     <t>
@@ -6628 +6629 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/224"/>:
-      "Header Classification"
+      "Header Field Classification"
     </t>
     <t>
@@ -6754 +6755 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/231"/>:
-      "Considerations for new headers"
+      "Considerations for new header fields"
     </t>
     <t>
@@ -6782 +6783 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/185"/>:
-      "Location header payload handling"
+      "Location header field payload handling"
     </t>
     <t>

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

@@ -794 +794 @@
       <div id="rfc.iref.h.2"></div>
       <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
-      <p id="rfc.section.2.3.p.1">The ETag header field provides the current entity-tag for the selected representation. An entity-tag is an opaque validator
+      <p id="rfc.section.2.3.p.1">The "ETag" header field provides the current entity-tag for the selected representation. An entity-tag is an opaque validator
          for differentiating between multiple representations of the same resource, regardless of whether those multiple representations
          are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the

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

@@ -482 +482 @@
   <x:anchor-alias value="etagc"/>
 <t>
-   The ETag header field provides the current entity-tag for the
+   The "ETag" header field provides the current entity-tag for the
    selected representation.
    An entity-tag is an opaque validator for differentiating between

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

@@ -525 +525 @@
 </artwork></figure>
 <t>
-      Origin servers that accept byte-range requests &MAY; send
+   Origin servers that accept byte-range requests &MAY; send
 </t>
 <figure><artwork type="example">
@@ -531 +531 @@
 </artwork></figure>
 <t>
-      but are not required to do so. Clients &MAY; generate range
-      requests without having received this header field for the resource
-      involved. Range units are defined in <xref target="range.units"/>.
-</t>
-<t>
-      Servers that do not accept any kind of range request for a
-      resource &MAY; send
+   but are not required to do so. Clients &MAY; generate range
+   requests without having received this header field for the resource
+   involved. Range units are defined in <xref target="range.units"/>.
+</t>
+<t>
+   Servers that do not accept any kind of range request for a
+   resource &MAY; send
 </t>
 <figure><artwork type="example">
@@ -543 +543 @@
 </artwork></figure>
 <t>
-      to advise the client not to attempt a range request.
+   to advise the client not to attempt a range request.
 </t>
 </section>

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

@@ -1188 +1188 @@
       <p id="rfc.section.5.p.2">If one or more stored GET responses can be selected (as per <a href="#caching.negotiated.responses" title="Using Negotiated Responses">Section&nbsp;4.3</a>) for a HEAD request, and the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <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.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <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="Using Negotiated Responses">Section&nbsp;4.3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining headers in the stored response using the following rules: 
+      <p id="rfc.section.5.p.3">If the <a href="p1-messaging.html#header.content-length" class="smpl">Content-Length</a>, <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="Using Negotiated Responses">Section&nbsp;4.3</a>), the cache <em class="bcp14">SHOULD</em> update the remaining header fields in the stored response using the following rules: 
       </p>
       <ul>
@@ -1591 +1591 @@
       </p>
       <p id="rfc.section.7.6.p.7">Systems that generate multiple Warning header fields are encouraged to order them with this user agent behavior in mind. New
-         Warning header fields are added after any existing Warning headers fields.
+         Warning header fields are added after any existing Warning header fields.
       </p>
       <p id="rfc.section.7.6.p.8">Warnings are assigned three digit warn-codes. The first digit indicates whether the Warning is required to be deleted from
@@ -2051 +2051 @@
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/307">http://tools.ietf.org/wg/httpbis/trac/ticket/307</a>&gt;: "untangle Cache-Control ABNF"
          </li>
-         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/353">http://tools.ietf.org/wg/httpbis/trac/ticket/353</a>&gt;: "Multiple values in Cache-Control headers"
+         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/353">http://tools.ietf.org/wg/httpbis/trac/ticket/353</a>&gt;: "Multiple values in Cache-Control header fields"
          </li>
          <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/355">http://tools.ietf.org/wg/httpbis/trac/ticket/355</a>&gt;: "Case sensitivity of header fields in CC values"

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

@@ -1133 +1133 @@
    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:
+   the remaining header fields 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
@@ -1924 +1925 @@
    Systems that generate multiple Warning header fields are encouraged to
    order them with this user agent behavior in mind. New Warning header fields
-   are added after any existing Warning headers fields.
+   are added after any existing Warning header fields.
 </t>
 <t>
@@ -2672 +2673 @@
     <t>
       <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/353"/>:
-      "Multiple values in Cache-Control headers"
+      "Multiple values in Cache-Control header fields"
     </t>
     <t>