- From: Brian Smith <brian@briansmith.org>
- Date: Fri, 8 May 2009 12:08:11 -0500
- To: "'Julian Reschke'" <julian.reschke@gmx.de>
- Cc: "'Geoffrey Sneddon'" <foolistbar@googlemail.com>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Julian Reschke wrote: > 3.2. Date/Time Formats > The first format is preferred as an Internet standard and > represents a fixed-length subset of that defined by > [RFC1123]. I still think it is misleading to refer to RFC1123 here when HTTP doesn't use the syntax or the semantics of RFC1123. Besides, the specification doesn't have to justify why the that syntax is preferred. The next paragraph already states that implementations MUST use it. I'd just delete that paragraph. I don't get why s-Mon, s-Jan, l-Mon, etc. are named productions (instead of unnamed alternatives like in RFC 5023), but that is not new to this change. The semantics of the obsolete date formats are not defined. How is a server supposed to interpret a 2-digit year? > asctime-date = day-name SP date3 SP time-of-day SP 4DIGIT > date2 = 2DIGIT "-" month "-" 2DIGIT > ; day-month-year (e.g., 02-Jun-82) Might as well use "day" and "year": asctime-date = day-name SP date3 SP time-of-day SP year date2 = day "-" month "-" 2DIGIT ; day-month-year (e.g., 02-Jun-82) > 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. Might as well delete this while you are at it. It is strange to single out that this one part of the HTTP syntax doesn't have to be used outside of the protocol, when that is generally true for all parts of the syntax. > While at it, we probably should also drop the surplus subsection 3.2.1 > and move all of this into 3.2 (this is a left-over from partitioning > RFC 2616). +1. - Brian
Received on Friday, 8 May 2009 17:08:51 UTC