Re: [hybi] workability (or otherwise) of HTTP upgrade

Maciej Stachowiak <mjs@apple.com> Tue, 07 December 2010 23:46 UTC

Return-Path: <mjs@apple.com>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66DDC3A68B5 for <hybi@core3.amsl.com>; Tue, 7 Dec 2010 15:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -107.241
X-Spam-Level:
X-Spam-Status: No, score=-107.241 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsSnq51DERsk for <hybi@core3.amsl.com>; Tue, 7 Dec 2010 15:46:33 -0800 (PST)
Received: from mail-out4.apple.com (mail-out4.apple.com [17.254.13.23]) by core3.amsl.com (Postfix) with ESMTP id 47F533A6881 for <hybi@ietf.org>; Tue, 7 Dec 2010 15:46:33 -0800 (PST)
Received: from relay14.apple.com (relay14.apple.com [17.128.113.52]) by mail-out4.apple.com (Postfix) with ESMTP id AE32EC23DB0A for <hybi@ietf.org>; Tue, 7 Dec 2010 15:47:59 -0800 (PST)
X-AuditID: 11807134-b7c51ae000005439-e4-4cfec7aff249
Received: from et.apple.com (et.apple.com [17.151.62.12]) by relay14.apple.com (Apple SCV relay) with SMTP id FF.2F.21561.FA7CEFC4; Tue, 7 Dec 2010 15:47:59 -0800 (PST)
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_J8UmbD3Rkud8i5RQV1Wf0A)"
Received: from [17.72.146.17] by et.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0LD300NA00RV2L30@et.apple.com> for hybi@ietf.org; Tue, 07 Dec 2010 15:47:59 -0800 (PST)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <C51C08FD-989E-43AC-A17B-EA4483CC2F9C@mnot.net>
Date: Tue, 07 Dec 2010 15:47:54 -0800
Message-id: <CF412E56-591F-46F4-AC45-F21D40E30CC9@apple.com>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <20101126000352.ad396b9a.eric@bisonsystems.net> <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com> <BB947F6D-15AA-455D-B830-5E12C80C1ACD@mnot.net> <81870DB1-B177-4253-8233-52C4168BE99D@apple.com> <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net> <57D4B885-B1D8-482F-8747-6460C0FFF166@apple.com> <37A00E8D-B55C-49AD-A85C-A299C80FFF17@mnot.net> <4F2580A7-79C2-4B0A-BCE5-7FB6D9AA0ED7@apple.com> <C51C08FD-989E-43AC-A17B-EA4483CC2F9C@mnot.net>
To: Mark Nottingham <mnot@mnot.net>
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
Cc: hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 23:46:34 -0000

On Dec 7, 2010, at 2:53 AM, Mark Nottingham wrote:

> 
> On 07/12/2010, at 6:04 PM, Maciej Stachowiak wrote:
> 
> 
>> It's also worth noting that operating over ports 80/443 and coexisting with an HTTP server are goals that come from our charter and requirements document, so abandoning those goals would likely require a major reboot of the group.
> 
> No, the charter says nothing about what port(s) the protocol will run over. The requirements you refer to are a -01 draft, so they don't represent IETF consensus. Have there been any WG consensus calls on them?

Not on the whole document, but there have been consensus calls on specific items in the draft, notably including the "share a port" item and the related concept of http compatibility.

> 
>> We already have implementors impatient to see a production-shippable protocol, it doesn't seem so great to me to go back to the drawing board.
> 
> 
> AIUI changing the handshake is already the subject of a lot of discussion, so this is hardly "going back to the drawing board."
> 
> I fully agree we need to unblock this discussion and ship a protocol. I'm trying to understand why people are digging in their heels on a design that's supposed to be helping server deployment, when AFAICT the server folks are telling them it's not workable.

The main complaint about CONNECT from server folks seems to be literally a question of semantics. There is also the related practical issue of having to turn off alerts on CONNECT attempts if you want to serve WebSocket.

If there are other proposals that would work better and serve the same use cases, that would be useful input to the conversation. "Don't try to share a port with a Web server" is not a sufficiently fleshed out proposal to move the conversation forward, and does break some use cases that were identified as desirable. If someone cares to present a more concrete proposal, we'd be in a position to evaluate the tradeoffs.

Regards,
Maciej