Changeset 2077 for draft-ietf-httpbis

Timestamp:

01/01/13 05:58:52 (9 years ago)

Author:

fielding@…

Message:

(editorial) another attempt to explain GMT as UTC

Location:

draft-ietf-httpbis/latest

Files:

• p2-semantics.html (modified) (4 diffs)
• p2-semantics.xml (modified) (3 diffs)

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

@@ -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 applications have 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 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
@@ -2811 +2811 @@
       <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/1.1 clients and servers that parse a date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields.
-      </p>
-      <p id="rfc.section.7.1.1.1.p.6">All HTTP date/time stamps are represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is
-         exactly equal to UTC (Coordinated Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as
-         the three-letter abbreviation for time zone, and is assumed when reading the asctime format. 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.
+</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.8">                    Preferred format:</p>
+         <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>
@@ -2860 +2856 @@
   <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.10">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>).
+</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.11">              Obsolete formats:</p>
+         <p id="rfc.section.7.1.1.1.p.10">              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> 
@@ -2880 +2876 @@
   <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><div class="note" id="rfc.section.7.1.1.1.p.15"> 
+</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.
+      </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.16"> 
+      <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.

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

@@ -3512 +3512 @@
   <x:anchor-alias value="HTTP-date"/>
 <t>
-   HTTP applications have historically allowed three different formats
+   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"/>:
@@ -3528 +3528 @@
 </artwork></figure>
 <t>
-   HTTP/1.1 clients and servers that parse a date value &MUST; accept
-   all three formats (for compatibility with HTTP/1.0), though they &MUST;
-   only generate the RFC 1123 format for representing HTTP-date values
-   in header fields.
-</t>
-<t>
-   All HTTP date/time stamps are represented in Greenwich Mean Time
-   (GMT), without exception. For the purposes of HTTP, GMT is exactly
-   equal to UTC (Coordinated Universal Time). This is indicated in the
-   first two formats by the inclusion of "GMT" as the three-letter
-   abbreviation for time zone, and is assumed when reading the
-   asctime format. HTTP-date is case sensitive. A sender &MUST-NOT; generate
-   additional whitespace in an HTTP-date beyond that specifically included as
-   SP in the grammar.
+   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"/>
@@ -3636 +3627 @@
                  ; month day (e.g., Jun  2)
 </artwork></figure>
+<t>
+   HTTP-date is case sensitive.
+   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>