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

On 29/10/2013 8:22 a.m., John C Klensin wrote:
>
> --On Monday, October 28, 2013 15:24 +0100 Julian Reschke
> <julian.reschke@gmx.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

Received on Tuesday, 29 October 2013 01:27:02 UTC