Re: [hybi] Formal declaration of consensus: HTTP Compliance

Mike Belshe <mike@belshe.com> Fri, 06 August 2010 21:20 UTC

Return-Path: <mike@belshe.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 33C3228C2C4 for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 14:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.676
X-Spam-Level:
X-Spam-Status: No, score=-1.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6]
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 2jySMAnuX4bn for <hybi@core3.amsl.com>; Fri, 6 Aug 2010 14:20:28 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 5934528C13A for <hybi@ietf.org>; Fri, 6 Aug 2010 13:51:39 -0700 (PDT)
Received: by pvg7 with SMTP id 7so135371pvg.31 for <hybi@ietf.org>; Fri, 06 Aug 2010 13:52:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.180.1 with SMTP id c1mr10801670wff.25.1281127931101; Fri, 06 Aug 2010 13:52:11 -0700 (PDT)
Received: by 10.142.120.8 with HTTP; Fri, 6 Aug 2010 13:52:11 -0700 (PDT)
In-Reply-To: <op.vg0cjfij64w2qv@anne-van-kesterens-macbook-pro.local>
References: <4C5AE0EF.6050701@ericsson.com> <op.vg0a7yjk64w2qv@anne-van-kesterens-macbook-pro.local> <AANLkTin=A3H9W_LfudbB2AhR7Xcfy75GVq9krH7EJ4Lx@mail.gmail.com> <2286.1281083088.270132@puncture> <op.vg0cjfij64w2qv@anne-van-kesterens-macbook-pro.local>
Date: Fri, 06 Aug 2010 13:52:11 -0700
Message-ID: <AANLkTinHptu8A-AyvngGx4Rw4AmmT9eq09+uHykiXiwq@mail.gmail.com>
From: Mike Belshe <mike@belshe.com>
To: Anne van Kesteren <annevk@opera.com>
Content-Type: multipart/alternative; boundary="000e0cd173e43ec13f048d2dd7ec"
Cc: Server-Initiated HTTP <hybi@ietf.org>, S Moonesamy <sm+ietf@elandsys.com>
Subject: Re: [hybi] Formal declaration of consensus: HTTP Compliance
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: Fri, 06 Aug 2010 21:20:32 -0000

On Fri, Aug 6, 2010 at 1:29 AM, Anne van Kesteren <annevk@opera.com> wrote:

> On Fri, 06 Aug 2010 10:24:48 +0200, Dave Cridland <dave@cridland.net>
> wrote:
>
>> On Fri Aug  6 09:11:43 2010, Adam Barth wrote:
>>
>>> Also, the main advocates for a TLS+NPN based handshake (Maciej and
>>> myself) weren't present at the face-to-face meeting.  I don't see that
>>> we've reached a rough consensus on this point at all.  I'm certainly
>>> not as experienced in IETF process as Salvatore, but we seem to be
>>> jumping the gun here.
>>>
>>
>> As I recall, EKR made the point that TLS+NPN has yet to go through the
>> standards process, so would be problematic from that standpoint.
>>
>> It's not that anyone's arguing that it should be discarded, it's more that
>> for the foreseeable, we should concentrate on an HTTP Upgrade based
>> solution.
>>
>
> I'm not sure who EKR is, but WebSocket itself is also not through the
> process. :-)


NPN even has implementations for OpenSSL, NSS, and Chrome available!  :-)  I
believe it has been submitted, but I'm not 100% sure:
http://tools.ietf.org/html/draft-agl-tls-nextprotoneg-00

But we don't have to tie WebSockets agreement to NPN finalization.  The two
are independent.  The question at hand is whether WebSockets expects or
requires an independent handshake.  NPN is a simple example of one way where
out-of-band protocol negotiation can be done, alleviating the need for an
http upgrade.  If WebSockets requires a round-trip via the HTTP upgrade
mechanism and cannot exist without it (as declared by the chairs in this
email), then NPN, or any other similar mechanisms will likely not be useful.

The WebSockets team has everything it needs today (independent of NPN
formalization) to make a decision on this now.  NPN will be happening; it's
a simple and good idea with basically unanimous support.

I suspect that separating deployment questions for WebSocket is a good idea.
 The deployment over port 80, port 443, or another random port may all be
slightly different.  If we wish to support anything other than port 80 with
reasonable latency, I'd recommend not adding reliance on the Upgrade header
for handshaking.   But we can decide all this without waiting for formal
approval on NPN.

Mike




>
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>