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

Timestamp:

29/12/12 08:22:04 (9 years ago)

Author:

fielding@…

Message:

(editorial) rephrase Date for better targeting of subject requirements

File:

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

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

@@ -2585 +2585 @@
   <iref primary="true" item="Status Codes Classes" subitem="1xx Informational" x:for-anchor=""/>
 <t>
-   This class of status code indicates a provisional response,
+   This class of status code indicates an interim response,
    consisting only of the status-line and optional header fields, and is
    terminated by an empty line. There are no required header fields for this
@@ -3628 +3628 @@
    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.
+   The field value is an HTTP-date, as defined in <xref target="http.date"/>,
+   though a sender &MUST; generate a Date value in the rfc1123-date format.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
@@ -3641 +3641 @@
 </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.
+   When a Date header field is generated, the sender &SHOULD; generate its
+   field value as the best available approximation of the date and time of
+   message generation. 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 message origination.
+</t>
+<t>
+   An origin server &MUST-NOT; send a Date header field if it does not have a
+   clock capable of providing a reasonable approximation of the current time.
+   An origin server &MAY; send a Date header field if the response is in the
+   <x:ref>1xx (Informational)</x:ref> or <x:ref>5xx (Server Error)</x:ref>
+   class of status codes.
+   An origin server &MUST; send a Date header field in all other cases.
+</t>
+<t>
+   A recipient with a clock that receives a response message without a Date
+   header field &MUST; record the time it was received and append a
+   corresponding Date header field to the message's header block if it is
+   cached or forwarded downstream.
+</t>
+<t>
+   A user agent &MAY; send a Date header field in a request, though generally
+   will not do so unless it is believed to convey useful information to the
+   server. For example, custom applications of HTTP might convey a Date if
+   the server is expected to adjust its interpretation of the user's request
+   based on differences between the user agent and server clocks.
 </t>
 </section>