On 29/10/2013 8:22 a.m., John C Klensin wrote:
--On Monday, October 28, 2013 15:24 +0100 Julian Reschke
<julian(_dot_)reschke(_at_)gmx(_dot_)de> wrote:
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.
Julian,
I don't know enough of the issues in enough detail to argue
this, and won't. My goal is only to be sure the question has
been asked.
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.
No. The focus on the WG has been to document what is actually *working*
and clarify existing HTTP behaviour in order to encourage interoperability.
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.
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.
It has been rather longer than I think we expected, but it was
clear when HTTP 1.1 was adopted (I am sure it was clear at least
to the relevant ADs) that there could be incompatible changes in
the future and that the concern should be a non-disruptive
migration path, not absolute forward compatibility. That is one
of the several reasons why the successor to HTTP 1.0 was
identified as HTTP 1.1, not HTTP 2.
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.
This sort of change would still make HTTP 1.1 implementations
non-compliant with HTTP 2.0, but that is ok -- they still comply
with HTTP 1.1 and I hope no one is going to claim that all HTTP
1.1 implementations are non-compliant with HTTP the day HTTP 2.0
is published.
Those existing 1.1 implementations will certainly not be compliant with 2.0
binary traffic encoding!
But mapping between 1.1 with its useless GMT / day-of-week and the new
improved 2.0 date format (whatever that may be) can be explicitly specified
for the 1.1<->2.0 gateway translations in the new 2.0 implementations
without altering 1.1 compliance for any existing or future implementations.
The WG has chosen this approach over attempting a difficult upgrade within
1.1 itself.
Amos