W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

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

From: John C Klensin <john-ietf@jck.com>
Date: Mon, 28 Oct 2013 15:22:16 -0400
To: Julian Reschke <julian.reschke@gmx.de>, S Moonesamy <sm+ietf@elandsys.com>, apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org
cc: ietf@ietf.org, iesg@ietf.org, ietf-http-wg@w3.org
Message-ID: <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com>


--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.  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.

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.

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.

If the WG has considered these options and rejected them after
an open discusssion, please ignore the comment/ suggestion.

> And yes, it would have been nice if a same date format would
> have been chosen back then.

Yes, even for the mail header syntax that inspired the current
form and that predates the web by more than a decade.  But that
was before there was an ISO Standard, few of us were worried
about the year 2000 transition, etc.  My practical concern is
that, as we internationalize more, those perfectly
well-specified ASCII month and day names will get mapped, by
implementations who consider the local (and sometimes paying)
customers far more important than any standard, into local names
that no one else can read.   That would be fine if the local
forms stayed local, but we have lots of experience, including
with email, to indicate that they will leak and cause at least
user confusion if not interoperability problems.

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.

  best,
   john


   john
Received on Monday, 28 October 2013 19:22:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:18 UTC