- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sun, 17 May 2009 13:56:48 +0200
- To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
- CC: Brian Smith <brian@briansmith.org>, 'Geoffrey Sneddon' <foolistbar@googlemail.com>, 'HTTP Working Group' <ietf-http-wg@w3.org>
Julian Reschke wrote:
> Martin J. Dürst wrote:
>> That seems to be backward. Wouldn't the comments be helpful in the
>> collected ABNF, too?
>
> The collected ABNF is produced by an ABNF parser (Bill Fenner's), by
> serializing the rule objects it generates. Thus, it doesn't have the
> comments anymore.
> ...
In the meantime I noticed that BAP (Bill Fenner's ABNF Parser) can
automatically generate comments for printable byte sequences; with that
feature turned on the generated ABNF is readable enough without the
extra productions.
See <http://trac.tools.ietf.org/wg/httpbis/trac/changeset/582>. The
section now reads:
-- snip --
3.2. Date/Time Formats: Full Date
HTTP applications have historically allowed three different formats
for the representation of date/time stamps:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
The first format is preferred as an Internet standard and represents
a fixed-length subset of that defined by [RFC1123]. The other
formats are described here only for compatibility with obsolete
implementations. HTTP/1.1 clients and servers that parse the 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. See Appendix A for
further information.
All HTTP date/time stamps MUST be 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 MUST be assumed when reading the
asctime format. HTTP-date is case sensitive and MUST NOT include
additional whitespace beyond that specifically included as SP in the
grammar.
HTTP-date = rfc1123-date / obs-date
Preferred format:
rfc1123-date = day-name "," SP date1 SP time-of-day SP GMT
day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year
; e.g., 02 Jun 1982
day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT
GMT = %x47.4D.54 ; "GMT", case-sensitive
time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:59
hour = 2DIGIT
minute = 2DIGIT
second = 2DIGIT
The semantics of day-name, day, month, year, and time-of-day are the
same as those defined in the RFC 5322 constructs with the
corresponding name ([RFC5322], Section 3.3).
Obsolete formats:
obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
day-name-l = %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
asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; month day (e.g., Jun 2)
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been sent by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
Note: 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.
-- snip --
BR, Julian
Received on Sunday, 17 May 2009 11:57:45 UTC