Re: [hybi] Extensibility mechanisms?

Scott Ferguson <ferg@caucho.com> Thu, 22 July 2010 01:31 UTC

Return-Path: <ferg@caucho.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 567833A6A53 for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 18:31:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 RVMkSWSCDEcM for <hybi@core3.amsl.com>; Wed, 21 Jul 2010 18:31:47 -0700 (PDT)
Received: from smtp111.biz.mail.sp1.yahoo.com (smtp111.biz.mail.sp1.yahoo.com [69.147.92.224]) by core3.amsl.com (Postfix) with SMTP id 4A2F93A69BB for <hybi@ietf.org>; Wed, 21 Jul 2010 18:31:47 -0700 (PDT)
Received: (qmail 85069 invoked from network); 22 Jul 2010 01:32:02 -0000
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 21 Jul 2010 18:32:02 -0700 PDT
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
X-YMail-OSG: yNLljkwVM1mqT4AX842HsxY_t0pPcvNYobu9Hh5wBJTKSUB HpBnf8Zo6SOHXeY5AlyigFVjYxO9q0MWBxr6QKzoSsXK9Ti7iXJnvyftvlOe gGOv5vBk7SMbalEpL2CNfW6tTEllQLzisrmmHzPSOnfZaLO8lhrK8ar3nIzd QGSk7bRynQygrmjIqwaCuSOMiSQObn2GOJ5wU9qbzaqCKYU2uKyAd7GN4Lkg dFReMombTEDtg_R9ik6UwD5uDAfpFOnC_I5gZxhu0__YuD8qytRKIJOUdwFj 5qan80vIDJJ49W0X14IoQew.AQCQRjsDzMKR0gjApyhi9_8PA5wezUg--
X-Yahoo-Newman-Property: ymail-3
Message-ID: <4C479F8D.8030601@caucho.com>
Date: Wed, 21 Jul 2010 18:31:57 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: Maciej Stachowiak <mjs@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>
In-Reply-To: <B6EA60FA-53BB-49AD-82B4-D1E7B460C297@apple.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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:31:48 -0000

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.

-- Scott
> Regards,
> Maciej
>
>
>
>
>