- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 28 Oct 2013 15:24:56 +0100
- To: John C Klensin <john-ietf@jck.com>, S Moonesamy <sm+ietf@elandsys.com>, apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org
- CC: ietf@ietf.org, iesg@ietf.org, ietf-http-wg@w3.org
On 2013-10-28 15:22, John C Klensin wrote: > --On Monday, October 28, 2013 15:00 +0100 Julian Reschke > <julian.reschke@gmx.de> wrote: > >> On 2013-10-28 09:07, S Moonesamy wrote: >>> ... >>> In Section 7.1.1: >>> >>> "The preferred format is a fixed-length and single-zone >>> subset of the date and time specification used by the >>> Internet Message Format [RFC5322]" >> ... >> Actually, HTTPbis has its own obs-date: >> >> obs-date = rfc850-date / asctime-date >> >> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semant >> ics-24.html#rfc.section.7.1.1.1> > > Julian, > > I've been reluctant to step into this mess, but, having had > another bad experience over the weekend, and with the > understanding that we already have multiple "obsolete" forms > floating around that implementations are supposed to recognize, > I'd like to see if it is still possible to think about moving to > an ISO-compatible "preferred form" that would eliminate the > difficulty in handling and ambiguities in month names (and the > frequent violations where they are made upper-case or translated > into local languages). Doing so, and getting rid of "GMT" > (which about half the world's population seems to think is a > synonym for whatever time is being used around Greenwich), in > favor of UT (which no one who has any understanding at all seems > to think might change in the summer), would save a lot of > problems long-term. That would make the preferred form > > [day-name ","] year "-" monthNumber "-" day SP time-of-day SP > "UT" > > with > monthNumber = 2DIGIT > > and > obs-date = rfc850-date / asctime-date / IMF-fixdate > if that is necessary. > > I don't care whether day-name is optional or not, but there > would be some small i18n charm in saying "either write it the > way the spec says or leave it out" rather than the current rule, > which is effectively "use those English-based abbreviations no > matter how obnoxious they are in your environment". > > It is obviously late to be suggesting this, but it was also late > a dozen years ago and will be a lot later five or ten years > hence. > ... John, that change would make almost every HTTP/1.1 code ever written non-compliant. And yes, it would have been nice if a same date format would have been chosen back then. Best regards, Julian
Received on Monday, 28 October 2013 14:25:27 UTC