Re: HTTP/2 has been approved

Jari Arkko <jari.arkko@piuha.net> Thu, 19 February 2015 19:31 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B2F1A00A8 for <ietf@ietfa.amsl.com>; Thu, 19 Feb 2015 11:31:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xC7oGBMMT7H for <ietf@ietfa.amsl.com>; Thu, 19 Feb 2015 11:31:06 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id B608E1A0016 for <ietf@ietf.org>; Thu, 19 Feb 2015 11:30:55 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 1433E2CC5F; Thu, 19 Feb 2015 21:30:55 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScUIO_gL_d82; Thu, 19 Feb 2015 21:30:54 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 8DE832CC4D; Thu, 19 Feb 2015 21:30:54 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_2BB333E5-9E35-43F0-A3ED-52B8E3E85657"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
Subject: Re: HTTP/2 has been approved
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <20423.1424358980@sandelman.ca>
Date: Thu, 19 Feb 2015 21:30:52 +0200
Message-Id: <B54E4D7B-26F3-4850-8AC0-E419A2DB56C4@piuha.net>
References: <96332FA9-9C09-4AD8-A76E-41593AA2652B@piuha.net> <20423.1424358980@sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/UbmEj4raEgqyP3NYhzIDFa4Jv7Y>
Cc: IETF Discussion List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 19 Feb 2015 19:31:08 -0000

Michael,

> It sure seems to me like those "implementation drafts" are what used to be
> called proposed standards.
> 
> What I see is a new step in the standardization process, along with a view
> that the step after internet-draft seems to include proven interoperability.
> 
> I propose that this document skip PS, and go straight to Internet Standard to
> accurately reflect the status of this document.

As others have noted, once there is real-world deployment and
not just implementations, we should consider that. Status of
various specifications should be accurately reflected.

But I want to take this discussion back to possibly more
relevant question of how we make standards. I think you
are asking if this level of ‘validation’ is a requirement or
even a desirable property of the standards process. And
I think we can immediately respond to the first question,
and respond indirectly to the second question.

There is absolutely no requirement anywhere that something
like this should be done in a particular standards effort. However,
I think it made in this particular case, and the WG chose to go
through this effort. I think that was a reasonable decision. In
general, I actually prefer to see more code and development
mixed as a part of the process of getting to standards. However,
it should not be a requirement, and whether that even make
sense in a particular situation should be up to the WG
and evaluated on a case-by-case basis.

Jari