ietf
[Top] [All Lists]

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

2013-10-30 03:45:51
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
<Prev in Thread] Current Thread [Next in Thread>