Re: Call for Adoption: draft-hutton-httpbis-connect-protocol-00

Amos Jeffries <squid3@treenet.co.nz> Tue, 29 July 2014 11:16 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CC1F1A0351 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Jul 2014 04:16:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 89bZxLVOrBUC for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Jul 2014 04:16:42 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D302D1B27BD for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 29 Jul 2014 04:16:37 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XC5MV-0007NT-1A for ietf-http-wg-dist@listhub.w3.org; Tue, 29 Jul 2014 11:14:31 +0000
Resent-Date: Tue, 29 Jul 2014 11:14:31 +0000
Resent-Message-Id: <E1XC5MV-0007NT-1A@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XC5MI-0007Lm-4M for ietf-http-wg@listhub.w3.org; Tue, 29 Jul 2014 11:14:18 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XC5MH-0002Qo-3Z for ietf-http-wg@w3.org; Tue, 29 Jul 2014 11:14:18 +0000
Received: from [192.168.0.6] (121-99-61-110.bng1.tvc.orcon.net.nz [121.99.61.110]) by treenet.co.nz (Postfix) with ESMTP id BDA29E6FBD for <ietf-http-wg@w3.org>; Tue, 29 Jul 2014 23:13:47 +1200 (NZST)
Message-ID: <53D781E9.2070702@treenet.co.nz>
Date: Tue, 29 Jul 2014 23:13:45 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <7970206F-8A31-487D-B2FA-AB237BCDA14E@mnot.net>
In-Reply-To: <7970206F-8A31-487D-B2FA-AB237BCDA14E@mnot.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.418, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001
X-W3C-Scan-Sig: maggie.w3.org 1XC5MH-0002Qo-3Z f8da743b0733e6fff960de35b08ccae7
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: draft-hutton-httpbis-connect-protocol-00
Archived-At: <http://www.w3.org/mid/53D781E9.2070702@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26421
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 29/07/2014 6:38 p.m., Mark Nottingham wrote:
> <http://tools.ietf.org/html/draft-hutton-httpbis-connect-protocol-00>
> 
> In Toronto, we had a discussion about adopting this document as a WG document:
>   <https://github.com/httpwg/wg-materials/blob/gh-pages/ietf90/minutes.md#draft-hutton-httpbis-connect-protocol>
> 
> One concern raised there was regarding the model for the extension; i.e., by effectively making support for webrtc (or any other protocol) on proxy opt-in rather than opt-out, it may cause problems as more traffic goes over proxies. However, the HTTP folks in the room didn't seem to concerned about this, since bad actors were already able to (ab)use CONNECT tunnels with impunity (effectively.
> 
> Another concern briefly mentioned was that such an extension might inhibit protocol evolution; e.g., if a firewall whitelists what tunnelled protocols it accepts, it might be that we're stuck advertising "h2" in the future. However, there didn't seem to be strong concern here, since ALPN negotiation is a separate step, and HTTP can choose to omit this header when using CONNECT for its own purposes.
> 
> With that context in place, it seemed like there was general support in the room for adopting this spec. Does anyone else have additional thoughts / concerns? 
> 

I would also like to express interest and support for this.

We already have several outstanding requests from the Squid community
for features and protocol access controls this signal will enable.

Amos