Re: obs-date, was: [apps-discuss] APPSDIR review, etc.
S Moonesamy <sm+ietf@elandsys.com> Wed, 30 October 2013 08:43 UTC
Return-Path: <sm@elandsys.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B5211E8102; Wed, 30 Oct 2013 01:43:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.177
X-Spam-Level:
X-Spam-Status: No, score=-103.177 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mmiVvGBRW8c; Wed, 30 Oct 2013 01:43:45 -0700 (PDT)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A33311E8272; Wed, 30 Oct 2013 01:43:20 -0700 (PDT)
Received: from SUBMAN.elandsys.com ([197.224.128.39]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r9U8gxjw013206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Oct 2013 01:43:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1383122598; bh=e1hoBZoErs6MEj9SLtqH4TRp+V6cTqky8NNWEeQOBPk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=jdr/w7MRlZs08qNk0V6NT2bQtrGTWO5AR4/8hCaMlCTzqMTdB9UsSAalAkhhRbsJv E036U6rQQSoE+WxnUqyzgIyxDNMrL18gGoprALbPl7ZtPTkLncCwRMRWNhkpGeGHnQ exTvUu84D8W042ZdJaadNm0nvNs5889JdEAzEvlY=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1383122598; i=@elandsys.com; bh=e1hoBZoErs6MEj9SLtqH4TRp+V6cTqky8NNWEeQOBPk=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=im7v1pyPFXMX0IR8PlgiAyxowYjQ15MbBcsvktRme7X0v5hfKS2IttO0xFGAziJKM V+SxJuvvTO6/7kpMXrEAZ3Q0uybtxmuQEPL7Lv248RMWJhLXK6R1bji4oHZLV/TGwN 3O2rjVY+hGsYj9KGpJ4t+Ygb68cMupGvrqKXYYQQ=
Message-Id: <6.2.5.6.2.20131029223814.0ce8c880@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Tue, 29 Oct 2013 23:26:12 -0700
To: John C Klensin <john-ietf@jck.com>, Amos Jeffries <squid3@treenet.co.nz>
From: S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: obs-date, was: [apps-discuss] APPSDIR review, etc.
In-Reply-To: <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <526F0EC1.7010809@treenet.co.nz>
References: <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <6.2.5.6.2.20131027115007.07e32210@elandnews.com> <526E6DF4.4030509@gmx.de> <751EE3ED19D0A62BD858585C@JcK-HP8200.jck.com> <526E73B8.90705@gmx.de> <4F6568484E956ADBC46BEB16@JcK-HP8200.jck.com> <526F0EC1.7010809@treenet.co.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Cc: draft-ietf-httpbis-p2-semantics.all@tools.ietf.org, ietf@ietf.org, apps-discuss@ietf.org, ietf-http-wg@w3.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Oct 2013 08:43:46 -0000
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
- APPSDIR review of draft-ietf-httpbis-p2-semantics… S Moonesamy
- obs-date, was: [apps-discuss] APPSDIR review of d… Julian Reschke
- Re: obs-date, was: [apps-discuss] APPSDIR review … John C Klensin
- Re: obs-date, was: [apps-discuss] APPSDIR review … Julian Reschke
- IANA issues, was: APPSDIR review of draft-ietf-ht… Julian Reschke
- content inspection in absence of media type, was:… Julian Reschke
- Re: obs-date, was: [apps-discuss] APPSDIR review … John C Klensin
- Re: content inspection in absence of media type, … S Moonesamy
- Re: content inspection in absence of media type, … Julian Reschke
- Re: obs-date, was: [apps-discuss] APPSDIR review … Amos Jeffries
- Re: content inspection in absence of media type, … Barry Leiba
- Re: IANA issues, was: APPSDIR review of draft-iet… S Moonesamy
- Re: obs-date, was: [apps-discuss] APPSDIR review,… S Moonesamy
- Re: [apps-discuss] content inspection in absence … Martin J. Dürst
- Re: obs-date, was: [apps-discuss] APPSDIR review … Martin J. Dürst
- Re: [apps-discuss] content inspection in absence … Julian Reschke
- Re: content inspection in absence of media type, … S Moonesamy
- Re: IANA issues, was: APPSDIR review of draft-iet… Julian Reschke
- Re: content inspection in absence of media type, … Mark Nottingham
- Re: [apps-discuss] content inspection in absence … Martin J. Dürst
- Re: content inspection in absence of media type, … S Moonesamy
- RE: [apps-discuss] content inspection in absence … Larry Masinter
- Re: [apps-discuss] content inspection in absence … Henry S. Thompson