Changeset 2082 for draft-ietf-httpbis

Timestamp:

Jan 4, 2013, 2:29:06 AM (7 years ago)

Author:

fielding@…

Message:

Yet another attempt to explain HTTP-date, remove redundant requirements in sections that use HTTP-date, and correct some inconsistent requirements regarding time zones; related to #375 and [2077]

Location:

draft-ietf-httpbis/latest

Files:

• httpbis.abnf (modified) (3 diffs)
• p2-semantics.html (modified) (16 diffs)
• p2-semantics.xml (modified) (11 diffs)
• p6-cache.html (modified) (12 diffs)
• p6-cache.xml (modified) (8 diffs)

draft-ietf-httpbis/latest/httpbis.abnf

@@ -27 +27 @@
 GMT = %x47.4D.54 ; GMT
 
-HTTP-date = rfc1123-date / obs-date
+HTTP-date = IMF-fixdate / obs-date
 HTTP-message = start-line *( header-field CRLF ) CRLF [ message-body ]
 HTTP-name = %x48.54.54.50 ; HTTP
@@ -33 +33 @@
 HTTP-version = HTTP-name "/" DIGIT "." DIGIT
 Host = uri-host [ ":" port ]
+IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
 If-Match = "*" / ( *( "," OWS ) entity-tag *( OWS "," [ OWS entity-tag ] ) )
 If-Modified-Since = HTTP-date
@@ -201 +202 @@
 request-line = method SP request-target SP HTTP-version CRLF
 request-target = origin-form / absolute-form / authority-form / asterisk-form
-rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
 rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
 second = 2DIGIT

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

@@ -449 +449 @@
   } 
   @bottom-center {
-       content: "Expires July 6, 2013"; 
+       content: "Expires July 8, 2013"; 
   } 
   @bottom-right {
@@ -495 +495 @@
       <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="2013-01-02">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-04">
       <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. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
@@ -523 +523 @@
             <tr>
                <td class="left">Intended status: Standards Track</td>
-               <td class="right">January 2, 2013</td>
+               <td class="right">January 4, 2013</td>
             </tr>
             <tr>
-               <td class="left">Expires: July 6, 2013</td>
+               <td class="left">Expires: July 8, 2013</td>
                <td class="right"></td>
             </tr>
@@ -554 +554 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 6, 2013.</p>
+      <p>This Internet-Draft will expire on July 8, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -2804 +2804 @@
       <h3 id="rfc.section.7.1.1"><a href="#rfc.section.7.1.1">7.1.1</a>&nbsp;<a id="origination.date" href="#origination.date">Origination Date</a></h3>
       <h4 id="rfc.section.7.1.1.1"><a href="#rfc.section.7.1.1.1">7.1.1.1</a>&nbsp;<a id="http.date" href="#http.date">Date/Time Formats</a></h4>
-      <p id="rfc.section.7.1.1.1.p.1">HTTP has historically allowed three different formats for date/time stamps. However, the preferred format is a fixed-length
-         subset of that defined by <a href="#RFC1123" id="rfc.xref.RFC1123.1"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>:
-      </p>
-      <div id="rfc.figure.u.42"></div><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
-</pre><p id="rfc.section.7.1.1.1.p.3">The other formats are described here only for compatibility with obsolete implementations.</p>
-      <div id="rfc.figure.u.43"></div><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
-Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
-</pre><p id="rfc.section.7.1.1.1.p.5">HTTP always represents dates as an instance of Coordinated Universal Time (UTC), without exception; the first two formats
-         indicate UTC as "GMT" in the three-letter abbreviation for time zone. Recipients <em class="bcp14">MAY</em> assume UTC even if the time zone abbreviation is missing, invalid, or might indicate some other time zone.
-      </p>
-      <div id="rfc.figure.u.44"></div><pre class="inline"><span id="rfc.iref.g.39"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">rfc1123-date</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
-</pre><div id="preferred.date.format">
+      <p id="rfc.section.7.1.1.1.p.1">Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with
+         old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date
+         and time specification used by the Internet Message Format <a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>.
+      </p>
+      <div id="rfc.figure.u.42"></div><pre class="inline"><span id="rfc.iref.g.39"></span>  <a href="#http.date" class="smpl">HTTP-date</a>    = <a href="#preferred.date.format" class="smpl">IMF-fixdate</a> / <a href="#obsolete.date.formats" class="smpl">obs-date</a>
+</pre><div id="rfc.figure.u.43"></div>
+      <p>An example of the preferred format is</p><pre class="text">Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
+</pre><div id="rfc.figure.u.44"></div>
+      <p>Examples of the two obsolete formats are</p><pre class="text">Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
+Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
+</pre><p id="rfc.section.7.1.1.1.p.5">A recipient that parses a timestamp value in an HTTP header field <em class="bcp14">MUST</em> accept all three formats. A sender <em class="bcp14">MUST</em> generate the IMF-fixdate format when sending an HTTP-date value in a header field.
+      </p>
+      <p id="rfc.section.7.1.1.1.p.6">An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC
+         by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format
+         are assumed to be in UTC. A sender that generates HTTP-date values from a local clock ought to use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clock to UTC.
+      </p>
+      <div id="preferred.date.format">
          <p id="rfc.section.7.1.1.1.p.7">                    Preferred format:</p>
       </div>
-      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span>  <a href="#preferred.date.format" class="smpl">rfc1123-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#imported.abnf" class="smpl">SP</a> date1 <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
-  ; fixed length subset of the format defined in
-  ; <a href="http://tools.ietf.org/html/rfc1123#section-5.2.14">Section 5.2.14</a> of <a href="#RFC1123" id="rfc.xref.RFC1123.2"><cite title="Requirements for Internet Hosts - Application and Support">[RFC1123]</cite></a>
+      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span><span id="rfc.iref.g.51"></span>  <a href="#preferred.date.format" class="smpl">IMF-fixdate</a>  = <a href="#preferred.date.format" class="smpl">day-name</a> "," <a href="#imported.abnf" class="smpl">SP</a> date1 <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
+  ; fixed length/zone subset of the format defined in
+  ; <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>
   
   <a href="#preferred.date.format" class="smpl">day-name</a>     = %x4D.6F.6E ; "Mon", case-sensitive
@@ -2848 +2853 @@
   <a href="#preferred.date.format" class="smpl">year</a>         = 4<a href="#imported.abnf" class="smpl">DIGIT</a>
 
-  <a href="#preferred.date.format" class="smpl">GMT</a>   = %x47.4D.54 ; "GMT", case-sensitive
+  <a href="#preferred.date.format" class="smpl">GMT</a>          = %x47.4D.54 ; "GMT", case-sensitive
 
   <a href="#preferred.date.format" class="smpl">time-of-day</a>  = <a href="#preferred.date.format" class="smpl">hour</a> ":" <a href="#preferred.date.format" class="smpl">minute</a> ":" <a href="#preferred.date.format" class="smpl">second</a>
-                 ; 00:00:00 - 23:59:59
+               ; 00:00:00 - 23:59:60 (leap second)
                  
   <a href="#preferred.date.format" class="smpl">hour</a>         = 2<a href="#imported.abnf" class="smpl">DIGIT</a>               
   <a href="#preferred.date.format" class="smpl">minute</a>       = 2<a href="#imported.abnf" class="smpl">DIGIT</a>               
   <a href="#preferred.date.format" class="smpl">second</a>       = 2<a href="#imported.abnf" class="smpl">DIGIT</a>               
-</pre><p id="rfc.section.7.1.1.1.p.9">The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the RFC 5322 constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.3"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
-      </p>
-      <div id="obsolete.date.formats">
-         <p id="rfc.section.7.1.1.1.p.10">              Obsolete formats:</p>
+</pre><div id="obsolete.date.formats">
+         <p id="rfc.section.7.1.1.1.p.9">              Obsolete formats:</p>
       </div>
       <div id="rfc.figure.u.46"></div><pre class="inline"><span id="rfc.iref.g.52"></span>  <a href="#obsolete.date.formats" class="smpl">obs-date</a>     = <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> / <a href="#obsolete.date.formats" class="smpl">asctime-date</a> 
 </pre><div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.53"></span>  <a href="#obsolete.date.formats" class="smpl">rfc850-date</a>  = <a href="#obsolete.date.formats" class="smpl">day-name-l</a> "," <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date2</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">GMT</a>
   <a href="#obsolete.date.formats" class="smpl">date2</a>        = <a href="#preferred.date.format" class="smpl">day</a> "-" <a href="#preferred.date.format" class="smpl">month</a> "-" 2<a href="#imported.abnf" class="smpl">DIGIT</a>
-                 ; day-month-year (e.g., 02-Jun-82)
-
-  <a href="#obsolete.date.formats" class="smpl">day-name-l</a>   = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
-         / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
+               ; e.g., 02-Jun-82
+
+  <a href="#obsolete.date.formats" class="smpl">day-name-l</a>   = %x4D.6F.6E.64.61.79    ; "Monday", case-sensitive
+         / %x54.75.65.73.64.61.79       ; "Tuesday", case-sensitive
          / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
-         / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
-         / %x46.72.69.64.61.79 ; "Friday", case-sensitive
-         / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
-         / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
+         / %x54.68.75.72.73.64.61.79    ; "Thursday", case-sensitive
+         / %x46.72.69.64.61.79          ; "Friday", case-sensitive
+         / %x53.61.74.75.72.64.61.79    ; "Saturday", case-sensitive
+         / %x53.75.6E.64.61.79          ; "Sunday", case-sensitive
 </pre><div id="rfc.figure.u.48"></div><pre class="inline"><span id="rfc.iref.g.54"></span>  <a href="#obsolete.date.formats" class="smpl">asctime-date</a> = <a href="#preferred.date.format" class="smpl">day-name</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#obsolete.date.formats" class="smpl">date3</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">time-of-day</a> <a href="#imported.abnf" class="smpl">SP</a> <a href="#preferred.date.format" class="smpl">year</a>
   <a href="#obsolete.date.formats" class="smpl">date3</a>        = <a href="#preferred.date.format" class="smpl">month</a> <a href="#imported.abnf" class="smpl">SP</a> ( 2<a href="#imported.abnf" class="smpl">DIGIT</a> / ( <a href="#imported.abnf" class="smpl">SP</a> 1<a href="#imported.abnf" class="smpl">DIGIT</a> ))
-                 ; month day (e.g., Jun  2)
-</pre><p id="rfc.section.7.1.1.1.p.14">HTTP-date is case sensitive. A sender <em class="bcp14">MUST NOT</em> generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar.
-      </p>
-      <p id="rfc.section.7.1.1.1.p.15">Recipients that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0). A sender <em class="bcp14">MUST</em> only generate the RFC 1123 format when sending HTTP-date values in header fields.
+               ; e.g., Jun  2
+</pre><p id="rfc.section.7.1.1.1.p.13">HTTP-date is case sensitive. A sender <em class="bcp14">MUST NOT</em> generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. The semantics of <a href="#preferred.date.format" class="smpl">day-name</a>, <a href="#preferred.date.format" class="smpl">day</a>, <a href="#preferred.date.format" class="smpl">month</a>, <a href="#preferred.date.format" class="smpl">year</a>, and <a href="#preferred.date.format" class="smpl">time-of-day</a> are the same as those defined for the Internet Message Format constructs with the corresponding name (<a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>, <a href="http://tools.ietf.org/html/rfc5322#section-3.3">Section 3.3</a>).
+      </p>
+      <p id="rfc.section.7.1.1.1.p.14">Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, <em class="bcp14">SHOULD</em> interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past
+         that had the same last two digits.
+      </p>
+      <p id="rfc.section.7.1.1.1.p.15">Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field
+         definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the
+         date and time specifications defined by the Internet Message Format.
       </p>
       <div class="note" id="rfc.section.7.1.1.1.p.16"> 
-         <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that might have been sent by non-HTTP applications,
-            as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP.
-         </p> 
-      </div>
-      <div class="note" id="rfc.section.7.1.1.1.p.17"> 
-         <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
-            are not required to use these formats for user presentation, request logging, etc.
+         <p> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Implementations are
+            not required to use these formats for user presentation, request logging, etc.
          </p> 
       </div>
@@ -2893 +2896 @@
       <h4 id="rfc.section.7.1.1.2"><a href="#rfc.section.7.1.1.2">7.1.1.2</a>&nbsp;<a id="header.date" href="#header.date">Date</a></h4>
       <p id="rfc.section.7.1.1.2.p.1">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 <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.4"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>, though a sender <em class="bcp14">MUST</em> generate a Date value in the rfc1123-date format.
+         Origination Date Field (orig-date) defined in <a href="http://tools.ietf.org/html/rfc5322#section-3.6.1">Section 3.6.1</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.6"><cite title="Internet Message Format">[RFC5322]</cite></a>. The field value is an HTTP-date, as defined in <a href="#http.date" title="Date/Time Formats">Section&nbsp;7.1.1.1</a>.
       </p>
       <div id="rfc.figure.u.49"></div><pre class="inline"><span id="rfc.iref.g.55"></span>  <a href="#header.date" class="smpl">Date</a> = <a href="#http.date" class="smpl">HTTP-date</a>
@@ -2902 +2905 @@
          message origination.
       </p>
-      <p id="rfc.section.7.1.1.2.p.6">An origin server <em class="bcp14">MUST NOT</em> 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 <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases.
+      <p id="rfc.section.7.1.1.2.p.6">An origin server <em class="bcp14">MUST NOT</em> send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance
+         in Coordinated Universal Time. An origin server <em class="bcp14">MAY</em> send a Date header field if the response is in the <a href="#status.1xx" class="smpl">1xx (Informational)</a> or <a href="#status.5xx" class="smpl">5xx (Server Error)</a> class of status codes. An origin server <em class="bcp14">MUST</em> send a Date header field in all other cases.
       </p>
       <p id="rfc.section.7.1.1.2.p.7">A recipient with a clock that receives a response message without a Date header field <em class="bcp14">MUST</em> record the time it was received and append a corresponding Date header field to the message's header block if it is cached
@@ -3951 +3954 @@
          </tr>
          <tr>
-            <td class="reference"><b id="RFC1123">[RFC1123]</b></td>
-            <td class="top"><a href="mailto:Braden@ISI.EDU" title="University of Southern California (USC), Information Sciences Institute">Braden, R.</a>, “<a href="http://tools.ietf.org/html/rfc1123">Requirements for Internet Hosts - Application and Support</a>”, STD&nbsp;3, RFC&nbsp;1123, October&nbsp;1989.
+            <td class="reference"><b id="RFC1305">[RFC1305]</b></td>
+            <td class="top"><a href="mailto:mills@udel.edu" title="University of Delaware, Electrical Engineering Department">Mills, D.</a>, “<a href="http://tools.ietf.org/html/rfc1305">Network Time Protocol (Version 3) Specification, Implementation</a>”, RFC&nbsp;1305, March&nbsp;1992.
             </td>
          </tr>
@@ -4056 +4059 @@
       </div>
       <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="differences.between.http.and.mime" href="#differences.between.http.and.mime">Differences between HTTP and MIME</a></h1>
-      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.5"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However,
+      <p id="rfc.section.A.p.1">HTTP/1.1 uses many of the constructs defined for Internet Mail (<a href="#RFC5322" id="rfc.xref.RFC5322.7"><cite title="Internet Message Format">[RFC5322]</cite></a>) and the Multipurpose Internet Mail Extensions (MIME <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>) to allow a message body to be transmitted in an open variety of representations and with extensible mechanisms. However,
          RFC 2045 discusses mail, and HTTP has a few features that are different from those described in MIME. These differences were
          carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types,
@@ -4252 +4255 @@
 <a href="#preferred.date.format" class="smpl">GMT</a> = %x47.4D.54 ; GMT
 
-<a href="#http.date" class="smpl">HTTP-date</a> = rfc1123-date / obs-date
+<a href="#http.date" class="smpl">HTTP-date</a> = IMF-fixdate / obs-date
+
+<a href="#preferred.date.format" class="smpl">IMF-fixdate</a> = day-name "," SP date1 SP time-of-day SP GMT
 
 <a href="#header.location" class="smpl">Location</a> = URI-reference
@@ -4346 +4351 @@
 <a href="#quality.values" class="smpl">qvalue</a> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
 
-<a href="#preferred.date.format" class="smpl">rfc1123-date</a> = day-name "," SP date1 SP time-of-day SP GMT
 <a href="#obsolete.date.formats" class="smpl">rfc850-date</a> = day-name-l "," SP date2 SP time-of-day SP GMT
 
@@ -4519 +4523 @@
                         <li><tt>hour</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.43"><b>7.1.1.1</b></a></li>
                         <li><tt>HTTP-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.39"><b>7.1.1.1</b></a></li>
+                        <li><tt>IMF-fixdate</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>
                         <li><tt>language-range</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.33"><b>5.3.5</b></a></li>
                         <li><tt>language-tag</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.12"><b>3.1.3.1</b></a></li>
@@ -4536 +4541 @@
                         <li><tt>Referer</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.35"><b>5.5.2</b></a></li>
                         <li><tt>Retry-After</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.57"><b>7.1.3</b></a></li>
-                        <li><tt>rfc1123-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.40"><b>7.1.1.1</b></a></li>
                         <li><tt>rfc850-date</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.53"><b>7.1.1.1</b></a></li>
                         <li><tt>second</tt>&nbsp;&nbsp;<a href="#rfc.iref.g.45"><b>7.1.1.1</b></a></li>
@@ -4658 +4662 @@
                   <li><em>REST</em>&nbsp;&nbsp;<a href="#rfc.xref.REST.1">3</a>, <a href="#rfc.xref.REST.2">4.1</a>, <a href="#REST"><b>11.2</b></a></li>
                   <li>Retry-After header field&nbsp;&nbsp;<a href="#rfc.xref.header.retry-after.1">6.6.4</a>, <a href="#rfc.xref.header.retry-after.2">7.1</a>, <a href="#rfc.iref.r.3"><b>7.1.3</b></a>, <a href="#rfc.xref.header.retry-after.3">8.3.2</a></li>
-                  <li><em>RFC1123</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.1">7.1.1.1</a>, <a href="#rfc.xref.RFC1123.2">7.1.1.1</a>, <a href="#RFC1123"><b>11.2</b></a><ul>
-                        <li><em>Section 5.2.14</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1123.2">7.1.1.1</a></li>
-                     </ul>
-                  </li>
+                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">7.1.1.1</a>, <a href="#RFC1305"><b>11.2</b></a></li>
                   <li><em>RFC1945</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a>, <a href="#RFC1945"><b>11.2</b></a>, <a href="#rfc.xref.RFC1945.2">B</a><ul>
                         <li><em>Section 9.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1945.1">6.4</a></li>
@@ -4722 +4723 @@
                      </ul>
                   </li>
-                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1.2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.5">A</a><ul>
-                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.3">7.1.1.1</a></li>
+                  <li><em>RFC5322</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a>, <a href="#rfc.xref.RFC5322.3">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.6">7.1.1.2</a>, <a href="#RFC5322"><b>11.2</b></a>, <a href="#rfc.xref.RFC5322.7">A</a><ul>
+                        <li><em>Section 3.3</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.1</a>, <a href="#rfc.xref.RFC5322.5">7.1.1.1</a></li>
                         <li><em>Section 3.4</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.1">5.5.1</a>, <a href="#rfc.xref.RFC5322.2">5.5.1</a></li>
-                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.4">7.1.1.2</a></li>
+                        <li><em>Section 3.6.1</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC5322.6">7.1.1.2</a></li>
                      </ul>
                   </li>

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

@@ -3516 +3516 @@
   <x:anchor-alias value="HTTP-date"/>
 <t>
-   HTTP has historically allowed three different formats
-   for date/time stamps. However, the preferred format is a fixed-length subset
-   of that defined by <xref target="RFC1123"/>:
-</t>
-<figure><artwork type="example" x:indent-with="  ">
-Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
+   Prior to 1995, there were three different formats commonly used by servers
+   to communicate timestamps.  For compatibility with old implementations, all
+   three are defined here. The preferred format is a fixed-length and
+   single-zone subset of the date and time specification used by the
+   Internet Message Format <xref target="RFC5322"/>.
+</t>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/>
+  <x:ref>HTTP-date</x:ref>    = <x:ref>IMF-fixdate</x:ref> / <x:ref>obs-date</x:ref>
 </artwork></figure>
-<t>
-   The other formats are described here only for compatibility with obsolete
-   implementations.
-</t>
-<figure><artwork type="example" x:indent-with="  ">
-Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
-Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
+<figure><preamble>An example of the preferred format is</preamble><artwork type="example" x:indent-with="  ">
+Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
 </artwork></figure>
-<t>
-   HTTP always represents dates as an instance of Coordinated Universal Time
-   (UTC), without exception; the first two formats indicate UTC as "GMT" in
-   the three-letter abbreviation for time zone. Recipients &MAY; assume UTC
-   even if the time zone abbreviation is missing, invalid, or might indicate
-   some other time zone.
-</t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/>
-  <x:ref>HTTP-date</x:ref>    = <x:ref>rfc1123-date</x:ref> / <x:ref>obs-date</x:ref>
+<figure><preamble>Examples of the two obsolete formats are</preamble><artwork type="example" x:indent-with="  ">
+Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
+Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
 </artwork></figure>
+<t>
+   A recipient that parses a timestamp value in an HTTP header field &MUST;
+   accept all three formats. A sender &MUST; generate the IMF-fixdate
+   format when sending an HTTP-date value in a header field.
+</t>
+<t>
+   An HTTP-date value represents time as an instance of Coordinated Universal
+   Time (UTC). The first two formats indicate UTC by the three-letter
+   abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name;
+   values in the asctime format are assumed to be in UTC.
+   A sender that generates HTTP-date values from a local clock ought to use
+   NTP (<xref target="RFC1305"/>) or some similar protocol to synchronize its
+   clock to UTC.
+</t>
 <t anchor="preferred.date.format">
-  <x:anchor-alias value="rfc1123-date"/>
+  <x:anchor-alias value="IMF-fixdate"/>
   <x:anchor-alias value="time-of-day"/>
   <x:anchor-alias value="hour"/>
@@ -3554 +3559 @@
   Preferred format:
 </t>
-<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/>
-  <x:ref>rfc1123-date</x:ref> = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
-  ; fixed length subset of the format defined in
-  ; <xref target="RFC1123" x:fmt="of" x:sec="5.2.14"/>
+<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="IMF-fixdate"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/>
+  <x:ref>IMF-fixdate</x:ref>  = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
+  ; fixed length/zone subset of the format defined in
+  ; <xref target="RFC5322" x:fmt="of" x:sec="3.3"/>
   
   <x:ref>day-name</x:ref>     = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive
@@ -3585 +3590 @@
   <x:ref>year</x:ref>         = 4<x:ref>DIGIT</x:ref>
 
-  <x:ref>GMT</x:ref>   = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive
+  <x:ref>GMT</x:ref>          = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive
 
   <x:ref>time-of-day</x:ref>  = <x:ref>hour</x:ref> ":" <x:ref>minute</x:ref> ":" <x:ref>second</x:ref>
-                 ; 00:00:00 - 23:59:59
+               ; 00:00:00 - 23:59:60 (leap second)
                  
   <x:ref>hour</x:ref>         = 2<x:ref>DIGIT</x:ref>               
@@ -3594 +3599 @@
   <x:ref>second</x:ref>       = 2<x:ref>DIGIT</x:ref>               
 </artwork></figure>
-<t>
-  The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>,
-  <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref> are the
-  same as those defined for the RFC 5322 constructs
-  with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).
-</t>
 <t anchor="obsolete.date.formats">
   <x:anchor-alias value="obs-date"/>
@@ -3616 +3615 @@
   <x:ref>rfc850-date</x:ref>  = <x:ref>day-name-l</x:ref> "," <x:ref>SP</x:ref> <x:ref>date2</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
   <x:ref>date2</x:ref>        = <x:ref>day</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref>
-                 ; day-month-year (e.g., 02-Jun-82)
-
-  <x:ref>day-name-l</x:ref>   = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive
-         / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive
+               ; e.g., 02-Jun-82
+
+  <x:ref>day-name-l</x:ref>   = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence>    ; "Monday", case-sensitive
+         / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence>       ; "Tuesday", case-sensitive
          / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive
-         / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive
-         / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive
-         / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive
-         / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive
+         / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence>    ; "Thursday", case-sensitive
+         / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence>          ; "Friday", case-sensitive
+         / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence>    ; "Saturday", case-sensitive
+         / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence>          ; "Sunday", case-sensitive
 </artwork></figure>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/>
   <x:ref>asctime-date</x:ref> = <x:ref>day-name</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
   <x:ref>date3</x:ref>        = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> / ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> ))
-                 ; month day (e.g., Jun  2)
+               ; e.g., Jun  2
 </artwork></figure>
 <t>
@@ -3635 +3634 @@
    A sender &MUST-NOT; generate additional whitespace in an HTTP-date beyond
    that specifically included as SP in the grammar.
-</t>
-<t>
-   Recipients that parse a date value &MUST; accept all three formats (for
-   compatibility with HTTP/1.0). A sender &MUST; only generate the RFC 1123
-   format when sending HTTP-date values in header fields.
-</t>
-<x:note>
-  <t>
-    &Note; Recipients of date values are encouraged to be robust in
-    accepting date values that might have been sent by non-HTTP
-    applications, as is sometimes the case when retrieving or posting
-    messages via proxies/gateways to SMTP or NNTP.
-  </t>
-</x:note>
+   The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>,
+   <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref>
+   are the same as those defined for the Internet Message Format constructs
+   with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).
+</t>
+<t>
+   Recipients of a timestamp value in rfc850-date format, which uses a
+   two-digit year, &SHOULD; interpret a timestamp that appears to be more
+   than 50 years in the future as representing the most recent year in the
+   past that had the same last two digits.
+</t>
+<t>
+   Recipients of timestamp values are encouraged to be robust in parsing
+   timestamps unless otherwise restricted by the field definition.
+   For example, messages are occasionally forwarded over HTTP from a non-HTTP
+   source that might generate any of the date and time specifications defined
+   by the Internet Message Format.
+</t>
 <x:note>
   <t>
     &Note; HTTP requirements for the date/time stamp format apply only
-    to their usage within the protocol stream. Clients and servers are
+    to their usage within the protocol stream. Implementations are
     not required to use these formats for user presentation, request
     logging, etc.
@@ -3666 +3669 @@
    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"/>,
-   though a sender &MUST; generate a Date value in the rfc1123-date format.
+   The field value is an HTTP-date, as defined in <xref target="http.date"/>.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Date"/>
@@ -3687 +3689 @@
 <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.
+   clock capable of providing a reasonable approximation of the current
+   instance in Coordinated Universal 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>
@@ -5198 +5201 @@
 </reference>
 
-<reference anchor="RFC1123">
-  <front>
-    <title>Requirements for Internet Hosts - Application and Support</title>
-    <author initials="R." surname="Braden" fullname="Robert Braden">
-      <organization>University of Southern California (USC), Information Sciences Institute</organization>
-      <address><email>Braden@ISI.EDU</email></address>
-    </author>
-    <date month="October" year="1989"/>
-  </front>
-  <seriesInfo name="STD" value="3"/>
-  <seriesInfo name="RFC" value="1123"/>
+<reference anchor="RFC1305">
+ <front>
+   <title>Network Time Protocol (Version 3) Specification, Implementation</title>
+   <author fullname="David L. Mills" initials="D." surname="Mills">
+     <organization>University of Delaware, Electrical Engineering Department</organization>
+     <address><email>mills@udel.edu</email></address>
+   </author>
+   <date month="March" year="1992" />
+ </front>
+ <seriesInfo name="RFC" value="1305" />
 </reference>
 
@@ -5993 +5995 @@
 <x:ref>GMT</x:ref> = %x47.4D.54 ; GMT
 
-<x:ref>HTTP-date</x:ref> = rfc1123-date / obs-date
+<x:ref>HTTP-date</x:ref> = IMF-fixdate / obs-date
+
+<x:ref>IMF-fixdate</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
 
 <x:ref>Location</x:ref> = URI-reference
@@ -6087 +6091 @@
 <x:ref>qvalue</x:ref> = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
 
-<x:ref>rfc1123-date</x:ref> = day-name "," SP date1 SP time-of-day SP GMT
 <x:ref>rfc850-date</x:ref> = day-name-l "," SP date2 SP time-of-day SP GMT
 

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

@@ -452 +452 @@
   } 
   @bottom-center {
-       content: "Expires July 6, 2013"; 
+       content: "Expires July 8, 2013"; 
   } 
   @bottom-right {
@@ -498 +498 @@
       <meta name="dct.creator" content="Reschke, J. F.">
       <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
-      <meta name="dct.issued" scheme="ISO8601" content="2013-01-02">
+      <meta name="dct.issued" scheme="ISO8601" content="2013-01-04">
       <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. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.">
@@ -524 +524 @@
             </tr>
             <tr>
-               <td class="left">Expires: July 6, 2013</td>
+               <td class="left">Expires: July 8, 2013</td>
                <td class="right">J. Reschke, Editor</td>
             </tr>
@@ -533 +533 @@
             <tr>
                <td class="left"></td>
-               <td class="right">January 2, 2013</td>
+               <td class="right">January 4, 2013</td>
             </tr>
          </tbody>
@@ -559 +559 @@
          in progress”.
       </p>
-      <p>This Internet-Draft will expire on July 6, 2013.</p>
+      <p>This Internet-Draft will expire on July 8, 2013.</p>
       <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
       <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
@@ -894 +894 @@
          which response to use.
       </p>
-      <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use. A cache, especially a shared cache, <em class="bcp14">SHOULD</em> use a mechanism, such as NTP <a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>, to synchronize its clock with a reliable external standard.
+      <p id="rfc.section.4.p.7">A cache that does not have a clock available <em class="bcp14">MUST NOT</em> use stored responses without revalidating them on every use.
       </p>
       <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="expiration.model" href="#expiration.model">Freshness Model</a></h2>
@@ -957 +957 @@
       </div>
       <h3 id="rfc.section.4.1.3"><a href="#rfc.section.4.1.3">4.1.3</a>&nbsp;<a id="age.calculations" href="#age.calculations">Calculating Age</a></h3>
-      <p id="rfc.section.4.1.3.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 id="rfc.section.4.1.3.p.1">The <a href="#header.age" class="smpl">Age</a> header field is used to convey an estimated age of the response message when obtained from a cache. The Age field value is
+         the cache's estimate of the number of seconds 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.4.1.3.p.2">The following data is used for the age calculation:</p>
@@ -972 +972 @@
       </p>
       <ul class="empty">
-         <li>HTTP/1.1 requires origin servers to send a <a href="p2-semantics.html#header.date" class="smpl">Date</a> header field, if possible, with every response, giving the time at which the response was generated. The term "date_value"
-            denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
+         <li>The term "date_value" denotes the value of the Date header field, in a form appropriate for arithmetic operations. See <a href="p2-semantics.html#header.date" title="Date">Section 7.1.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a> for the definition of the Date header field, and for requirements regarding responses without it.
          </li>
       </ul>
@@ -979 +978 @@
       </p>
       <ul class="empty">
-         <li>The term "now" means "the current value of the clock at the host performing the calculation". A cache <em class="bcp14">SHOULD</em> use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.2"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to a globally accurate time standard.
+         <li>The term "now" means "the current value of the clock at the host performing the calculation". A host ought to use NTP (<a href="#RFC1305" id="rfc.xref.RFC1305.1"><cite title="Network Time Protocol (Version 3) Specification, Implementation">[RFC1305]</cite></a>) or some similar protocol to synchronize its clocks to Coordinated Universal Time.
          </li>
       </ul>
@@ -1017 +1016 @@
       <p id="rfc.section.4.1.3.p.15"> </p>
       <ul>
-         <li>Recipients <em class="bcp14">SHOULD</em> assume that an RFC-850 date appearing to be more than 50 years in the future is in fact in the past (this helps solve the
-            "year 2000" problem).
-         </li>
-         <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 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>Recipients <em class="bcp14">MUST</em> perform all expiration-related calculations in GMT. The local time zone <em class="bcp14">MUST NOT</em> influence the calculation or comparison of an age or expiration time.
-         </li>
-         <li>Caches <em class="bcp14">SHOULD</em> consider dates with time zones other than "GMT" invalid.
+         <li>Although all date formats are specified to be case-sensitive, cache recipients <em class="bcp14">SHOULD</em> match day, week and timezone names case-insensitively.
+         </li>
+         <li>If a cache recipient's internal implementation of time has less resolution than the value of an HTTP-date, the recipient <em class="bcp14">MUST</em> internally represent a parsed <a href="#header.expires" class="smpl">Expires</a> date as the nearest time equal to or earlier than the received value.
+         </li>
+         <li>Cache recipients <em class="bcp14">MUST NOT</em> allow local time zones to influence the calculation or comparison of an age or expiration time.
+         </li>
+         <li>Cache recipients <em class="bcp14">SHOULD</em> consider a date with a zone abbreviation other than "GMT" to be invalid for calculating expiration.
          </li>
       </ul>
@@ -1423 +1419 @@
          that time.
       </p>
-      <p id="rfc.section.7.3.p.3">The field-value is an absolute date and time as defined by HTTP-date in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>; a sender <em class="bcp14">MUST</em> use the rfc1123-date format.
+      <p id="rfc.section.7.3.p.3">The Expires value is an HTTP-date timestamp, as defined in <a href="p2-semantics.html#http.date" title="Date/Time Formats">Section 7.1.1.1</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>.
       </p>
       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  <a href="#header.expires" class="smpl">Expires</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
 </pre><div id="rfc.figure.u.10"></div> 
       <p>For example</p>  <pre class="text">  Expires: Thu, 01 Dec 1994 16:00:00 GMT
-</pre><p id="rfc.section.7.3.p.6">A cache <em class="bcp14">MUST</em> treat other invalid date formats, especially including the value "0", as in the past (i.e., "already expired").
-      </p>
-      <div class="note" id="rfc.section.7.3.p.7"> 
-         <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.max-age" title="max-age">Section&nbsp;7.2.2.7</a>), that directive overrides the Expires field. Likewise, the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.8</a>) overrides the <a href="#header.expires" class="smpl">Expires</a> header field in shared caches.
-         </p> 
-      </div>
-      <p id="rfc.section.7.3.p.8">Historically, HTTP required the Expires field-value to be no more than a year in the future. While longer freshness lifetimes
+</pre><p id="rfc.section.7.3.p.6">A cache recipient <em class="bcp14">MUST</em> interpret invalid date formats, especially the value "0", as representing a time in the past (i.e., "already expired").
+      </p>
+      <p id="rfc.section.7.3.p.7">If a response includes a <a href="#header.cache-control" class="smpl">Cache-Control</a> field with the max-age directive (<a href="#cache-response-directive.max-age" title="max-age">Section&nbsp;7.2.2.7</a>), a recipient <em class="bcp14">MUST</em> ignore the Expires field. Likewise, if a response includes the s-maxage directive (<a href="#cache-response-directive.s-maxage" title="s-maxage">Section&nbsp;7.2.2.8</a>), a shared cache recipient <em class="bcp14">MUST</em> ignore the Expires field. In both these cases, the value in Expires is only intended for recipients that have not yet implemented
+         the Cache-Control field.
+      </p>
+      <p id="rfc.section.7.3.p.8">An origin server without a clock <em class="bcp14">MUST NOT</em> generate an Expires field unless its value represents a fixed time in the past (always expired) or its value has been associated
+         with the resource by a system or user with a reliable clock.
+      </p>
+      <p id="rfc.section.7.3.p.9">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 time values), and many caches will evict a response far sooner than that.
-      </p>
-      <p id="rfc.section.7.3.p.9">An origin server without a clock <em class="bcp14">MUST NOT</em> assign Expires values to a response unless these values were associated with the resource by a system or user with a reliable
-         clock. It <em class="bcp14">MAY</em> assign an Expires value that is known, at or before server configuration time, to be in the past (this allows "pre-expiration"
-         of responses without storing separate Expires values for each resource).
       </p>
       <div id="rfc.iref.p.5"></div>
@@ -2175 +2169 @@
             </li>
             <li><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul>
-                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4</a>, <a href="#rfc.xref.RFC1305.2">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
+                  <li><em>RFC1305</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC1305.1">4.1.3</a>, <a href="#RFC1305"><b>12.2</b></a></li>
                   <li><em>RFC2119</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2119.1">1.3</a>, <a href="#RFC2119"><b>12.1</b></a></li>
                   <li><em>RFC2616</em>&nbsp;&nbsp;<a href="#rfc.xref.RFC2616.1">4.1.2</a>, <a href="#RFC2616"><b>12.2</b></a><ul>

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

@@ -527 +527 @@
 <t>
    A cache that does not have a clock available &MUST-NOT; use stored
-   responses without revalidating them on every use. A cache, especially a
-   shared cache, &SHOULD; use a mechanism, such as NTP <xref
-   target="RFC1305"/>, to synchronize its clock with a reliable external
-   standard.
+   responses without revalidating them on every use.
 </t>
 
@@ -659 +656 @@
 <section anchor="age.calculations" title="Calculating Age">
 <t>
-   HTTP/1.1 uses the <x:ref>Age</x:ref> header field to convey the estimated
+   The <x:ref>Age</x:ref> header field is used to convey an 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
+   is the cache's estimate of the number of seconds 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
@@ -684 +681 @@
    <list>
       <t>
-         HTTP/1.1 requires origin servers to send a <x:ref>Date</x:ref> header
-         field, if possible, with every response, giving the time at which the
-         response was generated. The term "date_value" denotes the value of
+         The term "date_value" denotes the value of
          the Date header field, in a form appropriate for arithmetic
          operations. See &header-date; for the definition of the Date header
@@ -698 +693 @@
       <t>
          The term "now" means "the current value of the clock at the host
-         performing the calculation". A cache &SHOULD; use NTP (<xref
+         performing the calculation". A host ought to use NTP (<xref
          target="RFC1305"/>) or some similar protocol to synchronize its
-         clocks to a globally accurate time standard.
+         clocks to Coordinated Universal Time.
       </t>
    </list>
@@ -766 +761 @@
 <t>
   <list style="symbols">
-     <t>Recipients &SHOULD; assume that an RFC-850 date
-        appearing to be more than 50 years in the future is in fact
-        in the past (this helps solve the "year 2000" problem).</t>
-
      <t>Although all date formats are specified to be case-sensitive, 
-        recipients &SHOULD; match day, week and timezone names
+        cache recipients &SHOULD; match day, week and timezone names
         case-insensitively.</t>
              
-     <t>An implementation &MAY; internally represent a parsed
-        <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>
-
-     <t>Recipients &MUST; perform all expiration-related calculations in GMT.
-        The local time zone &MUST-NOT; influence the calculation or comparison
-        of an age or expiration time.</t>
-
-     <t>Caches &SHOULD; consider dates with time zones other than "GMT"
-        invalid.</t>
+     <t>If a cache recipient's internal implementation of time has less
+        resolution than the value of an HTTP-date, the recipient &MUST;
+        internally represent a parsed <x:ref>Expires</x:ref> date as the
+        nearest time equal to or earlier than the received value.</t>
+
+     <t>Cache recipients &MUST-NOT; allow local time zones to influence the
+        calculation or comparison of an age or expiration time.</t>
+
+     <t>Cache recipients &SHOULD; consider a date with a zone abbreviation
+        other than "GMT" to be invalid for calculating expiration.</t>
   </list>
 </t>
@@ -1592 +1582 @@
 </t>
 <t>
-   The field-value is an absolute date and time as defined by HTTP-date in
-   &http-date;; a sender &MUST; use the rfc1123-date format.
+   The Expires value is an HTTP-date timestamp, as defined in &http-date;.
 </t>
 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Expires"/>
@@ -1604 +1593 @@
 </artwork></figure>
 <t>
-   A cache &MUST; treat other invalid date formats,
-   especially including the value "0", as in the past (i.e., "already
-   expired").
-</t>
-<x:note>
-   <t>
-       &Note; If a response includes a <x:ref>Cache-Control</x:ref> field with
-       the max-age directive (see <xref target="cache-response-directive.max-age" />),
-       that directive overrides the Expires field. Likewise, the s-maxage
-       directive (<xref target="cache-response-directive.s-maxage" />) overrides
-       the <x:ref>Expires</x:ref> header field in shared caches.
-   </t>
-</x:note>
+   A cache recipient &MUST; interpret invalid date formats, especially the
+   value "0", as representing a time in the past (i.e., "already expired").
+</t>
+<t>
+   If a response includes a <x:ref>Cache-Control</x:ref> field with
+   the max-age directive (<xref target="cache-response-directive.max-age"/>),
+   a recipient &MUST; ignore the Expires field.
+   Likewise, if a response includes the s-maxage directive
+   (<xref target="cache-response-directive.s-maxage" />), a shared cache
+   recipient &MUST; ignore the Expires field. In both these cases, the value
+   in Expires is only intended for recipients that have not yet implemented
+   the Cache-Control field.
+</t>
+<t>
+   An origin server without a clock &MUST-NOT; generate an Expires field
+   unless its value represents a fixed time in the past (always expired)
+   or its value has been associated with the resource by a system or user
+   with a reliable clock.
+</t>
 <t>
    Historically, HTTP required the Expires field-value to be no more than a 
@@ -1624 +1619 @@
    time values), and many caches will evict a response far sooner than 
    that.
-</t>
-<t>
-   An origin server without a clock &MUST-NOT; assign Expires
-   values to a response unless these values were associated
-   with the resource by a system or user with a reliable clock. It &MAY;
-   assign an Expires value that is known, at or before server
-   configuration time, to be in the past (this allows "pre-expiration"
-   of responses without storing separate Expires values for each
-   resource).
 </t>
 </section>