Re: obs-date, was: [apps-discuss] APPSDIR review, etc.

[S Moonesamy <[e-mail]>]

At 12:22 28-10-2013, John C Klensin wrote:
>My understanding is that the HTTPbis work is a rather major
>revision with at least some cases for which "get it right" is
>more important that complete backward compatibility, especially
>if there is a clear migration path.  All of the usual arguments
>for that are relevant, especially the ones that focus on how
>many implementations and pages are likely to be created in the
>future relative to those that exist today.   Here, the clear
>migration path would be a narrow and restrictive "send syntax"
>and a permissive "receive syntax" that requires support of all
>known older forms, _especially_ those that were recommended by
>HTTP 1.1.

Yes.

>So, from my point of view, this isn't about introducing an
>incompatibility with something that one merely regrets not being
>done differently.  It is rather more about what might be the
>last chance to get it right and, in the process, eliminate
>completely predictable future confusion and interoperability
>problems.

The argument is about code complexity versus what the working group 
charter says.  It is difficult to review a specification when the 
current specification is still referencing RFC 822.  I don't recall 
whether there are any other application-related specifications using 
"GMT".  The HTTPbis drafts discusses about "GMT" when it actually means "UTC".

At 18:26 28-10-2013, Amos Jeffries wrote:
>However it is important to note that there is no clear migration path. Many
>implementations are actively *rejecting* or ignoring date formats which do
>not include the "GMT" moniker.

That can be a problem.

>Indeed. This option was considered by the WG several times as people keep
>bringing up this same point. (I myself even a few  years back). The WG charter
>is explicitly prohibiting addition of a new version number in these documents
>so there are several things like this which have had to be left unchanged.

People usually keep bringing up the same point when a choice is not 
documented.  I read what John Klensin wrote as during each revision 
of the specification the above argument is used to avoid making a change.

Regards,
S. Moonesamy