- From: S Moonesamy <sm+ietf@elandsys.com>
- Date: Tue, 29 Oct 2013 23:26:12 -0700
- To: John C Klensin <john-ietf@jck.com>, Amos Jeffries <squid3@treenet.co.nz>
- Cc: apps-discuss@ietf.org, draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, ietf@ietf.org, ietf-http-wg@w3.org
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
Received on Wednesday, 30 October 2013 08:45:38 UTC