Changeset 1920 for draft-ietf-httpbis/latest/p2-semantics.xml

Timestamp:

01/10/12 01:14:48 (10 years ago)

Author:

fielding@…

Message:

(editorial) move selected representation fields to response header fields

File:

• draft-ietf-httpbis/latest/p2-semantics.xml (modified) (3 diffs)

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

@@ -529 +529 @@
 </section>
 
-<section title="Selected Representation Header Fields" anchor="selected.representation">
-<t><iref primary="true" item="selected representation"/>
-   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
-   the current representation of a target resource that would have been
-   selected in a successful response if the same request had used the
-   method GET and excluded any conditional request header fields.
-</t>
-<t>
-   Additional header fields define metadata about the selected
-   representation, which might differ from the representation included
-   in the message for responses to some state-changing methods.
-   The following header fields are defined as selected representation
-   metadata:
-</t>
-<texttable align="left">
-  <ttcol>Header Field Name</ttcol>
-  <ttcol>Defined in...</ttcol>
-
-  <c>ETag</c> <c>&header-etag;</c>
-  <c>Last-Modified</c> <c>&header-last-modified;</c>
-</texttable>
-</section>
-
 <section title="Representation Data" anchor="representation.data">
   <x:anchor-alias value="representation-data"/>
@@ -3261 +3238 @@
   <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
 
+  <c>Age</c> <c>&header-age;</c>
+  <c>Date</c> <c><xref target="header.date"/></c>
   <c>Location</c> <c><xref target="header.location"/></c>
   <c>Retry-After</c> <c><xref target="header.retry-after"/></c>
 </texttable>
+
+<section title="Date" anchor="header.date">
+  <iref primary="true" item="Date header field" x:for-anchor=""/>
+  <x:anchor-alias value="Date"/>
+<t>
+   The "Date" header field represents the date and time at which
+   the message was originated, having the same semantics as the Origination
+   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
+   The field value is an HTTP-date, as defined in <xref target="http.date"/>;
+   it &MUST; be sent in rfc1123-date format.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
+  <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
+</artwork></figure>
+<t>
+   An example is
+</t>
+<figure><artwork type="example">
+  Date: Tue, 15 Nov 1994 08:12:31 GMT
+</artwork></figure>
+<t>
+   Origin servers &MUST; include a Date header field in all responses,
+   except in these cases:
+  <list style="numbers">
+      <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
+         <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
+         Date header field, at the server's option.</t>
+
+      <t>If the response status code conveys a server error, e.g., <x:ref>500
+         (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
+         and it is inconvenient or impossible to generate a valid Date.</t>
+
+      <t>If the server does not have a clock that can provide a
+         reasonable approximation of the current time, its responses
+         &MUST-NOT; include a Date header field.</t>
+  </list>
+</t>
+<t>
+   A received message that does not have a Date header field &MUST; be
+   assigned one by the recipient if the message will be cached by that
+   recipient.
+</t>
+<t>
+   Clients can use the Date header field as well; in order to keep request
+   messages small, they are advised not to include it when it doesn't convey
+   any useful information (as is usually the case for requests that do not
+   contain a payload).
+</t>
+<t>
+   The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
+   time subsequent to the generation of the message. It &SHOULD; represent
+   the best available approximation of the date and time of message
+   generation, unless the implementation has no means of generating a
+   reasonably accurate date and time. In theory, the date ought to
+   represent the moment just before the payload is generated. In
+   practice, the date can be generated at any time during the message
+   origination without affecting its semantic value.
+</t>
+</section>
 
 <section title="Location" anchor="header.location">
@@ -3367 +3405 @@
 </section>
 
-<section title="Cache-related" anchor="response.cache.related">
-<t>
-   Cache-related response header fields provide metadata about the message
-   in order to assist downstream caches.
+<section title="Selected Representation Header Fields" anchor="selected.representation">
+<t><iref primary="true" item="selected representation"/>
+   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
+   the current representation of a target resource that would have been
+   selected in a successful response if the same request had used the
+   method GET and excluded any conditional request header fields.
+</t>
+<t>
+   Additional header fields define metadata about the selected
+   representation, which might differ from the representation included
+   in the message for responses to some state-changing methods.
+   The following header fields are defined as selected representation
+   metadata:
 </t>
 <texttable align="left">
-  <ttcol>Header Field Name</ttcol><ttcol>Defined in...</ttcol>
-
-  <c>Age</c> <c>&header-age;</c>
-  <c>Date</c> <c><xref target="header.date"/></c>
+  <ttcol>Header Field Name</ttcol>
+  <ttcol>Defined in...</ttcol>
+
+  <c>ETag</c> <c>&header-etag;</c>
+  <c>Last-Modified</c> <c>&header-last-modified;</c>
   <c>Vary</c> <c><xref target="header.vary"/></c>
 </texttable>
-
-<section title="Date" anchor="header.date">
-  <iref primary="true" item="Date header field" x:for-anchor=""/>
-  <x:anchor-alias value="Date"/>
-<t>
-   The "Date" header field represents the date and time at which
-   the message was originated, having the same semantics as the Origination
-   Date Field (orig-date) defined in <xref target="RFC5322" x:fmt="of" x:sec="3.6.1"/>.
-   The field value is an HTTP-date, as defined in <xref target="http.date"/>;
-   it &MUST; be sent in rfc1123-date format.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
-  <x:ref>Date</x:ref> = <x:ref>HTTP-date</x:ref>
-</artwork></figure>
-<t>
-   An example is
-</t>
-<figure><artwork type="example">
-  Date: Tue, 15 Nov 1994 08:12:31 GMT
-</artwork></figure>
-<t>
-   Origin servers &MUST; include a Date header field in all responses,
-   except in these cases:
-  <list style="numbers">
-      <t>If the response status code is <x:ref>100 (Continue)</x:ref> or
-         <x:ref>101 (Switching Protocols)</x:ref>, the response &MAY; include a
-         Date header field, at the server's option.</t>
-
-      <t>If the response status code conveys a server error, e.g., <x:ref>500
-         (Internal Server Error)</x:ref> or <x:ref>503 (Service Unavailable)</x:ref>,
-         and it is inconvenient or impossible to generate a valid Date.</t>
-
-      <t>If the server does not have a clock that can provide a
-         reasonable approximation of the current time, its responses
-         &MUST-NOT; include a Date header field.</t>
-  </list>
-</t>
-<t>
-   A received message that does not have a Date header field &MUST; be
-   assigned one by the recipient if the message will be cached by that
-   recipient.
-</t>
-<t>
-   Clients can use the Date header field as well; in order to keep request
-   messages small, they are advised not to include it when it doesn't convey
-   any useful information (as is usually the case for requests that do not
-   contain a payload).
-</t>
-<t>
-   The HTTP-date sent in a Date header field &SHOULD-NOT; represent a date and
-   time subsequent to the generation of the message. It &SHOULD; represent
-   the best available approximation of the date and time of message
-   generation, unless the implementation has no means of generating a
-   reasonably accurate date and time. In theory, the date ought to
-   represent the moment just before the payload is generated. In
-   practice, the date can be generated at any time during the message
-   origination without affecting its semantic value.
-</t>
-</section>
 
 <section anchor="header.vary" title="Vary">