Re: [hybi] Extensibility mechanisms?

Maciej Stachowiak <mjs@apple.com> Thu, 22 July 2010 01:43 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 86F793A6A56 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 18:43:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 MVP+6SUGor8D for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 18:43:16 -0700 (PDT)
Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 3F2703A6A53 for <hybi@ietf.org>; Wed, 21 Jul 2010 18:43:16 -0700 (PDT)
Received: from relay15.apple.com (relay15.apple.com [17.128.113.54]) by mail-out3.apple.com (Postfix) with ESMTP id 555AB9ED84DD for <hybi@ietf.org>; Wed, 21 Jul 2010 18:43:33 -0700 (PDT)
X-AuditID: 11807136-b7c9dae000000fcd-70-4c47a24589fb
Received: from elliott.apple.com (elliott.apple.com [17.151.62.13]) by relay15.apple.com (Apple SCV relay) with SMTP id 1C.64.04045.542A74C4; Wed, 21 Jul 2010 18:43:33 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from [17.151.90.251] by elliott.apple.com (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPSA id <0L5X0037GRGLXGB0@elliott.apple.com> for hybi@ietf.org; Wed, 21 Jul 2010 18:43:33 -0700 (PDT)
From: Maciej Stachowiak <mjs@apple.com>
In-reply-to: <4C479F8D.8030601@caucho.com>
Date: Wed, 21 Jul 2010 18:43:30 -0700
Message-id: <D1F89752-F5D4-4C02-B78D-DDD7FFF91CB1@apple.com>
References: <h2w5c902b9e1004152345j992b815bz5f8d38f06a19181a@mail.gmail.com> <4BCAB2C1.2000404@webtide.com> <B9DC25B0-CD21-44E7-BD9B-06D0C9440933@apple.com> <4BCB7829.9010204@caucho.com> <Pine.LNX.4.64.1004182349240.751@ps20323.dreamhostps.com> <4BCC0A07.9030003@gmx.de> <Pine.LNX.4.64.1004190753510.23507@ps20323.dreamhostps.com> <4BCC111C.90707@gmx.de> <Pine.LNX.4.64.1004190837570.23507@ps20323.dreamhostps.com> <4BCC204D.30004@gmx.de> <z2gad99d8ce1004190822ne4dd36b6v54d63efcc448e840@mail.gmail.com> <Pine.LNX.4.64.1007202204270.7242@ps20323.dreamhostps.com> <AANLkTikkfdlUxQ0MGNvVQKa5gfovkGHWdCgyN9juKSQJ@mail.gmail.com> <4C462F9E.9030207@caucho.com> <Pine.LNX.4.64.1007212153110.7242@ps20323.dreamhostps.com> <AANLkTiku76oSucTNDFdwgsFBNFa_cCpC-YktTnMfX47-@mail.gmail.com> <4C479130.4020500@caucho.com> <B6EA60FA-53BB-49AD-82B4-D1E7B460C297@apple.com> <4C479F8D.8030601@caucho.com>
To: Scott Ferguson <ferg@caucho.com>
X-Mailer: Apple Mail (2.1081)
X-Brightmail-Tracker: AAAAAQAAAZE=
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Extensibility mechanisms?
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: Thu, 22 Jul 2010 01:43:17 -0000

On Jul 21, 2010, at 6:31 PM, Scott Ferguson wrote:

> Maciej Stachowiak wrote:
>> On Jul 21, 2010, at 5:30 PM, Scott Ferguson wrote:
>> 
>>  
>>> The counterproposal at
>>> 
>>> http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-latest.html
>>> 
>>> not complicated at all: it's a trivial protocol, and yet it solves the HyBi requirements, including requirements that the current draft ignores, as well as being extensible to muxing requirements.
>>>    
>> 
>> Can you explain how this proposal provides an HTTP-compatible upgrade in the non-TLS case? Or how it provides protection against cross-protocol attacks? I think those are two pretty important requirements, and it is not obvious to me how they are met.
>>  
> The HTTP negotiation was in an earlier draft:
> 
> http://hessian.caucho.com/websockets/draft-ferg-hybi-websockets-m1.html
> 
> The previous non-HTTP link was based on the discussion we had a few months ago for the non-HTTP case, just showing how you could have the handshake as part of the protocol syntax itself.  (And as I mentioned in the other response, my main focus was on the stream part of the protocol. There's nothing interesting or innovative in the handshake.)
> 
> The only thing I changed in the HTTP portion was to make it actually HTTP.
> 
> But focusing on the handshake is really missing the point of that proposal.

You said it solved all the requirements, so I was interested to find out if this was really so. It looks like that is not the case with your current draft, although it does have some nice properties.

Regards,
Maciej