Mnot 111

draft-ietf-httpbis-cache-latest.xml

@@ -933,7 +933,7 @@
    (<xref target="header.if-none-match"/>) indicates that the client wants to validate one
    or more of its own stored responses in comparison to whichever stored
    response is selected by the cache.
-   If the field-value is "*", or if the field-value is a list of entity-tags
+   If the field value is "*", or if the field value is a list of entity-tags
    and at least one of them matches the entity-tag of the selected stored
    response, a cache recipient &SHOULD; generate a
    <x:ref>304 (Not Modified)</x:ref> response (using the metadata of the
@@ -965,9 +965,9 @@
    response (using the metadata of the selected stored response) if one of the
    following cases is true:
    1) the selected stored response has a <x:ref>Last-Modified</x:ref>
-   field-value that is earlier than or equal to the conditional timestamp;
+   field value that is earlier than or equal to the conditional timestamp;
    2) no <x:ref>Last-Modified</x:ref> field is present in the selected stored
-   response, but it has a <x:ref>Date</x:ref> field-value that is earlier than
+   response, but it has a <x:ref>Date</x:ref> field value that is earlier than
    or equal to the conditional timestamp; or,
    3) neither <x:ref>Last-Modified</x:ref> nor <x:ref>Date</x:ref> is present
    in the selected stored response, but the cache recorded it as having been
@@ -1129,17 +1129,17 @@
 
 
 
-<section title="Header Field Definitions" anchor="header.field.definitions">
+<section title="Field Definitions" anchor="header.field.definitions">
 <t>
-   This section defines the syntax and semantics of HTTP header fields
+   This section defines the syntax and semantics of HTTP fields
    related to caching.
 </t>
 <?BEGININC build/draft-ietf-httpbis-cache-latest.iana-headers ?>
 <!--AUTOGENERATED FROM extract-header-defs.xslt, do not edit manually-->
 <table align="left" anchor="iana.header.registration.table">
    <thead>
       <tr>
-         <th>Header Field Name</th>
+         <th>Field Name</th>
          <th>Status</th>
          <th>Reference</th>
       </tr>
@@ -1200,7 +1200,7 @@
   <x:ref>Age</x:ref> = <x:ref>delta-seconds</x:ref>
 </sourcecode>
 <t>
-   The Age field-value is a non-negative integer, representing time in seconds
+   The Age field value is a non-negative integer, representing time in seconds
    (see <xref target="delta-seconds"/>).
 </t>
 <t>
@@ -1525,17 +1525,17 @@
    been configured to send stale responses.
 </t>
 <t>
-   If the no-cache response directive specifies one or more field-names,
+   If the no-cache response directive specifies one or more field names,
    then a cache &MAY; use the response to satisfy a subsequent request,
    subject to any other restrictions on caching. However, any header fields
-   in the response that have the field-name(s) listed &MUST-NOT; be sent
+   in the response that have the field name(s) listed &MUST-NOT; be sent
    in the response to a subsequent request without successful revalidation
    with the origin server. This allows an origin server to prevent the
    re-use of certain header fields in a response, while still allowing
    caching of the rest of the response.
 </t> 
 <t>
-   The field-names given are not limited to the set of header
+   The field names given are not limited to the set of header
    fields defined by this specification. Field names are case-insensitive.
 </t>
 <t>
@@ -1546,7 +1546,7 @@
 <t>
    &Note; Although it has been back-ported to many implementations, some
    HTTP/1.0 caches will not recognize or obey this directive. Also, no-cache
-   response directives with field-names are often handled by caches
+   response directives with field names are often handled by caches
    as if an unqualified no-cache directive was received; i.e., the special
    handling for the qualified form is not widely implemented.
 </t>
@@ -1613,14 +1613,14 @@
    even if the response would normally be non-cacheable.
 </t>
 <t>
-   If the private response directive specifies one or more field-names,
-   this requirement is limited to the field-values associated with the
+   If the private response directive specifies one or more field names,
+   this requirement is limited to the field values associated with the
    listed response header fields. That is, a shared cache &MUST-NOT; store
-   the specified field-names(s), whereas it &MAY; store the remainder of the
+   the specified field names(s), whereas it &MAY; store the remainder of the
    response message.
 </t>
 <t>
-   The field-names given are not limited to the set of header
+   The field names given are not limited to the set of header
    fields defined by this specification. Field names are case-insensitive.
 </t>
 <t>
@@ -1631,7 +1631,7 @@
 <t>
    &Note; This usage of the word "private" only controls
    where the response can be stored; it cannot ensure the privacy of the
-   message content. Also, private response directives with field-names are
+   message content. Also, private response directives with field names are
    often handled by caches as if an unqualified private directive
    was received; i.e., the special handling for the qualified form is not
    widely implemented.
@@ -1811,7 +1811,7 @@
    with a reliable clock.
 </t>
 <t>
-   Historically, HTTP required the Expires field-value to be no more than a 
+   Historically, HTTP required the Expires field value to be no more than a 
    year in the future. While longer freshness lifetimes are no longer 
    prohibited, extremely large values have been demonstrated to cause 
    problems (e.g., clock overflows due to use of 32-bit integers for 
@@ -1963,12 +1963,12 @@
    "IETF ([email protected]) - Internet Engineering Task Force".
 </t>
 
-<section title="Header Field Registration" anchor="header.field.registration">
+<section title="Field Registration" anchor="header.field.registration">
 <t>
-   Please update the "Hypertext Transfer Protocol (HTTP) Header Field
+   Please update the "Hypertext Transfer Protocol (HTTP) Field
    Registry" registry at <eref
-   target="https://www.iana.org/assignments/http-headers"/> with the
-   header field names listed in the two tables of <xref
+   target="https://www.iana.org/assignments/http-fields"/> with the
+   field names listed in the two tables of <xref
    target="header.field.definitions"/>.
 </t>
 </section>
@@ -2252,17 +2252,17 @@
 
 <x:ref>HTTP-date</x:ref> = &lt;HTTP-date, see <xref target="Semantics" x:fmt="," x:sec="10.1.1.1"/>&gt;
 
-<x:ref>OWS</x:ref> = &lt;OWS, see <xref target="Semantics" x:fmt="," x:sec="4.3"/>&gt;
+<x:ref>OWS</x:ref> = &lt;OWS, see <xref target="Semantics" x:fmt="," x:sec="11.1"/>&gt;
 
 <x:ref>cache-directive</x:ref> = token [ "=" ( token / quoted-string ) ]
 
 <x:ref>delta-seconds</x:ref> = 1*DIGIT
 
-<x:ref>field-name</x:ref> = &lt;field-name, see <xref target="Semantics" x:fmt="," x:sec="4.2"/>&gt;
+<x:ref>field-name</x:ref> = &lt;field-name, see <xref target="Semantics" x:fmt="," x:sec="4.3"/>&gt;
 
-<x:ref>quoted-string</x:ref> = &lt;quoted-string, see <xref target="Semantics" x:fmt="," x:sec="4.2.3"/>&gt;
+<x:ref>quoted-string</x:ref> = &lt;quoted-string, see <xref target="Semantics" x:fmt="," x:sec="4.4.1.2"/>&gt;
 
-<x:ref>token</x:ref> = &lt;token, see <xref target="Semantics" x:fmt="," x:sec="4.2.3"/>&gt;
+<x:ref>token</x:ref> = &lt;token, see <xref target="Semantics" x:fmt="," x:sec="4.4.1.1"/>&gt;
 </sourcecode>
 </section>
 <?ENDINC build/draft-ietf-httpbis-cache-latest.abnf-appendix ?>