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