Re: obs-date, was: [apps-discuss] APPSDIR review of draft-ietf-httpbis-p2-semantics-24

[Julian Reschke <[e-mail]>]

On 2013-10-28 15:22, John C Klensin wrote:
> --On Monday, October 28, 2013 15:00 +0100 Julian Reschke
> <[e-mail]> 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