
From bruce@callenish.com  Wed Jun  1 13:15:09 2011
Return-Path: <bruce@callenish.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAAAE0833 for <hybi@ietfa.amsl.com>; Wed,  1 Jun 2011 13:15:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FraQuE76wIdr for <hybi@ietfa.amsl.com>; Wed,  1 Jun 2011 13:15:08 -0700 (PDT)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id E8CDBE06E9 for <hybi@ietf.org>; Wed,  1 Jun 2011 13:15:08 -0700 (PDT)
Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from <bruce@callenish.com>) id 1QRroo-0006tw-MK; Wed, 01 Jun 2011 13:15:06 -0700
Message-ID: <4DE69DBF.7010501@callenish.com>
Date: Wed, 01 Jun 2011 13:14:55 -0700
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <BANLkTinqQiMQ4N1vWjyCe682BmdisW-=KA@mail.gmail.com>	<BANLkTik1a6CEA8LiiLgsnBt9qHCaybmWfg@mail.gmail.com>	<4DBA3809.4010004@oracle.com>	<CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>	<cbutt65hgt3ujdbi9jqa3v9a42iigglldk@hive.bjoern.hoehrmann.de>	<CA566BAEAD6B3F4E8B5C5C4F61710C11402F796C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>	<BANLkTimT=hgop617WmhC+iijqWg80Q2ucw@mail.gmail.com>	<BANLkTimn3vcjuk3fSW=zY6ZpAfRMt1c0vw@mail.gmail.com>	<BANLkTimNrSVhZicjwz4pGiS6aufaTzbRfw@mail.gmail.com>	<BANLkTim3PYcTZra_Qr-3hshS1nWJxXvB2A@mail.gmail.com> <BANLkTikaYiX+weYHiQb_T7Sz6QNX-jkTBA@mail.gmail.com>
In-Reply-To: <BANLkTikaYiX+weYHiQb_T7Sz6QNX-jkTBA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Cc: Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] method of allocation of reserved bits to extensions
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 01 Jun 2011 20:15:09 -0000

On 31/05/2011 5:53 PM, Greg Wilkins wrote:
>
> So if you have extensions A, B and C, each wanting to have opcodes and
> flags then you might see a payload like:
>
>   <A opcode><A flags>  <B opcode>  <B flags>  <C opcode>  <C flags>  <payload>
>
> Except that in reality the semantics of that is actually
>
>   <A opcode><A flags>  <A payload  of<B opcode>  <B flags>   <  B
> payload of<C opcode>  <C flags>  <  payload>>>
>
> Which essentially means that on the wire all you would see is
>
>   <A opcode><A flags>  <A payload>
>

I understand your concerns about squatting on bits, but I don't follow 
your reasons for wanting this scheme. If A wants its own opcode and 
bits, why not let it put that into its extension data? Why not have 
something like:

<Standard Opcode><Standard Flags><A Payload>

where <A Payload> is composed of:

<A Opcode><A Flags><B Payload>

and <B Payload> is:

<B Opcode><B Flags><C Payload>

and so on. A's crypto/compression/muxing could apply only after it had 
retrieved its opcode and flags. What is the benefit of popping the 
opcode and flag requirements up a level?


From gregw@intalio.com  Wed Jun  1 18:19:02 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85285E0749 for <hybi@ietfa.amsl.com>; Wed,  1 Jun 2011 18:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.656
X-Spam-Level: 
X-Spam-Status: No, score=-2.656 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5mvynIQbKfl for <hybi@ietfa.amsl.com>; Wed,  1 Jun 2011 18:19:01 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B875E0914 for <hybi@ietf.org>; Wed,  1 Jun 2011 18:18:33 -0700 (PDT)
Received: by vxg33 with SMTP id 33so388334vxg.31 for <hybi@ietf.org>; Wed, 01 Jun 2011 18:18:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.32.2 with SMTP id e2mr181215vdi.189.1306977512699; Wed, 01 Jun 2011 18:18:32 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Wed, 1 Jun 2011 18:18:32 -0700 (PDT)
In-Reply-To: <4DE69DBF.7010501@callenish.com>
References: <BANLkTinqQiMQ4N1vWjyCe682BmdisW-=KA@mail.gmail.com> <BANLkTik1a6CEA8LiiLgsnBt9qHCaybmWfg@mail.gmail.com> <4DBA3809.4010004@oracle.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11402DB23F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <cbutt65hgt3ujdbi9jqa3v9a42iigglldk@hive.bjoern.hoehrmann.de> <CA566BAEAD6B3F4E8B5C5C4F61710C11402F796C@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <BANLkTimT=hgop617WmhC+iijqWg80Q2ucw@mail.gmail.com> <BANLkTimn3vcjuk3fSW=zY6ZpAfRMt1c0vw@mail.gmail.com> <BANLkTimNrSVhZicjwz4pGiS6aufaTzbRfw@mail.gmail.com> <BANLkTim3PYcTZra_Qr-3hshS1nWJxXvB2A@mail.gmail.com> <BANLkTikaYiX+weYHiQb_T7Sz6QNX-jkTBA@mail.gmail.com> <4DE69DBF.7010501@callenish.com>
Date: Thu, 2 Jun 2011 11:18:32 +1000
Message-ID: <BANLkTimLTWNwMGdzTbY6nucgFDzaTdE3nw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Bruce Atherton <bruce@callenish.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] method of allocation of reserved bits to extensions
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 02 Jun 2011 01:19:02 -0000

Bruce,

I think we are saying the same thing.   I am proposing extensions put
their stuff in the extension data - I was just not calling it that and
saying they should put it in the payload.

So what you describe is exactly what I was saying... just said differently.

cheers


On 2 June 2011 06:14, Bruce Atherton <bruce@callenish.com> wrote:
> On 31/05/2011 5:53 PM, Greg Wilkins wrote:
>>
>> So if you have extensions A, B and C, each wanting to have opcodes and
>> flags then you might see a payload like:
>>
>> =A0<A opcode><A flags> =A0<B opcode> =A0<B flags> =A0<C opcode> =A0<C fl=
ags>
>> =A0<payload>
>>
>> Except that in reality the semantics of that is actually
>>
>> =A0<A opcode><A flags> =A0<A payload =A0of<B opcode> =A0<B flags> =A0 < =
=A0B
>> payload of<C opcode> =A0<C flags> =A0< =A0payload>>>
>>
>> Which essentially means that on the wire all you would see is
>>
>> =A0<A opcode><A flags> =A0<A payload>
>>
>
> I understand your concerns about squatting on bits, but I don't follow yo=
ur
> reasons for wanting this scheme. If A wants its own opcode and bits, why =
not
> let it put that into its extension data? Why not have something like:
>
> <Standard Opcode><Standard Flags><A Payload>
>
> where <A Payload> is composed of:
>
> <A Opcode><A Flags><B Payload>
>
> and <B Payload> is:
>
> <B Opcode><B Flags><C Payload>
>
> and so on. A's crypto/compression/muxing could apply only after it had
> retrieved its opcode and flags. What is the benefit of popping the opcode
> and flag requirements up a level?
>
>

From self.disconnect@gmail.com  Fri Jun  3 09:33:17 2011
Return-Path: <self.disconnect@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B211E06C2 for <hybi@ietfa.amsl.com>; Fri,  3 Jun 2011 09:33:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level: 
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR5GMDYLabUk for <hybi@ietfa.amsl.com>; Fri,  3 Jun 2011 09:33:16 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id C11E4E067F for <hybi@ietf.org>; Fri,  3 Jun 2011 09:33:16 -0700 (PDT)
Received: by gwb20 with SMTP id 20so1063466gwb.31 for <hybi@ietf.org>; Fri, 03 Jun 2011 09:33:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=Sv4sNbvjV2tXzvChURAef8TKkLdRoqx0JPOwrfmSo3A=; b=RL/YTQ4ugN4jA2K/hCOBk7/lJZwDKzYiefJz9UCmXoPywhHKw/drUJykDZh8LvSXEu KH5FD1+I9N/nFMQ8q/SJbb92RltRjS93cLBXagNxyXM4RmXlCJyoz8l9N5TrifYifHad GZS4QW07Fs5+4ys1Bt0KfAZL8hxnfmR5/IYT0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=FctFwmLMFcYELgQ9pCA8h38D6sXKNS5WZfWPPFvCMqaSx177Cpr/H4+wUduXcg9usV 0+buGmmadGPHd3EPkuoauFQQQR7CB6Wpslluxq2GKoyW/HwDAKIsvIouWMcQQB8ctWEo bXmFSLCOOHRTSngsQbeA1q/GGESqje+e+Mh1A=
MIME-Version: 1.0
Received: by 10.101.176.33 with SMTP id d33mr1529145anp.2.1307118796083; Fri, 03 Jun 2011 09:33:16 -0700 (PDT)
Received: by 10.100.197.18 with HTTP; Fri, 3 Jun 2011 09:33:16 -0700 (PDT)
Date: Fri, 3 Jun 2011 09:33:16 -0700
Message-ID: <BANLkTimgaMbjtK_ynHDnC1J_XxYJwXGTOQ@mail.gmail.com>
From: Self Disconnect <self.disconnect@gmail.com>
To: hybi <hybi@ietf.org>
Content-Type: multipart/alternative; boundary=001636c5bea285131a04a4d14f6d
Subject: [hybi] Apache WebSocket module
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 03 Jun 2011 16:33:17 -0000

--001636c5bea285131a04a4d14f6d
Content-Type: text/plain; charset=UTF-8

For those interested, I have updated the Apache WebSocket module on GitHub
to support draft-07.

git clone git@github.com:disconnect/apache-websocket.git

It is an initial implementation, and feedback is welcome.

-- 
def self.disconnect
  redirect_to http://github.com/disconnect/apache-websocket
end

--001636c5bea285131a04a4d14f6d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

For those interested, I have updated the Apache WebSocket module on GitHub =
to support draft-07.<div><br></div><div>git clone=C2=A0git@github.com:disco=
nnect/apache-websocket.git</div><div><br></div><div>It is an initial implem=
entation, and feedback is welcome.<br clear=3D"all">
<br>-- <br><div>def self.disconnect</div><div>=C2=A0=C2=A0redirect_to=C2=A0=
<a href=3D"http://github.com/disconnect/apache-websocket" target=3D"_blank"=
>http://github.com/disconnect/apache-websocket</a></div><div>end</div><br>
</div>

--001636c5bea285131a04a4d14f6d--

From salvatore.loreto@ericsson.com  Mon Jun  6 00:04:55 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F54C11E80C2 for <hybi@ietfa.amsl.com>; Mon,  6 Jun 2011 00:04:55 -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=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 43b-l-0Ps4gF for <hybi@ietfa.amsl.com>; Mon,  6 Jun 2011 00:04:53 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 1E17C11E80BE for <hybi@ietf.org>; Mon,  6 Jun 2011 00:04:52 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-78-4dec7c12e10a
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 89.71.09774.21C7CED4; Mon,  6 Jun 2011 09:04:51 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Mon, 6 Jun 2011 09:04:50 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 8CECE2356	for <hybi@ietf.org>; Mon,  6 Jun 2011 10:04:50 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 57CDE50FCD	for <hybi@ietf.org>; Mon,  6 Jun 2011 10:04:50 +0300 (EEST)
Received: from n211.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 18B8A508D8	for <hybi@ietf.org>; Mon,  6 Jun 2011 10:04:50 +0300 (EEST)
Message-ID: <4DEC7C11.9070409@ericsson.com>
Date: Mon, 6 Jun 2011 10:04:49 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [hybi] IETF81 in Quebec City
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 06 Jun 2011 07:04:55 -0000

Hi,

I have just requested a HyBi wg session for Quebec City.

Agenda items are welcome, as always.

best regards
Sal

-- 
Salvatore Loreto
www.sloreto.com


From gregw@intalio.com  Mon Jun  6 19:32:02 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C77E611E809B for <hybi@ietfa.amsl.com>; Mon,  6 Jun 2011 19:32:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GGuAG0brCrYB for <hybi@ietfa.amsl.com>; Mon,  6 Jun 2011 19:32:02 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE9F11E8082 for <hybi@ietf.org>; Mon,  6 Jun 2011 19:32:01 -0700 (PDT)
Received: by vxg33 with SMTP id 33so4101033vxg.31 for <hybi@ietf.org>; Mon, 06 Jun 2011 19:32:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr969483vdd.269.1307413921468; Mon, 06 Jun 2011 19:32:01 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Mon, 6 Jun 2011 19:32:01 -0700 (PDT)
Date: Tue, 7 Jun 2011 12:32:01 +1000
Message-ID: <BANLkTim0QA4LQFGqBZ1iD9rpAY_7gh_bFQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [hybi] Status?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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 Jun 2011 02:32:02 -0000

Editors and Chairs,

what's the current status/plans for a -08?


cheers

From ifette@google.com  Mon Jun  6 20:31:34 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568B21F0C4A for <hybi@ietfa.amsl.com>; Mon,  6 Jun 2011 20:31:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-kaa1bVYiOB for <hybi@ietfa.amsl.com>; Mon,  6 Jun 2011 20:31:33 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 615851F0C46 for <hybi@ietf.org>; Mon,  6 Jun 2011 20:31:33 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p573VVNK024527 for <hybi@ietf.org>; Mon, 6 Jun 2011 20:31:31 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307417492; bh=qgShNF19kqGYov3nUDVu0wbNHgk=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=Q+GhuIKAs5hkzNb0gzq3Gm0FPyELWBmLtNV7QUcm20PnscZ9/oBdryygUjObMBCKP bkGlyttewjZ8bO82+pKcw==
Received: from qwc9 (qwc9.prod.google.com [10.241.193.137]) by hpaq5.eem.corp.google.com with ESMTP id p573V2pl028422 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 6 Jun 2011 20:31:30 -0700
Received: by qwc9 with SMTP id 9so3365226qwc.27 for <hybi@ietf.org>; Mon, 06 Jun 2011 20:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=SH2sgGC/1bFr3zjQA8dtyHs92VSApazfEyYtpR2STRM=; b=c9ZEkLCiskYEbp+hcEnJhjgIUaigxqmyyEUj1/MzMY17S8CGJCWpPC8ZXmYunQ79et UAVRaBdxJ0r+3ZVBEu+g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=k4ptjR7TIw+fygVKm1IkwqUClGOeYyHNbNp7jL8v2NYUMt8sKt0MDQGA3f5CsYaNlx 0Dc7OxVxJGfDbsWm9wdg==
MIME-Version: 1.0
Received: by 10.229.1.144 with SMTP id 16mr134743qcf.105.1307417489371; Mon, 06 Jun 2011 20:31:29 -0700 (PDT)
Received: by 10.229.78.206 with HTTP; Mon, 6 Jun 2011 20:31:29 -0700 (PDT)
In-Reply-To: <BANLkTim0QA4LQFGqBZ1iD9rpAY_7gh_bFQ@mail.gmail.com>
References: <BANLkTim0QA4LQFGqBZ1iD9rpAY_7gh_bFQ@mail.gmail.com>
Date: Mon, 6 Jun 2011 20:31:29 -0700
Message-ID: <BANLkTimAG=EdBASCjejhHKNPdbwHGz8-Ag@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary=0016364ed4f006f3ba04a516db84
X-System-Of-Record: true
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] Status?
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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 Jun 2011 03:31:34 -0000

--0016364ed4f006f3ba04a516db84
Content-Type: text/plain; charset=UTF-8

We're going over some final editorial passes. I believe we are targeting
tomorrow (Tuesday), though there's a possibility it may slip to Wednesday.

-Ian

On Mon, Jun 6, 2011 at 7:32 PM, Greg Wilkins <gregw@intalio.com> wrote:

> Editors and Chairs,
>
> what's the current status/plans for a -08?
>
>
> cheers
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--0016364ed4f006f3ba04a516db84
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We&#39;re going over some final editorial passes. I believe we are targetin=
g tomorrow (Tuesday), though there&#39;s a possibility it may slip to Wedne=
sday.<div><br></div><div>-Ian<br><br><div class=3D"gmail_quote">On Mon, Jun=
 6, 2011 at 7:32 PM, Greg Wilkins <span dir=3D"ltr">&lt;<a href=3D"mailto:g=
regw@intalio.com">gregw@intalio.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Editors and Chairs,<br>
<br>
what&#39;s the current status/plans for a -08?<br>
<br>
<br>
cheers<br>
_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</blockquote></div><br></div>

--0016364ed4f006f3ba04a516db84--

From ifette@google.com  Tue Jun  7 16:06:43 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7C711E8120 for <hybi@ietfa.amsl.com>; Tue,  7 Jun 2011 16:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PGsSpWK3cAZ for <hybi@ietfa.amsl.com>; Tue,  7 Jun 2011 16:06:42 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3B2C211E8106 for <hybi@ietf.org>; Tue,  7 Jun 2011 16:06:42 -0700 (PDT)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p57N6eKs030603 for <hybi@ietf.org>; Tue, 7 Jun 2011 16:06:41 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307488001; bh=SuNHzgdYBUh8D6q9Meqxj5e5RT4=; h=MIME-Version:Reply-To:Date:Message-ID:Subject:From:To: Content-Type; b=XDkgzvCOvCuTG2GKuIQVcyD8qDrevyftAlRIv9AgrKi4yk1n+6fHXkwulW/c4R6/c ZtEZRFJ0Dp0gJZTBMr5cQ==
Received: from iwn34 (iwn34.prod.google.com [10.241.68.98]) by wpaz9.hot.corp.google.com with ESMTP id p57N6dnm007727 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 7 Jun 2011 16:06:39 -0700
Received: by iwn34 with SMTP id 34so6649089iwn.33 for <hybi@ietf.org>; Tue, 07 Jun 2011 16:06:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=phRq0mqN2e1BXOFk+uQ13I44u0Y9GWpS1fnlN+09lzA=; b=EwxQDY4K50atEdmbfpgJukielPWyMOEFAVahroLqnLoVlx4zrAYDSTldK99jNJPljS BUlfKD1uwN/fPiqBINMw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=DMBWNvcs2/7VthlqJ4CcmxvDdiOjY8vxQowXm5YyEMuMSyHNGfA4QsyHvHuHywGhMu zECw7qGkkEDUIlxsQ1yA==
MIME-Version: 1.0
Received: by 10.231.74.2 with SMTP id s2mr9140535ibj.8.1307487999189; Tue, 07 Jun 2011 16:06:39 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Tue, 7 Jun 2011 16:06:39 -0700 (PDT)
Date: Tue, 7 Jun 2011 16:06:39 -0700
Message-ID: <BANLkTinV8ZA=spbMQEtOf03cOhVN9xBsFg@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: multipart/alternative; boundary=000e0cd6b2debd626c04a52745be
X-System-Of-Record: true
Subject: [hybi] WebSockets -08
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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 Jun 2011 23:06:43 -0000

--000e0cd6b2debd626c04a52745be
Content-Type: text/plain; charset=UTF-8

The I-D Submission Tool seems to be erroring out at some point, as it is not
letting me complete the upload process. I have emailed ietf-action@ in an
attempt to get this resolved, hopefully -08 will still go out tonight.

FYI.

--000e0cd6b2debd626c04a52745be
Content-Type: text/html; charset=UTF-8

The I-D Submission Tool seems to be erroring out at some point, as it is not letting me complete the upload process. I have emailed ietf-action@ in an attempt to get this resolved, hopefully -08 will still go out tonight.<div>
<br></div><div>FYI.</div>

--000e0cd6b2debd626c04a52745be--

From Internet-Drafts@ietf.org  Wed Jun  8 10:30:14 2011
Return-Path: <Internet-Drafts@ietf.org>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DEF11E8157; Wed,  8 Jun 2011 10:30:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIa-m3odZHgX; Wed,  8 Jun 2011 10:30:13 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E0811E816E; Wed,  8 Jun 2011 10:30:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
From: Internet-Drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jun 2011 10:30:12 -0700
Cc: hybi@ietf.org
Subject: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 17:30:15 -0000

--NextPart

A new Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF.

    Title         : The WebSocket protocol
    Author(s)     : I. Fette
    Filename      : draft-ietf-hybi-thewebsocketprotocol-08.txt
    Pages         : 68
    Date          : 2011-06-08
    
   The WebSocket protocol enables two-way communication between a client
   running untrusted code running in a controlled environment to a
   remote host that has opted-in to communications from that code.  The
   security model used for this is the Origin-based security model
   commonly used by Web browsers.  The protocol consists of an opening
   handshake followed by basic message framing, layered over TCP.  (In
   theory, any transport protocol could be used so long as it provides
   for reliable transport, is byte clean, and supports relatively large
   message sizes.  However, for this document, we consider only TCP.)
   The goal of this technology is to provide a mechanism for browser-
   based applications that need two-way communication with servers that
   does not rely on opening multiple HTTP connections (e.g. using
   XMLHttpRequest or <iframe>s and long polling).

   Please send feedback to the hybi@ietf.org mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-hybi-thewebsocketprotocol-08.txt";
	site="ftp.ietf.org"; access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <2011-06-08102619.I-D@ietf.org>


--NextPart--

From gregw@intalio.com  Wed Jun  8 15:26:04 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DA611E80A3; Wed,  8 Jun 2011 15:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.868
X-Spam-Level: 
X-Spam-Status: No, score=-1.868 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMY5ZqIjDjiw; Wed,  8 Jun 2011 15:26:04 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36C0B11E808D; Wed,  8 Jun 2011 15:26:04 -0700 (PDT)
Received: by vws12 with SMTP id 12so1052612vws.31 for <multiple recipients>; Wed, 08 Jun 2011 15:26:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.114.196 with SMTP id ji4mr16483vdb.29.1307571963343; Wed, 08 Jun 2011 15:26:03 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Wed, 8 Jun 2011 15:26:03 -0700 (PDT)
In-Reply-To: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
Date: Thu, 9 Jun 2011 08:26:03 +1000
Message-ID: <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Internet-Drafts@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: hybi@ietf.org, i-d-announce@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 22:26:05 -0000

On 9 June 2011 03:30,  <Internet-Drafts@ietf.org> wrote:
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

best viewed at http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08
 with diff tools etc.

From a.catel@weelya.com  Wed Jun  8 15:41:08 2011
Return-Path: <a.catel@weelya.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A8101F0C3E for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 15:41:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFf8UOelAa-6 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 15:41:07 -0700 (PDT)
Received: from hermes.weelya.com (hermes.weelya.com [91.121.5.68]) by ietfa.amsl.com (Postfix) with ESMTP id 60E201F0C3C for <hybi@ietf.org>; Wed,  8 Jun 2011 15:41:07 -0700 (PDT)
Received: from [192.168.1.239] (e179073159.adsl.alicedsl.de [85.179.73.159]) by hermes.weelya.com (Postfix) with ESMTPSA id C087C4AD60 for <hybi@ietf.org>; Thu,  9 Jun 2011 00:45:00 +0200 (CEST)
Message-ID: <4DEFFA7F.7080802@weelya.com>
Date: Thu, 09 Jun 2011 00:41:03 +0200
From: Anthony Catel <a.catel@weelya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com>
In-Reply-To: <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 22:41:08 -0000

Hi,

           ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
           wss-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]


Should be

           ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
           wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]




Le 09/06/2011 00:26, Greg Wilkins a écrit :
> On 9 June 2011 03:30,<Internet-Drafts@ietf.org>  wrote:
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt
> best viewed at http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08
>   with diff tools etc.
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


From gregw@intalio.com  Wed Jun  8 16:03:40 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6159221F8578; Wed,  8 Jun 2011 16:03:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.422
X-Spam-Level: 
X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.555,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIhQHF-jfp1i; Wed,  8 Jun 2011 16:03:38 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB43D21F8571; Wed,  8 Jun 2011 16:03:37 -0700 (PDT)
Received: by vws12 with SMTP id 12so1077060vws.31 for <multiple recipients>; Wed, 08 Jun 2011 16:03:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.32.2 with SMTP id e2mr25785vdi.189.1307574217177; Wed, 08 Jun 2011 16:03:37 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Wed, 8 Jun 2011 16:03:37 -0700 (PDT)
In-Reply-To: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
Date: Thu, 9 Jun 2011 09:03:37 +1000
Message-ID: <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Internet-Drafts@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Cc: hybi@ietf.org, i-d-announce@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 23:03:40 -0000

Wow - that was a more extensive rewrite than I was expecting - but
most of the text looks to be good improvements - good work!


However 4.2 says

     The payload data is defined as extension data concatenated wit
application data.

and this is reflected elsewhere in the document.   Concatenation is
not the correct paradigm as this prohibits a compression or encrypting
extension which changes the entire payload.
I think we should simply say that the payload data is the application
data as processed by all the negotiated extensions.


Section 4.4, bullet point 3 is formatted as a bullet point, when it is
really a sub clause of the previous bullet point.  Also the Note about
control frames is formatted as another bullet point.

I also think this section needs another point like:

  * The fragments of one message may not be interleaved between the
fragments of another message unless an extension has been negotiated
that can interpret the interleaving.


4.8 says:

   o  Extension data may be placed in the payload data before the
      application data.

As above, this prevents compression/encrypting extensions.  Extensions
must be allowed to arbitrarily mutate the application data.


9.2.1 Compression

I still maintain that this extension should not be supported - it
breaks all the rules the spec defines for extensions - specifically it
mutates the framing.   There is an alternative compression proposal
available for in frame compression that would comply with the rules of
extensions (assuming we remove the concatenation restriction above).


In section 10, the draft says:

   The biggest security risk when sending text data using this protocol
   is sending data using the wrong encoding.  If an attacker can trick
   the server into sending data encoded as ISO-8859-1 verbatim (for
   instance), rather than encoded as UTF-8, then the attacker could
   inject arbitrary frames into the data stream.

I don't think this is true - not since we dropped sentinel encoded frames.
Length encoded frames are safe to send arbitrary data and there is no
possibility of any payload being interpreted as a frame in the
datastream.

From ifette@google.com  Wed Jun  8 16:13:36 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB8B711E80A0 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.304
X-Spam-Level: 
X-Spam-Status: No, score=-105.304 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2tbGYCgBj1au for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:13:35 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4761211E809B for <hybi@ietf.org>; Wed,  8 Jun 2011 16:13:34 -0700 (PDT)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p58NDVrV026248 for <hybi@ietf.org>; Wed, 8 Jun 2011 16:13:31 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307574811; bh=0clorNHO6i4wXgse+srTW7VkCcM=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=jZnHV/im3vRnD/iDNETZ/rBHwmRRTVvAujcxAbTEh4Nl6p1jwYK1icguihtBlR6+I Z1q30/S/tpxA7wNeCQ2Cg==
Received: from qyk7 (qyk7.prod.google.com [10.241.83.135]) by kpbe17.cbf.corp.google.com with ESMTP id p58NDLFj000379 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 8 Jun 2011 16:13:29 -0700
Received: by qyk7 with SMTP id 7so2328356qyk.12 for <hybi@ietf.org>; Wed, 08 Jun 2011 16:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=NFBeIzVWASp8CSt2u9JgqQ3dP2Tp6GR8NDwfzMnfno8=; b=UvcEKnimkqNp83lfCw5HJ4P5XSiDSgCmBwlC5tz//9yAv0PDvJD64EcNWxxsExQc10 L1N0Qq36we0Xf6UU9EEw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=U391uMmdeIhHxUerUNvdAsywFM+Aq1L98jOYqi0xfoHxuPxL+GRlJ/s2VDQ1TSXAJt VwsZFQaSJhcYqTBTgh1w==
MIME-Version: 1.0
Received: by 10.229.1.144 with SMTP id 16mr23682qcf.105.1307574807839; Wed, 08 Jun 2011 16:13:27 -0700 (PDT)
Received: by 10.229.78.206 with HTTP; Wed, 8 Jun 2011 16:13:27 -0700 (PDT)
In-Reply-To: <4DEFFA7F.7080802@weelya.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com> <4DEFFA7F.7080802@weelya.com>
Date: Wed, 8 Jun 2011 16:13:27 -0700
Message-ID: <BANLkTimKCFrgVNb=uT=eVfvXWs7KwPDBOA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Anthony Catel <a.catel@weelya.com>
Content-Type: multipart/alternative; boundary=0016364ed4f0f0457a04a53b7b57
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 23:13:36 -0000

--0016364ed4f0f0457a04a53b7b57
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 8, 2011 at 3:41 PM, Anthony Catel <a.catel@weelya.com> wrote:

> Hi,
>
>          ws-URI =3D "ws:" "//" host [ ":" port ] path [ "?" query ]
>          wss-URI =3D "ws:" "//" host [ ":" port ] path [ "?" query ]
>
>
> Should be
>
>          ws-URI =3D "ws:" "//" host [ ":" port ] path [ "?" query ]
>          wss-URI =3D "wss:" "//" host [ ":" port ] path [ "?" query ]
>
>
>
Sigh, will fix. There may be a -09 in a day or two I suspect ;-)


>
>
> Le 09/06/2011 00:26, Greg Wilkins a =C3=A9crit :
>
>  On 9 June 2011 03:30,<Internet-Drafts@ietf.org>  wrote:
>>
>>> A URL for this Internet-Draft is:
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotoco=
l-08.txt
>>>
>> best viewed at
>> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-08
>>  with diff tools etc.
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--0016364ed4f0f0457a04a53b7b57
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 8, 2011 at 3:41 PM, Anthony Catel <s=
pan dir=3D"ltr">&lt;<a href=3D"mailto:a.catel@weelya.com">a.catel@weelya.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi,<br>
<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ws-URI =3D &quot;ws:&quot; &quot;//&quot=
; host [ &quot;:&quot; port ] path [ &quot;?&quot; query ]<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wss-URI =3D &quot;ws:&quot; &quot;//&quo=
t; host [ &quot;:&quot; port ] path [ &quot;?&quot; query ]<br>
<br>
<br>
Should be<br>
<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ws-URI =3D &quot;ws:&quot; &quot;//&quot=
; host [ &quot;:&quot; port ] path [ &quot;?&quot; query ]<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wss-URI =3D &quot;wss:&quot; &quot;//&qu=
ot; host [ &quot;:&quot; port ] path [ &quot;?&quot; query ]<br>
<br>
<br></blockquote><div><br></div><div>Sigh, will fix. There may be a -09 in =
a day or two I suspect ;-)</div><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex;">

<br>
<br>
Le 09/06/2011 00:26, Greg Wilkins a =C3=A9crit :<div><div></div><div class=
=3D"h5"><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 9 June 2011 03:30,&lt;<a href=3D"mailto:Internet-Drafts@ietf.org" target=
=3D"_blank">Internet-Drafts@ietf.org</a>&gt; =C2=A0wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
A URL for this Internet-Draft is:<br>
<a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocket=
protocol-08.txt" target=3D"_blank">http://www.ietf.org/internet-drafts/draf=
t-ietf-hybi-thewebsocketprotocol-08.txt</a><br>
</blockquote>
best viewed at <a href=3D"http://tools.ietf.org/html/draft-ietf-hybi-theweb=
socketprotocol-08" target=3D"_blank">http://tools.ietf.org/html/draft-ietf-=
hybi-thewebsocketprotocol-08</a><br>
 =C2=A0with diff tools etc.<br>
_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</blockquote>
<br>
_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</div></div></blockquote></div><br>

--0016364ed4f0f0457a04a53b7b57--

From ifette@google.com  Wed Jun  8 16:24:03 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082961F0C3C for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:24:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2jKeJsv0xTf for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:24:01 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3840A1F0C3B for <hybi@ietf.org>; Wed,  8 Jun 2011 16:24:00 -0700 (PDT)
Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p58NNxl6021529 for <hybi@ietf.org>; Wed, 8 Jun 2011 16:23:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307575439; bh=fIauQ76JUXCWQM92aRgactd8bpk=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=StWP1QDtbyRNfbJv9l91ai1tH0d0Q80O4asTa1CA8reZwUbyELMp3rXTrDIQ5KELY D5dnaDKry2Om84NjmHRpg==
Received: from qwe5 (qwe5.prod.google.com [10.241.194.5]) by hpaq2.eem.corp.google.com with ESMTP id p58NNDfS018411 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 8 Jun 2011 16:23:57 -0700
Received: by qwe5 with SMTP id 5so570239qwe.37 for <hybi@ietf.org>; Wed, 08 Jun 2011 16:23:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YzGW1OL+nf8W+zYEueR41M+UyX0r2r1reNyTrr7QkSQ=; b=qD+M7perTdFJfcAkLsde7ltIU5latdueT5lQQAuaXd4aDlzsNbVa3gqtxEke8+/842 /zaqfP37kR2SUCnLx9vw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=LPvJxLciQuY00GWo1kxJV+j3vyZKEy9SNEEgcZ0dkB9FCiC3Etk2BcbmzQcL5BUlez HhyVJ89PhxA4nHp16S5g==
MIME-Version: 1.0
Received: by 10.229.6.196 with SMTP id a4mr25317qca.143.1307575437331; Wed, 08 Jun 2011 16:23:57 -0700 (PDT)
Received: by 10.229.78.206 with HTTP; Wed, 8 Jun 2011 16:23:57 -0700 (PDT)
In-Reply-To: <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com>
Date: Wed, 8 Jun 2011 16:23:57 -0700
Message-ID: <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary=0015175cb120758ce204a53ba190
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 23:24:03 -0000

--0015175cb120758ce204a53ba190
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <gregw@intalio.com> wrote:

> Wow - that was a more extensive rewrite than I was expecting - but
> most of the text looks to be good improvements - good work!
>
>
> However 4.2 says
>
>     The payload data is defined as extension data concatenated wit
> application data.
>
> and this is reflected elsewhere in the document.   Concatenation is
> not the correct paradigm as this prohibits a compression or encrypting
> extension which changes the entire payload.
>

Not really. We used to say the "body" of the frame was extension data
followed by application data, indeed the payload len has always meant
len(ext)+len(app). This re-write takes a lot of the sections that used to
talk about this and now just talks about "payload" where payload data is
extension data followed by application data, just as before. It doesn't
prevent a compressing or encrypting extension -- the extension is free to
modify the application data. [perhaps that point needs to be called out more
explicitly somewhere]. For instance, a compressing extension could have a
small amount of "extension data" such as an instruction to reset state and
contain "application data" (the compressed data).


> I think we should simply say that the payload data is the application
> data as processed by all the negotiated extensions.
>
>
I think I would prefer to to keep some distinction of what data is purely
for the extensions and what data is the actual data being passed by the
protocol, at least conceptually. We can make it clearer that the extensions
modify payload data, and at some points the distinction may not be crystal
clear, but I think the distinction is still useful (for instance, by saying
that a pong must have identical application data, we don't have to say that
the payload is identical.)


>
> Section 4.4, bullet point 3 is formatted as a bullet point, when it is
> really a sub clause of the previous bullet point.  Also the Note about
> control frames is formatted as another bullet point.
>


yes, sorry


>
> I also think this section needs another point like:
>
>  * The fragments of one message may not be interleaved between the
> fragments of another message unless an extension has been negotiated
> that can interpret the interleaving.
>

anyone else have thoughts here? it seems reasonable to me but I'd like to
hear other opinions.


>
>
> 4.8 says:
>
>   o  Extension data may be placed in the payload data before the
>      application data.
>
> As above, this prevents compression/encrypting extensions.  Extensions
> must be allowed to arbitrarily mutate the application data.
>

see prior explanation earlier in this response


>
>
> 9.2.1 Compression
>
> I still maintain that this extension should not be supported - it
> breaks all the rules the spec defines for extensions - specifically it
> mutates the framing.   There is an alternative compression proposal
> available for in frame compression that would comply with the rules of
> extensions (assuming we remove the concatenation restriction above).
>
>
How do others feel about keeping it / yanking it?


>
> In section 10, the draft says:
>
>   The biggest security risk when sending text data using this protocol
>   is sending data using the wrong encoding.  If an attacker can trick
>   the server into sending data encoded as ISO-8859-1 verbatim (for
>   instance), rather than encoded as UTF-8, then the attacker could
>   inject arbitrary frames into the data stream.
>
> I don't think this is true - not since we dropped sentinel encoded frames.
> Length encoded frames are safe to send arbitrary data and there is no
> possibility of any payload being interpreted as a frame in the
> datastream.
>

I agree the text needs to be changed, but perhaps rather than killing it
entirely, it can be rewritten as a more general statement of please be
careful with encodings, as when you tell a recipient something is utf-8,
they may make assumptions that will prove problematic if you send them
something like iso-8859-1 instead, or at the least may cause
misinterpretation or loss of data.


> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--0015175cb120758ce204a53ba190
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:gregw@intalio.com">gregw@intalio.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Wow - that was a more extensive rewrite than I was expecting - but<br>
most of the text looks to be good improvements - good work!<br>
<br>
<br>
However 4.2 says<br>
<br>
 =C2=A0 =C2=A0 The payload data is defined as extension data concatenated w=
it<br>
application data.<br>
<br>
and this is reflected elsewhere in the document. =C2=A0 Concatenation is<br=
>
not the correct paradigm as this prohibits a compression or encrypting<br>
extension which changes the entire payload.<br></blockquote><div><br></div>=
<div>Not really. We used to say the &quot;body&quot; of the frame was exten=
sion data followed by application data, indeed the payload len has always m=
eant len(ext)+len(app). This re-write takes a lot of the sections that used=
 to talk about this and now just talks about &quot;payload&quot; where payl=
oad data is extension data followed by application data, just as before. It=
 doesn&#39;t prevent a compressing or encrypting extension -- the extension=
 is free to modify the application data. [perhaps that point needs to be ca=
lled out more explicitly somewhere]. For instance, a compressing extension =
could have a small amount of &quot;extension data&quot; such as an instruct=
ion to reset state and contain &quot;application data&quot; (the compressed=
 data).</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
I think we should simply say that the payload data is the application<br>
data as processed by all the negotiated extensions.<br>
<br></blockquote><div><br></div><div>I think I would prefer to to keep some=
 distinction of what data is purely for the extensions and what data is the=
 actual data being passed by the protocol, at least conceptually. We can ma=
ke it clearer that the extensions modify payload data, and at some points t=
he distinction may not be crystal clear, but I think the distinction is sti=
ll useful (for instance, by saying that a pong must have identical applicat=
ion data, we don&#39;t have to say that the payload is identical.)</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Section 4.4, bullet point 3 is formatted as a bullet point, when it is<br>
really a sub clause of the previous bullet point. =C2=A0Also the Note about=
<br>
control frames is formatted as another bullet point.<br></blockquote><div><=
br></div><div><br></div><div>yes, sorry</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;">

<br>
I also think this section needs another point like:<br>
<br>
 =C2=A0* The fragments of one message may not be interleaved between the<br=
>
fragments of another message unless an extension has been negotiated<br>
that can interpret the interleaving.<br></blockquote><div><br></div><div>an=
yone else have thoughts here? it seems reasonable to me but I&#39;d like to=
 hear other opinions.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"=
>

<br>
<br>
4.8 says:<br>
<br>
 =C2=A0 o =C2=A0Extension data may be placed in the payload data before the=
<br>
 =C2=A0 =C2=A0 =C2=A0application data.<br>
<br>
As above, this prevents compression/encrypting extensions. =C2=A0Extensions=
<br>
must be allowed to arbitrarily mutate the application data.<br></blockquote=
><div><br></div><div>see prior explanation earlier in this response</div><d=
iv>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;">

<br>
<br>
9.2.1 Compression<br>
<br>
I still maintain that this extension should not be supported - it<br>
breaks all the rules the spec defines for extensions - specifically it<br>
mutates the framing. =C2=A0 There is an alternative compression proposal<br=
>
available for in frame compression that would comply with the rules of<br>
extensions (assuming we remove the concatenation restriction above).<br>
<br></blockquote><div><br></div><div>How do others feel about keeping it / =
yanking it?</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
In section 10, the draft says:<br>
<br>
 =C2=A0 The biggest security risk when sending text data using this protoco=
l<br>
 =C2=A0 is sending data using the wrong encoding. =C2=A0If an attacker can =
trick<br>
 =C2=A0 the server into sending data encoded as ISO-8859-1 verbatim (for<br=
>
 =C2=A0 instance), rather than encoded as UTF-8, then the attacker could<br=
>
 =C2=A0 inject arbitrary frames into the data stream.<br>
<br>
I don&#39;t think this is true - not since we dropped sentinel encoded fram=
es.<br>
Length encoded frames are safe to send arbitrary data and there is no<br>
possibility of any payload being interpreted as a frame in the<br>
datastream.<br></blockquote><div><br></div><div>I agree the text needs to b=
e changed, but perhaps rather than killing it entirely, it can be rewritten=
 as a more general statement of please be careful with encodings, as when y=
ou tell a recipient something is utf-8, they may make assumptions that will=
 prove problematic if you send them something like iso-8859-1 instead, or a=
t the least may cause misinterpretation or loss of data.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><div></div><div class=3D"h5">_________________________________________=
______<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</div></div></blockquote></div><br>

--0015175cb120758ce204a53ba190--

From Gabriel.Montenegro@microsoft.com  Wed Jun  8 16:28:16 2011
Return-Path: <Gabriel.Montenegro@microsoft.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE05A11E80CD for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:28:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD+v2+pkv8gj for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:28:15 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id BD83311E8085 for <hybi@ietf.org>; Wed,  8 Jun 2011 16:28:15 -0700 (PDT)
Received: from TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 8 Jun 2011 16:28:09 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.1.289.8; Wed, 8 Jun 2011 16:28:08 -0700
Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Wed, 8 Jun 2011 16:28:08 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: "ifette@google.com" <ifette@google.com>, Greg Wilkins <gregw@intalio.com>
Thread-Topic: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
Thread-Index: AQHMJgIGNC+RWZvmeEiFRxtORC8MYpS0ie2AgAAFroD//4ttwA==
Date: Wed, 8 Jun 2011 23:28:07 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
In-Reply-To: <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7TK5EX14MBXW603w_"
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 23:28:16 -0000

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7TK5EX14MBXW603w_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QWJvdXQgY29tcHJlc3Npb246IEdyZWcgYWxyZWFkeSBleHByZXNzZWQgdGhpcyBmZWVsaW5nIG9u
IHRoZSBtYWlsaW5nIGxpc3QgYW5kIHRoZXJlIHdhcyB2ZXJ5IHN0cm9uZyBvcHBvc2l0aW9uLg0K
QXQgdGhpcyBwb2ludCwgSeKAmWQgcmF0aGVyIHdlIG5vdCBtYWtlIHN1Y2ggYmlnIGNoYW5nZXMu
IExldOKAmXMgbGltaXQgMDkgdG8gbml0cyBhbmQgdHlwb3MuDQoNCkZyb206IGh5YmktYm91bmNl
c0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElh
biBGZXR0ZSAoPz8/Pz8/Pz8pDQpTZW50OiBXZWRuZXNkYXksIEp1bmUgMDgsIDIwMTEgMTY6MjQN
ClRvOiBHcmVnIFdpbGtpbnMNCkNjOiBoeWJpQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2h5Ymld
IEktRCBBQ1RJT046ZHJhZnQtaWV0Zi1oeWJpLXRoZXdlYnNvY2tldHByb3RvY29sLTA4LnR4dA0K
DQpPbiBXZWQsIEp1biA4LCAyMDExIGF0IDQ6MDMgUE0sIEdyZWcgV2lsa2lucyA8Z3JlZ3dAaW50
YWxpby5jb208bWFpbHRvOmdyZWd3QGludGFsaW8uY29tPj4gd3JvdGU6DQpXb3cgLSB0aGF0IHdh
cyBhIG1vcmUgZXh0ZW5zaXZlIHJld3JpdGUgdGhhbiBJIHdhcyBleHBlY3RpbmcgLSBidXQNCm1v
c3Qgb2YgdGhlIHRleHQgbG9va3MgdG8gYmUgZ29vZCBpbXByb3ZlbWVudHMgLSBnb29kIHdvcmsh
DQoNCg0KSG93ZXZlciA0LjIgc2F5cw0KDQogICAgVGhlIHBheWxvYWQgZGF0YSBpcyBkZWZpbmVk
IGFzIGV4dGVuc2lvbiBkYXRhIGNvbmNhdGVuYXRlZCB3aXQNCmFwcGxpY2F0aW9uIGRhdGEuDQoN
CmFuZCB0aGlzIGlzIHJlZmxlY3RlZCBlbHNld2hlcmUgaW4gdGhlIGRvY3VtZW50LiAgIENvbmNh
dGVuYXRpb24gaXMNCm5vdCB0aGUgY29ycmVjdCBwYXJhZGlnbSBhcyB0aGlzIHByb2hpYml0cyBh
IGNvbXByZXNzaW9uIG9yIGVuY3J5cHRpbmcNCmV4dGVuc2lvbiB3aGljaCBjaGFuZ2VzIHRoZSBl
bnRpcmUgcGF5bG9hZC4NCg0KTm90IHJlYWxseS4gV2UgdXNlZCB0byBzYXkgdGhlICJib2R5IiBv
ZiB0aGUgZnJhbWUgd2FzIGV4dGVuc2lvbiBkYXRhIGZvbGxvd2VkIGJ5IGFwcGxpY2F0aW9uIGRh
dGEsIGluZGVlZCB0aGUgcGF5bG9hZCBsZW4gaGFzIGFsd2F5cyBtZWFudCBsZW4oZXh0KStsZW4o
YXBwKS4gVGhpcyByZS13cml0ZSB0YWtlcyBhIGxvdCBvZiB0aGUgc2VjdGlvbnMgdGhhdCB1c2Vk
IHRvIHRhbGsgYWJvdXQgdGhpcyBhbmQgbm93IGp1c3QgdGFsa3MgYWJvdXQgInBheWxvYWQiIHdo
ZXJlIHBheWxvYWQgZGF0YSBpcyBleHRlbnNpb24gZGF0YSBmb2xsb3dlZCBieSBhcHBsaWNhdGlv
biBkYXRhLCBqdXN0IGFzIGJlZm9yZS4gSXQgZG9lc24ndCBwcmV2ZW50IGEgY29tcHJlc3Npbmcg
b3IgZW5jcnlwdGluZyBleHRlbnNpb24gLS0gdGhlIGV4dGVuc2lvbiBpcyBmcmVlIHRvIG1vZGlm
eSB0aGUgYXBwbGljYXRpb24gZGF0YS4gW3BlcmhhcHMgdGhhdCBwb2ludCBuZWVkcyB0byBiZSBj
YWxsZWQgb3V0IG1vcmUgZXhwbGljaXRseSBzb21ld2hlcmVdLiBGb3IgaW5zdGFuY2UsIGEgY29t
cHJlc3NpbmcgZXh0ZW5zaW9uIGNvdWxkIGhhdmUgYSBzbWFsbCBhbW91bnQgb2YgImV4dGVuc2lv
biBkYXRhIiBzdWNoIGFzIGFuIGluc3RydWN0aW9uIHRvIHJlc2V0IHN0YXRlIGFuZCBjb250YWlu
ICJhcHBsaWNhdGlvbiBkYXRhIiAodGhlIGNvbXByZXNzZWQgZGF0YSkuDQoNCkkgdGhpbmsgd2Ug
c2hvdWxkIHNpbXBseSBzYXkgdGhhdCB0aGUgcGF5bG9hZCBkYXRhIGlzIHRoZSBhcHBsaWNhdGlv
bg0KZGF0YSBhcyBwcm9jZXNzZWQgYnkgYWxsIHRoZSBuZWdvdGlhdGVkIGV4dGVuc2lvbnMuDQoN
CkkgdGhpbmsgSSB3b3VsZCBwcmVmZXIgdG8gdG8ga2VlcCBzb21lIGRpc3RpbmN0aW9uIG9mIHdo
YXQgZGF0YSBpcyBwdXJlbHkgZm9yIHRoZSBleHRlbnNpb25zIGFuZCB3aGF0IGRhdGEgaXMgdGhl
IGFjdHVhbCBkYXRhIGJlaW5nIHBhc3NlZCBieSB0aGUgcHJvdG9jb2wsIGF0IGxlYXN0IGNvbmNl
cHR1YWxseS4gV2UgY2FuIG1ha2UgaXQgY2xlYXJlciB0aGF0IHRoZSBleHRlbnNpb25zIG1vZGlm
eSBwYXlsb2FkIGRhdGEsIGFuZCBhdCBzb21lIHBvaW50cyB0aGUgZGlzdGluY3Rpb24gbWF5IG5v
dCBiZSBjcnlzdGFsIGNsZWFyLCBidXQgSSB0aGluayB0aGUgZGlzdGluY3Rpb24gaXMgc3RpbGwg
dXNlZnVsIChmb3IgaW5zdGFuY2UsIGJ5IHNheWluZyB0aGF0IGEgcG9uZyBtdXN0IGhhdmUgaWRl
bnRpY2FsIGFwcGxpY2F0aW9uIGRhdGEsIHdlIGRvbid0IGhhdmUgdG8gc2F5IHRoYXQgdGhlIHBh
eWxvYWQgaXMgaWRlbnRpY2FsLikNCg0KDQpTZWN0aW9uIDQuNCwgYnVsbGV0IHBvaW50IDMgaXMg
Zm9ybWF0dGVkIGFzIGEgYnVsbGV0IHBvaW50LCB3aGVuIGl0IGlzDQpyZWFsbHkgYSBzdWIgY2xh
dXNlIG9mIHRoZSBwcmV2aW91cyBidWxsZXQgcG9pbnQuICBBbHNvIHRoZSBOb3RlIGFib3V0DQpj
b250cm9sIGZyYW1lcyBpcyBmb3JtYXR0ZWQgYXMgYW5vdGhlciBidWxsZXQgcG9pbnQuDQoNCg0K
eWVzLCBzb3JyeQ0KDQoNCkkgYWxzbyB0aGluayB0aGlzIHNlY3Rpb24gbmVlZHMgYW5vdGhlciBw
b2ludCBsaWtlOg0KDQogKiBUaGUgZnJhZ21lbnRzIG9mIG9uZSBtZXNzYWdlIG1heSBub3QgYmUg
aW50ZXJsZWF2ZWQgYmV0d2VlbiB0aGUNCmZyYWdtZW50cyBvZiBhbm90aGVyIG1lc3NhZ2UgdW5s
ZXNzIGFuIGV4dGVuc2lvbiBoYXMgYmVlbiBuZWdvdGlhdGVkDQp0aGF0IGNhbiBpbnRlcnByZXQg
dGhlIGludGVybGVhdmluZy4NCg0KYW55b25lIGVsc2UgaGF2ZSB0aG91Z2h0cyBoZXJlPyBpdCBz
ZWVtcyByZWFzb25hYmxlIHRvIG1lIGJ1dCBJJ2QgbGlrZSB0byBoZWFyIG90aGVyIG9waW5pb25z
Lg0KDQoNCg0KNC44IHNheXM6DQoNCiAgbyAgRXh0ZW5zaW9uIGRhdGEgbWF5IGJlIHBsYWNlZCBp
biB0aGUgcGF5bG9hZCBkYXRhIGJlZm9yZSB0aGUNCiAgICAgYXBwbGljYXRpb24gZGF0YS4NCg0K
QXMgYWJvdmUsIHRoaXMgcHJldmVudHMgY29tcHJlc3Npb24vZW5jcnlwdGluZyBleHRlbnNpb25z
LiAgRXh0ZW5zaW9ucw0KbXVzdCBiZSBhbGxvd2VkIHRvIGFyYml0cmFyaWx5IG11dGF0ZSB0aGUg
YXBwbGljYXRpb24gZGF0YS4NCg0Kc2VlIHByaW9yIGV4cGxhbmF0aW9uIGVhcmxpZXIgaW4gdGhp
cyByZXNwb25zZQ0KDQoNCg0KOS4yLjEgQ29tcHJlc3Npb24NCg0KSSBzdGlsbCBtYWludGFpbiB0
aGF0IHRoaXMgZXh0ZW5zaW9uIHNob3VsZCBub3QgYmUgc3VwcG9ydGVkIC0gaXQNCmJyZWFrcyBh
bGwgdGhlIHJ1bGVzIHRoZSBzcGVjIGRlZmluZXMgZm9yIGV4dGVuc2lvbnMgLSBzcGVjaWZpY2Fs
bHkgaXQNCm11dGF0ZXMgdGhlIGZyYW1pbmcuICAgVGhlcmUgaXMgYW4gYWx0ZXJuYXRpdmUgY29t
cHJlc3Npb24gcHJvcG9zYWwNCmF2YWlsYWJsZSBmb3IgaW4gZnJhbWUgY29tcHJlc3Npb24gdGhh
dCB3b3VsZCBjb21wbHkgd2l0aCB0aGUgcnVsZXMgb2YNCmV4dGVuc2lvbnMgKGFzc3VtaW5nIHdl
IHJlbW92ZSB0aGUgY29uY2F0ZW5hdGlvbiByZXN0cmljdGlvbiBhYm92ZSkuDQoNCkhvdyBkbyBv
dGhlcnMgZmVlbCBhYm91dCBrZWVwaW5nIGl0IC8geWFua2luZyBpdD8NCg0KDQpJbiBzZWN0aW9u
IDEwLCB0aGUgZHJhZnQgc2F5czoNCg0KICBUaGUgYmlnZ2VzdCBzZWN1cml0eSByaXNrIHdoZW4g
c2VuZGluZyB0ZXh0IGRhdGEgdXNpbmcgdGhpcyBwcm90b2NvbA0KICBpcyBzZW5kaW5nIGRhdGEg
dXNpbmcgdGhlIHdyb25nIGVuY29kaW5nLiAgSWYgYW4gYXR0YWNrZXIgY2FuIHRyaWNrDQogIHRo
ZSBzZXJ2ZXIgaW50byBzZW5kaW5nIGRhdGEgZW5jb2RlZCBhcyBJU08tODg1OS0xIHZlcmJhdGlt
IChmb3INCiAgaW5zdGFuY2UpLCByYXRoZXIgdGhhbiBlbmNvZGVkIGFzIFVURi04LCB0aGVuIHRo
ZSBhdHRhY2tlciBjb3VsZA0KICBpbmplY3QgYXJiaXRyYXJ5IGZyYW1lcyBpbnRvIHRoZSBkYXRh
IHN0cmVhbS4NCg0KSSBkb24ndCB0aGluayB0aGlzIGlzIHRydWUgLSBub3Qgc2luY2Ugd2UgZHJv
cHBlZCBzZW50aW5lbCBlbmNvZGVkIGZyYW1lcy4NCkxlbmd0aCBlbmNvZGVkIGZyYW1lcyBhcmUg
c2FmZSB0byBzZW5kIGFyYml0cmFyeSBkYXRhIGFuZCB0aGVyZSBpcyBubw0KcG9zc2liaWxpdHkg
b2YgYW55IHBheWxvYWQgYmVpbmcgaW50ZXJwcmV0ZWQgYXMgYSBmcmFtZSBpbiB0aGUNCmRhdGFz
dHJlYW0uDQoNCkkgYWdyZWUgdGhlIHRleHQgbmVlZHMgdG8gYmUgY2hhbmdlZCwgYnV0IHBlcmhh
cHMgcmF0aGVyIHRoYW4ga2lsbGluZyBpdCBlbnRpcmVseSwgaXQgY2FuIGJlIHJld3JpdHRlbiBh
cyBhIG1vcmUgZ2VuZXJhbCBzdGF0ZW1lbnQgb2YgcGxlYXNlIGJlIGNhcmVmdWwgd2l0aCBlbmNv
ZGluZ3MsIGFzIHdoZW4geW91IHRlbGwgYSByZWNpcGllbnQgc29tZXRoaW5nIGlzIHV0Zi04LCB0
aGV5IG1heSBtYWtlIGFzc3VtcHRpb25zIHRoYXQgd2lsbCBwcm92ZSBwcm9ibGVtYXRpYyBpZiB5
b3Ugc2VuZCB0aGVtIHNvbWV0aGluZyBsaWtlIGlzby04ODU5LTEgaW5zdGVhZCwgb3IgYXQgdGhl
IGxlYXN0IG1heSBjYXVzZSBtaXNpbnRlcnByZXRhdGlvbiBvciBsb3NzIG9mIGRhdGEuDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpoeWJpIG1haWxp
bmcgbGlzdA0KaHliaUBpZXRmLm9yZzxtYWlsdG86aHliaUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHliaQ0KDQo=

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7TK5EX14MBXW603w_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl
DQoJe2ZvbnQtZmFtaWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAz
IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg
NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh
bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxl
IERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFs
DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4w
cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw
YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K
CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu
a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt
dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
Ow0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw
b3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBX
b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu
MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+
PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9
ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt
c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0
PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K
PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K
PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BYm91dCBjb21wcmVzc2lvbjogR3Jl
ZyBhbHJlYWR5IGV4cHJlc3NlZCB0aGlzIGZlZWxpbmcgb24gdGhlIG1haWxpbmcgbGlzdCBhbmQg
dGhlcmUgd2FzIHZlcnkgc3Ryb25nIG9wcG9zaXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPkF0IHRoaXMgcG9pbnQsIEnigJlkIHJhdGhlciB3ZSBub3QgbWFrZSBzdWNoIGJpZyBj
aGFuZ2VzLiBMZXTigJlzIGxpbWl0IDA5IHRvIG5pdHMgYW5kIHR5cG9zLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxl
PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBp
biAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6
c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21h
aWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPklhbiBGZXR0
ZSAoPz8/Pz8/Pz8pPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVuZSAwOCwgMjAxMSAx
NjoyNDxicj4NCjxiPlRvOjwvYj4gR3JlZyBXaWxraW5zPGJyPg0KPGI+Q2M6PC9iPiBoeWJpQGll
dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gSS1EIEFDVElPTjpkcmFmdC1p
ZXRmLWh5YmktdGhld2Vic29ja2V0cHJvdG9jb2wtMDgudHh0PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgSnVuIDgsIDIwMTEgYXQg
NDowMyBQTSwgR3JlZyBXaWxraW5zICZsdDs8YSBocmVmPSJtYWlsdG86Z3JlZ3dAaW50YWxpby5j
b20iPmdyZWd3QGludGFsaW8uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5Xb3cgLSB0aGF0IHdhcyBhIG1vcmUgZXh0ZW5zaXZlIHJld3JpdGUg
dGhhbiBJIHdhcyBleHBlY3RpbmcgLSBidXQ8YnI+DQptb3N0IG9mIHRoZSB0ZXh0IGxvb2tzIHRv
IGJlIGdvb2QgaW1wcm92ZW1lbnRzIC0gZ29vZCB3b3JrITxicj4NCjxicj4NCjxicj4NCkhvd2V2
ZXIgNC4yIHNheXM8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFRoZSBwYXlsb2FkIGRhdGEgaXMg
ZGVmaW5lZCBhcyBleHRlbnNpb24gZGF0YSBjb25jYXRlbmF0ZWQgd2l0PGJyPg0KYXBwbGljYXRp
b24gZGF0YS48YnI+DQo8YnI+DQphbmQgdGhpcyBpcyByZWZsZWN0ZWQgZWxzZXdoZXJlIGluIHRo
ZSBkb2N1bWVudC4gJm5ic3A7IENvbmNhdGVuYXRpb24gaXM8YnI+DQpub3QgdGhlIGNvcnJlY3Qg
cGFyYWRpZ20gYXMgdGhpcyBwcm9oaWJpdHMgYSBjb21wcmVzc2lvbiBvciBlbmNyeXB0aW5nPGJy
Pg0KZXh0ZW5zaW9uIHdoaWNoIGNoYW5nZXMgdGhlIGVudGlyZSBwYXlsb2FkLjxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90IHJlYWxseS4gV2UgdXNlZCB0
byBzYXkgdGhlICZxdW90O2JvZHkmcXVvdDsgb2YgdGhlIGZyYW1lIHdhcyBleHRlbnNpb24gZGF0
YSBmb2xsb3dlZCBieSBhcHBsaWNhdGlvbiBkYXRhLCBpbmRlZWQgdGhlIHBheWxvYWQgbGVuIGhh
cyBhbHdheXMgbWVhbnQgbGVuKGV4dCkmIzQzO2xlbihhcHApLiBUaGlzIHJlLXdyaXRlIHRha2Vz
IGEgbG90IG9mIHRoZSBzZWN0aW9ucyB0aGF0IHVzZWQgdG8gdGFsayBhYm91dCB0aGlzIGFuZCBu
b3cNCiBqdXN0IHRhbGtzIGFib3V0ICZxdW90O3BheWxvYWQmcXVvdDsgd2hlcmUgcGF5bG9hZCBk
YXRhIGlzIGV4dGVuc2lvbiBkYXRhIGZvbGxvd2VkIGJ5IGFwcGxpY2F0aW9uIGRhdGEsIGp1c3Qg
YXMgYmVmb3JlLiBJdCBkb2Vzbid0IHByZXZlbnQgYSBjb21wcmVzc2luZyBvciBlbmNyeXB0aW5n
IGV4dGVuc2lvbiAtLSB0aGUgZXh0ZW5zaW9uIGlzIGZyZWUgdG8gbW9kaWZ5IHRoZSBhcHBsaWNh
dGlvbiBkYXRhLiBbcGVyaGFwcyB0aGF0IHBvaW50IG5lZWRzIHRvIGJlDQogY2FsbGVkIG91dCBt
b3JlIGV4cGxpY2l0bHkgc29tZXdoZXJlXS4gRm9yIGluc3RhbmNlLCBhIGNvbXByZXNzaW5nIGV4
dGVuc2lvbiBjb3VsZCBoYXZlIGEgc21hbGwgYW1vdW50IG9mICZxdW90O2V4dGVuc2lvbiBkYXRh
JnF1b3Q7IHN1Y2ggYXMgYW4gaW5zdHJ1Y3Rpb24gdG8gcmVzZXQgc3RhdGUgYW5kIGNvbnRhaW4g
JnF1b3Q7YXBwbGljYXRpb24gZGF0YSZxdW90OyAodGhlIGNvbXByZXNzZWQgZGF0YSkuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn
aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB0aGluayB3ZSBzaG91bGQgc2ltcGx5IHNheSB0
aGF0IHRoZSBwYXlsb2FkIGRhdGEgaXMgdGhlIGFwcGxpY2F0aW9uPGJyPg0KZGF0YSBhcyBwcm9j
ZXNzZWQgYnkgYWxsIHRoZSBuZWdvdGlhdGVkIGV4dGVuc2lvbnMuPG86cD48L286cD48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIEkgd291
bGQgcHJlZmVyIHRvIHRvIGtlZXAgc29tZSBkaXN0aW5jdGlvbiBvZiB3aGF0IGRhdGEgaXMgcHVy
ZWx5IGZvciB0aGUgZXh0ZW5zaW9ucyBhbmQgd2hhdCBkYXRhIGlzIHRoZSBhY3R1YWwgZGF0YSBi
ZWluZyBwYXNzZWQgYnkgdGhlIHByb3RvY29sLCBhdCBsZWFzdCBjb25jZXB0dWFsbHkuIFdlIGNh
biBtYWtlIGl0IGNsZWFyZXIgdGhhdCB0aGUgZXh0ZW5zaW9ucyBtb2RpZnkgcGF5bG9hZA0KIGRh
dGEsIGFuZCBhdCBzb21lIHBvaW50cyB0aGUgZGlzdGluY3Rpb24gbWF5IG5vdCBiZSBjcnlzdGFs
IGNsZWFyLCBidXQgSSB0aGluayB0aGUgZGlzdGluY3Rpb24gaXMgc3RpbGwgdXNlZnVsIChmb3Ig
aW5zdGFuY2UsIGJ5IHNheWluZyB0aGF0IGEgcG9uZyBtdXN0IGhhdmUgaWRlbnRpY2FsIGFwcGxp
Y2F0aW9uIGRhdGEsIHdlIGRvbid0IGhhdmUgdG8gc2F5IHRoYXQgdGhlIHBheWxvYWQgaXMgaWRl
bnRpY2FsLik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PGJyPg0KU2VjdGlvbiA0LjQsIGJ1bGxldCBwb2ludCAzIGlzIGZvcm1hdHRl
ZCBhcyBhIGJ1bGxldCBwb2ludCwgd2hlbiBpdCBpczxicj4NCnJlYWxseSBhIHN1YiBjbGF1c2Ug
b2YgdGhlIHByZXZpb3VzIGJ1bGxldCBwb2ludC4gJm5ic3A7QWxzbyB0aGUgTm90ZSBhYm91dDxi
cj4NCmNvbnRyb2wgZnJhbWVzIGlzIGZvcm1hdHRlZCBhcyBhbm90aGVyIGJ1bGxldCBwb2ludC48
bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+eWVzLCBzb3JyeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0
eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpJIGFsc28gdGhpbmsgdGhpcyBzZWN0aW9uIG5lZWRz
IGFub3RoZXIgcG9pbnQgbGlrZTo8YnI+DQo8YnI+DQombmJzcDsqIFRoZSBmcmFnbWVudHMgb2Yg
b25lIG1lc3NhZ2UgbWF5IG5vdCBiZSBpbnRlcmxlYXZlZCBiZXR3ZWVuIHRoZTxicj4NCmZyYWdt
ZW50cyBvZiBhbm90aGVyIG1lc3NhZ2UgdW5sZXNzIGFuIGV4dGVuc2lvbiBoYXMgYmVlbiBuZWdv
dGlhdGVkPGJyPg0KdGhhdCBjYW4gaW50ZXJwcmV0IHRoZSBpbnRlcmxlYXZpbmcuPG86cD48L286
cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hbnlv
bmUgZWxzZSBoYXZlIHRob3VnaHRzIGhlcmU/IGl0IHNlZW1zIHJlYXNvbmFibGUgdG8gbWUgYnV0
IEknZCBsaWtlIHRvIGhlYXIgb3RoZXIgb3BpbmlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND
Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn
aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjQuOCBzYXlz
Ojxicj4NCjxicj4NCiZuYnNwOyBvICZuYnNwO0V4dGVuc2lvbiBkYXRhIG1heSBiZSBwbGFjZWQg
aW4gdGhlIHBheWxvYWQgZGF0YSBiZWZvcmUgdGhlPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDth
cHBsaWNhdGlvbiBkYXRhLjxicj4NCjxicj4NCkFzIGFib3ZlLCB0aGlzIHByZXZlbnRzIGNvbXBy
ZXNzaW9uL2VuY3J5cHRpbmcgZXh0ZW5zaW9ucy4gJm5ic3A7RXh0ZW5zaW9uczxicj4NCm11c3Qg
YmUgYWxsb3dlZCB0byBhcmJpdHJhcmlseSBtdXRhdGUgdGhlIGFwcGxpY2F0aW9uIGRhdGEuPG86
cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5zZWUgcHJpb3IgZXhwbGFuYXRpb24gZWFybGllciBpbiB0aGlzIHJlc3BvbnNlPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s
ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t
bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KPGJyPg0KOS4yLjEgQ29tcHJlc3Npb248YnI+
DQo8YnI+DQpJIHN0aWxsIG1haW50YWluIHRoYXQgdGhpcyBleHRlbnNpb24gc2hvdWxkIG5vdCBi
ZSBzdXBwb3J0ZWQgLSBpdDxicj4NCmJyZWFrcyBhbGwgdGhlIHJ1bGVzIHRoZSBzcGVjIGRlZmlu
ZXMgZm9yIGV4dGVuc2lvbnMgLSBzcGVjaWZpY2FsbHkgaXQ8YnI+DQptdXRhdGVzIHRoZSBmcmFt
aW5nLiAmbmJzcDsgVGhlcmUgaXMgYW4gYWx0ZXJuYXRpdmUgY29tcHJlc3Npb24gcHJvcG9zYWw8
YnI+DQphdmFpbGFibGUgZm9yIGluIGZyYW1lIGNvbXByZXNzaW9uIHRoYXQgd291bGQgY29tcGx5
IHdpdGggdGhlIHJ1bGVzIG9mPGJyPg0KZXh0ZW5zaW9ucyAoYXNzdW1pbmcgd2UgcmVtb3ZlIHRo
ZSBjb25jYXRlbmF0aW9uIHJlc3RyaWN0aW9uIGFib3ZlKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBkbyBvdGhlcnMgZmVl
bCBhYm91dCBrZWVwaW5nIGl0IC8geWFua2luZyBpdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND
QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp
bi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KSW4gc2VjdGlvbiAxMCwg
dGhlIGRyYWZ0IHNheXM6PGJyPg0KPGJyPg0KJm5ic3A7IFRoZSBiaWdnZXN0IHNlY3VyaXR5IHJp
c2sgd2hlbiBzZW5kaW5nIHRleHQgZGF0YSB1c2luZyB0aGlzIHByb3RvY29sPGJyPg0KJm5ic3A7
IGlzIHNlbmRpbmcgZGF0YSB1c2luZyB0aGUgd3JvbmcgZW5jb2RpbmcuICZuYnNwO0lmIGFuIGF0
dGFja2VyIGNhbiB0cmljazxicj4NCiZuYnNwOyB0aGUgc2VydmVyIGludG8gc2VuZGluZyBkYXRh
IGVuY29kZWQgYXMgSVNPLTg4NTktMSB2ZXJiYXRpbSAoZm9yPGJyPg0KJm5ic3A7IGluc3RhbmNl
KSwgcmF0aGVyIHRoYW4gZW5jb2RlZCBhcyBVVEYtOCwgdGhlbiB0aGUgYXR0YWNrZXIgY291bGQ8
YnI+DQombmJzcDsgaW5qZWN0IGFyYml0cmFyeSBmcmFtZXMgaW50byB0aGUgZGF0YSBzdHJlYW0u
PGJyPg0KPGJyPg0KSSBkb24ndCB0aGluayB0aGlzIGlzIHRydWUgLSBub3Qgc2luY2Ugd2UgZHJv
cHBlZCBzZW50aW5lbCBlbmNvZGVkIGZyYW1lcy48YnI+DQpMZW5ndGggZW5jb2RlZCBmcmFtZXMg
YXJlIHNhZmUgdG8gc2VuZCBhcmJpdHJhcnkgZGF0YSBhbmQgdGhlcmUgaXMgbm88YnI+DQpwb3Nz
aWJpbGl0eSBvZiBhbnkgcGF5bG9hZCBiZWluZyBpbnRlcnByZXRlZCBhcyBhIGZyYW1lIGluIHRo
ZTxicj4NCmRhdGFzdHJlYW0uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFncmVlIHRoZSB0ZXh0IG5lZWRzIHRvIGJlIGNoYW5n
ZWQsIGJ1dCBwZXJoYXBzIHJhdGhlciB0aGFuIGtpbGxpbmcgaXQgZW50aXJlbHksIGl0IGNhbiBi
ZSByZXdyaXR0ZW4gYXMgYSBtb3JlIGdlbmVyYWwgc3RhdGVtZW50IG9mIHBsZWFzZSBiZSBjYXJl
ZnVsIHdpdGggZW5jb2RpbmdzLCBhcyB3aGVuIHlvdSB0ZWxsIGEgcmVjaXBpZW50IHNvbWV0aGlu
ZyBpcyB1dGYtOCwgdGhleSBtYXkgbWFrZSBhc3N1bXB0aW9ucw0KIHRoYXQgd2lsbCBwcm92ZSBw
cm9ibGVtYXRpYyBpZiB5b3Ugc2VuZCB0aGVtIHNvbWV0aGluZyBsaWtlIGlzby04ODU5LTEgaW5z
dGVhZCwgb3IgYXQgdGhlIGxlYXN0IG1heSBjYXVzZSBtaXNpbnRlcnByZXRhdGlvbiBvciBsb3Nz
IG9mIGRhdGEuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv
cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu
IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX188YnI+DQpoeWJpIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h
aWx0bzpoeWJpQGlldGYub3JnIj5oeWJpQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHliaSIgdGFyZ2V0PSJfYmxhbmsiPmh0
dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHliaTwvYT48bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7TK5EX14MBXW603w_--

From gregw@intalio.com  Wed Jun  8 16:53:38 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B960521F8557 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:53:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.607
X-Spam-Level: 
X-Spam-Status: No, score=-2.607 tagged_above=-999 required=5 tests=[AWL=0.370,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1iESDIheo7X for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 16:53:38 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4071821F8556 for <hybi@ietf.org>; Wed,  8 Jun 2011 16:53:38 -0700 (PDT)
Received: by vws12 with SMTP id 12so1107836vws.31 for <hybi@ietf.org>; Wed, 08 Jun 2011 16:53:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.114.196 with SMTP id ji4mr110229vdb.29.1307577217373; Wed, 08 Jun 2011 16:53:37 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Wed, 8 Jun 2011 16:53:37 -0700 (PDT)
In-Reply-To: <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
Date: Thu, 9 Jun 2011 09:53:37 +1000
Message-ID: <BANLkTikHNVB7J3bE0Z4=HN8+Wjj13k6Ctg@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: ifette@google.com
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 08 Jun 2011 23:53:38 -0000

2011/6/9 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>:

> I think I would prefer to to keep some distinction of what data is purely
> for the extensions and what data is the actual data being passed by the
> protocol, at least conceptually.

Fair enough, but I do think that we need to call out that extensions
may also mutate the application data.

cheers

From derhoermi@gmx.net  Wed Jun  8 17:22:11 2011
Return-Path: <derhoermi@gmx.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7357611E80AA for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 17:22:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v-1uCVAkftdy for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 17:22:09 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 14EF511E809E for <hybi@ietf.org>; Wed,  8 Jun 2011 17:22:07 -0700 (PDT)
Received: (qmail invoked by alias); 09 Jun 2011 00:22:05 -0000
Received: from dslb-094-222-153-106.pools.arcor-ip.net (EHLO HIVE) [94.222.153.106] by mail.gmx.net (mp071) with SMTP; 09 Jun 2011 02:22:05 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX18T8/IIsA0Tb7VPcyzzZlmu2GYQ/NhpCYMvGZobYV pj4mb0JkzI5D0i
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Date: Thu, 09 Jun 2011 02:22:10 +0200
Message-ID: <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" <hybi@ietf.org>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 00:22:11 -0000

* Gabriel Montenegro wrote:
>About compression: Greg already expressed this feeling on the mailing
>list and there was very strong opposition. At this point, Iâ€™d rather we 
>not make such big changes. Letâ€™s limit 09 to nits and typos.

I don't care much about the next draft, but at some point we'll need a
draft that addresses the known issues, so we can then have a working
group last call to be sure that that the known issues have indeed been
addressed so we can then ask the IESG to consider the document for pub-
lication. When should we make the big changes to compression so we can
move forward on that issue?

(It is possible you might mean that the next draft is meant as just a
bit of polish as last step before an IETF Last Call, so we are really
past a point where we would consider "big changes". I do not believe
that is the case, we haven't, for instance, been getting any comments
from the W3C who work on the browser API for Websockets, on the
document, that I've seen anyway; and I haven't done any review in April
when you announced a Last Call myself, since we still had to make "big
changes" like to compression at that point. Overall, there has been a
distinct lack of review of the document so far. Greg Wilkins noted he
found the Last Call premature. I very much agree.)

As an aside, I am not aware of any opposition to address the security
concerns I noted with respect to `deflate-stream` back in April.
-- 
BjÃ¶rn HÃ¶hrmann Â· mailto:bjoern@hoehrmann.de Â· http://bjoern.hoehrmann.de
Am Badedeich 7 Â· Telefon: +49(0)160/4415681 Â· http://www.bjoernsworld.de
25899 DagebÃ¼ll Â· PGP Pub. KeyID: 0xA4357E78 Â· http://www.websitedev.de/ 

From ifette@google.com  Wed Jun  8 17:27:02 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE2211E8085 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 17:27:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Zm1TboSOvl2 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 17:27:01 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 28A3B11E8080 for <hybi@ietf.org>; Wed,  8 Jun 2011 17:27:00 -0700 (PDT)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p590QxW2016043 for <hybi@ietf.org>; Wed, 8 Jun 2011 17:26:59 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307579220; bh=Rhp06XL6nKnENIgVUftjWD8FHd0=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=b1g8Yx7eTVjTDX9Y5/+Mxq7i42qqkNpuFfm2+b3jGJgCO8GWEZelHA/PPfUYqxHfg T1YFX5/X5DOt9qF1YLK8Q==
Received: from qwb7 (qwb7.prod.google.com [10.241.193.71]) by kpbe14.cbf.corp.google.com with ESMTP id p590Qvxk008291 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 8 Jun 2011 17:26:58 -0700
Received: by qwb7 with SMTP id 7so649210qwb.40 for <hybi@ietf.org>; Wed, 08 Jun 2011 17:26:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QtLP+1pcWyAEYonTJP+MsY5TZ5RTSpF8RSPAwgCKgQs=; b=Ym1kUrPvC9U0bD6ZRGIfd85wEl68SlHUy3gktd0r3jHkxZkuW+ls8zZp4RPl7N7TIh jBzy6D21A+DxxjGL7BpA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=kXoFk0qIlDZlJRo7uih5Aku4Syj/piqFSH4PC2CyySfCckI/q1TpojIWTJfaeeVS14 lvg3t5ommEiak2JbPndg==
MIME-Version: 1.0
Received: by 10.229.44.198 with SMTP id b6mr60638qcf.67.1307579217366; Wed, 08 Jun 2011 17:26:57 -0700 (PDT)
Received: by 10.229.78.206 with HTTP; Wed, 8 Jun 2011 17:26:57 -0700 (PDT)
In-Reply-To: <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de>
Date: Wed, 8 Jun 2011 17:26:57 -0700
Message-ID: <BANLkTinBM1+s2J_qAmnUz5OEy_yjU38C9Q@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: multipart/alternative; boundary=0016364184ffc44e6004a53c829b
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 00:27:02 -0000

--0016364184ffc44e6004a53c829b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 8, 2011 at 5:22 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Gabriel Montenegro wrote:
> >About compression: Greg already expressed this feeling on the mailing
> >list and there was very strong opposition. At this point, I=E2=80=99d ra=
ther we
> >not make such big changes. Let=E2=80=99s limit 09 to nits and typos.
>
> I don't care much about the next draft, but at some point we'll need a
> draft that addresses the known issues, so we can then have a working
> group last call to be sure that that the known issues have indeed been
> addressed so we can then ask the IESG to consider the document for pub-
> lication. When should we make the big changes to compression so we can
> move forward on that issue?
>
> (It is possible you might mean that the next draft is meant as just a
> bit of polish as last step before an IETF Last Call, so we are really
> past a point where we would consider "big changes". I do not believe
> that is the case, we haven't, for instance, been getting any comments
> from the W3C who work on the browser API for Websockets, on the
> document, that I've seen anyway; and I haven't done any review in April
> when you announced a Last Call myself, since we still had to make "big
> changes" like to compression at that point. Overall, there has been a
> distinct lack of review of the document so far. Greg Wilkins noted he
> found the Last Call premature. I very much agree.)
>
>
>From the W3C side, Hixie and I have gone over it and he just published a ne=
w
API spec a day or two ago that properly lines up the two documents.



> As an aside, I am not aware of any opposition to address the security
> concerns I noted with respect to `deflate-stream` back in April.
> --
> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://=
bjoern.hoehrmann.de
> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern=
sworld.de
> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w=
ebsitedev.de/
>

--0016364184ffc44e6004a53c829b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 8, 2011 at 5:22 PM, Bjoern Hoehrmann=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:derhoermi@gmx.net">derhoermi@gmx.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">* Gabriel Montenegro wrote:<br>
&gt;About compression: Greg already expressed this feeling on the mailing<b=
r>
&gt;list and there was very strong opposition. At this point, I=E2=80=99d r=
ather we<br>
&gt;not make such big changes. Let=E2=80=99s limit 09 to nits and typos.<br=
>
<br>
</div>I don&#39;t care much about the next draft, but at some point we&#39;=
ll need a<br>
draft that addresses the known issues, so we can then have a working<br>
group last call to be sure that that the known issues have indeed been<br>
addressed so we can then ask the IESG to consider the document for pub-<br>
lication. When should we make the big changes to compression so we can<br>
move forward on that issue?<br>
<br>
(It is possible you might mean that the next draft is meant as just a<br>
bit of polish as last step before an IETF Last Call, so we are really<br>
past a point where we would consider &quot;big changes&quot;. I do not beli=
eve<br>
that is the case, we haven&#39;t, for instance, been getting any comments<b=
r>
from the W3C who work on the browser API for Websockets, on the<br>
document, that I&#39;ve seen anyway; and I haven&#39;t done any review in A=
pril<br>
when you announced a Last Call myself, since we still had to make &quot;big=
<br>
changes&quot; like to compression at that point. Overall, there has been a<=
br>
distinct lack of review of the document so far. Greg Wilkins noted he<br>
found the Last Call premature. I very much agree.)<br>
<br></blockquote><div><br></div><div>From the W3C side, Hixie and I have go=
ne over it and he just published a new API spec a day or two ago that prope=
rly lines up the two documents.</div><div><br></div><div>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex;">

As an aside, I am not aware of any opposition to address the security<br>
concerns I noted with respect to `deflate-stream` back in April.<br>
<font color=3D"#888888">--<br>
Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:<a href=3D"mailto:bjoern@hoehrmann.d=
e">bjoern@hoehrmann.de</a> =C2=B7 <a href=3D"http://bjoern.hoehrmann.de" ta=
rget=3D"_blank">http://bjoern.hoehrmann.de</a><br>
Am Badedeich 7 =C2=B7 Telefon: <a href=3D"tel:%2B49%280%29160%2F4415681" va=
lue=3D"+491604415681">+49(0)160/4415681</a> =C2=B7 <a href=3D"http://www.bj=
oernsworld.de" target=3D"_blank">http://www.bjoernsworld.de</a><br>
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 <a href=3D"htt=
p://www.websitedev.de/" target=3D"_blank">http://www.websitedev.de/</a><br>
</font></blockquote></div><br>

--0016364184ffc44e6004a53c829b--

From gregw@intalio.com  Wed Jun  8 18:02:08 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CDA11E8080 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 18:02:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxT0p8QVOoRn for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 18:02:06 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3E341F0C35 for <hybi@ietf.org>; Wed,  8 Jun 2011 18:01:51 -0700 (PDT)
Received: by vxg33 with SMTP id 33so1120691vxg.31 for <hybi@ietf.org>; Wed, 08 Jun 2011 18:01:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.18.11 with SMTP id s11mr128310vdd.269.1307581311290; Wed, 08 Jun 2011 18:01:51 -0700 (PDT)
Received: by 10.52.108.35 with HTTP; Wed, 8 Jun 2011 18:01:51 -0700 (PDT)
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Date: Thu, 9 Jun 2011 11:01:51 +1000
Message-ID: <BANLkTikDaEYSdb0oTendrpmjL5LioOc9Ww@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 01:02:08 -0000

On 9 June 2011 09:28, Gabriel Montenegro
<Gabriel.Montenegro@microsoft.com> wrote:
> About compression: Greg already expressed this feeling on the mailing list
> and there was very strong opposition.

I agree that there are strong opinions for and against stream compression.

Typically such division should mean that such a feature should not be
put into the draft.  But unfortunately, as has happened all to often
with this process, the feature was put in without much discussion and
we now have to argue to have it removed.  So the status quo is the
inclusion of a non consensus feature.

I really do not see how we can go forward with an optional feature
that does not have consensus support, that contradicts the rest of the
specification on what an extension is able to do and has some
unresolved security questions about it.

regards

From derhoermi@gmx.net  Wed Jun  8 18:08:36 2011
Return-Path: <derhoermi@gmx.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9459411E80A8 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 18:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9euELcMLdSUU for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 18:08:35 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 7A6F511E8080 for <hybi@ietf.org>; Wed,  8 Jun 2011 18:08:33 -0700 (PDT)
Received: (qmail invoked by alias); 09 Jun 2011 01:08:31 -0000
Received: from dslb-094-222-153-106.pools.arcor-ip.net (EHLO HIVE) [94.222.153.106] by mail.gmx.net (mp043) with SMTP; 09 Jun 2011 03:08:31 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19yRxkLerdyx9hVBQWedeYgwko1E8bjCAK9vAuEhu TsF9pr4tdc9UWr
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: ifette@google.com
Date: Thu, 09 Jun 2011 03:08:36 +0200
Message-ID: <1660v6ps0d8t6qfbb0lgvnvueggk59tfei@hive.bjoern.hoehrmann.de>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de> <BANLkTinBM1+s2J_qAmnUz5OEy_yjU38C9Q@mail.gmail.com>
In-Reply-To: <BANLkTinBM1+s2J_qAmnUz5OEy_yjU38C9Q@mail.gmail.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 01:08:36 -0000

* Ian Fette wrote:
>From the W3C side, Hixie and I have gone over it and he just published a new
>API spec a day or two ago that properly lines up the two documents.

I think it is good that you help "Hixie" with his editing duties. But we
do need to know if there are any problems with the documents we work on.
I have not seen a representative of the W3C tell us of any problems, or
tell us they reviewed the draft and found no problems. In either case, I
would expect there to be mails in the list archive detailing either, but
I am not aware of, and haven't found when searching, any to this end. If
"Hixie" did provide comments on our documents, I would welcome pointers
to them.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From ifette@google.com  Wed Jun  8 19:17:00 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB2B311E80D9 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 19:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.428
X-Spam-Level: 
X-Spam-Status: No, score=-105.428 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2BLtiEhEvcim for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 19:16:59 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0A71211E8074 for <hybi@ietf.org>; Wed,  8 Jun 2011 19:16:58 -0700 (PDT)
Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p592GwdW010259 for <hybi@ietf.org>; Wed, 8 Jun 2011 19:16:58 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307585818; bh=WdGtqdUu3+jX7SlIJUqekF6JOLY=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=NLY4r2Ohoax6wgU4/8iPAc9TOhuoyiNHUDbliFyqRkurE6IA3sqZa4/JtdtSdZK6X o8UUzLSmoNhIbFbyPFWsw==
Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by wpaz24.hot.corp.google.com with ESMTP id p592Giww001197 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 8 Jun 2011 19:16:57 -0700
Received: by qwj9 with SMTP id 9so735454qwj.21 for <hybi@ietf.org>; Wed, 08 Jun 2011 19:16:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7WNoBjtzu/3L46q4NbZNkWZ1tgAa9Z+ocWn820bcOG8=; b=m3u0bXJZYprxFoEfqOXdBYmBRyIBY4ZeuqiY4Fy2PRyF/n/Iypk6Gs+VQlmqFrK9pg u9vwIJrWTdt3D1hABK7w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=XTlQ7nHNdxvCsM2L826G68iEG08l/m7SRV71wM0g5ZzqJedkIejYUF/OSXQqqTZXIu WuN3EOVQSnYvMyKh+0gw==
MIME-Version: 1.0
Received: by 10.229.118.78 with SMTP id u14mr115667qcq.29.1307585816810; Wed, 08 Jun 2011 19:16:56 -0700 (PDT)
Received: by 10.229.78.206 with HTTP; Wed, 8 Jun 2011 19:16:56 -0700 (PDT)
In-Reply-To: <1660v6ps0d8t6qfbb0lgvnvueggk59tfei@hive.bjoern.hoehrmann.de>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de> <BANLkTinBM1+s2J_qAmnUz5OEy_yjU38C9Q@mail.gmail.com> <1660v6ps0d8t6qfbb0lgvnvueggk59tfei@hive.bjoern.hoehrmann.de>
Date: Wed, 8 Jun 2011 19:16:56 -0700
Message-ID: <BANLkTimU0a=3=vAOsQR-We-c-CU+HniMRQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: multipart/alternative; boundary=000e0cd5f4aa1fd71204a53e0c3f
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 02:17:00 -0000

--000e0cd5f4aa1fd71204a53e0c3f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 8, 2011 at 6:08 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:

> * Ian Fette wrote:
> >From the W3C side, Hixie and I have gone over it and he just published a
> new
> >API spec a day or two ago that properly lines up the two documents.
>
> I think it is good that you help "Hixie" with his editing duties. But we
> do need to know if there are any problems with the documents we work on.
> I have not seen a representative of the W3C tell us of any problems, or
> tell us they reviewed the draft and found no problems. In either case, I
> would expect there to be mails in the list archive detailing either, but
> I am not aware of, and haven't found when searching, any to this end. If
> "Hixie" did provide comments on our documents, I would welcome pointers
> to them.
>

Hixie is the editor of the HTML spec. He pointed out problems, they were
addressed. I've a series of emails from him that I am happy to share if he
does not mind (there's nothing private in them, but I don't make a habit of
forwarding private correspondence.) As we have the luxury of meeting
face-to-face, there were also face-to-face discussions to resolve stickier
issues, along with a few late night IRC sessions on #whatwg.

Largely the issues were not substantive. The spec has not changed much from
the API perspective, the exception being exposing the extensions that were
negotiated in the handshake via the API, and some semantics around whether
onError() is necessary or not and how that interacts with the WebSocket
Close Status Codes. That has been aligned in his latest spec. The rest was
just "I need hooks for this" e.g. "How do I send data? What is the algorith=
m
/ section of the spec I reference to send data?".

Finally, I'm not sure what you expect to get from W3C that you're not
getting from the people on this list. You've got the people implementing th=
e
API watching this list, that's the same subset of the people from W3C that
would provide meaningful commentary about the spec.


> --
> Bj=C3=B6rn H=C3=B6hrmann =C2=B7 mailto:bjoern@hoehrmann.de =C2=B7 http://=
bjoern.hoehrmann.de
> Am Badedeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoern=
sworld.de
> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://www.w=
ebsitedev.de/
>

--000e0cd5f4aa1fd71204a53e0c3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 8, 2011 at 6:08 PM, Bjoern Hoehrmann=
 <span dir=3D"ltr">&lt;<a href=3D"mailto:derhoermi@gmx.net">derhoermi@gmx.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">* Ian Fette wrote:<br>
&gt;From the W3C side, Hixie and I have gone over it and he just published =
a new<br>
&gt;API spec a day or two ago that properly lines up the two documents.<br>
<br>
</div>I think it is good that you help &quot;Hixie&quot; with his editing d=
uties. But we<br>
do need to know if there are any problems with the documents we work on.<br=
>
I have not seen a representative of the W3C tell us of any problems, or<br>
tell us they reviewed the draft and found no problems. In either case, I<br=
>
would expect there to be mails in the list archive detailing either, but<br=
>
I am not aware of, and haven&#39;t found when searching, any to this end. I=
f<br>
&quot;Hixie&quot; did provide comments on our documents, I would welcome po=
inters<br>
to them.<br></blockquote><div><br></div><div>Hixie is the editor of the HTM=
L spec. He pointed out problems, they were addressed. I&#39;ve a series of =
emails from him that I am happy to share if he does not mind (there&#39;s n=
othing private in them, but I don&#39;t make a habit of forwarding private =
correspondence.) As we have the luxury of meeting face-to-face, there were =
also face-to-face discussions to resolve stickier issues, along with a few =
late night IRC sessions on #whatwg.</div>
<div><br></div><div>Largely the issues were not substantive. The spec has n=
ot changed much from the API perspective, the exception being exposing the =
extensions that were negotiated in the handshake via the API, and some sema=
ntics around whether onError() is necessary or not and how that interacts w=
ith the WebSocket Close Status Codes. That has been aligned in his latest s=
pec. The rest was just &quot;I need hooks for this&quot; e.g. &quot;How do =
I send data? What is the algorithm / section of the spec I reference to sen=
d data?&quot;.</div>
<div><br></div><div>Finally, I&#39;m not sure what you expect to get from W=
3C that you&#39;re not getting from the people on this list. You&#39;ve got=
 the people implementing the API watching this list, that&#39;s the same su=
bset of the people from W3C that would provide meaningful commentary about =
the spec.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color=3D"#888888">--<br>
</font><div><div></div><div class=3D"h5">Bj=C3=B6rn H=C3=B6hrmann =C2=B7 ma=
ilto:<a href=3D"mailto:bjoern@hoehrmann.de">bjoern@hoehrmann.de</a> =C2=B7 =
<a href=3D"http://bjoern.hoehrmann.de" target=3D"_blank">http://bjoern.hoeh=
rmann.de</a><br>
Am Badedeich 7 =C2=B7 Telefon: <a href=3D"tel:%2B49%280%29160%2F4415681" va=
lue=3D"+491604415681">+49(0)160/4415681</a> =C2=B7 <a href=3D"http://www.bj=
oernsworld.de" target=3D"_blank">http://www.bjoernsworld.de</a><br>
25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 <a href=3D"htt=
p://www.websitedev.de/" target=3D"_blank">http://www.websitedev.de/</a><br>
</div></div></blockquote></div><br>

--000e0cd5f4aa1fd71204a53e0c3f--

From tyoshino@google.com  Wed Jun  8 20:21:32 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACBF211E8084 for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 20:21:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.223
X-Spam-Level: 
X-Spam-Status: No, score=-104.223 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EtG2wHv1cPrT for <hybi@ietfa.amsl.com>; Wed,  8 Jun 2011 20:21:32 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 337A811E80D9 for <hybi@ietf.org>; Wed,  8 Jun 2011 20:21:29 -0700 (PDT)
Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p593LTms024990 for <hybi@ietf.org>; Wed, 8 Jun 2011 20:21:29 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307589689; bh=qA0QayenOD3mOX7zwHGYvm3GNZ4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=g6+vJvE/6iVmWmZBkhDEdsqqwVeXKBIFgGGBgRKkjUcVBk5WetLGGWVgUNDmjLGfH Sx/TTJ+NGMYMUpKoMclkg==
Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by hpaq1.eem.corp.google.com with ESMTP id p593KQYS022003 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 8 Jun 2011 20:21:27 -0700
Received: by ywf9 with SMTP id 9so856475ywf.22 for <hybi@ietf.org>; Wed, 08 Jun 2011 20:21:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RcQE7uk6xt+BNiCBB7EvmksIZtFnbXmeQzxmEuY++DE=; b=nt5N3zZv5JIfl5Qk1F+qcO8ToDhOPH5K38AEV0VAY7YiR0ecmwBsFB0gun1/gRpza8 5PkuTfSiX1ZmTaJEMfNg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lDvAPt7+SJ9Dnaj8qMsx0rJh+Ei6LzQHL5BM/EbYqcBqAVdIigZiVXavCdoJBoOBZO iuwllqdXwwBJ4MCS/vpg==
Received: by 10.150.208.8 with SMTP id f8mr1517708ybg.399.1307589687139; Wed, 08 Jun 2011 20:21:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.13 with HTTP; Wed, 8 Jun 2011 20:21:07 -0700 (PDT)
In-Reply-To: <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 9 Jun 2011 12:21:07 +0900
Message-ID: <BANLkTikD-WFE+uctHGovg9atezSd9nEe_N6aLsog5X65pS2xkw@mail.gmail.com>
To: Ian Fette <ifette@google.com>
Content-Type: multipart/alternative; boundary=000e0cdf1a60d05ccb04a53ef214
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 03:21:32 -0000

--000e0cdf1a60d05ccb04a53ef214
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

On Thu, Jun 9, 2011 at 08:23, Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>wrote:

> On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <gregw@intalio.com> wrote:
>
>>  * The fragments of one message may not be interleaved between the
>
> fragments of another message unless an extension has been negotiated
>> that can interpret the interleaving.
>>
>
> anyone else have thoughts here? it seems reasonable to me but I'd like to
> hear other opinions.
>

I think it's good for clarification (though when we read the fragmentation
spec, it's clear that interleaving doesn't work without extension).

It's a small edit.

--000e0cdf1a60d05ccb04a53ef214
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFRodSwgSnVuIDksIDIwMTEgYXQgMDg6MjMsIElh
biBGZXR0ZSAoGyRCJSQlIiVzJVUlJyVDJUYlIxsoQikgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBo
cmVmPSJtYWlsdG86aWZldHRlQGdvb2dsZS5jb20iPmlmZXR0ZUBnb29nbGUuY29tPC9hPiZndDs8
L3NwYW4+IHdyb3RlOjxicj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJt
YXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6
MWV4OyI+Cgo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBjbGFzcz0iaW0iPk9uIFdlZCwg
SnVuIDgsIDIwMTEgYXQgNDowMyBQTSwgR3JlZyBXaWxraW5zIDxzcGFuIGRpcj0ibHRyIj4mbHQ7
PGEgaHJlZj0ibWFpbHRvOmdyZWd3QGludGFsaW8uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3JlZ3dA
aW50YWxpby5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPjxibG9ja3F1b3RlIGNsYXNzPSJn
bWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2Nj
IHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPgoKJm5ic3A7KiBUaGUgZnJhZ21lbnRzIG9mIG9uZSBt
ZXNzYWdlIG1heSBub3QgYmUgaW50ZXJsZWF2ZWQgYmV0d2VlbiB0aGU8L2Jsb2NrcXVvdGU+PC9k
aXY+PGRpdiBjbGFzcz0iaW0iPjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9
Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVm
dDoxZXgiPgpmcmFnbWVudHMgb2YgYW5vdGhlciBtZXNzYWdlIHVubGVzcyBhbiBleHRlbnNpb24g
aGFzIGJlZW4gbmVnb3RpYXRlZDxicj4KdGhhdCBjYW4gaW50ZXJwcmV0IHRoZSBpbnRlcmxlYXZp
bmcuPGJyPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2PmFueW9uZSBlbHNl
IGhhdmUgdGhvdWdodHMgaGVyZT8gaXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSBidXQgSSYjMzk7
ZCBsaWtlIHRvIGhlYXIgb3RoZXIgb3BpbmlvbnMuJm5ic3A7PC9kaXY+PC9kaXY+PC9ibG9ja3F1
b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+CgpJIHRoaW5rIGl0JiMzOTtzIGdvb2QgZm9yIGNsYXJp
ZmljYXRpb24gKHRob3VnaCB3aGVuIHdlIHJlYWQgdGhlIGZyYWdtZW50YXRpb24gc3BlYywgaXQm
IzM5O3MgY2xlYXIgdGhhdCBpbnRlcmxlYXZpbmcgZG9lc24mIzM5O3Qgd29yayB3aXRob3V0IGV4
dGVuc2lvbikuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JdCYjMzk7cyBhIHNtYWxsIGVkaXQu
PC9kaXY+PGRpdj48YnI+PC9kaXY+Cgo8L2Rpdj4K
--000e0cdf1a60d05ccb04a53ef214--

From andy.warmcat.com@googlemail.com  Thu Jun  9 00:38:55 2011
Return-Path: <andy.warmcat.com@googlemail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A530511E807D; Thu,  9 Jun 2011 00:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2sJMowpxsqB; Thu,  9 Jun 2011 00:38:55 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 238D911E8071; Thu,  9 Jun 2011 00:38:52 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1025970wyb.31 for <multiple recipients>; Thu, 09 Jun 2011 00:38:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=pUA5u26WnQH5AIy5H02hDcXXmDC5t7Dr10N5cBzn/wY=; b=Qw7ZgWlY+n1dK14PsDoMjtUc3oT29PR6SLFIo+XllK3KULFQXSXl44dB5x8y0n391Z FJ6SmUBUE5S42uVGTfz274ldLH1rAd8g3lrVH/H+/I2K+NS3XdDClZ5RgFwR7uAW8tqw blLQIg5bDUiLq9UWUr6lvG08XbxhWoXXrAotI=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=liK/UgG36Dk1TP4m9Sk0ihWWTjGDAsyG7e+iudndlSFEgyfvZfYxEJYdWAj9loUCwa kFxoTBT08L+14UO06zALW4pJ0g6W7DSRv+cosXrEymXEPa1a+Php/pMmpWr/aNzkAE/E tZNdQEW1wO+v3Kg52EviWjgH0mUhUVYnEbfRQ=
Received: by 10.227.11.131 with SMTP id t3mr388255wbt.113.1307605132161; Thu, 09 Jun 2011 00:38:52 -0700 (PDT)
Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id ge4sm996962wbb.47.2011.06.09.00.38.49 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 00:38:50 -0700 (PDT)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4DF07883.4070609@warmcat.com>
Date: Thu, 09 Jun 2011 08:38:43 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Internet-Drafts@ietf.org
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
In-Reply-To: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org, i-d-announce@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 07:38:55 -0000

On 06/08/2011 06:30 PM, Somebody in the thread at some point said:

>     Please send feedback to the hybi@ietf.org mailing list.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-08.txt

The diff is really big...

http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-08.txt

...I can see it has gotten tidier and more referential to existing TLAs 
but I had a hard time spotting what actually changed implementation-wise 
from -07 protocol.

Is there anything or we just crank the default version number up to 8?

-Andy

From djc.ochtman@gmail.com  Thu Jun  9 01:09:03 2011
Return-Path: <djc.ochtman@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D7F11E807D for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 01:09:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8O1p82NcUOjN for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 01:09:02 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8224A11E8071 for <hybi@ietf.org>; Thu,  9 Jun 2011 01:09:02 -0700 (PDT)
Received: by qwc23 with SMTP id 23so833297qwc.31 for <hybi@ietf.org>; Thu, 09 Jun 2011 01:09:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=t99KkWAM/Wifd4NrcNHe9GzeKlx/fvprVoUZlxA83Fk=; b=qVYg4k49xAwtyKoPNrH5vvo/FghvZXM6gi3JyvVhcvh/HMvLpAP6JAjHrvgTmG41ZW SUDYqhCV+CiO7AdMAjGd5wPDdHhK7cdSGN1BE5/L9Ee2p94HtqgbMX3G0WYdIIXShevf LkzEfCO3lWHCG3ukuaTzx7oHQFUk5ohK1u2V0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=GudkZciABrSWGbcUv0izb69AJYaXNnnUvtAl2qQWavJUI7YgjcoGLMprnZdsRW3BEd 2w3c4XbU1WBGcgYDHUMnukt4uxGyg2QK9CzGFgZ8nLlg4AXsaiIX8E4UaWE+DsFytRxy gXnGjorM3SUd7IvknO/y0skwBbOO3H/fuczes=
Received: by 10.229.7.2 with SMTP id b2mr263124qcb.179.1307606940128; Thu, 09 Jun 2011 01:09:00 -0700 (PDT)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.229.187.145 with HTTP; Thu, 9 Jun 2011 01:08:40 -0700 (PDT)
In-Reply-To: <4DF07883.4070609@warmcat.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Thu, 9 Jun 2011 10:08:40 +0200
X-Google-Sender-Auth: iHwLp_SpkTS5S6Z2YuDXsGkrXCA
Message-ID: <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= <andy@warmcat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 08:09:03 -0000

On Thu, Jun 9, 2011 at 09:38, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" <a=
ndy@warmcat.com> wrote:
> Is there anything or we just crank the default version number up to 8?

It looks like there are at least some differences:

- The extended payload length may now use 64 bits (instead of just 63).
- Invalid client handshake results in HTTP error instead of connection abor=
tion.
- Two new closure status codes (1005 and 1006).
- Specified handling of invalid UTF-8 on the client side.

I note that the remarks from my email (from May 30, [1]) seem to not
have had any impact on this draft. Did my message come to late to make
any changes to this draft, did my suggestions not make sense for
inclusion, or did I perhaps not follow the correct protocol for
suggesting improvements? (I noticed that the required server headers
*are* listed in the section on client acceptance of the server's
opening handshake, but not in the section on the server sending that
handshake.)

Two further questions on things that I feel could be clarified, in draft-08=
:

- This may be silly, but in the introduction text for the figure
(which is very useful!) in section 4.2, I wonder if it would be
helpful to state explicitly whether the bits are listed in big- or
little-endian order. For bytes, this is defined explicitly in the
descriptions, but I know that I was at least somewhat confused about
this (and got it wrong in my initial implementation). This might just
be my inexperience with diagrams/specs like this, so feel free to
ignore this.

- Section 4.5.1 (about status codes for Close frames) does not mention
anything about masking. I would presume that the status code bytes,
being part of the application data part of the frame, should be
masked, but perhaps it's worth pointing this out explicitly.

Cheers,

Dirkjan

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg07461.html

From andy.warmcat.com@googlemail.com  Thu Jun  9 01:18:00 2011
Return-Path: <andy.warmcat.com@googlemail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E10511E8071 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 01:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adnT265n5E0k for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 01:17:59 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F53611E807F for <hybi@ietf.org>; Thu,  9 Jun 2011 01:17:59 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1050576wyb.31 for <hybi@ietf.org>; Thu, 09 Jun 2011 01:17:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=DaIxX5FzM79WwaWj6Nc3iopB8Vrs5mavARISw3SLh44=; b=Qvu0g1PNbncKkN7ChSdH98If37AJpjskx/rbcWj5BMrCtuMZZt5NKmcv6kfiMLsxdE q4LhqTnhW2qQpyHD6eKjXBC+K11uBHyGdnKrFofP329MTjP6GSkLbVu3mcx16Yar4loW N4aDLziWLhv6nLV+APsiqfYjnBu87ln1B2lfQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=e6L/MfspfDwLcGMvnMKPPgf6sei03dja87rdDrIbTE5vw99Q1QO70yeImj2AUODZko 3ZdkSsHeh4MxULbNqf5I8WHouo6VQMSjWrpqURgUjZ64K1j9Hv3OyqUzKb36+nBqQoF9 fsE8qBPfSPKGYY+u3vB9wQlt/y9EMuiANlfmc=
Received: by 10.227.108.233 with SMTP id g41mr475933wbp.22.1307607478308; Thu, 09 Jun 2011 01:17:58 -0700 (PDT)
Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id ex2sm1023057wbb.31.2011.06.09.01.17.56 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 01:17:57 -0700 (PDT)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4DF081B3.1030808@warmcat.com>
Date: Thu, 09 Jun 2011 09:17:55 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Dirkjan Ochtman <dirkjan@ochtman.nl>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com> <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
In-Reply-To: <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 08:18:00 -0000

On 06/09/2011 09:08 AM, Somebody in the thread at some point said:
> On Thu, Jun 9, 2011 at 09:38, "Andy Green (æž—å®‰å»¸)"<andy@warmcat.com>  wrote:
>> Is there anything or we just crank the default version number up to 8?
>
> It looks like there are at least some differences:

Thanks for the summary.

> - The extended payload length may now use 64 bits (instead of just 63).

Well, that went in the wrong direction then.

> - Invalid client handshake results in HTTP error instead of connection abortion.

Seems important...

> - Two new closure status codes (1005 and 1006).
> - Specified handling of invalid UTF-8 on the client side.

OK.

> I note that the remarks from my email (from May 30, [1]) seem to not
> have had any impact on this draft.

Welcome to hybi ^^

-Andy

From Norio.Kobota@jp.sony.com  Thu Jun  9 02:28:43 2011
Return-Path: <Norio.Kobota@jp.sony.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA56811E80A7 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 02:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.495
X-Spam-Level: 
X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ydq1LH7cV630 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 02:28:43 -0700 (PDT)
Received: from ms6.sony.co.jp (ms6.sony.co.jp [IPv6:2001:cf8:0:56::204]) by ietfa.amsl.com (Postfix) with ESMTP id 1707611E8093 for <hybi@ietf.org>; Thu,  9 Jun 2011 02:28:41 -0700 (PDT)
Received: from mta8.sony.co.jp (mta8.sony.co.jp [IPv6:2001:cf8:0:191::15]) by ms6.sony.co.jp (R8/Sony) with ESMTP id p599SbuV019797 for <hybi@ietf.org>; Thu, 9 Jun 2011 18:28:37 +0900 (JST)
Received: from mta8.sony.co.jp (localhost [127.0.0.1]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p599SbhE014691 for <hybi@ietf.org>; Thu, 9 Jun 2011 18:28:37 +0900 (JST)
Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p599SbH6014521 for <hybi@ietf.org>; Thu, 9 Jun 2011 18:28:37 +0900 (JST)
Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 9 Jun 2011 18:28:31 +0900
Received: from [43.0.235.115] ([43.0.235.115]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 18:28:31 +0900
Message-ID: <4DF0923D.3070005@jp.sony.com>
Date: Thu, 09 Jun 2011 18:28:29 +0900
From: Norio Kobota <norio.kobota@jp.sony.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>	<4DF07883.4070609@warmcat.com> <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
In-Reply-To: <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 09 Jun 2011 09:28:31.0413 (UTC) FILETIME=[98DF8E50:01CC2687]
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 09:28:44 -0000

Hello,

I'm confused a little about the following matter.

 > - The extended payload length may now use 64 bits (instead of just 63).

The figure at section 4.2 shows Extended payload length(16/63).
But in text, payload length is 7+64 bits.(MSB==0)

Am I correct though I understood as follows?

1.extended payload length 'field' has 64 bit length.
2.but most significant bit must be 0.
3.so, the max size of extended payload length is equal to
   INT64_MAX(0x7fffffffffffffffLL)

Sincerely,

Nori

(2011/06/09 17:08), Dirkjan Ochtman wrote:
> On Thu, Jun 9, 2011 at 09:38, "Andy Green (æž—å®‰å»¸)"<andy@warmcat.com>  wrote:
>> Is there anything or we just crank the default version number up to 8?
>
> It looks like there are at least some differences:
>
> - The extended payload length may now use 64 bits (instead of just 63).
> - Invalid client handshake results in HTTP error instead of connection abortion.
> - Two new closure status codes (1005 and 1006).
> - Specified handling of invalid UTF-8 on the client side.
>
> I note that the remarks from my email (from May 30, [1]) seem to not
> have had any impact on this draft. Did my message come to late to make
> any changes to this draft, did my suggestions not make sense for
> inclusion, or did I perhaps not follow the correct protocol for
> suggesting improvements? (I noticed that the required server headers
> *are* listed in the section on client acceptance of the server's
> opening handshake, but not in the section on the server sending that
> handshake.)
>
> Two further questions on things that I feel could be clarified, in draft-08:
>
> - This may be silly, but in the introduction text for the figure
> (which is very useful!) in section 4.2, I wonder if it would be
> helpful to state explicitly whether the bits are listed in big- or
> little-endian order. For bytes, this is defined explicitly in the
> descriptions, but I know that I was at least somewhat confused about
> this (and got it wrong in my initial implementation). This might just
> be my inexperience with diagrams/specs like this, so feel free to
> ignore this.
>
> - Section 4.5.1 (about status codes for Close frames) does not mention
> anything about masking. I would presume that the status code bytes,
> being part of the application data part of the frame, should be
> masked, but perhaps it's worth pointing this out explicitly.
>
> Cheers,
>
> Dirkjan
>
> [1] http://www.ietf.org/mail-archive/web/hybi/current/msg07461.html
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


From tyoshino@google.com  Thu Jun  9 03:06:38 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7721011E80BD for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:06:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.1
X-Spam-Level: 
X-Spam-Status: No, score=-105.1 tagged_above=-999 required=5 tests=[AWL=0.877,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEQx-pN6wxkI for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:06:37 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B168511E80B1 for <hybi@ietf.org>; Thu,  9 Jun 2011 03:06:37 -0700 (PDT)
Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p59A6auK008353 for <hybi@ietf.org>; Thu, 9 Jun 2011 03:06:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307613996; bh=cMrtunPtJ44UxYg2r+cDZGkGFiY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ezMDEMzMVPlMuom0tdyZvw7vNyI/9fSC/qGzc5QK+EyILJoVQ5bxKZNUbuxUE9ahf 1vDMbi5wOuaSVwB9W/3LA==
Received: from yib18 (yib18.prod.google.com [10.243.65.82]) by kpbe19.cbf.corp.google.com with ESMTP id p59A6YNH017466 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 9 Jun 2011 03:06:35 -0700
Received: by yib18 with SMTP id 18so1048242yib.31 for <hybi@ietf.org>; Thu, 09 Jun 2011 03:06:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tVGvi1k6ilwZ6wpJSXHpEFBTpOTtYJKvRAhw6XG17Cw=; b=t1yQ9nUZQK53m8WpezqcnVKfsm2liPms8mwpKEEt74wuxv4+OKdoOq+rusbvmHeZJl qSU98+RBgxXFNJ4ST/2g==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=TKlYEK4/LRcaLaXbWbm4dNNp6EnS+J862evnAlxvZLKQa4PXie5SFp0wnyoVfy3xQk 3Q+mD1S6AZwTMT+WOAPA==
Received: by 10.91.33.27 with SMTP id l27mr1793852agj.136.1307613994595; Thu, 09 Jun 2011 03:06:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.218.9 with HTTP; Thu, 9 Jun 2011 03:06:13 -0700 (PDT)
In-Reply-To: <4DF0923D.3070005@jp.sony.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com> <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com> <4DF0923D.3070005@jp.sony.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 9 Jun 2011 19:06:13 +0900
Message-ID: <BANLkTinq4e5cQWc+eAPcn3A6ZCgfA4pGWYOdxQ=j78jzA7EZqg@mail.gmail.com>
To: Norio Kobota <norio.kobota@jp.sony.com>
Content-Type: multipart/alternative; boundary=0016e640cbfea6b4a904a5449bbd
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 10:06:38 -0000

--0016e640cbfea6b4a904a5449bbd
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 9, 2011 at 18:28, Norio Kobota <norio.kobota@jp.sony.com> wrote:

> > - The extended payload length may now use 64 bits (instead of just 63).
>
> The figure at section 4.2 shows Extended payload length(16/63).
> But in text, payload length is 7+64 bits.(MSB==0)
>

Values written after each field in Section 4.2 are the number of bits each
field occupies. Extended payload field occupies 64 bits but still can hold
only value <= 0x7fffffffffffffff.

It may be a bit confusing that the diagram is using 63 instead of actual
field length of 64.


> Am I correct though I understood as follows?
>
> 1.extended payload length 'field' has 64 bit length.
>

yes


> 2.but most significant bit must be 0.
>

yes


> 3.so, the max size of extended payload length is equal to
>  INT64_MAX(0x7fffffffffffffffLL)
>

yes

--0016e640cbfea6b4a904a5449bbd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jun 9, 2011 at 18:28, Norio Kobota <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:norio.kobota@jp.sony.com">norio.kobota@j=
p.sony.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">&gt; - The extended payload length may now use 64 bits (i=
nstead of just 63).<br>
<br></div>
The figure at section 4.2 shows Extended payload length(16/63).<br>
But in text, payload length is 7+64 bits.(MSB=3D=3D0)<br></blockquote><div>=
<br></div><div>Values written after each field in Section 4.2 are the numbe=
r of bits each field occupies. Extended payload field occupies 64 bits but =
still can hold only value &lt;=3D 0x7fffffffffffffff.</div>

<div><br></div><div><div>It may be a bit confusing that the diagram is usin=
g 63 instead of actual field length of 64.</div></div><div>=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex;">


Am I correct though I understood as follows?<br>
<br>
1.extended payload length &#39;field&#39; has 64 bit length.<br></blockquot=
e><div><br></div><div>yes</div><div>=A0</div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;=
">


2.but most significant bit must be 0.<br></blockquote><div><br></div><div>y=
es</div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
3.so, the max size of extended payload length is equal to<br>
 =A0INT64_MAX(0x7fffffffffffffffLL)<br></blockquote><div><br></div><div>yes=
</div><div><br></div></div>

--0016e640cbfea6b4a904a5449bbd--

From djc.ochtman@gmail.com  Thu Jun  9 03:13:54 2011
Return-Path: <djc.ochtman@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960DF11E80C4 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Level: 
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MR0YuZ51suIR for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:13:53 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id D52BF11E80C3 for <hybi@ietf.org>; Thu,  9 Jun 2011 03:13:51 -0700 (PDT)
Received: by qyk7 with SMTP id 7so834396qyk.10 for <hybi@ietf.org>; Thu, 09 Jun 2011 03:13:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=nAsxb27bL+a7i3i7Dx28A2srCJw5dLPtUDge5oCnQvI=; b=v7N+fjilWWDHW9DPaOk1og/yTv+ogZNdZny8gOg/5RD0Csm5NHeDJmjlMvc7G2Ds4/ VUBkq7Hue5aygd39IfFRyZ74nd8z4jtPN/WMGtvZdgZ45LYwfEeMJkOD9kuc0XLB6zg1 XwtC+RjKgva3KGNouc3cKsrWowT3QMqyLi7S8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=IDc2Xl/3cevx/mgvfpjX3p0ZSj5Dt6t7e1ZO+Gsh5MHhyDseFMbmGKVQsymcGHN9Ff FeTa3umZhD3Cyy+yPu/KaEymGtVGMibWFIiuL1mUpRA+NpnPntnhT5U50zXO083LlnlD HhmElTPfdsvzOpqfnBNy8C2UsqEyJYc/4vxH4=
Received: by 10.229.34.130 with SMTP id l2mr317529qcd.293.1307614414113; Thu, 09 Jun 2011 03:13:34 -0700 (PDT)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.229.187.145 with HTTP; Thu, 9 Jun 2011 03:13:14 -0700 (PDT)
In-Reply-To: <4DF0923D.3070005@jp.sony.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com> <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com> <4DF0923D.3070005@jp.sony.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Thu, 9 Jun 2011 12:13:14 +0200
X-Google-Sender-Auth: Vr8499_l6win2z_7972GjRQkWCg
Message-ID: <BANLkTinvJBEbsnFJdQQzudx3T1vx0nCatg@mail.gmail.com>
To: Norio Kobota <norio.kobota@jp.sony.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 10:13:54 -0000

On Thu, Jun 9, 2011 at 11:28, Norio Kobota <norio.kobota@jp.sony.com> wrote=
:
>> - The extended payload length may now use 64 bits (instead of just 63).
>
> The figure at section 4.2 shows Extended payload length(16/63).
> But in text, payload length is 7+64 bits.(MSB=3D=3D0)
>
> Am I correct though I understood as follows?
>
> 1.extended payload length 'field' has 64 bit length.
> 2.but most significant bit must be 0.
> 3.so, the max size of extended payload length is equal to
> =C2=A0INT64_MAX(0x7fffffffffffffffLL)

Yes, I got my reading wrong. The new draft removes one mention of the
effective 63-bits limit of the length field, but the mandate for
zeroing the most significant bit is still there.

Cheers,

Dirkjan

From Norio.Kobota@jp.sony.com  Thu Jun  9 03:18:02 2011
Return-Path: <Norio.Kobota@jp.sony.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA4211E80E8 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.292
X-Spam-Level: 
X-Spam-Status: No, score=-0.292 tagged_above=-999 required=5 tests=[AWL=-0.203, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSHW3RFGrptA for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:18:00 -0700 (PDT)
Received: from ms5.sony.co.jp (ms5.sony.co.jp [IPv6:2001:cf8:0:56::201]) by ietfa.amsl.com (Postfix) with ESMTP id 4F34811E80B5 for <hybi@ietf.org>; Thu,  9 Jun 2011 03:17:58 -0700 (PDT)
Received: from mta6.sony.co.jp (mta6.sony.co.jp [137.153.71.9]) by ms5.sony.co.jp (R8/Sony) with ESMTP id p59AHsjs000810 for <hybi@ietf.org>; Thu, 9 Jun 2011 19:17:54 +0900 (JST)
Received: from mta6.sony.co.jp (localhost [127.0.0.1]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p59AHren025143 for <hybi@ietf.org>; Thu, 9 Jun 2011 19:17:53 +0900 (JST)
Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta6.sony.co.jp (R8/Sony) with ESMTP id p59AHr9K025102 for <hybi@ietf.org>; Thu, 9 Jun 2011 19:17:53 +0900 (JST)
Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 9 Jun 2011 19:17:46 +0900
Received: from [43.0.235.115] ([43.0.235.115]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 9 Jun 2011 19:17:46 +0900
Message-ID: <4DF09DC7.306@jp.sony.com>
Date: Thu, 09 Jun 2011 19:17:43 +0900
From: Norio Kobota <norio.kobota@jp.sony.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Takeshi Yoshino <tyoshino@google.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com> <BANLkTimQn-6AbRrk_2FWOZ7WS1fSRu=9Ag@mail.gmail.com> <4DF0923D.3070005@jp.sony.com> <BANLkTinq4e5cQWc+eAPcn3A6ZCgfA4pGWYOdxQ=j78jzA7EZqg@mail.gmail.com>
In-Reply-To: <BANLkTinq4e5cQWc+eAPcn3A6ZCgfA4pGWYOdxQ=j78jzA7EZqg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Jun 2011 10:17:46.0060 (UTC) FILETIME=[79FAE8C0:01CC268E]
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 10:18:02 -0000

Thanks!

(2011/06/09 19:06), Takeshi Yoshino wrote:
> On Thu, Jun 9, 2011 at 18:28, Norio Kobota <norio.kobota@jp.sony.com
> <mailto:norio.kobota@jp.sony.com>> wrote:
>
>      > - The extended payload length may now use 64 bits (instead of
>     just 63).
>
>     The figure at section 4.2 shows Extended payload length(16/63).
>     But in text, payload length is 7+64 bits.(MSB==0)
>
>
> Values written after each field in Section 4.2 are the number of bits
> each field occupies. Extended payload field occupies 64 bits but still
> can hold only value <= 0x7fffffffffffffff.
>
> It may be a bit confusing that the diagram is using 63 instead of actual
> field length of 64.
>
>     Am I correct though I understood as follows?
>
>     1.extended payload length 'field' has 64 bit length.
>
>
> yes
>
>     2.but most significant bit must be 0.
>
>
> yes
>
>     3.so, the max size of extended payload length is equal to
>       INT64_MAX(0x7fffffffffffffffLL)
>
>
> yes
>


From dilmah@google.com  Thu Jun  9 03:18:55 2011
Return-Path: <dilmah@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3FB11E80F8 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:18:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e2C5Bt7RVqgb for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:18:55 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 05AF811E80F2 for <hybi@ietf.org>; Thu,  9 Jun 2011 03:18:54 -0700 (PDT)
Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p59AIsk0014498 for <hybi@ietf.org>; Thu, 9 Jun 2011 03:18:54 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307614734; bh=Zr+TyxrSzbu7/yh12p3jnvlizlA=; h=MIME-Version:Sender:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=QnlwyotGE0nsWeHMzm6CIZ7XnpVtz7f25vPcaTVB+9waRxxHYpdyMnk+LOE3xW9DP jamsJ2hse4cXosLLuvjHw==
Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by hpaq11.eem.corp.google.com with ESMTP id p59AIqiA015504 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 9 Jun 2011 03:18:52 -0700
Received: by qyk29 with SMTP id 29so2474415qyk.3 for <hybi@ietf.org>; Thu, 09 Jun 2011 03:18:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yjZBr3drEfhtgvmIOQwFgYeg4oYaFWN/lSaVkuEneRc=; b=cTMYkDPl812SUtHVBaZbW8zmXnQldwRSaVKyqtiO/d5M+uYtF0dN4Tnp+Zj1XEsL6n WWjfOZBCnD8jODGntPAg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=U4GwPrbduOFpmPsdc7keO90+mzuJZA4dC0BWZ5gDIBA+iyVNZ+pn06/phlx3xuT5ko b6rHqUOxDKwjb6LmLyUQ==
MIME-Version: 1.0
Received: by 10.229.78.96 with SMTP id j32mr355032qck.121.1307614731553; Thu, 09 Jun 2011 03:18:51 -0700 (PDT)
Sender: dilmah@google.com
Received: by 10.229.18.69 with HTTP; Thu, 9 Jun 2011 03:18:51 -0700 (PDT)
In-Reply-To: <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com>
Date: Thu, 9 Jun 2011 14:18:51 +0400
X-Google-Sender-Auth: Lc_iZBA54AnRi2NytOZwVmI-Ui0
Message-ID: <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com>
From: Denis Lagno <dilmah@chromium.org>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Cc: hybi@ietf.org, Internet-Drafts@ietf.org, i-d-announce@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 10:18:55 -0000

Draft specifies that ABNF for value of "Sec-WebSocket-Protocol" field
is 1#token.
First nit is that looking at definition of # rule in RFC2616 it
specifies that 1#token can contain Linear White Space, and LWS can
contain CRLF; I guess CRLF in subprotocols list is not expected?
Second nit is that it is not ABNF, ABNF RFC does not contain # rule.

From tyoshino@google.com  Thu Jun  9 03:21:25 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAD511E80CC for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.388
X-Spam-Level: 
X-Spam-Status: No, score=-105.388 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWyTAxqg9DWH for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:21:24 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8693811E80A7 for <hybi@ietf.org>; Thu,  9 Jun 2011 03:21:24 -0700 (PDT)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p59AL4fJ025439 for <hybi@ietf.org>; Thu, 9 Jun 2011 03:21:04 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1307614869; bh=2w7HucWl09hnRH6fEaTgah/PXlc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZV6LXWj8sietCqlxJY8dqTvTZ0PO37qPwUluIrc5UXP5jEn13jdaVLScqGBvNwEoN Au9kMqCzwi78VQIJ5yVcA==
Received: from gxk21 (gxk21.prod.google.com [10.202.11.21]) by wpaz1.hot.corp.google.com with ESMTP id p59AKTsW018893 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 9 Jun 2011 03:20:58 -0700
Received: by gxk21 with SMTP id 21so854117gxk.5 for <hybi@ietf.org>; Thu, 09 Jun 2011 03:20:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vqPAyZA7YNzGSNY9QcAuadHSMO+NzwDpqPyltabZI1A=; b=ighINupn8v7O6rqSnyk24BayCwezQy62CCmmFaepw/WHygRrxdWKa6JUeZ8K6GRm8p NhIXEYY6Y+Y3wfnjnKKA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=V3twKwM4oOuzrJi9G0eahSY/LoX65BaW7BJSp7Gol1OLS7zSxJviR80QqrO8Pe6bau +kKGjFr2PsJE4JOij6+A==
Received: by 10.91.66.39 with SMTP id t39mr1775232agk.28.1307614853249; Thu, 09 Jun 2011 03:20:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.91.218.9 with HTTP; Thu, 9 Jun 2011 03:20:33 -0700 (PDT)
In-Reply-To: <4DF07883.4070609@warmcat.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Thu, 9 Jun 2011 19:20:33 +0900
Message-ID: <BANLkTikWHWgB--rv4Tnt-fD9_SthvgLcGmJ1B5f80DnYPw74uQ@mail.gmail.com>
To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= <andy@warmcat.com>
Content-Type: multipart/alternative; boundary=0016e640cc7cd4bb4d04a544cee0
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 10:21:25 -0000

--0016e640cc7cd4bb4d04a544cee0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Some more minor but non trivial changes I can name are

08: Solicited pong must have the same application data as ping
07: Solicited pong must have the same payload as ping

08: without any extension, receiver ignores RSV1-3 even if turned on
07: not specified

08: without any extension, receiver ignores frames with unknown opcode
07: not specified

08: Client -> server Sec-WebSocket-Protocol ABNF is 1#token
07: Client -> server Sec-WebSocket-Protocol ABNF is 1#(token |
quoted-string)

08: Server -> client Sec-WebSocket-Protocol ABNF is (token)
07: not explicitly specified

On Thu, Jun 9, 2011 at 16:38, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" <a=
ndy@warmcat.com> wrote:

> ...I can see it has gotten tidier and more referential to existing TLAs b=
ut
> I had a hard time spotting what actually changed implementation-wise from
> -07 protocol.
>
> Is there anything or we just crank the default version number up to 8?
>

--0016e640cc7cd4bb4d04a544cee0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>Some more minor but non trivial changes I can name are</div><div><br><=
/div>08: Solicited pong must have the same application data as ping<br>07: =
Solicited pong must have the same payload as ping<div><br></div><div>08: wi=
thout any extension, receiver ignores RSV1-3 even if turned on</div>

<div>07: not specified</div><div><br></div><div>08: without any extension, =
receiver ignores frames with unknown opcode</div><div>07: not specified</di=
v><div><br></div><div><div>08: Client -&gt; server Sec-WebSocket-Protocol A=
BNF is 1#token</div>

</div><div><div>07: Client -&gt; server Sec-WebSocket-Protocol ABNF is 1#(t=
oken | quoted-string)</div></div><div><br></div><div><div><div>08: Server -=
&gt; client Sec-WebSocket-Protocol ABNF is (token)</div></div><div><div>

07: not explicitly specified</div></div></div><div><br></div><div><div clas=
s=3D"gmail_quote">On Thu, Jun 9, 2011 at 16:38, &quot;Andy Green (=E6=9E=97=
=E5=AE=89=E5=BB=B8)&quot; <span dir=3D"ltr">&lt;<a href=3D"mailto:andy@warm=
cat.com">andy@warmcat.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">...I can see it has gotte=
n tidier and more referential to existing TLAs but I had a hard time spotti=
ng what actually changed implementation-wise from -07 protocol.</div>


<br>
Is there anything or we just crank the default version number up to 8?<font=
 class=3D"Apple-style-span" color=3D"#888888"><br></font></blockquote></div=
></div>

--0016e640cc7cd4bb4d04a544cee0--

From andy.warmcat.com@googlemail.com  Thu Jun  9 03:28:09 2011
Return-Path: <andy.warmcat.com@googlemail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02EA511E80A7 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level: 
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id voggyJ9MfL8X for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 03:28:08 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 21A6B11E8083 for <hybi@ietf.org>; Thu,  9 Jun 2011 03:28:07 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1011072fxm.31 for <hybi@ietf.org>; Thu, 09 Jun 2011 03:28:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uUzFXZFJmefSPIKnojppL1NMqO1pBZWQWoreLKAWYu0=; b=C2qPIT7mLY5069584llJFAnDAXxyb6s3y0ELEVptSoDsaW2VrrFEDgcNuetJxvSLGH /Gr1SX22PB9cRS31QbXDNSfYkB1br0nLuZ9JPep+TuRd9S/uAKqffSqk7QA7Sq2nbOqx u9gdJmZfmMuAHOa8JWUBr+khGJkO8+LnFmHM4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=SG4zZfhO/ZmhQIfW9uqSvYYMOCSFUbtP/8GvABv7MzIjFlgBEU9RlvzoDTmxHT7PDi 4FUcRvksqXv6lfCJjY7zSzatOg/o4nSUS1Q2yRN9qzvyitcaAcPT8UGo7f83M0zJjFsh 7JAumlium0vTDwjQaTSFpIvAQa8bJ9pyKmipo=
Received: by 10.223.4.136 with SMTP id 8mr617843far.16.1307615287196; Thu, 09 Jun 2011 03:28:07 -0700 (PDT)
Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id e15sm590365faa.47.2011.06.09.03.28.04 (version=SSLv3 cipher=OTHER); Thu, 09 Jun 2011 03:28:05 -0700 (PDT)
Sender: Andy Green <andy.warmcat.com@googlemail.com>
Message-ID: <4DF0A033.7020903@warmcat.com>
Date: Thu, 09 Jun 2011 11:28:03 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Takeshi Yoshino <tyoshino@google.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <4DF07883.4070609@warmcat.com> <BANLkTikWHWgB--rv4Tnt-fD9_SthvgLcGmJ1B5f80DnYPw74uQ@mail.gmail.com>
In-Reply-To: <BANLkTikWHWgB--rv4Tnt-fD9_SthvgLcGmJ1B5f80DnYPw74uQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 10:28:09 -0000

On 06/09/2011 11:20 AM, Somebody in the thread at some point said:

Hi -

> Some more minor but non trivial changes I can name are
>
> 08: Solicited pong must have the same application data as ping
> 07: Solicited pong must have the same payload as ping

This is already done like that in libwebsockets fwiw.

> 08: without any extension, receiver ignores RSV1-3 even if turned on
> 07: not specified

OK it kills the connection right now, important.

> 08: without any extension, receiver ignores frames with unknown opcode
> 07: not specified

Hm okay at the moment it just blows chunks, this is a better idea.

> 08: Client -> server Sec-WebSocket-Protocol ABNF is 1#token
> 07: Client -> server Sec-WebSocket-Protocol ABNF is 1#(token |
> quoted-string)

OK.

> 08: Server -> client Sec-WebSocket-Protocol ABNF is (token)
> 07: not explicitly specified

Right that is a good change.

Thanks for pointing these out I would definitely miss them otherwise.

-Andy

From salvatore.loreto@ericsson.com  Thu Jun  9 04:10:51 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3A7C11E80B6 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 04:10:51 -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.001, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu5quwVvKYjt for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 04:10:51 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 838BA11E80A7 for <hybi@ietf.org>; Thu,  9 Jun 2011 04:10:50 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-37-4df0aa2cab03
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3A.22.20773.C2AA0FD4; Thu,  9 Jun 2011 13:10:36 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Thu, 9 Jun 2011 13:10:35 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 7D8D423F5	for <hybi@ietf.org>; Thu,  9 Jun 2011 14:10:35 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 46F69509C3	for <hybi@ietf.org>; Thu,  9 Jun 2011 14:10:35 +0300 (EEST)
Received: from n211.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 030BD50152	for <hybi@ietf.org>; Thu,  9 Jun 2011 14:10:34 +0300 (EEST)
Message-ID: <4DF0AA2A.1030708@ericsson.com>
Date: Thu, 9 Jun 2011 14:10:34 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>	<BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com>	<BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <BANLkTikD-WFE+uctHGovg9atezSd9nEe_N6aLsog5X65pS2xkw@mail.gmail.com>
In-Reply-To: <BANLkTikD-WFE+uctHGovg9atezSd9nEe_N6aLsog5X65pS2xkw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------030707010702040309070502"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 11:10:51 -0000

--------------030707010702040309070502
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

On 6/9/11 6:21 AM, Takeshi Yoshino wrote:
> On Thu, Jun 9, 2011 at 08:23, Ian Fette ($B%$%"%s%U%'%C%F%#(B)
> <ifette@google.com <mailto:ifette@google.com>> wrote:
>
>     On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins <gregw@intalio.com
>     <mailto:gregw@intalio.com>> wrote:
>
>         * The fragments of one message may not be interleaved between the
>
>         fragments of another message unless an extension has been
>         negotiated
>         that can interpret the interleaving.
>
>
>     anyone else have thoughts here? it seems reasonable to me but I'd
>     like to hear other opinions.
>
>
> I think it's good for clarification (though when we read the
> fragmentation spec, it's clear that interleaving doesn't work without
> extension).
>
> It's a small edit.
>
I agree

/Sal


--------------030707010702040309070502
Content-Type: text/html; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-2022-JP"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 6/9/11 6:21 AM, Takeshi Yoshino wrote:
    <blockquote
cite="mid:BANLkTikD-WFE+uctHGovg9atezSd9nEe_N6aLsog5X65pS2xkw@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Thu, Jun 9, 2011 at 08:23, Ian Fette
        ($B%$%"%s%U%'%C%F%#(B) <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:ifette@google.com">ifette@google.com</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
          0.8ex; border-left: 1px solid rgb(204, 204, 204);
          padding-left: 1ex;">
          <div class="gmail_quote">
            <div class="im">On Wed, Jun 8, 2011 at 4:03 PM, Greg Wilkins
              <span dir="ltr">&lt;<a moz-do-not-send="true"
                  href="mailto:gregw@intalio.com" target="_blank">gregw@intalio.com</a>&gt;</span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
                0.8ex; border-left: 1px solid rgb(204, 204, 204);
                padding-left: 1ex;">
                &nbsp;* The fragments of one message may not be interleaved
                between the</blockquote>
            </div>
            <div class="im">
              <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
                0.8ex; border-left: 1px solid rgb(204, 204, 204);
                padding-left: 1ex;">
                fragments of another message unless an extension has
                been negotiated<br>
                that can interpret the interleaving.<br>
              </blockquote>
              <div><br>
              </div>
            </div>
            <div>anyone else have thoughts here? it seems reasonable to
              me but I'd like to hear other opinions.&nbsp;</div>
          </div>
        </blockquote>
        <div><br>
        </div>
        <div>
          I think it's good for clarification (though when we read the
          fragmentation spec, it's clear that interleaving doesn't work
          without extension).</div>
        <div><br>
        </div>
        <div>It's a small edit.</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    I agree<br>
    <br>
    /Sal<br>
    <br>
  </body>
</html>

--------------030707010702040309070502--

From julian.reschke@gmx.de  Thu Jun  9 04:22:50 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D9C811E80B4 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 04:22:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.562
X-Spam-Level: 
X-Spam-Status: No, score=-104.562 tagged_above=-999 required=5 tests=[AWL=-1.962, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErsoGzdVmg-G for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 04:22:49 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2185C11E8071 for <hybi@ietf.org>; Thu,  9 Jun 2011 04:22:48 -0700 (PDT)
Received: (qmail invoked by alias); 09 Jun 2011 11:22:47 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp072) with SMTP; 09 Jun 2011 13:22:47 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+qXbBp0qGqfTc22sbHlH7MroSFFhLAaS4jRSi4mC jpA++yfRKc5+TW
Message-ID: <4DF0ACFC.3090005@gmx.de>
Date: Thu, 09 Jun 2011 13:22:36 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Denis Lagno <dilmah@chromium.org>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>	<BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com> <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com>
In-Reply-To: <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: hybi@ietf.org, Internet-Drafts@ietf.org, Greg Wilkins <gregw@intalio.com>, i-d-announce@ietf.org
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 11:22:50 -0000

On 2011-06-09 12:18, Denis Lagno wrote:
> Draft specifies that ABNF for value of "Sec-WebSocket-Protocol" field
> is 1#token.
> First nit is that looking at definition of # rule in RFC2616 it
> specifies that 1#token can contain Linear White Space, and LWS can
> contain CRLF; I guess CRLF in subprotocols list is not expected?
> Second nit is that it is not ABNF, ABNF RFC does not contain # rule.

"The ABNF for the value of this header is 1#token, where the definitions 
of constructs and rules are as given in [RFC2616]."

From derhoermi@gmx.net  Thu Jun  9 07:10:34 2011
Return-Path: <derhoermi@gmx.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF8311E808B for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 07:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.449
X-Spam-Level: 
X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SATISF=2.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQlCM1vYUncR for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 07:10:32 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 29EC711E809A for <hybi@ietf.org>; Thu,  9 Jun 2011 07:10:32 -0700 (PDT)
Received: (qmail invoked by alias); 09 Jun 2011 14:10:22 -0000
Received: from dslb-094-222-153-106.pools.arcor-ip.net (EHLO HIVE) [94.222.153.106] by mail.gmx.net (mp065) with SMTP; 09 Jun 2011 16:10:22 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19J2OIoBYtJSN6/B/wvCUpAVM+XyXIYJ2rI7oRX6R INuJVZQblQASMP
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: ifette@google.com
Date: Thu, 09 Jun 2011 16:10:27 +0200
Message-ID: <ari1v69hulrs2a54ipgbi955bm43f4tnim@hive.bjoern.hoehrmann.de>
References: <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de> <BANLkTinBM1+s2J_qAmnUz5OEy_yjU38C9Q@mail.gmail.com> <1660v6ps0d8t6qfbb0lgvnvueggk59tfei@hive.bjoern.hoehrmann.de> <BANLkTimU0a=3=vAOsQR-We-c-CU+HniMRQ@mail.gmail.com>
In-Reply-To: <BANLkTimU0a=3=vAOsQR-We-c-CU+HniMRQ@mail.gmail.com>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 14:10:34 -0000

* Ian Fette wrote:
>Hixie is the editor of the HTML spec. He pointed out problems, they were
>addressed. I've a series of emails from him that I am happy to share if he
>does not mind (there's nothing private in them, but I don't make a habit of
>forwarding private correspondence.) As we have the luxury of meeting
>face-to-face, there were also face-to-face discussions to resolve stickier
>issues, along with a few late night IRC sessions on #whatwg.

When Google employees get together in private, decide to make changes,
and then post a document, without particularily telling the rest of us
what has changed, which issues have been addressed, which issues have
not been addressed, in fact, not even telling us what the issues were,
then that's not open and consensus-based vendor-independent standards
development.

>Finally, I'm not sure what you expect to get from W3C that you're not
>getting from the people on this list. You've got the people implementing the
>API watching this list, that's the same subset of the people from W3C that
>would provide meaningful commentary about the spec.

The hybi charter requires the working group to consider any concerns
raised by the W3C. I expect people from the IESG or the community at
large will ask whether this has been done, and the easy way to answer
would be showing them records of the W3C confirming they have reviewed
the document and any issues they had have been addressed to their sa-
tisfaction.

Arguing, instead, that we seem to have all the right people involved,
so such formalities are unnecessary, while at the same time people on
the list are working together to figure out what changes have been made
in the latest draft, would not be much of an answer to such questions.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From Gabriel.Montenegro@microsoft.com  Thu Jun  9 08:45:10 2011
Return-Path: <Gabriel.Montenegro@microsoft.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4FCE21F844E for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 08:45:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.449
X-Spam-Level: 
X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_SATISF=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3v5AE-jEjt0 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 08:45:08 -0700 (PDT)
Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 75A9B21F8441 for <hybi@ietf.org>; Thu,  9 Jun 2011 08:44:58 -0700 (PDT)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 9 Jun 2011 08:44:56 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 9 Jun 2011 08:44:56 -0700
Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 9 Jun 2011 08:44:56 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>, "ifette@google.com" <ifette@google.com>
Thread-Topic: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
Thread-Index: AQHMJgIGNC+RWZvmeEiFRxtORC8MYpS0ie2AgAAFroD//4ttwIAAhNcAgAABV4CAAAujAIAAExcAgADHW4D//6SMgA==
Date: Thu, 9 Jun 2011 15:44:56 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C114031431F@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive <ari1v69hulrs2a54ipgbi955bm43f4tnim@hive.bjoern.hoehrmann.de>
In-Reply-To: <ari1v69hulrs2a54ipgbi955bm43f4tnim@hive.bjoern.hoehrmann.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.41]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 15:45:11 -0000

That review and perhaps others sent to hybi happened in the context of the =
call made for w3c feedback. Please see:

http://lists.w3.org/Archives/Public/public-ietf-w3c/2011Mar/0002.html

Further discussion in the context of the joint W3C/IETF conference call:
http://lists.w3.org/Archives/Public/public-ietf-w3c/2011Apr/0000.html

thanks,

Gabriel

> -----Original Message-----
> From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net]
> Sent: Thursday, June 09, 2011 07:10
> To: ifette@google.com
> Cc: hybi@ietf.org; Gabriel Montenegro
> Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.tx=
t
>=20
> * Ian Fette wrote:
> >Hixie is the editor of the HTML spec. He pointed out problems, they
> >were addressed. I've a series of emails from him that I am happy to
> >share if he does not mind (there's nothing private in them, but I don't
> >make a habit of forwarding private correspondence.) As we have the
> >luxury of meeting face-to-face, there were also face-to-face
> >discussions to resolve stickier issues, along with a few late night IRC =
sessions
> on #whatwg.
>=20
> When Google employees get together in private, decide to make changes, an=
d
> then post a document, without particularily telling the rest of us what h=
as
> changed, which issues have been addressed, which issues have not been
> addressed, in fact, not even telling us what the issues were, then that's=
 not open
> and consensus-based vendor-independent standards development.
>=20
> >Finally, I'm not sure what you expect to get from W3C that you're not
> >getting from the people on this list. You've got the people
> >implementing the API watching this list, that's the same subset of the
> >people from W3C that would provide meaningful commentary about the spec.
>=20
> The hybi charter requires the working group to consider any concerns rais=
ed by
> the W3C. I expect people from the IESG or the community at large will ask
> whether this has been done, and the easy way to answer would be showing
> them records of the W3C confirming they have reviewed the document and an=
y
> issues they had have been addressed to their sa- tisfaction.
>=20
> Arguing, instead, that we seem to have all the right people involved, so =
such
> formalities are unnecessary, while at the same time people on the list ar=
e
> working together to figure out what changes have been made in the latest =
draft,
> would not be much of an answer to such questions.
> --
> Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr=
mann.de
> Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld=
.de
> 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev=
.de/


From jczic@free.fr  Thu Jun  9 08:13:47 2011
Return-Path: <jczic@free.fr>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4554311E80F2 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 08:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.389
X-Spam-Level: 
X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kU92mzBoSiqg for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 08:13:46 -0700 (PDT)
Received: from smtp3-g21.free.fr (smtp3-g21.free.fr [212.27.42.3]) by ietfa.amsl.com (Postfix) with ESMTP id 4EF3E11E80DB for <hybi@ietf.org>; Thu,  9 Jun 2011 08:13:44 -0700 (PDT)
Received: from JCzicLaptop (unknown [83.153.177.3]) by smtp3-g21.free.fr (Postfix) with ESMTP id CFABCA62AA for <hybi@ietf.org>; Thu,  9 Jun 2011 17:13:38 +0200 (CEST)
From: "Jean-Christophe Bos" <jczic@free.fr>
To: <hybi@ietf.org>
Date: Thu, 9 Jun 2011 17:13:25 +0200
Message-ID: <002101cc26b7$c8901c20$59b05460$@fr>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CC26C8.8C18EC20"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Acwmt8cyWIukpOPbS0WvnJ/o0ovl3Q==
Content-Language: fr
X-Mailman-Approved-At: Thu, 09 Jun 2011 08:51:14 -0700
Subject: [hybi] WebSockets : Question about masqued frames !
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 15:15:27 -0000

This is a multi-part message in MIME format.

------=_NextPart_000_0022_01CC26C8.8C18EC20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

Hello everyone,

 

I wanted to ask you (from France!) about the latest WebSocket's drafts that
I also fully implemented in my own HTTP server (since hixie 76).

 

On the masked frames, you mentioned earlier, that the mask must be selected
by an high entropy but it seemed illusive.

However, you came back to say that just choose a random mask but always in a
logical of non-predictability.

 

So, what is the real utility of this mask and that it should not be
predictable except to prevent a simple human readable dump of the
connection?

 

Why have won so much space on the data payload length and lose unnecessarily
32b for the masks contained in each frame?

 

WebSockets is indeed a protocol over HTTP over TCP, thus ensuring a good
packets order and lossless.

So why not simply imagine a mask whose evolutionary of the Salt was fixed at
the start (why not from the handshake key) and whose encryption evolve based
on the contents of the frames?

 

I would be really pleased that you explain on that!

 

Thank you very much because I truly believe that WebSockets are a priority
in the future of dynamic web apps :-)

 

 

Sincerely,

 

-

Jean-Christophe Bos,

CEO, Tenactys Group

0 820 620 118
06 80 27 93 84

 <mailto:jcb@tenactys-group.fr> jcb@tenactys-group.fr

 


------=_NextPart_000_0022_01CC26C8.8C18EC20
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" =
xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" =
xmlns=3D"http://www.w3.org/TR/REC-html40"><head><META =
HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 12 =
(filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Century Gothic";
	panose-1:2 11 5 2 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Century Gothic","sans-serif";
	color:#244061;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]--></head><body lang=3DFR link=3Dblue =
vlink=3Dpurple><div class=3DWordSection1><p class=3DMsoNormal><span =
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>Hello =
everyone,<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>I wanted to ask you (from France!) =
about the latest WebSocket's drafts that I also fully implemented in my =
own HTTP server (since hixie 76).<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>On the masked frames, you mentioned =
earlier, that the mask must be selected by an high entropy but it seemed =
illusive.<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>However, you came back to say that =
just choose a random mask but always in a logical of =
non-predictability.<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>So, what is the real utility of this =
mask and that it should not be predictable except to prevent a simple =
human readable dump of the connection?<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>Why have won so much space on the =
data payload length and lose unnecessarily 32b for the masks contained =
in each frame?<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>WebSockets is indeed a protocol over =
HTTP over TCP, thus ensuring a good packets order and =
lossless.<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>So why not simply imagine a mask =
whose evolutionary of the Salt was fixed at the start (why not from the =
handshake key) and whose encryption evolve based on the contents of the =
frames?<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>I would be really pleased that you =
explain on that!<o:p></o:p></span></p><p class=3DMsoNormal><span =
lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#0F243E'>Thank you very much because I truly =
believe that WebSockets are a priority in the future of dynamic web apps =
:-)<o:p></o:p></span></p><p class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#244061'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#244061'><o:p>&nbsp;</o:p></span></p><p =
class=3DMsoNormal><span style=3D'font-size:10.0pt;font-family:"Century =
Gothic","sans-serif";color:#244061'>Sincerely,<o:p></o:p></span></p><p =
class=3DMsoNormal><b><span style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#262626'><o:p>&nbsp;</o:p></span></b></p><p =
class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#262626'>-</span></b><span lang=3DEN-US =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#262626'><o:p></o:p></span></p><p =
class=3DMsoNormal><b><span lang=3DEN-US =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#404040'>Jean-Christophe Bos</span></b><span =
lang=3DEN-US style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#404040'>,<o:p></o:p></span></p><p =
class=3DMsoNormal><span lang=3DEN-US =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#262626'>CEO, Tenactys =
Group<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#262626'>0&nbsp;820&nbsp;620 118<br>06 80 27 =
93 84<o:p></o:p></span></p><p class=3DMsoNormal><span =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#365F91'><a =
href=3D"mailto:jcb@tenactys-group.fr"><span =
style=3D'color:#365F91'>jcb@tenactys-group.fr</span></a><o:p></o:p></span=
></p><p class=3DMsoNormal><span =
style=3D'font-size:9.0pt;font-family:"Century =
Gothic","sans-serif";color:#365F91'><o:p>&nbsp;</o:p></span></p></div></b=
ody></html>
------=_NextPart_000_0022_01CC26C8.8C18EC20--


From a.catel@weelya.com  Thu Jun  9 09:37:31 2011
Return-Path: <a.catel@weelya.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F3711E8148 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 09:37:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhwbjOOb0Sxs for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 09:37:30 -0700 (PDT)
Received: from hermes.weelya.com (hermes.weelya.com [91.121.5.68]) by ietfa.amsl.com (Postfix) with ESMTP id E612811E8114 for <hybi@ietf.org>; Thu,  9 Jun 2011 09:37:29 -0700 (PDT)
Received: from [192.168.1.239] (e179073159.adsl.alicedsl.de [85.179.73.159]) by hermes.weelya.com (Postfix) with ESMTPSA id 9B5C24AD99 for <hybi@ietf.org>; Thu,  9 Jun 2011 18:41:29 +0200 (CEST)
Message-ID: <4DF0F6C5.5050807@weelya.com>
Date: Thu, 09 Jun 2011 18:37:25 +0200
From: Anthony Catel <a.catel@weelya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <002101cc26b7$c8901c20$59b05460$@fr>
In-Reply-To: <002101cc26b7$c8901c20$59b05460$@fr>
Content-Type: multipart/alternative; boundary="------------090406030000090301010905"
Subject: Re: [hybi] WebSockets : Question about masqued frames !
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 16:37:31 -0000

This is a multi-part message in MIME format.
--------------090406030000090301010905
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit

Hi,

It's mainly because of proxy traversal (please read previous discussions 
about cache poisoning & co)

Anthony Catel

Le 09/06/2011 17:13, Jean-Christophe Bos a écrit :
>
> Hello everyone,
>
> I wanted to ask you (from France!) about the latest WebSocket's drafts 
> that I also fully implemented in my own HTTP server (since hixie 76).
>
> On the masked frames, you mentioned earlier, that the mask must be 
> selected by an high entropy but it seemed illusive.
>
> However, you came back to say that just choose a random mask but 
> always in a logical of non-predictability.
>
> So, what is the real utility of this mask and that it should not be 
> predictable except to prevent a simple human readable dump of the 
> connection?
>
> Why have won so much space on the data payload length and lose 
> unnecessarily 32b for the masks contained in each frame?
>
> WebSockets is indeed a protocol over HTTP over TCP, thus ensuring a 
> good packets order and lossless.
>
> So why not simply imagine a mask whose evolutionary of the Salt was 
> fixed at the start (why not from the handshake key) and whose 
> encryption evolve based on the contents of the frames?
>
> I would be really pleased that you explain on that!
>
> Thank you very much because I truly believe that WebSockets are a 
> priority in the future of dynamic web apps :-)
>
> Sincerely,
>
> **
>
> *-*
>
> *Jean-Christophe Bos*,
>
> CEO, Tenactys Group
>
> 0 820 620 118
> 06 80 27 93 84
>
> jcb@tenactys-group.fr <mailto:jcb@tenactys-group.fr>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


--------------090406030000090301010905
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Hi,<br>
    <br>
    It's mainly because of proxy traversal (please read previous
    discussions about cache poisoning &amp; co)<br>
    <br>
    Anthony Catel<br>
    <br>
    Le 09/06/2011 17:13, Jean-Christophe Bos a &eacute;crit&nbsp;:
    <blockquote cite="mid:002101cc26b7$c8901c20$59b05460$@fr"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="Generator" content="Microsoft Word 12 (filtered
        medium)">
      <style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"Century Gothic";
	panose-1:2 11 5 2 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Century Gothic","sans-serif";
	color:#244061;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:70.85pt 70.85pt 70.85pt 70.85pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">Hello everyone,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">I wanted to ask you (from
            France!) about the latest WebSocket's drafts that I also
            fully implemented in my own HTTP server (since hixie 76).<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">On the masked frames, you
            mentioned earlier, that the mask must be selected by an high
            entropy but it seemed illusive.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">However, you came back to say
            that just choose a random mask but always in a logical of
            non-predictability.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">So, what is the real utility
            of this mask and that it should not be predictable except to
            prevent a simple human readable dump of the connection?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">Why have won so much space on
            the data payload length and lose unnecessarily 32b for the
            masks contained in each frame?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">WebSockets is indeed a
            protocol over HTTP over TCP, thus ensuring a good packets
            order and lossless.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">So why not simply imagine a
            mask whose evolutionary of the Salt was fixed at the start
            (why not from the handshake key) and whose encryption evolve
            based on the contents of the frames?<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">I would be really pleased
            that you explain on that!<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(15, 36, 62);" lang="EN-US">Thank you very much because I
            truly believe that WebSockets are a priority in the future
            of dynamic web apps :-)<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(36, 64, 97);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(36, 64, 97);" lang="EN-US"><o:p>&nbsp;</o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 10pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(36, 64, 97);">Sincerely,<o:p></o:p></span></p>
        <p class="MsoNormal"><b><span style="font-size: 9pt;
              font-family: &quot;Century
              Gothic&quot;,&quot;sans-serif&quot;; color: rgb(38, 38,
              38);"><o:p>&nbsp;</o:p></span></b></p>
        <p class="MsoNormal"><b><span style="font-size: 9pt;
              font-family: &quot;Century
              Gothic&quot;,&quot;sans-serif&quot;; color: rgb(38, 38,
              38);" lang="EN-US">-</span></b><span style="font-size:
            9pt; font-family: &quot;Century
            Gothic&quot;,&quot;sans-serif&quot;; color: rgb(38, 38,
            38);" lang="EN-US"><o:p></o:p></span></p>
        <p class="MsoNormal"><b><span style="font-size: 9pt;
              font-family: &quot;Century
              Gothic&quot;,&quot;sans-serif&quot;; color: rgb(64, 64,
              64);" lang="EN-US">Jean-Christophe Bos</span></b><span
            style="font-size: 9pt; font-family: &quot;Century
            Gothic&quot;,&quot;sans-serif&quot;; color: rgb(64, 64,
            64);" lang="EN-US">,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 9pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(38, 38, 38);" lang="EN-US">CEO, Tenactys Group<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 9pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(38, 38, 38);">0&nbsp;820&nbsp;620 118<br>
            06 80 27 93 84<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 9pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(54, 95, 145);"><a moz-do-not-send="true"
              href="mailto:jcb@tenactys-group.fr"><span style="color:
                rgb(54, 95, 145);">jcb@tenactys-group.fr</span></a><o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size: 9pt; font-family:
            &quot;Century Gothic&quot;,&quot;sans-serif&quot;; color:
            rgb(54, 95, 145);"><o:p>&nbsp;</o:p></span></p>
      </div>
      <pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
hybi mailing list
<a class="moz-txt-link-abbreviated" href="mailto:hybi@ietf.org">hybi@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/hybi">https://www.ietf.org/mailman/listinfo/hybi</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------090406030000090301010905--

From salvatore.loreto@ericsson.com  Thu Jun  9 10:53:58 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ED111E8196 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 10:53:58 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKz4LTqyy6xo for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 10:53:57 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id BEC5611E8163 for <hybi@ietf.org>; Thu,  9 Jun 2011 10:53:47 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-0b-4df108aa5c8e
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.A1.09774.AA801FD4; Thu,  9 Jun 2011 19:53:46 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Thu, 9 Jun 2011 19:53:45 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 25F631EB9; Thu,  9 Jun 2011 20:53:45 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D22AC50FAD; Thu,  9 Jun 2011 20:53:44 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8324D50CF2; Thu,  9 Jun 2011 20:53:44 +0300 (EEST)
Message-ID: <4DF108A8.70608@ericsson.com>
Date: Thu, 9 Jun 2011 20:53:44 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: SM <sm+ietf@elandsys.com>
Subject: [hybi] additional editor for websockets
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 17:53:58 -0000

(as chairs)

Gabriel and I have asked Alexey Melnikov to become a co-editor for the 
WebSocket Protocol draft,
  helping Ian Fette in all the editing job that need to be done and that 
most likely will increase
as we go to IETF-wide and IESG reviews.
(The wire protocol is not expect to change, but there will be a lot of 
request to clarify text etc.).

As a former Application AD, Alexey is the right people to lighten the 
load on Ian Fette,
helping not only in editing but also in any eventual IETF or IANA 
process issue.

I want to thank Alexey to have accepted to spend cycles in this job.


Gabriele and Salvatore

-- 
Salvatore Loreto
www.sloreto.com


From buskanaka@gmail.com  Thu Jun  9 14:47:41 2011
Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD0111E8146 for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 14:47:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JoI5i5Gl0Fzd for <hybi@ietfa.amsl.com>; Thu,  9 Jun 2011 14:47:41 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53E5C11E8116 for <hybi@ietf.org>; Thu,  9 Jun 2011 14:47:40 -0700 (PDT)
Received: by ewy19 with SMTP id 19so864216ewy.31 for <hybi@ietf.org>; Thu, 09 Jun 2011 14:47:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=P5pcfqLCbaNFZezB+sdl70mdsFMI/WKcmWPvQ9DR6YE=; b=Akpq9Ef2bn0t59LBHPMuycn5AkvBg5dr7LNB6YJP7t/K/eOzxqDETE3EoKDVDKQxCd HP7mXUlhaZQPADls1C41Zz/QwWXPqasyV65hvqvvihCeqO+HbmF7XGtYsnc5f0Fv9xws yTcg25qSqDSfnoerDXDkBhEKnrhYsDNO2WJGQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=QjTbinUa8s6GJDgGrxjREHflrRwu+ithY794Ougz2cNBhQwbOKIggjXqcfvMlHPxHK uHXHepsDXDKixWaLXpRCbKr4X4S8KEH0Yvzhn+woKERXXhs7/EqRuos3EUtLJ8sb1oFM 0IixcpwbEYVqXetzJkZTRWUHtk6qTCtp12XfU=
Received: by 10.14.29.71 with SMTP id h47mr635526eea.106.1307656059375; Thu, 09 Jun 2011 14:47:39 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.14.127.1 with HTTP; Thu, 9 Jun 2011 14:47:19 -0700 (PDT)
In-Reply-To: <002101cc26b7$c8901c20$59b05460$@fr>
References: <002101cc26b7$c8901c20$59b05460$@fr>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 9 Jun 2011 17:47:19 -0400
X-Google-Sender-Auth: F6xQ6yXY6r7jUWZWB9rVjDxpD-0
Message-ID: <BANLkTi=EzKgrR7wPjyT0K6xiEVYGYkU+rg@mail.gmail.com>
To: Jean-Christophe Bos <jczic@free.fr>
Content-Type: multipart/alternative; boundary=90e6ba5bbae5e8502804a54e6665
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSockets : Question about masqued frames !
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 09 Jun 2011 21:47:41 -0000

--90e6ba5bbae5e8502804a54e6665
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 9, 2011 at 11:13 AM, Jean-Christophe Bos <jczic@free.fr> wrote:

> Why have won so much space on the data payload length and lose
> unnecessarily 32b for the masks contained in each frame?
>

It is worth noting that the masking is only in the client -> server
direction.

Joel Martin

--90e6ba5bbae5e8502804a54e6665
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jun 9, 2011 at 11:13 AM, Jean-Christophe=
 Bos <span dir=3D"ltr">&lt;<a href=3D"mailto:jczic@free.fr">jczic@free.fr</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div lang=3D"FR" link=3D"blue" vlink=3D"purple"><div><p class=3D"MsoNormal"=
><span class=3D"Apple-style-span" style=3D"color: rgb(15, 36, 62); font-siz=
e: 13px; ">Why have won so much space on the data payload length and lose u=
nnecessarily 32b for the masks contained in each frame?</span></p>

</div></div></blockquote><div><br></div><meta http-equiv=3D"content-type" c=
ontent=3D"text/html; charset=3Dutf-8">It is worth noting that the masking i=
s only in the client -&gt; server direction.</div><div class=3D"gmail_quote=
"><br>

</div><div class=3D"gmail_quote">Joel Martin<br><div>=A0</div></div>

--90e6ba5bbae5e8502804a54e6665--

From ibc@aliax.net  Fri Jun 10 22:32:31 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA36221F8462 for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 22:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.651
X-Spam-Level: 
X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJoRypdr2+bE for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 22:32:31 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1CE21F8461 for <hybi@ietf.org>; Fri, 10 Jun 2011 22:32:31 -0700 (PDT)
Received: by qyk7 with SMTP id 7so2037073qyk.10 for <hybi@ietf.org>; Fri, 10 Jun 2011 22:32:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr2227756qca.154.1307770350555; Fri, 10 Jun 2011 22:32:30 -0700 (PDT)
Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 22:32:30 -0700 (PDT)
In-Reply-To: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com>
Date: Sat, 11 Jun 2011 07:32:30 +0200
Message-ID: <BANLkTi=aWZaGUH+d66hAWNQbQLjbg3AFag@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 11 Jun 2011 05:32:32 -0000

2011/6/8  <Internet-Drafts@ietf.org>:
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-=
08.txt

Typo in page 15:

          host =3D <host, defined in [RFC3986], Section 3.2.2>
          port =3D <host, defined in [RFC3986], Section 3.2.3>
          path =3D <path-abempty, defined in [RFC3986], Section 3.3>
          query =3D <query, defined in [RFC3986], Section 3.4>

It should be:

          host =3D <host, defined in [RFC3986], Section 3.2.2>
          port =3D <port, defined in [RFC3986], Section 3.2.3>
          path =3D <path-abempty, defined in [RFC3986], Section 3.3>
          query =3D <query, defined in [RFC3986], Section 3.4>

(note the "port" line).

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Fri Jun 10 22:49:02 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 812D621F84CD for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 22:49:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.652
X-Spam-Level: 
X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEvGkakD7X7p for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 22:49:02 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E940F21F84CB for <hybi@ietf.org>; Fri, 10 Jun 2011 22:49:01 -0700 (PDT)
Received: by qyk7 with SMTP id 7so2039927qyk.10 for <hybi@ietf.org>; Fri, 10 Jun 2011 22:49:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr2213692qce.192.1307771341351; Fri, 10 Jun 2011 22:49:01 -0700 (PDT)
Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 22:49:01 -0700 (PDT)
In-Reply-To: <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com> <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com>
Date: Sat, 11 Jun 2011 07:49:01 +0200
Message-ID: <BANLkTimMA73hi-gAUtAyfJ+8ky0Onk+5Dg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Denis Lagno <dilmah@chromium.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 11 Jun 2011 05:49:02 -0000

2011/6/9 Denis Lagno <dilmah@chromium.org>:
> Draft specifies that ABNF for value of "Sec-WebSocket-Protocol" field
> is 1#token.
> First nit is that looking at definition of # rule in RFC2616 it
> specifies that 1#token can contain Linear White Space, and LWS can
> contain CRLF; I guess CRLF in subprotocols list is not expected?
> Second nit is that it is not ABNF, ABNF RFC does not contain # rule.


Page 12 says:

   if Example Corporation were to create a Chat subprotocol to
   be implemented by many servers around the Web, they could name it
   "chat.example.com".  If the Example Organization called their
   competing subprotocol "example.org's chat protocol", then the two
   subprotocols could be implemented by servers simultaneously

Of course "example.org's chat protocol" is not a valid token according
to RFC 2616 grammar:

  CHAR           =3D <any US-ASCII character (octets 0 - 127)>
  token            =3D 1*<any CHAR except CTLs or separators>


So there are two options:

1) Make Sec-WebSocket-Protocol grammar 1#token (as defined now). In
this case protocol values MUST be token (no quoted strings, neither
separators). Then fix example in page 12.

2) Make Sec-WebSocket-Protocol grammar as follows:   1#( quoted-string | to=
ken )
In this way both examples in page 12 are valid.

I strongly prefer option 1 (I don't consider that spaces or UTF'8
multibyte symbols are needed for naming a protocol).



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Fri Jun 10 22:56:27 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876559E800B for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 22:56:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.653
X-Spam-Level: 
X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.024,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s29awLMgDke2 for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 22:56:27 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 10A639E8008 for <hybi@ietf.org>; Fri, 10 Jun 2011 22:56:26 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2150858qwc.31 for <hybi@ietf.org>; Fri, 10 Jun 2011 22:56:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr2216547qce.192.1307771786443; Fri, 10 Jun 2011 22:56:26 -0700 (PDT)
Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 22:56:26 -0700 (PDT)
In-Reply-To: <ari1v69hulrs2a54ipgbi955bm43f4tnim@hive.bjoern.hoehrmann.de>
References: <BANLkTi=AsE_jHV_tMTEZEcaLnQZCBMp_jA@mail.gmail.com> <BANLkTimJSAF8NVEP87AG0u8Shzvk+p12RA@mail.gmail.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403124F7@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <q120v6lo85u3vu1d7nqbrt0r4encn4rb1j@hive.bjoern.hoehrmann.de> <BANLkTinBM1+s2J_qAmnUz5OEy_yjU38C9Q@mail.gmail.com> <1660v6ps0d8t6qfbb0lgvnvueggk59tfei@hive.bjoern.hoehrmann.de> <BANLkTimU0a=3=vAOsQR-We-c-CU+HniMRQ@mail.gmail.com> <ari1v69hulrs2a54ipgbi955bm43f4tnim@hive.bjoern.hoehrmann.de>
Date: Sat, 11 Jun 2011 07:56:26 +0200
Message-ID: <BANLkTimuWt6nSckE6iFCG5JMCQ5YNy0VRQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 11 Jun 2011 05:56:27 -0000

2011/6/9 Bjoern Hoehrmann <derhoermi@gmx.net>:
> When Google employees get together in private, decide to make changes,
> and then post a document, without particularily telling the rest of us
> what has changed, which issues have been addressed, which issues have
> not been addressed, in fact, not even telling us what the issues were,
> then that's not open and consensus-based vendor-independent standards
> development.

I've repeated many times in this maillist: please, add a fuxxxxx
Changelog section in the draft.
Revision 76+8 of the draft, and no Changelog section. And here the
problems. Will the authors ignore it again?

A Changelog section should be a MUST in any new revision.

PS: A diff is not a changelog.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Fri Jun 10 23:10:33 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DBD9E800B for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 23:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.654
X-Spam-Level: 
X-Spam-Status: No, score=-2.654 tagged_above=-999 required=5 tests=[AWL=0.023,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H+hu36JIiXW1 for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 23:10:32 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99F3F9E8009 for <hybi@ietf.org>; Fri, 10 Jun 2011 23:10:32 -0700 (PDT)
Received: by qyk29 with SMTP id 29so197061qyk.10 for <hybi@ietf.org>; Fri, 10 Jun 2011 23:10:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr2221732qce.192.1307772628433; Fri, 10 Jun 2011 23:10:28 -0700 (PDT)
Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 23:10:28 -0700 (PDT)
In-Reply-To: <4DF0F6C5.5050807@weelya.com>
References: <002101cc26b7$c8901c20$59b05460$@fr> <4DF0F6C5.5050807@weelya.com>
Date: Sat, 11 Jun 2011 08:10:28 +0200
Message-ID: <BANLkTimfxbcwPmYMcqW=8d22Z8sEpTn6rg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Anthony Catel <a.catel@weelya.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSockets : Question about masqued frames !
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 11 Jun 2011 06:10:33 -0000

2011/6/9 Anthony Catel <a.catel@weelya.com>:
> It's mainly because of proxy traversal (please read previous discussions
> about cache poisoning & co)

IMHO this doesn't answer the original question:

> So why not simply imagine a mask whose evolutionary of the Salt was fixed=
 at the start (why not from the handshake key) and whose encryption evolve =
based on the contents of the frames?

The author of the thread is not suggesting removing the client->server
masking, but just make it predictable (for example from the WS
handshake data) rather than having each frame its own masking key.
Would be any (security) issue in the suggested case? I don't think so,
but just wondering.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From w@1wt.eu  Fri Jun 10 23:15:21 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9D611E8071 for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 23:15:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.171
X-Spam-Level: 
X-Spam-Status: No, score=-6.171 tagged_above=-999 required=5 tests=[AWL=-4.428, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qZd1n7WkzXSm for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 23:15:21 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1D19E8008 for <hybi@ietf.org>; Fri, 10 Jun 2011 23:15:20 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5B6FEmS003318; Sat, 11 Jun 2011 08:15:14 +0200
Date: Sat, 11 Jun 2011 08:15:14 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110611061514.GA2252@1wt.eu>
References: <002101cc26b7$c8901c20$59b05460$@fr> <4DF0F6C5.5050807@weelya.com> <BANLkTimfxbcwPmYMcqW=8d22Z8sEpTn6rg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BANLkTimfxbcwPmYMcqW=8d22Z8sEpTn6rg@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSockets : Question about masqued frames !
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 11 Jun 2011 06:15:21 -0000

On Sat, Jun 11, 2011 at 08:10:28AM +0200, Iñaki Baz Castillo wrote:
> 2011/6/9 Anthony Catel <a.catel@weelya.com>:
> > It's mainly because of proxy traversal (please read previous discussions
> > about cache poisoning & co)
> 
> IMHO this doesn't answer the original question:
> 
> > So why not simply imagine a mask whose evolutionary of the Salt was fixed at the start (why not from the handshake key) and whose encryption evolve based on the contents of the frames?
> 
> The author of the thread is not suggesting removing the client->server
> masking, but just make it predictable (for example from the WS
> handshake data) rather than having each frame its own masking key.
> Would be any (security) issue in the suggested case? I don't think so,
> but just wondering.

This was discussed in great detail in the past (as everything around masking).
The issue if the mask doesn't change is that the server knows it, so if it is
running malicious code (and so does the client), then it can tell the mask to
the client which will be able to emit predicted contents over the wire. So the
mask must change between two exchanges so that the client cannot guess it.

Willy


From ibc@aliax.net  Fri Jun 10 23:26:54 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D7B11E8076 for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 23:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.655
X-Spam-Level: 
X-Spam-Status: No, score=-2.655 tagged_above=-999 required=5 tests=[AWL=0.022,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1xdhiMPHUuP for <hybi@ietfa.amsl.com>; Fri, 10 Jun 2011 23:26:54 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E053A11E8071 for <hybi@ietf.org>; Fri, 10 Jun 2011 23:26:53 -0700 (PDT)
Received: by qyk29 with SMTP id 29so199908qyk.10 for <hybi@ietf.org>; Fri, 10 Jun 2011 23:26:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr2248523qca.154.1307773613376; Fri, 10 Jun 2011 23:26:53 -0700 (PDT)
Received: by 10.229.189.209 with HTTP; Fri, 10 Jun 2011 23:26:53 -0700 (PDT)
In-Reply-To: <20110611061514.GA2252@1wt.eu>
References: <002101cc26b7$c8901c20$59b05460$@fr> <4DF0F6C5.5050807@weelya.com> <BANLkTimfxbcwPmYMcqW=8d22Z8sEpTn6rg@mail.gmail.com> <20110611061514.GA2252@1wt.eu>
Date: Sat, 11 Jun 2011 08:26:53 +0200
Message-ID: <BANLkTi=uOTokzuU4iuqYtbpcAtywVaJiQQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Willy Tarreau <w@1wt.eu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSockets : Question about masqued frames !
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 11 Jun 2011 06:26:54 -0000

2011/6/11 Willy Tarreau <w@1wt.eu>:
>> The author of the thread is not suggesting removing the client->server
>> masking, but just make it predictable (for example from the WS
>> handshake data) rather than having each frame its own masking key.
>> Would be any (security) issue in the suggested case? I don't think so,
>> but just wondering.
>
> This was discussed in great detail in the past (as everything around mask=
ing).
> The issue if the mask doesn't change is that the server knows it, so if i=
t is
> running malicious code (and so does the client), then it can tell the mas=
k to
> the client which will be able to emit predicted contents over the wire. S=
o the
> mask must change between two exchanges so that the client cannot guess it=
.

Clear now. Thanks.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From internet-drafts@ietf.org  Mon Jun 13 16:37:46 2011
Return-Path: <internet-drafts@ietf.org>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E61E21F85C4; Mon, 13 Jun 2011 16:37:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.578
X-Spam-Level: 
X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wa9cw41VL0oZ; Mon, 13 Jun 2011 16:37:45 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D566A21F85C2; Mon, 13 Jun 2011 16:37:45 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.55
Message-ID: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
Date: Mon, 13 Jun 2011 16:37:45 -0700
Cc: hybi@ietf.org
Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 13 Jun 2011 23:37:46 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the BiDirectional or Server-Initiated HTT=
P Working Group of the IETF.

	Title           : The WebSocket protocol
	Author(s)       : Ian Fette
	Filename        : draft-ietf-hybi-thewebsocketprotocol-09.txt
	Pages           : 68
	Date            : 2011-06-13

   The WebSocket protocol enables two-way communication between a client
   running untrusted code running in a controlled environment to a
   remote host that has opted-in to communications from that code.  The
   security model used for this is the Origin-based security model
   commonly used by Web browsers.  The protocol consists of an opening
   handshake followed by basic message framing, layered over TCP.  (In
   theory, any transport protocol could be used so long as it provides
   for reliable transport, is byte clean, and supports relatively large
   message sizes.  However, for this document, we consider only TCP.)
   The goal of this technology is to provide a mechanism for browser-
   based applications that need two-way communication with servers that
   does not rely on opening multiple HTTP connections (e.g. using
   XMLHttpRequest or &lt;iframe&gt;s and long polling).

   Please send feedback to the hybi@ietf.org mailing list.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09=
.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09.=
txt

From tyoshino@google.com  Mon Jun 13 23:03:19 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3641B11E8120 for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ooe-oOrpECWa for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:03:18 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC8511E80FC for <hybi@ietf.org>; Mon, 13 Jun 2011 23:03:17 -0700 (PDT)
Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p5E62u53032055 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:02:56 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308031377; bh=cAK2dhyyjsvi4yGQNGuxq1JzVsY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CTizfjnkA2vQomI/HsihvW0keMCw/+lApcIP6O7b8got1ZYWisFW603sF2uFBzZDl IOyE2xfUnDB5EB1Y/f4bA==
Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by kpbe20.cbf.corp.google.com with ESMTP id p5E62srP010463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 13 Jun 2011 23:02:54 -0700
Received: by ywo7 with SMTP id 7so3506132ywo.39 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:02:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cFUUWvIzl0NlQjkNx4w+bQ9DkPCKNoOWyIt9r8aXzms=; b=SLYUOmu9ALEbASewioENJD132NWS37YZfxKri5h1xfnAUxXa52RJBfH1A6HG5iFkU4 KFde20oG3Wzam3qjqgKQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lq5O5QHJhAiwOOov0appASjx5CW45xc1UII88oDHt2YomDBmxBQG8voCIJCMxKzr5x 4DjgISLDJtARuxP4EJCQ==
Received: by 10.150.69.27 with SMTP id r27mr7175520yba.114.1308031374279; Mon, 13 Jun 2011 23:02:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.13 with HTTP; Mon, 13 Jun 2011 23:02:34 -0700 (PDT)
In-Reply-To: <BANLkTimMA73hi-gAUtAyfJ+8ky0Onk+5Dg@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com> <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com> <BANLkTimMA73hi-gAUtAyfJ+8ky0Onk+5Dg@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 14 Jun 2011 15:02:34 +0900
Message-ID: <BANLkTi=hkSSQZ-QRpdY_VABaMAPozsv7fZRt7eARnZgXEzngUA@mail.gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=000e0cd5905a6b46d004a5a5c98e
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 06:03:19 -0000

--000e0cd5905a6b46d004a5a5c98e
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 11, 2011 at 14:49, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

> Page 12 says:
>
>   if Example Corporation were to create a Chat subprotocol to
>   be implemented by many servers around the Web, they could name it
>   "chat.example.com".  If the Example Organization called their
>   competing subprotocol "example.org's chat protocol", then the two
>   subprotocols could be implemented by servers simultaneously
>
> Of course "example.org's chat protocol" is not a valid token according
> to RFC 2616 grammar:
>
>  CHAR           =3D <any US-ASCII character (octets 0 - 127)>
>  token            =3D 1*<any CHAR except CTLs or separators>
>
>
I think this paragraph should be fixed by adding 'by using "chat.example.or=
g"
for their subprotocol name' right after "example.org's chat protocol".
Maybe, that's what the editor originally wanted this text to mean.


> So there are two options:
>
> 1) Make Sec-WebSocket-Protocol grammar 1#token (as defined now). In
> this case protocol values MUST be token (no quoted strings, neither
> separators). Then fix example in page 12.
>

I prefer 1) too.


> 2) Make Sec-WebSocket-Protocol grammar as follows:   1#( quoted-string |
> token )
> In this way both examples in page 12 are valid.
>
> I strongly prefer option 1 (I don't consider that spaces or UTF'8
> multibyte symbols are needed for naming a protocol).

--000e0cd5905a6b46d004a5a5c98e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Sat, Jun 11, 2011 at 14:49, I=F1aki Baz Casti=
llo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Page 12 says:<br>
<br>
 =A0 if Example Corporation were to create a Chat subprotocol to<br>
 =A0 be implemented by many servers around the Web, they could name it<br>
 =A0 &quot;<a href=3D"http://chat.example.com" target=3D"_blank">chat.examp=
le.com</a>&quot;. =A0If the Example Organization called their<br>
 =A0 competing subprotocol &quot;<a href=3D"http://example.org" target=3D"_=
blank">example.org</a>&#39;s chat protocol&quot;, then the two<br>
 =A0 subprotocols could be implemented by servers simultaneously<br>
<br>
Of course &quot;<a href=3D"http://example.org" target=3D"_blank">example.or=
g</a>&#39;s chat protocol&quot; is not a valid token according<br>
to RFC 2616 grammar:<br>
<br>
 =A0CHAR =A0 =A0 =A0 =A0 =A0 =3D &lt;any US-ASCII character (octets 0 - 127=
)&gt;<br>
 =A0token =A0 =A0 =A0 =A0 =A0 =A0=3D 1*&lt;any CHAR except CTLs or separato=
rs&gt;<br>
<br></blockquote><div><br></div><div>I think this paragraph should be fixed=
 by adding &#39;by using=A0&quot;<a href=3D"http://chat.example.org">chat.e=
xample.org</a>&quot; for=A0their subprotocol name&#39; right after &quot;<a=
 href=3D"http://example.org">example.org</a>&#39;s chat protocol&quot;. May=
be, that&#39;s what the editor originally wanted this text to mean.</div>

<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex;">So there are two options:<br>
<br>
1) Make Sec-WebSocket-Protocol grammar 1#token (as defined now). In<br>
this case protocol values MUST be token (no quoted strings, neither<br>
separators). Then fix example in page 12.<br></blockquote><div><br></div><d=
iv>I prefer 1) too.</div><div>=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2) M=
ake Sec-WebSocket-Protocol grammar as follows: =A0 1#( quoted-string | toke=
n )<br>


In this way both examples in page 12 are valid.<br>
<br>
I strongly prefer option 1 (I don&#39;t consider that spaces or UTF&#39;8<b=
r>
multibyte symbols are needed for naming a protocol).</blockquote><div>=A0</=
div></div>

--000e0cd5905a6b46d004a5a5c98e--

From tyoshino@google.com  Mon Jun 13 23:13:05 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38CC1F0C41 for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t2--XTnm6xRN for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:13:04 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 858E31F0C35 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:13:04 -0700 (PDT)
Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p5E6D2SE014631 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:13:02 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308031982; bh=JHo5+bRiD3LvCd/M0OMVwVlojk8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CGNSTK9B/NKdZ03jGGkyA/iROLQ6+j/JCYPw3ITNSzFwE2MZWx3FG7Hhn/2T69YpY 48knzZwthX5aYJqMhqHHw==
Received: from yxs7 (yxs7.prod.google.com [10.190.5.135]) by kpbe12.cbf.corp.google.com with ESMTP id p5E6D0En027204 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 13 Jun 2011 23:13:00 -0700
Received: by yxs7 with SMTP id 7so944977yxs.32 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:13:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=+7WyIq6eulv2g877BVrHx8HBYqHak6TwB5B+0WXWPDk=; b=lMCI1MPlPPJGcpqkKD2m8g220UhWRIRDJEAUMa/eBkTiC7+c/vVp5gvgYHiXe7s7W8 RGE8nLkFOhxf5vLzp4yA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=R6mXDth5BlZV0oFYKI1/ARDjP1VYEvEBhIEj2FSodRJ6JqKVhO/vX5W7walZ8XTM5D FRnczcSI8pPS+5m+1gdQ==
Received: by 10.151.130.2 with SMTP id h2mr7323626ybn.171.1308031980151; Mon, 13 Jun 2011 23:13:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.13 with HTTP; Mon, 13 Jun 2011 23:12:40 -0700 (PDT)
In-Reply-To: <BANLkTi=hkSSQZ-QRpdY_VABaMAPozsv7fZRt7eARnZgXEzngUA@mail.gmail.com>
References: <20110608173012.14596.50398.idtracker@ietfa.amsl.com> <BANLkTi=mEDLtuPJsc6eJThr-QUuKSFH-dw@mail.gmail.com> <BANLkTikmnMZ+e0Pv6L5F3aEj0u0mXC6FOX+ARaS0eoGitJ3WqQ@mail.gmail.com> <BANLkTimMA73hi-gAUtAyfJ+8ky0Onk+5Dg@mail.gmail.com> <BANLkTi=hkSSQZ-QRpdY_VABaMAPozsv7fZRt7eARnZgXEzngUA@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 14 Jun 2011 15:12:40 +0900
Message-ID: <BANLkTikiGZtH0FDKO3SmoapghLh1Nbhbt0XUT6OzRo2SK-C07A@mail.gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=00504502b2d18822aa04a5a5ed36
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D ACTION:draft-ietf-hybi-thewebsocketprotocol-08.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 06:13:05 -0000

--00504502b2d18822aa04a5a5ed36
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry, this just has been addressed by -09.

Takeshi


On Tue, Jun 14, 2011 at 15:02, Takeshi Yoshino <tyoshino@google.com> wrote:

> On Sat, Jun 11, 2011 at 14:49, I=F1aki Baz Castillo <ibc@aliax.net> wrote=
:
>
>> Page 12 says:
>>
>>   if Example Corporation were to create a Chat subprotocol to
>>   be implemented by many servers around the Web, they could name it
>>   "chat.example.com".  If the Example Organization called their
>>   competing subprotocol "example.org's chat protocol", then the two
>>   subprotocols could be implemented by servers simultaneously
>>
>> Of course "example.org's chat protocol" is not a valid token according
>> to RFC 2616 grammar:
>>
>>  CHAR           =3D <any US-ASCII character (octets 0 - 127)>
>>  token            =3D 1*<any CHAR except CTLs or separators>
>>
>>
> I think this paragraph should be fixed by adding 'by using "
> chat.example.org" for their subprotocol name' right after "example.org's
> chat protocol". Maybe, that's what the editor originally wanted this text=
 to
> mean.
>
>
>> So there are two options:
>>
>> 1) Make Sec-WebSocket-Protocol grammar 1#token (as defined now). In
>> this case protocol values MUST be token (no quoted strings, neither
>> separators). Then fix example in page 12.
>>
>
> I prefer 1) too.
>
>
>> 2) Make Sec-WebSocket-Protocol grammar as follows:   1#( quoted-string |
>> token )
>> In this way both examples in page 12 are valid.
>>
>> I strongly prefer option 1 (I don't consider that spaces or UTF'8
>> multibyte symbols are needed for naming a protocol).
>
>
>

--00504502b2d18822aa04a5a5ed36
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry, this just has been addressed by -09.<br clear=3D"all"><br><div>Takes=
hi<br>
<br><br><div class=3D"gmail_quote">On Tue, Jun 14, 2011 at 15:02, Takeshi Y=
oshino <span dir=3D"ltr">&lt;<a href=3D"mailto:tyoshino@google.com">tyoshin=
o@google.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"gmail_quote"><div class=3D"im">On Sat, Jun 11, 2011 at 14:49,=
 I=F1aki Baz Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net=
" target=3D"_blank">ibc@aliax.net</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex">


Page 12 says:<br>
<br>
 =A0 if Example Corporation were to create a Chat subprotocol to<br>
 =A0 be implemented by many servers around the Web, they could name it<br>
 =A0 &quot;<a href=3D"http://chat.example.com" target=3D"_blank">chat.examp=
le.com</a>&quot;. =A0If the Example Organization called their<br>
 =A0 competing subprotocol &quot;<a href=3D"http://example.org" target=3D"_=
blank">example.org</a>&#39;s chat protocol&quot;, then the two<br>
 =A0 subprotocols could be implemented by servers simultaneously<br>
<br>
Of course &quot;<a href=3D"http://example.org" target=3D"_blank">example.or=
g</a>&#39;s chat protocol&quot; is not a valid token according<br>
to RFC 2616 grammar:<br>
<br>
 =A0CHAR =A0 =A0 =A0 =A0 =A0 =3D &lt;any US-ASCII character (octets 0 - 127=
)&gt;<br>
 =A0token =A0 =A0 =A0 =A0 =A0 =A0=3D 1*&lt;any CHAR except CTLs or separato=
rs&gt;<br>
<br></blockquote><div><br></div></div><div>I think this paragraph should be=
 fixed by adding &#39;by using=A0&quot;<a href=3D"http://chat.example.org" =
target=3D"_blank">chat.example.org</a>&quot; for=A0their subprotocol name&#=
39; right after &quot;<a href=3D"http://example.org" target=3D"_blank">exam=
ple.org</a>&#39;s chat protocol&quot;. Maybe, that&#39;s what the editor or=
iginally wanted this text to mean.</div>

<div class=3D"im">
<div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">So there are two options:<br>
<br>
1) Make Sec-WebSocket-Protocol grammar 1#token (as defined now). In<br>
this case protocol values MUST be token (no quoted strings, neither<br>
separators). Then fix example in page 12.<br></blockquote><div><br></div></=
div><div>I prefer 1) too.</div><div class=3D"im"><div>=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex">

2) Make Sec-WebSocket-Protocol grammar as follows: =A0 1#( quoted-string | =
token )<br>

In this way both examples in page 12 are valid.<br>
<br>
I strongly prefer option 1 (I don&#39;t consider that spaces or UTF&#39;8<b=
r>
multibyte symbols are needed for naming a protocol).</blockquote><div>=A0</=
div></div></div>
</blockquote></div><br></div>

--00504502b2d18822aa04a5a5ed36--

From djc.ochtman@gmail.com  Mon Jun 13 23:34:24 2011
Return-Path: <djc.ochtman@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B499B11E81F5 for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.902
X-Spam-Level: 
X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZhh9CIdXQwV for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:34:24 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1982F11E81F4 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:34:24 -0700 (PDT)
Received: by qwc23 with SMTP id 23so3373437qwc.31 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:34:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; bh=pN1aaMBFmXWfZ9MT3o4faLFtdGKdLpDddDB1Nqt81Ok=; b=PBWaShdmCfNfJsVPWiYTeeORWTFkuNxVgrNSpLV78TCA2tvSGgM4MIiNbE7CORRS+m VVUFGH0kQ9NM/sqb6pz3BWWO2ZTtdmQm24+cGTWHTmMRXxWCWr5YPGs4ySEXdh+NRR+0 bkCxEVPIp6CiZTmTTqVEfbTk/SMKuphf7chvQ=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type :content-transfer-encoding; b=UgYUV6If976kJlNy3BGBdUT2/kKYzeCZSrZFQOiqjE2KFrKEli8iOzcQQSQns1DkS0 Jsq04gv/vTkdZi8Xz21dy1ZcOpkVPYw0hkXxMNdRjK5ZfYpFQ5qdySHVqsmLQl5O0EU4 KE7E2OBN4KobEtYrpB7LJ3dGBU6+h6dmVZlcw=
Received: by 10.229.34.130 with SMTP id l2mr4364753qcd.293.1308033263138; Mon, 13 Jun 2011 23:34:23 -0700 (PDT)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.229.187.145 with HTTP; Mon, 13 Jun 2011 23:34:02 -0700 (PDT)
In-Reply-To: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Tue, 14 Jun 2011 08:34:02 +0200
X-Google-Sender-Auth: LOJ-kNpmplMc2lCQlChSBKNNozM
Message-ID: <BANLkTin2yqXAirKYy22PTXtc=WUuE=GQrg@mail.gmail.com>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 06:34:24 -0000

On Tue, Jun 14, 2011 at 01:37,  <internet-drafts@ietf.org> wrote:
> =C2=A0 Please send feedback to the hybi@ietf.org mailing list.

Thanks for incorporating the changes I suggested.

One thing that seems weird: for draft-09, the protocol version has not
been updated because the wire protocol is unchanged, but it seems to
me like the changes in
handling RSV bit values would be enough to require a version update:
the required server behavior is different from draft 8 to draft 9, but
it cannot discern which version the client implements.

Cheers,

Dirkjan

From tyoshino@google.com  Mon Jun 13 23:38:26 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE1011E81F4 for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.634
X-Spam-Level: 
X-Spam-Status: No, score=-105.634 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nsFrAl7fYvw for <hybi@ietfa.amsl.com>; Mon, 13 Jun 2011 23:38:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 70DB111E8070 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:38:25 -0700 (PDT)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p5E6cOi6010191 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:38:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308033504; bh=gsrLh4t88il6e711F0hKtqtJYzw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=R49+MZKoJOqUF9yklKA4j5Lhv8BGOZh9TVuiqMG1WABS7/27xo4XQMLlZ6zhB8nf/ 80x5mNqWBDTP9n1uV1rnQ==
Received: from yia27 (yia27.prod.google.com [10.243.65.27]) by wpaz9.hot.corp.google.com with ESMTP id p5E6cNpp005404 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 13 Jun 2011 23:38:23 -0700
Received: by yia27 with SMTP id 27so1373850yia.19 for <hybi@ietf.org>; Mon, 13 Jun 2011 23:38:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=KpQK5DTiCmrS4dyGeLh3/Xi5WdDZ5pPYJ3m/l8G2KaA=; b=ls+H6DL3skhFvsd20FH8ZmkQGKE6rtOIRd1cPXsEfPE/8l/rs5wV1ghIwuJiYq6775 VNmYqPz+YdhIH4iNC/0w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=jmQDNVRybUmPhmaBevpMqA7JP4CpjNmNavPg3GPiiMGgZoN2wDnddGSpzXOmxl0Rzg r+6FqEzEH3rMslC3u1yg==
Received: by 10.150.208.8 with SMTP id f8mr7922585ybg.399.1308033502169; Mon, 13 Jun 2011 23:38:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.13 with HTTP; Mon, 13 Jun 2011 23:38:02 -0700 (PDT)
In-Reply-To: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 14 Jun 2011 15:38:02 +0900
Message-ID: <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com>
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: multipart/alternative; boundary=000e0cdf1a6040499204a5a64831
X-System-Of-Record: true
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 06:38:26 -0000

--000e0cdf1a6040499204a5a64831
Content-Type: text/plain; charset=ISO-8859-1

Side-by-side diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-09

FYI, list of changes 8->9

----

Semantic change
- any of RSV=1 : ignore the value -> _Fail the WebSocket Connection_
(section4.2)

Note addition, clarification
- example of subprotocol now doesn't contain space (section1.9)
- added note about message interleaving (section4.4)
- added note about close frame masking (section4.5.1)
- added note about version numbering (section5.1)
-- IANA version number registry 9 (actually, this won't be used)
(section11.12)
- added upgrade and connection header (section5.2.2)
- added note about what/how extension may modify (section6.2)
- big rewrite of security consideration about wrong encoding (section10)

Typo, etc.
- typo fixes
-- ws -> wss (section3)
-- host -> port (section3)
- style fixes
-- itemize (section3)
-- bullet point removal (section4.4)
-- moved out Note paragraph to the bottom of the subsection (section4.4)
-- phrasing fix (status-line) (section5.2.2)

--000e0cdf1a6040499204a5a64831
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Side-by-side diff:=A0<a href=3D"http://tools.ietf.org/rfcdiff?url2=3Ddraft-=
ietf-hybi-thewebsocketprotocol-09">http://tools.ietf.org/rfcdiff?url2=3Ddra=
ft-ietf-hybi-thewebsocketprotocol-09</a><div><br></div><div>FYI, list of ch=
anges 8-&gt;9</div>

<div><br></div><div>----</div><div><br></div><div><div>Semantic change</div=
><div>- any of RSV=3D1 : ignore the value -&gt; _Fail the WebSocket Connect=
ion_ (section4.2)</div></div><div><br></div><div>Note addition, clarificati=
on</div>

<div>- example of subprotocol now doesn&#39;t contain space (section1.9)</d=
iv><div>- added note about message interleaving (section4.4)</div><div>- ad=
ded note about close frame masking (section4.5.1)</div><div>- added note ab=
out version numbering (section5.1)</div>

<div>-- IANA version number registry 9 (actually, this won&#39;t be used) (=
section11.12)</div><div>- added upgrade and connection header (section5.2.2=
)</div><div>- added note about what/how extension may modify (section6.2)</=
div>

<div>- big rewrite of security consideration about wrong encoding (section1=
0)</div><div><br></div><div>Typo, etc.</div><div>- typo fixes</div><div>-- =
ws -&gt; wss (section3)</div><div>-- host -&gt; port (section3)</div><div>

- style fixes</div><div>-- itemize (section3)</div><div>-- bullet point rem=
oval (section4.4)</div><div>-- moved out Note paragraph to the bottom of th=
e subsection (section4.4)</div><div>-- phrasing fix (status-line) (section5=
.2.2)</div>

<div><br></div>

--000e0cdf1a6040499204a5a64831--

From pmcmanus@mozilla.com  Tue Jun 14 07:37:18 2011
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7869311E8135 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 07:37:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+OXCjNHFoqk for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 07:37:17 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id B7A2911E80B6 for <hybi@ietf.org>; Tue, 14 Jun 2011 07:37:17 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 96DCF10195; Tue, 14 Jun 2011 10:37:16 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 0E2E910193; Tue, 14 Jun 2011 10:37:11 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: Takeshi Yoshino <tyoshino@google.com>
In-Reply-To: <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 14 Jun 2011 10:37:07 -0400
Message-ID: <1308062227.1944.162.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 14:37:18 -0000

On Tue, 2011-06-14 at 15:38 +0900, Takeshi Yoshino wrote:

> 
> 
> Semantic change
> - any of RSV=1 : ignore the value -> _Fail the WebSocket Connection_
> (section4.2)
> 


Ian, Gabriel, Salvatore,

As always, thanks for the updates?

I'm trying to figure out where this change came from? I can't find a
reference to it in any of the feedback on -08, though I'm probably
overlooking something.



From pmcmanus@mozilla.com  Tue Jun 14 07:40:56 2011
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6A811E80C1 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 07:40:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8qwMowcGgMJ for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 07:40:55 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id CB8B311E80C0 for <hybi@ietf.org>; Tue, 14 Jun 2011 07:40:55 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 4CC8C10195; Tue, 14 Jun 2011 10:40:54 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 1276010154; Tue, 14 Jun 2011 10:40:51 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: Takeshi Yoshino <tyoshino@google.com>
In-Reply-To: <1308062227.1944.162.camel@ds9>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 14 Jun 2011 10:40:47 -0400
Message-ID: <1308062447.1944.163.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 14:40:56 -0000

On Tue, 2011-06-14 at 10:37 -0400, Patrick McManus wrote:

> 
> As always, thanks for the updates?
> 

rather "thanks for the updates.". Doh :)




From ifette@google.com  Tue Jun 14 10:02:58 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F14228007 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 10:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztVHrpr-l86l for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 10:02:57 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEE5228006 for <hybi@ietf.org>; Tue, 14 Jun 2011 10:02:57 -0700 (PDT)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p5EH2t34008619 for <hybi@ietf.org>; Tue, 14 Jun 2011 10:02:56 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308070976; bh=VEXtP31Inp98H6cZ+DksHZiUayo=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=kTO12ciRxHjfcxEFjtG1BOVngUUSiiIOrA31A42B1czqOYdrQU3Pil0Rl5/qunX95 I6idOVl25P5I1q67iXgHw==
Received: from qwj8 (qwj8.prod.google.com [10.241.195.72]) by wpaz9.hot.corp.google.com with ESMTP id p5EH2RSo014679 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 14 Jun 2011 10:02:54 -0700
Received: by qwj8 with SMTP id 8so3389779qwj.4 for <hybi@ietf.org>; Tue, 14 Jun 2011 10:02:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=2WhGSn85OW/3UdgWrSX0H9FWnGKDSoHFm6yUyHGKVyo=; b=vjCpUageFr9BmCzWYWglip0NUc4o8VjCsDzFVhRDoFKNysR3Gh1QXlQPNhZBwAtTni 2oXC1VJC2bjT11l9RL8A==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=Ixfqi29acYzC9vN1DHnbhSvcxjnnq9pArp0pdvZIcDwzCrNB0KSOQe+4uiElkeiPjt B1fYTv0mWH02JocZZZvg==
MIME-Version: 1.0
Received: by 10.229.118.78 with SMTP id u14mr5116107qcq.29.1308070974407; Tue, 14 Jun 2011 10:02:54 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Tue, 14 Jun 2011 10:02:54 -0700 (PDT)
In-Reply-To: <1308062227.1944.162.camel@ds9>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9>
Date: Tue, 14 Jun 2011 10:02:54 -0700
Message-ID: <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Patrick McManus <pmcmanus@mozilla.com>
Content-Type: multipart/alternative; boundary=000e0cd5f4aac5443504a5af011a
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 17:02:58 -0000

--000e0cd5f4aac5443504a5af011a
Content-Type: text/plain; charset=UTF-8

There was an email to the chairs pointing out that unknown values in
reserved bits vs unknown opcode values were handled differently. The chairs
discussed and asked me to make them both fail.

On Tue, Jun 14, 2011 at 7:37 AM, Patrick McManus <pmcmanus@mozilla.com>wrote:

> On Tue, 2011-06-14 at 15:38 +0900, Takeshi Yoshino wrote:
>
> >
> >
> > Semantic change
> > - any of RSV=1 : ignore the value -> _Fail the WebSocket Connection_
> > (section4.2)
> >
>
>
> Ian, Gabriel, Salvatore,
>
> As always, thanks for the updates?
>
> I'm trying to figure out where this change came from? I can't find a
> reference to it in any of the feedback on -08, though I'm probably
> overlooking something.
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--000e0cd5f4aac5443504a5af011a
Content-Type: text/html; charset=UTF-8

There was an email to the chairs pointing out that unknown values in reserved bits vs unknown opcode values were handled differently. The chairs discussed and asked me to make them both fail.<br><br><div class="gmail_quote">
On Tue, Jun 14, 2011 at 7:37 AM, Patrick McManus <span dir="ltr">&lt;<a href="mailto:pmcmanus@mozilla.com">pmcmanus@mozilla.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Tue, 2011-06-14 at 15:38 +0900, Takeshi Yoshino wrote:<br>
<br>
&gt;<br>
&gt;<br>
&gt; Semantic change<br>
&gt; - any of RSV=1 : ignore the value -&gt; _Fail the WebSocket Connection_<br>
&gt; (section4.2)<br>
&gt;<br>
<br>
<br>
</div>Ian, Gabriel, Salvatore,<br>
<br>
As always, thanks for the updates?<br>
<br>
I&#39;m trying to figure out where this change came from? I can&#39;t find a<br>
reference to it in any of the feedback on -08, though I&#39;m probably<br>
overlooking something.<br>
<div><div></div><div class="h5"><br>
<br>
_______________________________________________<br>
hybi mailing list<br>
<a href="mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/hybi" target="_blank">https://www.ietf.org/mailman/listinfo/hybi</a><br>
</div></div></blockquote></div><br>

--000e0cd5f4aac5443504a5af011a--

From pmcmanus@mozilla.com  Tue Jun 14 11:06:51 2011
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA8021F84F9 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 11:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bSAcJP6PgSN for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 11:06:50 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF8C21F849E for <hybi@ietf.org>; Tue, 14 Jun 2011 11:06:50 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id C3C8B10192; Tue, 14 Jun 2011 14:06:49 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 4399110154; Tue, 14 Jun 2011 14:06:45 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: ifette@google.com
In-Reply-To: <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 14 Jun 2011 14:06:42 -0400
Message-ID: <1308074802.1944.175.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 8bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 18:06:51 -0000

On Tue, 2011-06-14 at 10:02 -0700, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
> There was an email to the chairs pointing out that unknown values in
> reserved bits vs unknown opcode values were handled differently. The
> chairs discussed and asked me to make them both fail.
> 

I'm confused. 

In -08 an unknown RSV* mandates a MUST ignore, and an unknown opcode
also mandates a MUST ignore. That seems like a match to me.

In -09 unknown RSV* mandates a FAIL, and unknown opcode mandates an
ignore.

how does that mesh with what was done?





From andy@warmcat.com  Tue Jun 14 11:35:43 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2E11E812E for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 11:35:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level: 
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJxORNZ8v07W for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 11:35:42 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 99DB811E8072 for <hybi@ietf.org>; Tue, 14 Jun 2011 11:35:42 -0700 (PDT)
Message-ID: <4DF7A9ED.3000609@warmcat.com>
Date: Tue, 14 Jun 2011 19:35:25 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Patrick McManus <pmcmanus@mozilla.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>	<BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com>	<1308062227.1944.162.camel@ds9>	<BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9>
In-Reply-To: <1308074802.1944.175.camel@ds9>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 18:35:43 -0000

On 06/14/2011 07:06 PM, Somebody in the thread at some point said:
>
> On Tue, 2011-06-14 at 10:02 -0700, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
>> There was an email to the chairs pointing out that unknown values in
>> reserved bits vs unknown opcode values were handled differently. The
>> chairs discussed and asked me to make them both fail.
>>
>
> I'm confused.
>
> In -08 an unknown RSV* mandates a MUST ignore, and an unknown opcode
> also mandates a MUST ignore. That seems like a match to me.
>
> In -09 unknown RSV* mandates a FAIL, and unknown opcode mandates an
> ignore.
>
> how does that mesh with what was done?

I guess it can make sense, the opcode has a length so you can skip it 
okay even if you don't understand what's inside.

But RSV bits might mess with the framing so you can't interpret the 
length correctly any more, you're dead in the water then for skipping it.

-Andy

From Gabriel.Montenegro@microsoft.com  Tue Jun 14 15:43:43 2011
Return-Path: <Gabriel.Montenegro@microsoft.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D7711E8153 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 15:43:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.161
X-Spam-Level: 
X-Spam-Status: No, score=-10.161 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgZ+VU-5jVCj for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 15:43:43 -0700 (PDT)
Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 4869511E811E for <hybi@ietf.org>; Tue, 14 Jun 2011 15:43:43 -0700 (PDT)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 14 Jun 2011 15:43:42 -0700
Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 14 Jun 2011 15:43:42 -0700
Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Tue, 14 Jun 2011 15:43:41 -0700
From: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
To: =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>, "Patrick McManus" <pmcmanus@mozilla.com>
Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
Thread-Index: AQHMKiMqAJa2fRic6UyXwsa0KTbkfpS83EkAgACF24CAACi7AIAAEdQAgAAIBoD//8iK4A==
Date: Tue, 14 Jun 2011 22:43:41 +0000
Message-ID: <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com>
In-Reply-To: <4DF7A9ED.3000609@warmcat.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.90]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 14 Jun 2011 22:43:43 -0000

VGhlIDA3IHZlcnNpb24gaGFkIG5vIGV4cGxpY2l0IGJlaGF2aW9yIGRlZmluZWQsIGJ1dCBpZiBh
bnkgYml0cyBvciBvcGNvZGVzIHdlcmUgdXNlZCB1bmV4cGVjdGVkbHksIHNvbWV0aGluZyB3YXMg
b2J2aW91c2x5IHZlcnkgd3Jvbmc6DQoNCjA3Og0KICAgQXMgc3VjaCwgaW4gdGhlIGFic2VuY2Ug
b2YgZXh0ZW5zaW9ucyBuZWdvdGlhdGVkIGR1cmluZyB0aGUgb3BlbmluZyAgICANCiAgICBoYW5k
c2hha2UgKFNlY3Rpb24gNSksIGFsbCByZXNlcnZlZCBiaXRzIE1VU1QgYmUgMCBhbmQgcmVzZXJ2
ZWQgICAgIA0KICAgIG9wY29kZSB2YWx1ZXMgTVVTVCBOT1QgYmUgdXNlZC4NCg0KMDggaGFkIHRv
IHJlc29sdmUgd2hhdCB0byBkbyB3aXRoIFJTViBiaXRzIGFuZCBvcGNvZGVzLCBzbyBpdCBpbnRy
b2R1Y2VkIGJlaGF2aW9yIHRvIGlnbm9yZToNCg0KMDg6DQpGb3IgUlNWIGJpdHM6ICIgdGhlIHJl
Y2VpdmluZyBlbmRwb2ludCBNVVNUIGlnbm9yZSB0aGF0IHZhbHVlLiINCk9wY29kZTogIiByZWNl
aXZpbmcgZW5kcG9pbnQgTVVTVCBpZ25vcmUgdGhhdCBmcmFtZSINCg0KSW4gc29tZSBkaXNjdXNz
aW9uIHdpdGggQWxleGV5LCBJYW4gYW5kIHRoZSBjaGFpcnMsIGl0IHNlZW1lZCBsaWtlIHRoZSBi
ZWhhdmlvciB0byBpbnRyb2R1Y2Ugc2hvdWxkIGJlIHRvIGFib3J0IHRoZSBjb25uZWN0aW9uLCBp
biBsaW5lIHdpdGggc29tZXRoaW5nIGJlaW5nIHZlcnkgd3JvbmcuIDA5IHdhcyBzdXBwb3NlZCB0
byByZWZsZWN0IHRoYXQsIGJ1dCBhcyB5b3UgcG9pbnQgb3V0LCBpdCBvbmx5IGRvZXMgdGhhdCBo
YWxmIHdheToNCg0KMDk6DQpGb3IgUlNWIGJpdHM6ICIgcmVjZWl2aW5nIGVuZHBvaW50IE1VU1Qg
X0ZhaWwgdGhlIFdlYlNvY2tldCAgQ29ubmVjdGlvbl8uICINCk9wY29kZTogbm8gY2hhbmdlIGZy
b20gMDg6IGlnbm9yZSB0aGF0IGZyYW1lDQoNClRoZSBpbnRlbnQgd2FzIHRvIGhhdmUgT3Bjb2Rl
IGFsc28gc2F5ICIgcmVjZWl2aW5nIGVuZHBvaW50IE1VU1QgX0ZhaWwgdGhlIFdlYlNvY2tldCAg
Q29ubmVjdGlvbl8iIGdpdmVuIHRoYXQgc29tZXRoaW5nIGlzIHZlcnkgd3JvbmcgYW55d2F5cy4N
Cg0KV2hhdGV2ZXIgaXQgaXMsIGl0IGlzIGJlc3QgaWYgYm90aCBSU1YgYW5kIE9wY29kZSBhcmUg
aGFuZGxlZCB0aGUgc2FtZSB3YXkgKGVpdGhlciBhbHdheXMgZmFpbCB0aGUgY29ubmVjdGlvbiBv
ciBhbHdheXMgaWdub3JlKQ0KDQpEb2VzIHRoaXMgY2xhcmlmeT8gRG8gZm9sa3MgYWdyZWUgdGhh
dCByZXZpc2luZyB0byBmYWlsaW5nIGluIGJvdGggY2FzZXMgaXMgZmluZT8gDQoNCj4gLS0tLS1P
cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogaHliaS1ib3VuY2VzQGlldGYub3JnIFttYWls
dG86aHliaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gIkFuZHkgR3JlZW4gKD8/
PykiDQo+IFNlbnQ6IFR1ZXNkYXksIEp1bmUgMTQsIDIwMTEgMTE6MzUNCj4gVG86IFBhdHJpY2sg
TWNNYW51cw0KPiBDYzogaHliaUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2h5YmldIEktRCBB
Y3Rpb246IGRyYWZ0LWlldGYtaHliaS10aGV3ZWJzb2NrZXRwcm90b2NvbC0wOS50eHQNCj4gDQo+
IE9uIDA2LzE0LzIwMTEgMDc6MDYgUE0sIFNvbWVib2R5IGluIHRoZSB0aHJlYWQgYXQgc29tZSBw
b2ludCBzYWlkOg0KPiA+DQo+ID4gT24gVHVlLCAyMDExLTA2LTE0IGF0IDEwOjAyIC0wNzAwLCBJ
YW4gRmV0dGUgKOOCpOOCouODs+ODleOCp+ODg+ODhuOCoykgd3JvdGU6DQo+ID4+IFRoZXJlIHdh
cyBhbiBlbWFpbCB0byB0aGUgY2hhaXJzIHBvaW50aW5nIG91dCB0aGF0IHVua25vd24gdmFsdWVz
IGluDQo+ID4+IHJlc2VydmVkIGJpdHMgdnMgdW5rbm93biBvcGNvZGUgdmFsdWVzIHdlcmUgaGFu
ZGxlZCBkaWZmZXJlbnRseS4gVGhlDQo+ID4+IGNoYWlycyBkaXNjdXNzZWQgYW5kIGFza2VkIG1l
IHRvIG1ha2UgdGhlbSBib3RoIGZhaWwuDQo+ID4+DQo+ID4NCj4gPiBJJ20gY29uZnVzZWQuDQo+
ID4NCj4gPiBJbiAtMDggYW4gdW5rbm93biBSU1YqIG1hbmRhdGVzIGEgTVVTVCBpZ25vcmUsIGFu
ZCBhbiB1bmtub3duIG9wY29kZQ0KPiA+IGFsc28gbWFuZGF0ZXMgYSBNVVNUIGlnbm9yZS4gVGhh
dCBzZWVtcyBsaWtlIGEgbWF0Y2ggdG8gbWUuDQo+ID4NCj4gPiBJbiAtMDkgdW5rbm93biBSU1Yq
IG1hbmRhdGVzIGEgRkFJTCwgYW5kIHVua25vd24gb3Bjb2RlIG1hbmRhdGVzIGFuDQo+ID4gaWdu
b3JlLg0KPiA+DQo+ID4gaG93IGRvZXMgdGhhdCBtZXNoIHdpdGggd2hhdCB3YXMgZG9uZT8NCj4g
DQo+IEkgZ3Vlc3MgaXQgY2FuIG1ha2Ugc2Vuc2UsIHRoZSBvcGNvZGUgaGFzIGEgbGVuZ3RoIHNv
IHlvdSBjYW4gc2tpcCBpdCBva2F5IGV2ZW4gaWYNCj4geW91IGRvbid0IHVuZGVyc3RhbmQgd2hh
dCdzIGluc2lkZS4NCj4gDQo+IEJ1dCBSU1YgYml0cyBtaWdodCBtZXNzIHdpdGggdGhlIGZyYW1p
bmcgc28geW91IGNhbid0IGludGVycHJldCB0aGUgbGVuZ3RoDQo+IGNvcnJlY3RseSBhbnkgbW9y
ZSwgeW91J3JlIGRlYWQgaW4gdGhlIHdhdGVyIHRoZW4gZm9yIHNraXBwaW5nIGl0Lg0KPiANCj4g
LUFuZHkNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N
Cj4gaHliaSBtYWlsaW5nIGxpc3QNCj4gaHliaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm
Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkNCg==

From pmcmanus@mozilla.com  Tue Jun 14 17:35:36 2011
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A907621F84E9 for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 17:35:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwDngaH0D5Lf for <hybi@ietfa.amsl.com>; Tue, 14 Jun 2011 17:35:35 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id ACE7D21F8480 for <hybi@ietf.org>; Tue, 14 Jun 2011 17:35:35 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id F126010193; Tue, 14 Jun 2011 20:35:34 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 9C92510154; Tue, 14 Jun 2011 20:35:30 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
In-Reply-To: <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 14 Jun 2011 20:35:26 -0400
Message-ID: <1308098126.1944.194.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 00:35:36 -0000

On Tue, 2011-06-14 at 22:43 +0000, Gabriel Montenegro wrote:

> Whatever it is, it is best if both RSV and Opcode are handled the same way (either always fail the connection or always ignore)
> 
> Does this clarify? Do folks agree that revising to failing in both cases is fine? 

Yes, thanks. (yes both to clarification and failing both).

I've been talking with our security team and they are pretty strongly of
the point of view that violations of the RSV and Opcode MUSTs need to
result in failing the connection. That is what we did in our -07
implementation when the error handling was undefined. Silently redacting
messages from the application stream by dropping is considered tatamount
to corruption and is a security risk for the application.

There is a similar reaction to the -08+ requirement that (paraphrased)
non UTF-8 sequences are interpreted as U+FFFD. Silently rewriting the
data is frowned on from a security pov. We are considering just failing
such a non-conformant connection (and I suppose becoming non-conformant
ourselves by doing so.).

-Patrick







From simonp@opera.com  Wed Jun 15 02:16:09 2011
Return-Path: <simonp@opera.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE071F0C85 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 02:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level: 
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC71o4RcFE3A for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 02:16:08 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id B23561F0C66 for <hybi@ietf.org>; Wed, 15 Jun 2011 02:16:07 -0700 (PDT)
Received: from simon-pieterss-macbook.local (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5F9G369014138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 15 Jun 2011 09:16:04 GMT
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Gabriel Montenegro" <Gabriel.Montenegro@microsoft.com>, "Patrick McManus" <pmcmanus@mozilla.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <1308098126.1944.194.camel@ds9>
Date: Wed, 15 Jun 2011 11:16:04 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Simon Pieters" <simonp@opera.com>
Message-ID: <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
In-Reply-To: <1308098126.1944.194.camel@ds9>
User-Agent: Opera Mail/11.11 (MacIntel)
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 09:16:09 -0000

On Wed, 15 Jun 2011 02:35:26 +0200, Patrick McManus <pmcmanus@mozilla.com>  
wrote:

> On Tue, 2011-06-14 at 22:43 +0000, Gabriel Montenegro wrote:
>
>> Whatever it is, it is best if both RSV and Opcode are handled the same  
>> way (either always fail the connection or always ignore)
>>
>> Does this clarify? Do folks agree that revising to failing in both  
>> cases is fine?
>
> Yes, thanks. (yes both to clarification and failing both).
>
> I've been talking with our security team and they are pretty strongly of
> the point of view that violations of the RSV and Opcode MUSTs need to
> result in failing the connection.

I don't know what the security problem is here, but since extensions are  
agreed upon in the handshake the server has no business using the  
extension if the client didn't ask for it, so failing the connection is  
fine with me.

> That is what we did in our -07
> implementation when the error handling was undefined. Silently redacting
> messages from the application stream by dropping is considered tatamount
> to corruption and is a security risk for the application.
>
> There is a similar reaction to the -08+ requirement that (paraphrased)
> non UTF-8 sequences are interpreted as U+FFFD. Silently rewriting the
> data is frowned on from a security pov. We are considering just failing
> such a non-conformant connection (and I suppose becoming non-conformant
> ourselves by doing so.).

Rewriting broken UTF-8 sequences to U+FFFD is done all over the Web  
platform (exception being XML although most browsers did it in XML too  
until it was tested in Acid3). Failing the connection here seems to make  
the protocol brittle. What's the security problem?

-- 
Simon Pieters
Opera Software

From julian.reschke@gmx.de  Wed Jun 15 02:20:19 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFE121F846A for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 02:20:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.42
X-Spam-Level: 
X-Spam-Status: No, score=-103.42 tagged_above=-999 required=5 tests=[AWL=-1.421, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmrVK1NdDv58 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 02:20:18 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 677DA21F8458 for <hybi@ietf.org>; Wed, 15 Jun 2011 02:20:18 -0700 (PDT)
Received: (qmail invoked by alias); 15 Jun 2011 09:20:16 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp038) with SMTP; 15 Jun 2011 11:20:16 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/YfCE6b63YfKgHwQLTmUw9YrKxm/Ojn/AcmAx9Hs 0vZsbfQfuCrRJD
Message-ID: <4DF87950.9050506@gmx.de>
Date: Wed, 15 Jun 2011 11:20:16 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Simon Pieters <simonp@opera.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>	<BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com>	<1308062227.1944.162.camel@ds9>	<BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com>	<1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com>	<CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>	<1308098126.1944.194.camel@ds9> <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
In-Reply-To: <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 09:20:19 -0000

On 2011-06-15 11:16, Simon Pieters wrote:
> ...
>> There is a similar reaction to the -08+ requirement that (paraphrased)
>> non UTF-8 sequences are interpreted as U+FFFD. Silently rewriting the
>> data is frowned on from a security pov. We are considering just failing
>> such a non-conformant connection (and I suppose becoming non-conformant
>> ourselves by doing so.).
>
> Rewriting broken UTF-8 sequences to U+FFFD is done all over the Web
> platform (exception being XML although most browsers did it in XML too
> until it was tested in Acid3). Failing the connection here seems to make
> the protocol brittle. What's the security problem?
> ...

Failing the connections makes broken servers fail early. Sounds good to me.

Best regards, Julian


From pmcmanus@mozilla.com  Wed Jun 15 05:47:32 2011
Return-Path: <pmcmanus@mozilla.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAFC11E80F0 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 05:47:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.224
X-Spam-Level: 
X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_14=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cI0+au3seDM8 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 05:47:32 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 4817911E80EF for <hybi@ietf.org>; Wed, 15 Jun 2011 05:47:32 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 3DAF510194; Wed, 15 Jun 2011 08:47:31 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 008B110154; Wed, 15 Jun 2011 08:47:21 -0400 (EDT)
From: Patrick McManus <pmcmanus@mozilla.com>
To: Simon Pieters <simonp@opera.com>
In-Reply-To: <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTik3Lgp9H4EW1BwRj=n+OQFz6YN547A4y69SysoF7UXnzw@mail.gmail.com> <1308062227.1944.162.camel@ds9> <BANLkTim3PT8y3+u-99BRVb1WwzFUZyxAXQ@mail.gmail.com> <1308074802.1944.175.camel@ds9> <4DF7A9ED.3000609@warmcat.com> <CA566BAEAD6B3F4E8B5C5C4F61710C11403256BF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <1308098126.1944.194.camel@ds9> <op.vw31c2t3idj3kv@simon-pieterss-macbook.local>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 15 Jun 2011 08:47:18 -0400
Message-ID: <1308142038.1944.217.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>, Gabriel Montenegro <Gabriel.Montenegro@microsoft.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 12:47:32 -0000

On Wed, 2011-06-15 at 11:16 +0200, Simon Pieters wrote:

> Rewriting broken UTF-8 sequences to U+FFFD is done all over the Web  
> platform (exception being XML although most browsers did it in XML too  
> until it was tested in Acid3). Failing the connection here seems to make  
> the protocol brittle. What's the security problem?
> 

The objection is a general one to any silent rewriting of application
level data. The value of what was actually sent is now ambiguous to the
js application and this could interfere with application layer
semantics, checksums, signatures, etc... Unlike the broad HTML based
web, there is no reason to introduce the workaround here when we can
simply enforce the must use UTF-8 requirement.






From dadkins@google.com  Wed Jun 15 13:39:45 2011
Return-Path: <dadkins@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8FD611E8136 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 13:39:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVnOwm61jY6u for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 13:39:45 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0F68B11E8080 for <hybi@ietf.org>; Wed, 15 Jun 2011 13:39:44 -0700 (PDT)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p5FKdhsJ001765 for <hybi@ietf.org>; Wed, 15 Jun 2011 13:39:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308170384; bh=8KveHLzwqBN+lZBVXbo9pAQwQi8=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=WiIcoFFR+qKKnUNyfXNbwPc2lssYcrXp2gdyvLHex0B1I1CHp45zYRUbv1EwZNK77 BuPkQadVjv6aOXZrzfLFw==
Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by kpbe14.cbf.corp.google.com with ESMTP id p5FKcsgk013015 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 15 Jun 2011 13:39:42 -0700
Received: by ywf9 with SMTP id 9so842219ywf.22 for <hybi@ietf.org>; Wed, 15 Jun 2011 13:39:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=izHMYGUU2ofRcONKjDVuHK6JUXU0bELiYQ1i9RHIjPY=; b=pH09Rl3Vk6J3RaCgWKjn0VInH7K1C+NnfjtLv13sa1fBh4rDylfLG0i6K9slk9oD3x gTBJhbrlvTFl+Tm1VpEw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=SoaGkkF3yNxxfymuxAxQte/wYZlipgORcfoG0I6kuepSr10QdezDKRl8a6dAV72AEJ ZyVq2DPixmVCqVFD5goQ==
MIME-Version: 1.0
Received: by 10.151.115.6 with SMTP id s6mr70075ybm.130.1308170382094; Wed, 15 Jun 2011 13:39:42 -0700 (PDT)
Received: by 10.150.143.1 with HTTP; Wed, 15 Jun 2011 13:39:41 -0700 (PDT)
Date: Wed, 15 Jun 2011 13:39:41 -0700
Message-ID: <BANLkTi=xgArOEPP2ePmXaSax46T+CQ+Qqj2THgxDLboktjPCgQ@mail.gmail.com>
From: Dan Adkins <dadkins@google.com>
To: hybi@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Subject: [hybi] draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 20:39:45 -0000

Comment:

Sec 1.3. Opening Handshake

   Headers in the handshake are sent by the client in a random order;
   the order is not meaningful.

Saying "random order" here is misleading; it implies that the client
must shuffle the headers (I understand old versions of the protocol
required this.)  If the order is not meaningful, then it is perfectly
fine for an implementation to always send them in the same order.

I think the wording from RFC 2616 (HTTP/1.1) is clearer:

   The order in which header fields with differing field names are
   received is not significant.

-Dan

From stpeter@stpeter.im  Wed Jun 15 14:10:45 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73BF111E8080 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 14:10:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wd5ugiL8CpmX for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 14:10:44 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0571B228005 for <hybi@ietf.org>; Wed, 15 Jun 2011 14:10:44 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 5D4A1400A5 for <hybi@ietf.org>; Wed, 15 Jun 2011 15:11:00 -0600 (MDT)
Message-ID: <4DF91FCA.8060403@stpeter.im>
Date: Wed, 15 Jun 2011 15:10:34 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms010503060100060909000309"
Subject: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 21:10:45 -0000

This is a cryptographically signed message in MIME format.

--------------ms010503060100060909000309
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I've started reviewing -09. For several reasons (mostly because my
review time keeps getting interrupted), I'll provide feedback by
section. This set of comments is mostly editorial.

The abstract seems over-specific. I suggest deleting the parentheticals
and putting them in a slightly-longer first paragraph in the intro
(before Section 1.1).

Section 1.1 has always struck me as strange. It sounds as if we're
developing an IM protocol here! I suggest:

   Historically, creating Web applications that need bidirectional
   communication between a client and a server (e.g., instant messaging
   and gaming applications) has required an abuse of HTTP to poll the
   server for updates while sending upstream notifications as distinct
   HTTP calls. [RFC6202]

I think it would also be helpful to provide an additional paragraph at
the end of Section 1.1 with a bit of justification for why people who
want to write bidirectional Web applications can't simply use existing
application protocols such as IRC and XMPP. Yes, port 80 is the one true
port, and developers complain that it would be a pain to build protocols
like IRC and XMPP directly into a browser, but nothing says it's impossib=
le.

BTW [I-D.ietf-httpstate-cookie] is now [RFC6265] (thanks, Adam!).

Section 1.3 says:

   If the
   server does not wish to accept connections from this origin, it can
   choose to reject the connection by sending an appropriate HTTP error
   code.

Which code?

Section 1.3 says:

   A JavaScript application cannot set a header starting with "Sec-" via
   XHR.

Why not? What is the nature of the restriction?

Section 1.3 says:

   If the |Sec-WebSocket-Accept|
   value does not match the expected value, or if the header is missing,
   or if the HTTP status code is not 101, the connection will not be
   established and WebSocket frames will not be sent.

Do we really mean the following?

   If the |Sec-WebSocket-Accept|
   value does not match the expected value, or if the header is missing,
   or if the HTTP status code is not 101, the browser MUST NOT
   establish the connection and MUST NOT send WebSocket frames.

Section 1.4 uses the term "man-in-the-middle proxies". The term "man in
the middle" might lead people to think of man-in-the-middle attacks as
in RFC 4949 (BTW, an informational reference to RFC 4949 would be good
in Section 2.1). I suggest "middlebox proxies" or "intermediate proxies"
or some more neutral term.

In Section 1.5, I suggest...

OLD:
   It is expected
   that metadata would be layered on top of WebSocket by the application
   layer, in the same way that metadata is layered on top of TCP by the
   application layer (HTTP).

NEW:
   It is expected
   that metadata would be layered on top of WebSocket by the application
   layer, in the same way that metadata is layered on top of TCP by the
   application layer (e.g., HTTP).

This paragraph is hard to read:

   Conceptually, WebSocket is really just a layer on top of TCP that
   adds a Web "origin"-based security model for browsers; adds an
   addressing and protocol naming mechanism to support multiple services
   on one port and multiple host names on one IP address; layers a
   framing mechanism on top of TCP to get back to the IP packet
   mechanism that TCP is built on, but without length limits; and
   includes an additional closing handshake in-band that is designed to
   work in the presence of proxies and other intermediaries.  Other than
   that, it adds nothing.  Basically it is intended to be as close to
   just exposing raw TCP to script as possible given the constraints of
   the Web. It's also designed in such a way that its servers can share
   a port with HTTP servers, by having its handshake be a valid HTTP
   Upgrade request mechanism also.

I suggest breaking it up into bullet points:

   Conceptually, WebSocket is really just a layer on top of TCP that
   does the following:

   * adds a Web "origin"-based security model for browsers

   * adds an addressing and protocol naming mechanism to support
   multiple services on one port and multiple host names on one IP
   address;

   * layers a framing mechanism on top of TCP to get back to the IP
   packet mechanism that TCP is built on, but without length limits

   * includes an additional closing handshake in-band that is designed
   to work in the presence of proxies and other intermediaries

   Other than that, WebSocket adds nothing.  Basically it is intended
   to be as close to just exposing raw TCP to script as possible given
   the constraints of the Web. It's also designed in such a way that
   its servers can share a port with HTTP servers, by having its
   handshake be a valid HTTP Upgrade request mechanism also.

Section 1.7 says:

   By default the WebSocket protocol uses port 80 for regular WebSocket
   connections and port 443 for WebSocket connections tunneled over TLS
   [RFC2818].

I know this has been discussed on the list, but how can an entity
discover if WebSocket is offered on ports other than 80/443? Would the
web server use a redirect to do that? Could it define SRV records?

Section 1.9 says:

   These subprotocol names should be registered as per Section 11.10.
   To avoid potential collisions, it is recommended to use names that
   contain the domain name of the subprotocol's originator.

Following the trail, we find this in Section 11.10:

   Subprotocol Identifier
      The identifier of the subprotocol, as will be used in the Sec-
      WebSocket-Protocol header registered in Section 11.9 of this
      specification.  The value must conform to the requirements given
      in Paragraph 10 of Paragraph 4 of Section 5.1 of this
      specification, namely the value must be a token as defined by RFC
      2616 [RFC2616].

In RFC 2616 we find:

       token          =3D 1*<any CHAR except CTLs or separators>

And in RFC 5234 we find:

         CHAR           =3D  %x01-7F
                                ; any 7-bit US-ASCII character,
                                ;  excluding NUL

So a Subprotocol Identifier is limited to 7-bit ASCII. Given that the
domain name of the subprotocol's originator might be an IDNA, how will
the originator be able to include their domain name in the identifier?
This needs to be specified.

More soon.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms010503060100060909000309
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NTIxMTAzNFowIwYJKoZIhvcNAQkEMRYEFEAyQkAnNZyjnNPIb4Yvyw0yem8aMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBBweNPrKuoT7ZmjhbHvczXVYDZxamcFj7rsNzXuPnO9DNE/lf1+m65yyKy
LQ3DSUoami3EzZWlRyJ67s4+729YmqopotvYdHeC55TeN0UJsJJIpYwOaHHkTJB3eiBwBsKx
XZdTO+Jd+uFsEpAhRrVKiZr9WrE1wcZB0TVCrTWWZ9RCxMB8g1ymybxNP5XBtPnYrODgFSmb
Xt8EZPDI+Q6CGvTSgGSIEryCHvw1ZVWzF2sbP3OLkx/ap6HBpvsGveH6pQfpia7y9VvWpb7f
UslD1MhZHDvT0XchR+UCSVyy0BUzZRAKDGev7wyIW0vLbudf6aLcrFbgQJeGp9bci0WKAAAA
AAAA
--------------ms010503060100060909000309--

From w@1wt.eu  Wed Jun 15 14:14:07 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB6522800C for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 14:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.214
X-Spam-Level: 
X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=-3.171, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4g1umdThhUW for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 14:14:06 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 384EC228005 for <hybi@ietf.org>; Wed, 15 Jun 2011 14:14:06 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5FLE1Ev022092; Wed, 15 Jun 2011 23:14:01 +0200
Date: Wed, 15 Jun 2011 23:14:01 +0200
From: Willy Tarreau <w@1wt.eu>
To: Dan Adkins <dadkins@google.com>
Message-ID: <20110615211401.GG21551@1wt.eu>
References: <BANLkTi=xgArOEPP2ePmXaSax46T+CQ+Qqj2THgxDLboktjPCgQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTi=xgArOEPP2ePmXaSax46T+CQ+Qqj2THgxDLboktjPCgQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 21:14:07 -0000

Hi,

On Wed, Jun 15, 2011 at 01:39:41PM -0700, Dan Adkins wrote:
> Comment:
> 
> Sec 1.3. Opening Handshake
> 
>    Headers in the handshake are sent by the client in a random order;
>    the order is not meaningful.
> 
> Saying "random order" here is misleading; it implies that the client
> must shuffle the headers (I understand old versions of the protocol
> required this.)  If the order is not meaningful, then it is perfectly
> fine for an implementation to always send them in the same order.

Good point.

> I think the wording from RFC 2616 (HTTP/1.1) is clearer:
> 
>    The order in which header fields with differing field names are
>    received is not significant.

Or maybe a mix of both, something around this ?

     Headers in the handshake may be sent by the client in any order,
     so the order in which header fields with differing field names
     are received is not significant.

The same point is valid for the response format BTW.

Willy


From ibc@aliax.net  Wed Jun 15 15:53:04 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3364511E81D0 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 15:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wmqq1r-vgbB for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 15:53:03 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 699CC11E81C7 for <hybi@ietf.org>; Wed, 15 Jun 2011 15:53:03 -0700 (PDT)
Received: by qyk7 with SMTP id 7so640729qyk.10 for <hybi@ietf.org>; Wed, 15 Jun 2011 15:53:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.126.202 with SMTP id d10mr174076qas.253.1308178382648; Wed, 15 Jun 2011 15:53:02 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 15:53:02 -0700 (PDT)
In-Reply-To: <4DF91FCA.8060403@stpeter.im>
References: <4DF91FCA.8060403@stpeter.im>
Date: Thu, 16 Jun 2011 00:53:02 +0200
Message-ID: <BANLkTi=NZafXTNNgBB4-zpzUgtRCUfcY-g@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 22:53:04 -0000

2011/6/15 Peter Saint-Andre <stpeter@stpeter.im>:
> I think it would also be helpful to provide an additional paragraph at
> the end of Section 1.1 with a bit of justification for why people who
> want to write bidirectional Web applications can't simply use existing
> application protocols such as IRC and XMPP.

Right, there is other protocols than HTTP (except for web developers) :)

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Wed Jun 15 16:03:03 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8F1021F847D for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:03:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzMNTavcURPC for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:03:03 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3F79921F8472 for <hybi@ietf.org>; Wed, 15 Jun 2011 16:03:03 -0700 (PDT)
Received: by qyk7 with SMTP id 7so644714qyk.10 for <hybi@ietf.org>; Wed, 15 Jun 2011 16:03:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr180153qce.192.1308178981176; Wed, 15 Jun 2011 16:03:01 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 16:03:01 -0700 (PDT)
In-Reply-To: <4DF91FCA.8060403@stpeter.im>
References: <4DF91FCA.8060403@stpeter.im>
Date: Thu, 16 Jun 2011 01:03:01 +0200
Message-ID: <BANLkTinBEprfvY7oRu6_ZeiX4ei0rS5GjA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 23:03:04 -0000

2011/6/15 Peter Saint-Andre <stpeter@stpeter.im>:
> Section 1.7 says:
>
> =C2=A0 By default the WebSocket protocol uses port 80 for regular WebSock=
et
> =C2=A0 connections and port 443 for WebSocket connections tunneled over T=
LS
> =C2=A0 [RFC2818].
>
> I know this has been discussed on the list, but how can an entity
> discover if WebSocket is offered on ports other than 80/443?

I don't understand the question. The WebSocket URI is provided by the
webserver (most probably) and it can contain a port or not. If it does
not contain a port then default port should be used (80/443 depending
on URI schema). Do I miss something?


> Would the
> web server use a redirect to do that? Could it define SRV records?

I wrote a draft for including SRV records in WebSocket:

  http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02

...but got not too much interest, nothing in fact (I assume that since
HTTP just uses DNS A records, no more DNS stuff exists).




--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From stpeter@stpeter.im  Wed Jun 15 16:05:50 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C153D11E817D for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWle8ohBHxc7 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:05:50 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0F36B11E8178 for <hybi@ietf.org>; Wed, 15 Jun 2011 16:05:50 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4C596400A5 for <hybi@ietf.org>; Wed, 15 Jun 2011 17:06:12 -0600 (MDT)
Message-ID: <4DF93ACB.9070100@stpeter.im>
Date: Wed, 15 Jun 2011 17:05:47 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms060207060300050801040702"
Subject: [hybi] -09: data framing
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 23:05:50 -0000

This is a cryptographically signed message in MIME format.

--------------ms060207060300050801040702
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Here are some comments on Section 4 (I had comments on Section 3 of -08
but they were fixed in -09).

In 4.2...

   frame-rsv1              =3D %x0 ; 1 bit, MUST be 0

   frame-rsv2              =3D %x0 ; 1 bit, MUST be 0

   frame-rsv3              =3D %x0 ; 1 bit, MUST be 0

I think we mean "MUST be 0 unless negotiated otherwise".

In 4.3...

At the beginning of Section 4.4 there is a nice paragraph starting with
"The primary purpose of fragmentation is...", but we don't have
something similar about masking. What is masking intended to accomplish?
Is it supposed to have security properties? Etc.

   The client MUST mask all frames sent to the server.  A server MUST
   close the connection upon receiving a frame with the MASK bit set to
   0.

If framing is truly mandatory for all frames (not "if the parties
negotiate masking, then the client MUST mask all frames..."), why have
the MASK bit in the first place? Would frame-masked be set to 0 only for
control frames (or control frames not containing a body)?

In 4.5.2 and 4.5.3, it might be helpful to say explicitly whether Ping
frames and Pong frames are allowed to contain a body.

In 4.8, I think we mean "prescriptive" instead of "proscriptive" (from
"proscribe" =3D "forbid").

   o  Extension data may be placed in the payload data before the
      application data.

Do we mean "MAY"?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms060207060300050801040702
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NTIzMDU0N1owIwYJKoZIhvcNAQkEMRYEFPuOo31XiTopTH/mMDGmH3G2ExjRMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAfdeG85h+8+vpWY2kWCYV9Fivr1NdRGxTeDhVF8zetzTRUlriknGzxRVR/
EN/D7YJcIK4b9ZgN1kPXdOSG/Rwf4YNVlcr9tLq+rEkVx+inwE40Fu12VxZCQVbb2pGA3n+g
s6xWZORmGbxcILY5P34LfkwM5dRKpgz3z10EeAZekvaYJbz9bT4JJOWeYYH1dBcS7Z2oE5Fz
PDAnRub57bnv+ThPejc/bk3ny+cEvCAvExtMuafAB0YCv4qRok9zdM7M2Tu6EKJlqIrJCHEL
ZRtdK2dssfXLKHarA7uGHaVvQDLDFRkc5p64b0aQokrjtyAINvuhfqFHVSLQV7h+WItdAAAA
AAAA
--------------ms060207060300050801040702--

From stpeter@stpeter.im  Wed Jun 15 16:08:58 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0334D11E8178 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:08:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.449
X-Spam-Level: 
X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vEEkJaOt86Uy for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:08:57 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 644E611E80A0 for <hybi@ietf.org>; Wed, 15 Jun 2011 16:08:57 -0700 (PDT)
Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 95631400A5; Wed, 15 Jun 2011 17:09:19 -0600 (MDT)
Message-ID: <4DF93B86.7050704@stpeter.im>
Date: Wed, 15 Jun 2011 17:08:54 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <4DF91FCA.8060403@stpeter.im> <BANLkTinBEprfvY7oRu6_ZeiX4ei0rS5GjA@mail.gmail.com>
In-Reply-To: <BANLkTinBEprfvY7oRu6_ZeiX4ei0rS5GjA@mail.gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030002040103030105040808"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 23:08:58 -0000

This is a cryptographically signed message in MIME format.

--------------ms030002040103030105040808
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/15/11 5:03 PM, I=C3=B1aki Baz Castillo wrote:
> 2011/6/15 Peter Saint-Andre <stpeter@stpeter.im>:
>> Section 1.7 says:
>>
>>   By default the WebSocket protocol uses port 80 for regular WebSocket=

>>   connections and port 443 for WebSocket connections tunneled over TLS=

>>   [RFC2818].
>>
>> I know this has been discussed on the list, but how can an entity
>> discover if WebSocket is offered on ports other than 80/443?
>=20
> I don't understand the question. The WebSocket URI is provided by the
> webserver (most probably) and it can contain a port or not. If it does
> not contain a port then default port should be used (80/443 depending
> on URI schema). Do I miss something?

Not if you wrote that SRV spec!

I want to point a client to the WebSocket service at example.com. I
can't assume that it's served on port 80 or port 443. How does my client
figure out which port to use?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms030002040103030105040808
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NTIzMDg1NFowIwYJKoZIhvcNAQkEMRYEFIbCfjNTQ3ZJE5srAh8ekK+bzC03MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBSApSPOo6bu2/yU24AZK763feN2b/r/9/5Rg6HErKXlbae+rrMDAKNlovE
BJfGIfkE1oCeHmBZThhUSmn6q+eVlxyEUQAzc4THho1BKBPYX44pGONFikao3okl8gxS5e6b
Oa7TQt12FLdTHyBgCWxxaxwwxvI8jra3t0VdAaUtBecdhOBnHpm0E8zt2txVr6++sBMpcJck
+3cEtEN3JV5woXEL6r054DbawinKY7+NfjPrJXxFKOtAqIT+STVEjehlprWOJufTmSARrsUv
uCM95n8ZcF2+YLbHuZKnL6DXhQB7bf9/hmy6xqEA0Tj0cybDjoknTEhCV38H1rwOy5nOAAAA
AAAA
--------------ms030002040103030105040808--

From ibc@aliax.net  Wed Jun 15 16:16:10 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676CC11E80A0 for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9cLE70GJAlJm for <hybi@ietfa.amsl.com>; Wed, 15 Jun 2011 16:16:09 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0111E8080 for <hybi@ietf.org>; Wed, 15 Jun 2011 16:16:09 -0700 (PDT)
Received: by qwc23 with SMTP id 23so679449qwc.31 for <hybi@ietf.org>; Wed, 15 Jun 2011 16:16:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.90.83 with SMTP id h19mr163002qcm.268.1308179767656; Wed, 15 Jun 2011 16:16:07 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Wed, 15 Jun 2011 16:16:07 -0700 (PDT)
In-Reply-To: <4DF93B86.7050704@stpeter.im>
References: <4DF91FCA.8060403@stpeter.im> <BANLkTinBEprfvY7oRu6_ZeiX4ei0rS5GjA@mail.gmail.com> <4DF93B86.7050704@stpeter.im>
Date: Thu, 16 Jun 2011 01:16:07 +0200
Message-ID: <BANLkTinWNrjdA9sx3Kx7NX_h7OC8k0e_cg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 15 Jun 2011 23:16:10 -0000

2011/6/16 Peter Saint-Andre <stpeter@stpeter.im>:
> I want to point a client to the WebSocket service at example.com. I
> can't assume that it's served on port 80 or port 443. How does my client
> figure out which port to use?

You have not enough data. A WebSocket service is not just identified
by a host and optional port, it also requires an URI schema (ws for
plain TCP or wss for TLS over TCP). So you need a WebSocket URI (like
"ws://1.2.3.4[:999]).

In your example above, if you want to point a client to the WebSocket
service at example.com, how do you know wheter to use TLS or not? you
need to know the URI schema for that.

Of course, in the case of using SRV records things change a bit (since
the server IP and port) must be determined by performing SRV
procedures and more than one valid destinations can be retrieved in
the DNS response.

PS: If I want to point a http client to the HTTP service at
example.com, how does my client figure out which port to use? Same
response as abobe, I need the URI scheme (http or https).  ;)

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Thu Jun 16 03:31:03 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B695711E8106 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 03:31:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level: 
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-1rp5KWbDTw for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 03:31:02 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6D811E80CD for <hybi@ietf.org>; Thu, 16 Jun 2011 03:31:01 -0700 (PDT)
Received: by qwc23 with SMTP id 23so966118qwc.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 03:31:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr539854qcq.230.1308220260729; Thu, 16 Jun 2011 03:31:00 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 03:31:00 -0700 (PDT)
In-Reply-To: <BANLkTinWNrjdA9sx3Kx7NX_h7OC8k0e_cg@mail.gmail.com>
References: <4DF91FCA.8060403@stpeter.im> <BANLkTinBEprfvY7oRu6_ZeiX4ei0rS5GjA@mail.gmail.com> <4DF93B86.7050704@stpeter.im> <BANLkTinWNrjdA9sx3Kx7NX_h7OC8k0e_cg@mail.gmail.com>
Date: Thu, 16 Jun 2011 12:31:00 +0200
Message-ID: <BANLkTinJJKgtq+pr3AuY90SfbhSVJSVbMQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 10:31:03 -0000

2011/6/16 I=C3=B1aki Baz Castillo <ibc@aliax.net>:
> You have not enough data. A WebSocket service is not just identified
> by a host and optional port, it also requires an URI schema (ws for
> plain TCP or wss for TLS over TCP). So you need a WebSocket URI (like
> "ws://1.2.3.4[:999]).
>
> In your example above, if you want to point a client to the WebSocket
> service at example.com, how do you know wheter to use TLS or not? you
> need to know the URI schema for that.
>
> Of course, in the case of using SRV records things change a bit (since
> the server IP and port) must be determined by performing SRV
> procedures and more than one valid destinations can be retrieved in
> the DNS response.


However there is a way, at least in SIP protocol, for the client to
discover which transport (UDP, TCP, TLS over TCP) to use when
contacting a server: using DNS NAPTR records (RFC 2915).

For example, a SIP client wants to contact the server with domain
oversip.net so it performs a NAPTR DNS query:

  $ host -t NAPTR oversip.net
  oversip.net has NAPTR record 10 50 "S" "SIP+D2U" "" _sip._udp.oversip.net=
.
  oversip.net has NAPTR record 40 50 "S" "SIP+D2S" "" _sip._sctp.oversip.ne=
t.
  oversip.net has NAPTR record 50 50 "S" "SIPS+D2S" "" _sips._sctp.oversip.=
net.
  oversip.net has NAPTR record 5 50 "S" "SIPS+D2T" "" _sips._tcp.oversip.ne=
t.
  oversip.net has NAPTR record 10 50 "S" "SIP+D2T" "" _sip._tcp.oversip.net=
.

If the SIP client just supports SIP over UDP, TCP and TLS, it would
just take DNS records with service "SIP+D2U", "SIP+D2T" and
"SIPS+D2T".
It would then choose the resource with best 'order' (in this case
"SIPS+D2T") and perform a DNS SRV query for  _sips._tcp.oversip.net,
retrieving various SRV records (each one with a domain for which DNS A
must be queried, and a port). Then the client should try the SRV
record with best priority (taking into account the 'weight' field if
more than one record with same 'priority') and connect via TCP to the
resulting IP and port.

I see that NAPTR records don't exist in XMPP, so given a domain how
does a client know wheter it must use TCP or TLS??


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From simonp@opera.com  Thu Jun 16 04:15:39 2011
Return-Path: <simonp@opera.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4719711E823E for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 04:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level: 
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olpsobvddCuN for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 04:15:38 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 475E611E822C for <hybi@ietf.org>; Thu, 16 Jun 2011 04:15:37 -0700 (PDT)
Received: from simon-pieterss-macbook.local (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5GBFZm0006102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Jun 2011 11:15:35 GMT
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "hybi@ietf.org" <hybi@ietf.org>, "Peter Saint-Andre" <stpeter@stpeter.im>
References: <4DF91FCA.8060403@stpeter.im>
Date: Thu, 16 Jun 2011 13:15:37 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Simon Pieters" <simonp@opera.com>
Message-ID: <op.vw51kblbidj3kv@simon-pieterss-macbook.local>
In-Reply-To: <4DF91FCA.8060403@stpeter.im>
User-Agent: Opera Mail/11.11 (MacIntel)
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 11:15:39 -0000

On Wed, 15 Jun 2011 23:10:34 +0200, Peter Saint-Andre <stpeter@stpeter.im>  
wrote:

> Section 1.3 says:
>
>    A JavaScript application cannot set a header starting with "Sec-" via
>    XHR.
>
> Why not? What is the nature of the restriction?

"Header names starting with Sec- are not allowed to be set to allow new  
headers to be minted that are guaranteed not to come from XMLHttpRequest."

http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-xmlhttprequest-setrequestheader

> Section 1.3 says:
>
>    If the |Sec-WebSocket-Accept|
>    value does not match the expected value, or if the header is missing,
>    or if the HTTP status code is not 101, the connection will not be
>    established and WebSocket frames will not be sent.
>
> Do we really mean the following?
>
>    If the |Sec-WebSocket-Accept|
>    value does not match the expected value, or if the header is missing,
>    or if the HTTP status code is not 101, the browser MUST NOT
>    establish the connection and MUST NOT send WebSocket frames.

All of section 1 is non-normative so shouldn't contain any requirements.


> This paragraph is hard to read:
>
>    Conceptually, WebSocket is really just a layer on top of TCP that
>    adds a Web "origin"-based security model for browsers; adds an
>    addressing and protocol naming mechanism to support multiple services
>    on one port and multiple host names on one IP address; layers a
>    framing mechanism on top of TCP to get back to the IP packet
>    mechanism that TCP is built on, but without length limits; and
>    includes an additional closing handshake in-band that is designed to
>    work in the presence of proxies and other intermediaries.  Other than
>    that, it adds nothing.  Basically it is intended to be as close to
>    just exposing raw TCP to script as possible given the constraints of
>    the Web. It's also designed in such a way that its servers can share
>    a port with HTTP servers, by having its handshake be a valid HTTP
>    Upgrade request mechanism also.
>
> I suggest breaking it up into bullet points:
>
>    Conceptually, WebSocket is really just a layer on top of TCP that
>    does the following:
>
>    * adds a Web "origin"-based security model for browsers
>
>    * adds an addressing and protocol naming mechanism to support
>    multiple services on one port and multiple host names on one IP
>    address;
>
>    * layers a framing mechanism on top of TCP to get back to the IP
>    packet mechanism that TCP is built on, but without length limits
>
>    * includes an additional closing handshake in-band that is designed
>    to work in the presence of proxies and other intermediaries
>
>    Other than that, WebSocket adds nothing.  Basically it is intended
>    to be as close to just exposing raw TCP to script as possible given
>    the constraints of the Web. It's also designed in such a way that
>    its servers can share a port with HTTP servers, by having its
>    handshake be a valid HTTP Upgrade request mechanism also.

I'm not sure this text is accurate anymore now that we have extensions and  
whatnot.

> Section 1.7 says:
>
>    By default the WebSocket protocol uses port 80 for regular WebSocket
>    connections and port 443 for WebSocket connections tunneled over TLS
>    [RFC2818].
>
> I know this has been discussed on the list, but how can an entity
> discover if WebSocket is offered on ports other than 80/443? Would the
> web server use a redirect to do that? Could it define SRV records?

I don't think there's any discoverability. You can't know that WebSocket  
is offered on ports 80/443 either. I think the Web page that opens a  
WebSocket is supposed to know which port to use. (The WebSocket API  
doesn't allow redirects.)

-- 
Simon Pieters
Opera Software

From ibc@aliax.net  Thu Jun 16 04:18:40 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF33811E8243 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 04:18:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level: 
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooaQv09Q4yuR for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 04:18:40 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C55FC11E822C for <hybi@ietf.org>; Thu, 16 Jun 2011 04:18:39 -0700 (PDT)
Received: by qyk38 with SMTP id 38so267132qyk.10 for <hybi@ietf.org>; Thu, 16 Jun 2011 04:18:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr602739qca.154.1308223119030; Thu, 16 Jun 2011 04:18:39 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 04:18:38 -0700 (PDT)
In-Reply-To: <op.vw51kblbidj3kv@simon-pieterss-macbook.local>
References: <4DF91FCA.8060403@stpeter.im> <op.vw51kblbidj3kv@simon-pieterss-macbook.local>
Date: Thu, 16 Jun 2011 13:18:38 +0200
Message-ID: <BANLkTin-PjMOGekGSBTiyFwxoyrcvQvK-A@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Simon Pieters <simonp@opera.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 11:18:40 -0000

2011/6/16 Simon Pieters <simonp@opera.com>:
>> I know this has been discussed on the list, but how can an entity
>> discover if WebSocket is offered on ports other than 80/443? Would the
>> web server use a redirect to do that? Could it define SRV records?
>
> I don't think there's any discoverability. You can't know that WebSocket =
is
> offered on ports 80/443 either. I think the Web page that opens a WebSock=
et
> is supposed to know which port to use. (The WebSocket API doesn't allow
> redirects.)

Hummm, please, is it not clear that the WebSocket URI schema must be
provided in order to know which transport to use (TLS or TCP) and the
port to connect (80/443 depending the schema, in case no port is
explicitely given in the URI) ??



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Thu Jun 16 05:06:37 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0CD11E8074 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 05:06:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level: 
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id poHDb0TgSUPD for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 05:06:36 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 02F6311E8070 for <hybi@ietf.org>; Thu, 16 Jun 2011 05:06:33 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1019867qwc.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 05:06:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr619213qcq.230.1308225993344; Thu, 16 Jun 2011 05:06:33 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 05:06:33 -0700 (PDT)
In-Reply-To: <op.vw51kblbidj3kv@simon-pieterss-macbook.local>
References: <4DF91FCA.8060403@stpeter.im> <op.vw51kblbidj3kv@simon-pieterss-macbook.local>
Date: Thu, 16 Jun 2011 14:06:33 +0200
Message-ID: <BANLkTi=ddGU-Fwm1EwcYVFFiK=Xb5ys1Sw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Simon Pieters <simonp@opera.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 12:06:37 -0000

2011/6/16 Simon Pieters <simonp@opera.com>:
>> =C2=A0 If the |Sec-WebSocket-Accept|
>> =C2=A0 value does not match the expected value, or if the header is miss=
ing,
>> =C2=A0 or if the HTTP status code is not 101, the browser MUST NOT
>> =C2=A0 establish the connection and MUST NOT send WebSocket frames.
>
> All of section 1 is non-normative so shouldn't contain any requirements.

The question is: should such text be non-normative? WebSocket uses two
protocols:
1) HTTP for the handshake.
2) WebSocket "pure" protocol (masking, framing, WS messages, and so).

If this specification creates an extension for HTTP (as it does, point
1) it MUST specify certain HTTP response codes for certains
situations.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Thu Jun 16 06:06:40 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCD811E8097 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 06:06:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.665
X-Spam-Level: 
X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVCfaLFFgFiz for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 06:06:39 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70DDC11E8071 for <hybi@ietf.org>; Thu, 16 Jun 2011 06:06:35 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1055224qwc.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 06:06:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.202.129 with SMTP id fe1mr207534qab.203.1308229590843; Thu, 16 Jun 2011 06:06:30 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 06:06:30 -0700 (PDT)
Date: Thu, 16 Jun 2011 15:06:30 +0200
Message-ID: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 13:06:40 -0000

Hi, WebSocket is, most probably, the first protocol in the History of
Internet which is, in fact, two protocols over the same stream
(swtiching from HTTP to WebSocket "pure" binary protocol). As an
author of HTTP commented in this maillist, that is not the aim of HTTP
101 response.

So first, WebSocket uses HTTP for the handshake. This is an extension
to HTTP, of course, and as an extension to HTTP it MUST define HTTP
response codes for certain cases not covered by HTTP itself, but just
by this specification (just talking about HTTP for now). The draft
seems not to want to define such codes:

----------------
   The |Sec-WebSocket-Origin| header is used to protect against
   unauthorized cross-origin use of a WebSocket server by scripts using
   the |WebSocket| API in a Web browser.  The server is informed of the
   script origin generating the WebSocket connection request.  If the
   server does not wish to accept connections from this origin, it can
   choose to reject the connection by sending an appropriate HTTP error
   code.
----------------

Which "appropriate HTTP error code"? Please, define it.

What about if the HTTP handshake request contains an invalid
Sec-WebSocket-Key header? what about if the HTTP request misses some
required header? which HTTP status code should be returned by the
server? Please define it.


In the other side, as I said above WebSocket is the first protocol
that uses two different application protocols (HTTP and WebSocket
binary protocol) within the same transport stream (a TCP connection).
Please don't confuse it with SOAP over HTTP, JSONRPC over HTTP,
anything over HTTP or Flash protocol (RTMP) which is a *single*
protocol over TCP and such protocol contains different payloads for
different application streams (signalling, audio, video...).

The reason this WG gives is that "we want WebSocket to work in any
environment in which HTTP just works". So it assumes that Internet is
broken and HTTP is the only working protocol (or just the only valid
protocol). So, the only way to make a webbrowser to speak a protocol
different than HTTP is by opening first a TCP connection, send a HTTP
request and then "switch" to other protocol. Ugly assumption IMHO.

Have you taken a look to rtc-web? http://rtc-web.alvestrand.com/

  ---------------------
  The RTC-Web effort (Real Time Collaboration on the World Wide Web)
is an effort
  to achieve a standardized infrastructure in Web browsers on which real-ti=
me
  interactive communication between users of the World Wide Web can be achi=
eved.
  -----------------------

RTC-Web's aim is to provide realtime communication capabilities to web
browsers, so they could speak other protocols as RTP for audio/video
sessions. Of course I mean pure RTP and not "RTP over HTTP" neither
"first HTTP and then RTP" (following WebSocket fashion).

Now let's imagine we want web browsers to become real SIP or XMPP
clients (I don't mean SIP or XMPP over WebSocket). Do you expect that
the browser will first open a TCP connection, then send an HTTP
"handshake" and then switch same TCP stream to speak SIP or XMPP? and
all this stuff just because "HTTP is the only protocol in the world"?


So, from my point of view, WebSocket breaks Internet model and their
authors should ask themself "who are us to make such aberration in the
History of Internet protocols"?

Please, don't take me wrong. I also assume that there is no way to
rebuild WebSocket with a better design as it would require designing
it from the scratch. So at least, please complete the HTTP part of the
protocol by defining specific HTTP response codes for certain
situations that WebSocket creates (as it is also an extension to HTTP
protocol).

For example, in SIP protocol there are even more SIP response codes
than in HTTP. If a new extension for SIP appears, it may need to
create new response codes or, at least, specify which exact SIP
response codes the server should reply in certain cases (specific to
the given extension). IMHO WebSocket should do the same instead of
trying to avoid responsabilities at HTTP level (since it *does* speak
HTTP).


Regards.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From a.catel@weelya.com  Thu Jun 16 06:44:18 2011
Return-Path: <a.catel@weelya.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27DB011E807F for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 06:44:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.298
X-Spam-Level: 
X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lYwp2Wm5yfr for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 06:44:17 -0700 (PDT)
Received: from hermes.weelya.com (hermes.weelya.com [91.121.5.68]) by ietfa.amsl.com (Postfix) with ESMTP id 5918111E8071 for <hybi@ietf.org>; Thu, 16 Jun 2011 06:44:17 -0700 (PDT)
Received: from [192.168.1.239] (g231204086.adsl.alicedsl.de [92.231.204.86]) by hermes.weelya.com (Postfix) with ESMTPSA id B2BDB4AFFE; Thu, 16 Jun 2011 15:49:30 +0200 (CEST)
Message-ID: <4DFA08A5.3010608@weelya.com>
Date: Thu, 16 Jun 2011 15:44:05 +0200
From: Anthony Catel <a.catel@weelya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>,  hybi@ietf.org
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com>
In-Reply-To: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------010404050304080502010306"
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 13:44:18 -0000

This is a multi-part message in MIME format.
--------------010404050304080502010306
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

    Hi, WebSocket is, most probably, the first protocol in the History of
    Internet which is, in fact, two protocols over the same stream
    (swtiching from HTTP to WebSocket "pure" binary protocol). As an
    author of HTTP commented in this maillist, that is not the aim of HTTP
    101 response.


"101 Switching Protocols
The server understands and is willing to comply with the client's 
request, via the Upgrade message header field (section 14.42), for a 
change in the application protocol being used on this connection. The 
server will switch protocols to those defined by the response's Upgrade 
header field immediately after the empty line which terminates the 101 
response.
The protocol SHOULD be switched only when it is advantageous to do so. 
For example, switching to a newer version of HTTP is advantageous over 
older versions, and switching to a real-time, synchronous protocol might 
be advantageous when delivering resources that use such features."

HTTP doesn't define that a binary protocol should not be used. It also 
doesn't define that "swithing protocols" means "must switch between 
different HTTP version".

IMHO, WebSocket *needs* to be deployed in the wild as soon as possible 
and understood by a maximum of proxy/firewall.

    Now let's imagine we want web browsers to become real SIP or XMPP
    clients (I don't mean SIP or XMPP over WebSocket). Do you expect that
    the browser will first open a TCP connection, then send an HTTP
    "handshake" and then switch same TCP stream to speak SIP or XMPP? and
    all this stuff just because "HTTP is the only protocol in the world"?


Ok, but how do you handle origin security? By writting a SIP extension? 
And thus for every new protocol you want to handle?

Browsers were designed to speak HTTP. IMHO, if you break this rule, it 
leaves the doors wide open to any kind of crazy stuff.


--------------010404050304080502010306
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    <blockquote>
      <pre wrap="">Hi, WebSocket is, most probably, the first protocol in the History of
Internet which is, in fact, two protocols over the same stream
(swtiching from HTTP to WebSocket "pure" binary protocol). As an
author of HTTP commented in this maillist, that is not the aim of HTTP
101 response.</pre>
    </blockquote>
    <br>
    "101 Switching Protocols
    <br>
    The server understands and is willing to comply with the client's
    request, via the Upgrade message header field (section 14.42), for a
    change in the application protocol being used on this connection.
    The server will switch protocols to those defined by the response's
    Upgrade header field immediately after the empty line which
    terminates the 101 response.
    <br>
    The protocol SHOULD be switched only when it is advantageous to do
    so. For example, switching to a newer version of HTTP is
    advantageous over older versions, and switching to a real-time,
    synchronous protocol might be advantageous when delivering resources
    that use such features."<br>
    <br>
    HTTP doesn't define that a binary protocol should not be used. It
    also doesn't define that "swithing protocols" means "must switch
    between different HTTP version".<br>
    <br>
    IMHO, WebSocket *needs* to be deployed in the wild as soon as
    possible and understood by a maximum of proxy/firewall.<br>
    <pre wrap="">
</pre>
    <blockquote>Now let's imagine we want web browsers to become real
      SIP or XMPP<br>
      clients (I don't mean SIP or XMPP over WebSocket). Do you expect
      that<br>
      the browser will first open a TCP connection, then send an HTTP<br>
      "handshake" and then switch same TCP stream to speak SIP or XMPP?
      and<br>
      all this stuff just because "HTTP is the only protocol in the
      world"?<br>
    </blockquote>
    <pre wrap=""></pre>
    <br>
    Ok, but how do you handle origin security? By writting a SIP
    extension? And thus for every new protocol you want to handle?<br>
    <br>
    Browsers were designed to speak HTTP. IMHO, if you break this rule,
    it leaves the doors wide open to any kind of crazy stuff.<br>
    <br>
  </body>
</html>

--------------010404050304080502010306--

From ibc@aliax.net  Thu Jun 16 07:09:41 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C2311E8129 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.665
X-Spam-Level: 
X-Spam-Status: No, score=-2.665 tagged_above=-999 required=5 tests=[AWL=0.012,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL0Y7rbEyBya for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:09:40 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8F11311E810F for <hybi@ietf.org>; Thu, 16 Jun 2011 07:09:40 -0700 (PDT)
Received: by qyk29 with SMTP id 29so280919qyk.10 for <hybi@ietf.org>; Thu, 16 Jun 2011 07:09:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.90.83 with SMTP id h19mr714831qcm.268.1308233379935; Thu, 16 Jun 2011 07:09:39 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 07:09:39 -0700 (PDT)
In-Reply-To: <4DFA08A5.3010608@weelya.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com>
Date: Thu, 16 Jun 2011 16:09:39 +0200
Message-ID: <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Anthony Catel <a.catel@weelya.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 14:09:41 -0000

2011/6/16 Anthony Catel <a.catel@weelya.com>:
> "101 Switching Protocols
> The server understands and is willing to comply with the client's request=
,
> via the Upgrade message header field (section 14.42), for a change in the
> application protocol being used on this connection. The server will switc=
h
> protocols to those defined by the response's Upgrade header field
> immediately after the empty line which terminates the 101 response.
> The protocol SHOULD be switched only when it is advantageous to do so. Fo=
r
> example, switching to a newer version of HTTP is advantageous over older
> versions, and switching to a real-time, synchronous protocol might be
> advantageous when delivering resources that use such features."
>
> HTTP doesn't define that a binary protocol should not be used. It also
> doesn't define that "swithing protocols" means "must switch between
> different HTTP version".

Ok, RFC 2616 said that 21 years ago. That does not mean that it's
suitable. For me is just a vague specification that nobody cared too
much in 1999.



> > Now let's imagine we want web browsers to become real SIP or XMPP
> > clients (I don't mean SIP or XMPP over WebSocket). Do you expect that
> > the browser will first open a TCP connection, then send an HTTP
> > "handshake" and then switch same TCP stream to speak SIP or XMPP? and
> > all this stuff just because "HTTP is the only protocol in the world"?
>
> Ok, but how do you handle origin security? By writting a SIP extension? A=
nd
> thus for every new protocol you want to handle?

Security would be handled at SIP or XMPP level. I dont' understand the
problem. If a web browser becomes a real SIP or XMPP client it could
handle authentication as stated for SIP/XMPP and prompt the human user
when required (as when a web server replies 401).



> Browsers were designed to speak HTTP. IMHO, if you break this rule, it
> leaves the doors wide open to any kind of crazy stuff.

Web-browsers must also speak DNS protocol (directly or indirectly, it
does not matter). If a new protocol is standarized for web browsers,
which is the problem? what about Flash or Java applets? they can open
TCP/UDP connections from the webbrowser to make usage of any other
protocol. Is it a risk? of course, so let's do standards and mandate
security mechanims. But that has nothing to do with "just use HTTP".

Note that web browsers were originally designed to speak HTTP and
render HTML pages. But now everybody wants IM, video, audio and
whatever through a web browser. There is no need to implement all
these new requeriments on top of HTTP. Maybe HTTP is not a good
protocol for that! there are other protocols.

Also, take into account that, after the handshake WebSocket is no
longer HTTP, so it *is* a different protocol. It doesn't matter what
browsers were originally designed to.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From a.catel@weelya.com  Thu Jun 16 07:21:51 2011
Return-Path: <a.catel@weelya.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5AE411E80D7 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JGLyTSatM1dm for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:21:51 -0700 (PDT)
Received: from hermes.weelya.com (hermes.weelya.com [91.121.5.68]) by ietfa.amsl.com (Postfix) with ESMTP id 23D6911E8084 for <hybi@ietf.org>; Thu, 16 Jun 2011 07:21:50 -0700 (PDT)
Received: from [192.168.1.239] (g231204086.adsl.alicedsl.de [92.231.204.86]) by hermes.weelya.com (Postfix) with ESMTPSA id BAD0A4B00B; Thu, 16 Jun 2011 16:27:04 +0200 (CEST)
Message-ID: <4DFA1173.9050509@weelya.com>
Date: Thu, 16 Jun 2011 16:21:39 +0200
From: Anthony Catel <a.catel@weelya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com>	<4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com>
In-Reply-To: <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 14:21:51 -0000

>>> Now let's imagine we want web browsers to become real SIP or XMPP
>>> clients (I don't mean SIP or XMPP over WebSocket). Do you expect that
>>> the browser will first open a TCP connection, then send an HTTP
>>> "handshake" and then switch same TCP stream to speak SIP or XMPP? and
>>> all this stuff just because "HTTP is the only protocol in the world"?
>> Ok, but how do you handle origin security? By writting a SIP extension? And
>> thus for every new protocol you want to handle?
> Security would be handled at SIP or XMPP level. I dont' understand the
> problem. If a web browser becomes a real SIP or XMPP client it could
> handle authentication as stated for SIP/XMPP and prompt the human user
> when required (as when a web server replies 401).

I mean, it the browser can open a "raw" TCP connection and implement any 
kind of protocol.
This must lead to a prompt "Do you allow your browser to open a 
connection to xxxx:xxx?" which I think it's not suitable for user 
experience.

>> Browsers were designed to speak HTTP. IMHO, if you break this rule, it
>> leaves the doors wide open to any kind of crazy stuff.
> Web-browsers must also speak DNS protocol (directly or indirectly, it
> does not matter). If a new protocol is standarized for web browsers,
> which is the problem? what about Flash or Java applets? they can open
> TCP/UDP connections from the webbrowser to make usage of any other
> protocol. Is it a risk? of course, so let's do standards and mandate
> security mechanims. But that has nothing to do with "just use HTTP".
No that's not true. For instance flash use HTTP to ask for a 
"crossdomain.xml"
> Note that web browsers were originally designed to speak HTTP and
> render HTML pages. But now everybody wants IM, video, audio and
> whatever through a web browser. There is no need to implement all
> these new requeriments on top of HTTP. Maybe HTTP is not a good
> protocol for that! there are other protocols.
>

> Also, take into account that, after the handshake WebSocket is no
> longer HTTP, so it *is* a different protocol. It doesn't matter what
> browsers were originally designed to.
>
>

Maybe but intermediate think it's HTTP :)



From ibc@aliax.net  Thu Jun 16 07:28:26 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA0E11E8214 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:28:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.365
X-Spam-Level: 
X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDHXrdr+ZMN0 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:28:25 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7278811E8084 for <hybi@ietf.org>; Thu, 16 Jun 2011 07:28:25 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1112865qwc.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 07:28:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.193.2 with SMTP id ds2mr825781qab.303.1308234504792; Thu, 16 Jun 2011 07:28:24 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 07:28:24 -0700 (PDT)
In-Reply-To: <4DFA1173.9050509@weelya.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com>
Date: Thu, 16 Jun 2011 16:28:24 +0200
Message-ID: <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Anthony Catel <a.catel@weelya.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 14:28:26 -0000

2011/6/16 Anthony Catel <a.catel@weelya.com>:
> I mean, it the browser can open a "raw" TCP connection and implement any
> kind of protocol.
> This must lead to a prompt "Do you allow your browser to open a connectio=
n
> to xxxx:xxx?" which I think it's not suitable for user experience.

I never said that a web browser should allow opening any kind of
communication with a remote server :)

I just said that, if it's standarized, why not to allow a web browser
to directly speak other protocols as SIP or XMPP? I don't mean raw
speaking such protocol from JavaScript or whatever, that should be not
allowed as per security reasons. I mean that web browsers could
implement a SIP and/or XMPP client and provide an API (i.e. for
JavaScript) to use it (the very same as WebSocket proposes). Security
would be built-in within the browser implementation.

PS: I don't want web browsers implementing SIP or XMPP, it was just an
example ;)

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From w@1wt.eu  Thu Jun 16 07:40:29 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5A411E818E for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:40:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.13
X-Spam-Level: 
X-Spam-Status: No, score=-4.13 tagged_above=-999 required=5 tests=[AWL=-2.987,  BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8DLAy9VoxQT for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:40:29 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 9F75C11E80F0 for <hybi@ietf.org>; Thu, 16 Jun 2011 07:40:28 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5GEeKHE028369; Thu, 16 Jun 2011 16:40:20 +0200
Date: Thu, 16 Jun 2011 16:40:20 +0200
From: Willy Tarreau <w@1wt.eu>
To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
Message-ID: <20110616144020.GA28336@1wt.eu>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 14:40:29 -0000

On Thu, Jun 16, 2011 at 04:28:24PM +0200, Iñaki Baz Castillo wrote:
> 2011/6/16 Anthony Catel <a.catel@weelya.com>:
> > I mean, it the browser can open a "raw" TCP connection and implement any
> > kind of protocol.
> > This must lead to a prompt "Do you allow your browser to open a connection
> > to xxxx:xxx?" which I think it's not suitable for user experience.
> 
> I never said that a web browser should allow opening any kind of
> communication with a remote server :)
> 
> I just said that, if it's standarized, why not to allow a web browser
> to directly speak other protocols as SIP or XMPP? I don't mean raw
> speaking such protocol from JavaScript or whatever, that should be not
> allowed as per security reasons. I mean that web browsers could
> implement a SIP and/or XMPP client and provide an API (i.e. for
> JavaScript) to use it (the very same as WebSocket proposes). Security
> would be built-in within the browser implementation.
> 
> PS: I don't want web browsers implementing SIP or XMPP, it was just an
> example ;)

Those subjects were discussed to great extent last year. One of the points
was to reuse existing infrastructure (filtering, proxying, load balancing).
Another one was that a protocol relying on existing infrastructure and
policy rules will get faster adoption than one which requires new ports
to be qualified then opened at many places for the protocol to work. Many
of us are used to work at places where only 80 is opened via proxies, 443
is on a white-list and nothing else is allowed. In such environments, XHR
has been working well precisely because it did not require revisiting
established policies.

Regards,
Willy


From a.catel@weelya.com  Thu Jun 16 07:40:53 2011
Return-Path: <a.catel@weelya.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5377211E8219 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:40:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtIFl8RsnwH4 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 07:40:52 -0700 (PDT)
Received: from hermes.weelya.com (hermes.weelya.com [91.121.5.68]) by ietfa.amsl.com (Postfix) with ESMTP id 3309411E80F0 for <hybi@ietf.org>; Thu, 16 Jun 2011 07:40:52 -0700 (PDT)
Received: from [192.168.1.239] (g231204086.adsl.alicedsl.de [92.231.204.86]) by hermes.weelya.com (Postfix) with ESMTPSA id B7F674AFFD; Thu, 16 Jun 2011 16:46:06 +0200 (CEST)
Message-ID: <4DFA15E9.50800@weelya.com>
Date: Thu, 16 Jun 2011 16:40:41 +0200
From: Anthony Catel <a.catel@weelya.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com>	<4DFA08A5.3010608@weelya.com>	<BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com>	<4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com>
In-Reply-To: <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 14:40:53 -0000

Le 16/06/2011 16:28, IÃ±aki Baz Castillo a Ã©crit :
> 2011/6/16 Anthony Catel<a.catel@weelya.com>:
>> I mean, it the browser can open a "raw" TCP connection and implement any
>> kind of protocol.
>> This must lead to a prompt "Do you allow your browser to open a connection
>> to xxxx:xxx?" which I think it's not suitable for user experience.
> I never said that a web browser should allow opening any kind of
> communication with a remote server :)
>
> I just said that, if it's standarized, why not to allow a web browser
> to directly speak other protocols as SIP or XMPP? I don't mean raw
> speaking such protocol from JavaScript or whatever, that should be not
> allowed as per security reasons. I mean that web browsers could
> implement a SIP and/or XMPP client and provide an API (i.e. for
> JavaScript) to use it (the very same as WebSocket proposes). Security
> would be built-in within the browser implementation.
>
> PS: I don't want web browsers implementing SIP or XMPP, it was just an
> example ;)
>

Nobody said that one day a vendor isn't going to implement a wide 
deployed protocol.
But for now, I think that WebSocket is a good choice to stop the cancer 
of "long polling"
and other ugly hacks (which is what I do).

Also, WebSocket is more or less a generic protocol where you can 
encapsulate other protocol
without having to deal boring things like Origin security, 
proxy/firewall traversal, etc...





From buskanaka@gmail.com  Thu Jun 16 08:55:23 2011
Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DECC11E80FD for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 08:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XyLG1CbnkdvS for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 08:55:22 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E2AC911E80EF for <hybi@ietf.org>; Thu, 16 Jun 2011 08:55:21 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1319124wyb.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 08:55:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:content-type; bh=vDx9LpxKqW6/iIztpkB7TA2La4N50VK243cS84jj4UM=; b=o5Zg38AInW/4SLBExz6iq8xtUD6EwsxJuPag0SmOErXsCQrh0RsocXDHyGbJVhem78 HOiIi1dCYCe99MBeuVdXmUIjSsIPXfN69eQzSQ7z7ee8+B1jdvAYGnmALMEtq4p0XWkq tDACmPO0tYhYtYZI+7SviHYZ/gD3dw2DwTp8o=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=v9hgN+K0c8brrWjb90I3O97PvBITTIQqI9c9lNifbTTgxy3mCpYkYbEMiSdfpUUWhT sc1bp1d1iQTNubW+jgZc3xRxvUo8gC1S2x53lJNtEZ4tT5eeUNnXXmtres0xC9+NcuCE ociAsWIV5bsuyuSluaVdEgvedIpkubWsaVDRA=
Received: by 10.227.164.199 with SMTP id f7mr1087575wby.70.1308239720641; Thu, 16 Jun 2011 08:55:20 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.227.69.3 with HTTP; Thu, 16 Jun 2011 08:54:57 -0700 (PDT)
In-Reply-To: <4DFA15E9.50800@weelya.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 16 Jun 2011 10:54:57 -0500
X-Google-Sender-Auth: 4vkmIPDLKlCLJxt3It6zEnzNTyk
Message-ID: <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=20cf30025502d4761d04a5d64bba
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 15:55:23 -0000

--20cf30025502d4761d04a5d64bba
Content-Type: text/plain; charset=ISO-8859-1

I started to try and answer this StackOverflow question about the protocol
text and realized that I didn't understand it as well as I thought:
http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge

The question is related to this paragraph (which has been in the drafts for
a while unchanged):

    Finally, the server has to prove to the client that it received the
    client's WebSocket handshake, so that the server doesn't accept
    connections that are not WebSocket connections.  This prevents an
    attacker from tricking a WebSocket server by sending it carefully-
    crafted packets using |XMLHttpRequest| or a |form| submission.

I can see how the Sec-WebSocket-Accept would prevent a WebSocket client from
being tricked into connecting to a non-WebSocket server. However, I'm having
difficulty understanding how the Sec-WebSocket-Accept header would prevent a
XMLHttpRequest from succeeding to a WebSockets server since it is sent from
the server. I am aware of the prohibition against "Sec-" headers in the
client to server direction. Is there a requirement that XMLHttpRequest
responses with unrecognized "Sec-" headers be rejected by user agents (and
if so does this only apply in the browser case)?

It's likely I just don't have enough context to understand the paragraph,
but perhaps it could be clarified a bit.

Regards,

Joel Martin

--20cf30025502d4761d04a5d64bba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div><meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-=
8"><div>I started to try and answer this StackOverflow question about the p=
rotocol text and realized that I didn&#39;t understand it as well as I thou=
ght:</div>

<a href=3D"http://stackoverflow.com/questions/6372252/why-does-the-server-i=
n-a-websocket-request-have-to-answer-a-challenge">http://stackoverflow.com/=
questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer=
-a-challenge</a><br>

</div><div><br></div><div>The question is related to this paragraph (which =
has been in the drafts for a while unchanged):</div><div><br></div><div><di=
v>=A0 =A0 Finally, the server has to prove to the client that it received t=
he</div>

<div>=A0 =A0 client&#39;s WebSocket handshake, so that the server doesn&#39=
;t accept</div><div>=A0 =A0 connections that are not WebSocket connections.=
 =A0This prevents an</div><div>=A0 =A0 attacker from tricking a WebSocket s=
erver by sending it carefully-</div>

<div>=A0 =A0 crafted packets using |XMLHttpRequest| or a |form| submission.=
</div></div><div><br></div><div>I can see how the Sec-WebSocket-Accept woul=
d prevent a WebSocket client from being tricked into connecting to a non-We=
bSocket server. However, I&#39;m having difficulty understanding how=A0the=
=A0Sec-WebSocket-Accept header=A0would prevent a XMLHttpRequest from succee=
ding to a WebSockets server since it is sent from the server. I am aware of=
 the prohibition against &quot;Sec-&quot; headers in the client to server d=
irection. Is there a requirement that XMLHttpRequest responses with unrecog=
nized &quot;Sec-&quot; headers be rejected by user agents (and if so does t=
his only apply in the browser case)?</div>

<meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><m=
eta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8"><div=
><br></div><div>It&#39;s likely I just don&#39;t have enough context to und=
erstand the paragraph, but perhaps it could be clarified a bit.</div>

<div><br></div><div>Regards,</div><div><br></div><div>Joel Martin</div>

--20cf30025502d4761d04a5d64bba--

From buskanaka@gmail.com  Thu Jun 16 08:56:36 2011
Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 316CC11E818B for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 08:56:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cPJEQWq6Vzli for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 08:56:35 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3410E11E814C for <hybi@ietf.org>; Thu, 16 Jun 2011 08:56:35 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1320038wyb.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 08:56:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=j9KCEhHIn3oIqzK5tZj8zDzNB+iAq/08VFZgfdl77mQ=; b=MT/DaPHJkP8/RRBVSZv2ncH+u8IhWDPV/NHjMIx50hlQJnqXx2rS3JRqIdMCbvxA3R Nzdj5LiS84v5AIL+TyaH1O+POZbez9A2nrdEPbgg4UAf9AEa6/QEaJOQoR2Eh67jPViX MGLcTXHzaC2nACDC73VZZKRsSuubEK9iVw+bY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=QEdbab9AOveCHaV2OZvRXbcp4iMJHAumbzLsAxzBgvTtUwk9xw3GXQNZAFkNLBngSE 0mg2WZtvFN+4f8ZNaQ1ptPWN6/6jA5lHl0pu/8MeIDrPcaM31Vqi9/szU3XKom0AYykn J0skVAdKqc630a0F6jcpN1ENqqFwbOeY4b7tM=
Received: by 10.227.24.8 with SMTP id t8mr1111797wbb.0.1308239794186; Thu, 16 Jun 2011 08:56:34 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.227.69.3 with HTTP; Thu, 16 Jun 2011 08:56:13 -0700 (PDT)
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 16 Jun 2011 10:56:13 -0500
X-Google-Sender-Auth: By3MIvm2AwQfIhcfFEmHGFfEws0
Message-ID: <BANLkTinYPmc9FgMRN10zCupu5XUyEeUSSg@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=00221597512e36ac1304a5d650bb
Subject: [hybi] Question about Sec-WebSocket-Accept paragraph
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 15:56:36 -0000

--00221597512e36ac1304a5d650bb
Content-Type: text/plain; charset=ISO-8859-1

Sorry for the bogus subject in the previous post.

On Thu, Jun 16, 2011 at 10:54 AM, Joel Martin <hybi@martintribe.org> wrote:

> I started to try and answer this StackOverflow question about the protocol
> text and realized that I didn't understand it as well as I thought:
>
> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>
> The question is related to this paragraph (which has been in the drafts for
> a while unchanged):
>
>     Finally, the server has to prove to the client that it received the
>     client's WebSocket handshake, so that the server doesn't accept
>     connections that are not WebSocket connections.  This prevents an
>     attacker from tricking a WebSocket server by sending it carefully-
>     crafted packets using |XMLHttpRequest| or a |form| submission.
>
> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
> from being tricked into connecting to a non-WebSocket server. However, I'm
> having difficulty understanding how the Sec-WebSocket-Accept header would
> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
> sent from the server. I am aware of the prohibition against "Sec-" headers
> in the client to server direction. Is there a requirement that
> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
> user agents (and if so does this only apply in the browser case)?
>
> It's likely I just don't have enough context to understand the paragraph,
> but perhaps it could be clarified a bit.
>
> Regards,
>
> Joel Martin
>

--00221597512e36ac1304a5d650bb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Sorry for the bogus subject in the previous post.<br><br><div class=3D"gmai=
l_quote">On Thu, Jun 16, 2011 at 10:54 AM, Joel Martin <span dir=3D"ltr">&l=
t;<a href=3D"mailto:hybi@martintribe.org">hybi@martintribe.org</a>&gt;</spa=
n> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div><div>I started to try and answer this =
StackOverflow question about the protocol text and realized that I didn&#39=
;t understand it as well as I thought:</div>


<a href=3D"http://stackoverflow.com/questions/6372252/why-does-the-server-i=
n-a-websocket-request-have-to-answer-a-challenge" target=3D"_blank">http://=
stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-requ=
est-have-to-answer-a-challenge</a><br>


</div><div><br></div><div>The question is related to this paragraph (which =
has been in the drafts for a while unchanged):</div><div><br></div><div><di=
v>=A0 =A0 Finally, the server has to prove to the client that it received t=
he</div>


<div>=A0 =A0 client&#39;s WebSocket handshake, so that the server doesn&#39=
;t accept</div><div>=A0 =A0 connections that are not WebSocket connections.=
 =A0This prevents an</div><div>=A0 =A0 attacker from tricking a WebSocket s=
erver by sending it carefully-</div>


<div>=A0 =A0 crafted packets using |XMLHttpRequest| or a |form| submission.=
</div></div><div><br></div><div>I can see how the Sec-WebSocket-Accept woul=
d prevent a WebSocket client from being tricked into connecting to a non-We=
bSocket server. However, I&#39;m having difficulty understanding how=A0the=
=A0Sec-WebSocket-Accept header=A0would prevent a XMLHttpRequest from succee=
ding to a WebSockets server since it is sent from the server. I am aware of=
 the prohibition against &quot;Sec-&quot; headers in the client to server d=
irection. Is there a requirement that XMLHttpRequest responses with unrecog=
nized &quot;Sec-&quot; headers be rejected by user agents (and if so does t=
his only apply in the browser case)?</div>


<div><br></div><div>It&#39;s likely I just don&#39;t have enough context to=
 understand the paragraph, but perhaps it could be clarified a bit.</div>
<div><br></div><div>Regards,</div><div><br></div><font color=3D"#888888"><d=
iv>Joel Martin</div>
</font></blockquote></div><br>

--00221597512e36ac1304a5d650bb--

From ifette@google.com  Thu Jun 16 09:50:04 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD1511E8121 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 09:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z41dsdauNvIu for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 09:50:00 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C0E8011E811B for <hybi@ietf.org>; Thu, 16 Jun 2011 09:49:59 -0700 (PDT)
Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p5GGnwH4017677 for <hybi@ietf.org>; Thu, 16 Jun 2011 09:49:58 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308242998; bh=fiQuFBXLkFor/nnaOnWdUwjMBRo=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=fbxFOJHdrK1zsFg5xB0TLN3H0cDMMlV4oUwJnmw613+ukrbL8Fq7ivSe2L2OSeeMh QzAHn2521eNL61WOe6qkQ==
Received: from iwn36 (iwn36.prod.google.com [10.241.68.100]) by kpbe15.cbf.corp.google.com with ESMTP id p5GGnu2B014556 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 16 Jun 2011 09:49:56 -0700
Received: by iwn36 with SMTP id 36so1611671iwn.36 for <hybi@ietf.org>; Thu, 16 Jun 2011 09:49:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RTc130Cj2X2YC1o5S9QSec9Y0XXI/76inUMI/A4Dr9U=; b=hC/T8VQQfD6lMmemJpnb32evE8iDjILFOb5VJ8nKXNQx6iB6r+yt5klCvp6CcHF6X8 xkZyX/5dOk4dEKL0XPUA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=YUWt7WVWHUjKYebUMMyryA7lJtKf15knF/3k3YjTyz5FFFXNB/5yGhYALMasa3f5Y4 /Kp4bLLbd/yIpq9wCgWg==
MIME-Version: 1.0
Received: by 10.231.60.73 with SMTP id o9mr987188ibh.33.1308242996287; Thu, 16 Jun 2011 09:49:56 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Thu, 16 Jun 2011 09:49:56 -0700 (PDT)
In-Reply-To: <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com>
Date: Thu, 16 Jun 2011 09:49:56 -0700
Message-ID: <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Joel Martin <hybi@martintribe.org>
Content-Type: multipart/alternative; boundary=0015176f0d2812d94604a5d70f97
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 16:50:04 -0000

--0015176f0d2812d94604a5d70f97
Content-Type: text/plain; charset=UTF-8

Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from
the handshake to prove that the remote end is indeed a websocket server as
you point out. The other part is that Sec-WebSocket-Accept takes the key
from the Sec-WebSocket-Key header, which XHR cannot send and thus the server
doesn't have the information necessary to generate the Accept value as there
is no key from the client.

The original question you link to is basically "why does the server have to
answer a challenge", and it breaks down into two parts:

1. Force server to validate that the client is a WebSocket client (by making
it use a value from Sec-WebSocket-Key along with the GUID, we ensure that
the server actually checks for the presence of Sec-WebSocket-Key.)
2. Let the client validate that the server is actually a WebSocket server
(by checking that Sec-WebSocket-Accept is properly computed).

#1 lets the server be sure it's not responding to some random XHR request,
#2 lets the browser know that it's safe to connect and that it's
communicating to a WebSocket server and not some non-WS target.

On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <hybi@martintribe.org> wrote:

> I started to try and answer this StackOverflow question about the protocol
> text and realized that I didn't understand it as well as I thought:
>
> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>
> The question is related to this paragraph (which has been in the drafts for
> a while unchanged):
>
>     Finally, the server has to prove to the client that it received the
>     client's WebSocket handshake, so that the server doesn't accept
>     connections that are not WebSocket connections.  This prevents an
>     attacker from tricking a WebSocket server by sending it carefully-
>     crafted packets using |XMLHttpRequest| or a |form| submission.
>
> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
> from being tricked into connecting to a non-WebSocket server. However, I'm
> having difficulty understanding how the Sec-WebSocket-Accept header would
> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
> sent from the server. I am aware of the prohibition against "Sec-" headers
> in the client to server direction. Is there a requirement that
> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
> user agents (and if so does this only apply in the browser case)?
>
> It's likely I just don't have enough context to understand the paragraph,
> but perhaps it could be clarified a bit.
>
> Regards,
>
> Joel Martin
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

--0015176f0d2812d94604a5d70f97
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from t=
he handshake to prove that the remote end is indeed a websocket server as y=
ou point out. The other part is that Sec-WebSocket-Accept takes the key fro=
m the=C2=A0Sec-WebSocket-Key header, which XHR cannot send and thus the ser=
ver doesn&#39;t have the information necessary to generate the Accept value=
 as there is no key from the client.<div>
<br></div><div>The original question you link to is basically &quot;why doe=
s the server have to answer a challenge&quot;, and it breaks down into two =
parts:</div><div><br></div><div>1. Force server to validate that the client=
 is a WebSocket client (by making it use a value from Sec-WebSocket-Key alo=
ng with the GUID, we ensure that the server actually checks for the presenc=
e of Sec-WebSocket-Key.)</div>
<div>2. Let the client validate that the server is actually a WebSocket ser=
ver (by checking that Sec-WebSocket-Accept is properly computed).</div><div=
><br></div><div>#1 lets the server be sure it&#39;s not responding to some =
random XHR request,</div>
<div>#2 lets the browser know that it&#39;s safe to connect and that it&#39=
;s communicating to a WebSocket server and not some non-WS target.<br><br><=
div class=3D"gmail_quote">On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:hybi@martintribe.org">hybi@martintribe.=
org</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div><div>I started to try and answer this =
StackOverflow question about the protocol text and realized that I didn&#39=
;t understand it as well as I thought:</div>


<a href=3D"http://stackoverflow.com/questions/6372252/why-does-the-server-i=
n-a-websocket-request-have-to-answer-a-challenge" target=3D"_blank">http://=
stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-requ=
est-have-to-answer-a-challenge</a><br>


</div><div><br></div><div>The question is related to this paragraph (which =
has been in the drafts for a while unchanged):</div><div><br></div><div><di=
v>=C2=A0 =C2=A0 Finally, the server has to prove to the client that it rece=
ived the</div>


<div>=C2=A0 =C2=A0 client&#39;s WebSocket handshake, so that the server doe=
sn&#39;t accept</div><div>=C2=A0 =C2=A0 connections that are not WebSocket =
connections. =C2=A0This prevents an</div><div>=C2=A0 =C2=A0 attacker from t=
ricking a WebSocket server by sending it carefully-</div>


<div>=C2=A0 =C2=A0 crafted packets using |XMLHttpRequest| or a |form| submi=
ssion.</div></div><div><br></div><div>I can see how the Sec-WebSocket-Accep=
t would prevent a WebSocket client from being tricked into connecting to a =
non-WebSocket server. However, I&#39;m having difficulty understanding how=
=C2=A0the=C2=A0Sec-WebSocket-Accept header=C2=A0would prevent a XMLHttpRequ=
est from succeeding to a WebSockets server since it is sent from the server=
. I am aware of the prohibition against &quot;Sec-&quot; headers in the cli=
ent to server direction. Is there a requirement that XMLHttpRequest respons=
es with unrecognized &quot;Sec-&quot; headers be rejected by user agents (a=
nd if so does this only apply in the browser case)?</div>


<div><br></div><div>It&#39;s likely I just don&#39;t have enough context to=
 understand the paragraph, but perhaps it could be clarified a bit.</div>

<div><br></div><div>Regards,</div><div><br></div><font color=3D"#888888"><d=
iv>Joel Martin</div>
</font><br>_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
<br></blockquote></div><br></div>

--0015176f0d2812d94604a5d70f97--

From ifette@google.com  Thu Jun 16 09:50:31 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 402129E8004 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 09:50:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.49
X-Spam-Level: 
X-Spam-Status: No, score=-105.49 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkBwjMszXCMC for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 09:50:30 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6DE11E811B for <hybi@ietf.org>; Thu, 16 Jun 2011 09:50:30 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p5GGoTqW028341 for <hybi@ietf.org>; Thu, 16 Jun 2011 09:50:29 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308243029; bh=yk7bKnB/YJtCLWMFiBmzpAKmjCw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=McHY0/wXzEPXRTdyEpUnSN9tlPpUJW7Ord/SqvR4sqN8ntwdp3hut7W4S3F7sPTkf sV4rpEqxByi/54d4B8cLQ==
Received: from iwn9 (iwn9.prod.google.com [10.241.68.73]) by wpaz21.hot.corp.google.com with ESMTP id p5GGnk6K002420 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 16 Jun 2011 09:50:28 -0700
Received: by iwn9 with SMTP id 9so1612470iwn.37 for <hybi@ietf.org>; Thu, 16 Jun 2011 09:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0DCF4duyoUTv0RoCA+IlTI7X3vEuN6yp5Yxm8zqjnzs=; b=nQUdN6nXUKhHiXT3cCyEbsafj+tanWhXCR2NRyftyx7F/xSgXu/ArSyAK6qUinOED7 IDh1PX/GxF9saSbz1qCA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=WV1ebeP+Pr6tF9s0p/lx4ouPhlUiuqUmA65I4e+PoCYfDumbLTWv/JN8FuEdV+JUVU ovy/PfMwxnAaXjDZ/EdA==
MIME-Version: 1.0
Received: by 10.231.41.69 with SMTP id n5mr1007828ibe.83.1308243028421; Thu, 16 Jun 2011 09:50:28 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Thu, 16 Jun 2011 09:50:28 -0700 (PDT)
In-Reply-To: <BANLkTinYPmc9FgMRN10zCupu5XUyEeUSSg@mail.gmail.com>
References: <BANLkTinYPmc9FgMRN10zCupu5XUyEeUSSg@mail.gmail.com>
Date: Thu, 16 Jun 2011 09:50:28 -0700
Message-ID: <BANLkTikf+p+PLAkfOo6rYsHNN62AHFZaxA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Joel Martin <hybi@martintribe.org>
Content-Type: multipart/alternative; boundary=0015177407d4fd2b1b04a5d71059
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Question about Sec-WebSocket-Accept paragraph
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 16:50:31 -0000

--0015177407d4fd2b1b04a5d71059
Content-Type: text/plain; charset=UTF-8

I just replied on your other post...

On Thu, Jun 16, 2011 at 8:56 AM, Joel Martin <hybi@martintribe.org> wrote:

> Sorry for the bogus subject in the previous post.
>
> On Thu, Jun 16, 2011 at 10:54 AM, Joel Martin <hybi@martintribe.org>wrote:
>
>> I started to try and answer this StackOverflow question about the protocol
>> text and realized that I didn't understand it as well as I thought:
>>
>> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>>
>> The question is related to this paragraph (which has been in the drafts
>> for a while unchanged):
>>
>>     Finally, the server has to prove to the client that it received the
>>     client's WebSocket handshake, so that the server doesn't accept
>>     connections that are not WebSocket connections.  This prevents an
>>     attacker from tricking a WebSocket server by sending it carefully-
>>     crafted packets using |XMLHttpRequest| or a |form| submission.
>>
>> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
>> from being tricked into connecting to a non-WebSocket server. However, I'm
>> having difficulty understanding how the Sec-WebSocket-Accept header would
>> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
>> sent from the server. I am aware of the prohibition against "Sec-" headers
>> in the client to server direction. Is there a requirement that
>> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
>> user agents (and if so does this only apply in the browser case)?
>>
>> It's likely I just don't have enough context to understand the paragraph,
>> but perhaps it could be clarified a bit.
>>
>> Regards,
>>
>> Joel Martin
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

--0015177407d4fd2b1b04a5d71059
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I just replied on your other post...<br><br><div class=3D"gmail_quote">On T=
hu, Jun 16, 2011 at 8:56 AM, Joel Martin <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:hybi@martintribe.org">hybi@martintribe.org</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex;">
Sorry for the bogus subject in the previous post.<br><br><div class=3D"gmai=
l_quote">On Thu, Jun 16, 2011 at 10:54 AM, Joel Martin <span dir=3D"ltr">&l=
t;<a href=3D"mailto:hybi@martintribe.org" target=3D"_blank">hybi@martintrib=
e.org</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div><div>I started to try and answer this S=
tackOverflow question about the protocol text and realized that I didn&#39;=
t understand it as well as I thought:</div>



<a href=3D"http://stackoverflow.com/questions/6372252/why-does-the-server-i=
n-a-websocket-request-have-to-answer-a-challenge" target=3D"_blank">http://=
stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-requ=
est-have-to-answer-a-challenge</a><br>



</div><div><br></div><div>The question is related to this paragraph (which =
has been in the drafts for a while unchanged):</div><div><br></div><div><di=
v>=C2=A0 =C2=A0 Finally, the server has to prove to the client that it rece=
ived the</div>



<div>=C2=A0 =C2=A0 client&#39;s WebSocket handshake, so that the server doe=
sn&#39;t accept</div><div>=C2=A0 =C2=A0 connections that are not WebSocket =
connections. =C2=A0This prevents an</div><div>=C2=A0 =C2=A0 attacker from t=
ricking a WebSocket server by sending it carefully-</div>



<div>=C2=A0 =C2=A0 crafted packets using |XMLHttpRequest| or a |form| submi=
ssion.</div></div><div><br></div><div>I can see how the Sec-WebSocket-Accep=
t would prevent a WebSocket client from being tricked into connecting to a =
non-WebSocket server. However, I&#39;m having difficulty understanding how=
=C2=A0the=C2=A0Sec-WebSocket-Accept header=C2=A0would prevent a XMLHttpRequ=
est from succeeding to a WebSockets server since it is sent from the server=
. I am aware of the prohibition against &quot;Sec-&quot; headers in the cli=
ent to server direction. Is there a requirement that XMLHttpRequest respons=
es with unrecognized &quot;Sec-&quot; headers be rejected by user agents (a=
nd if so does this only apply in the browser case)?</div>



<div><br></div><div>It&#39;s likely I just don&#39;t have enough context to=
 understand the paragraph, but perhaps it could be clarified a bit.</div>
<div><br></div><div>Regards,</div><div><br></div><font color=3D"#888888"><d=
iv>Joel Martin</div>
</font></blockquote></div><br>
<br>_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
<br></blockquote></div><br>

--0015177407d4fd2b1b04a5d71059--

From buskanaka@gmail.com  Thu Jun 16 13:23:20 2011
Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0FC11E82BD for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.751
X-Spam-Level: 
X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOj2uHvWM6wv for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:23:17 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3B11E82C6 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:23:02 -0700 (PDT)
Received: by ewy19 with SMTP id 19so834348ewy.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:23:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=rOVneaAaWg4fzV2aTaR+NsMT2URM+tWuoEhXEqs7lkg=; b=KUhgcoLUKd1g8lkDu0wC1gaowa2kr3sc3XuikFkYYNpq7mtDJKlKy/wtODKDwa7oSG acNyyDb28li4GAx84nuvuGyCp2sUKMcf1gg9PUYcS2xOp9jKRFBc+LyRS+WohND4uMLE dhAeU6Popkbxha1Xhbuj4h7823JWTWKNDEeP0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=F2YfBMygSbcUra5gJRhke/2GGDYWrXfuu6aUqjD1rJd/j+mn7915nO1oWZNFGZ7hdo NDN/lFPHR8C2tXCj8r9svLFUGBs5YHTCKME6LvetVszlCvCQVK5ligyYIneNCmG1AYCH hTuHXTEZ46J0Pm/9XdjZRIOW5mExpedgH0B4c=
Received: by 10.14.2.67 with SMTP id 43mr555502eee.74.1308255781286; Thu, 16 Jun 2011 13:23:01 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.14.127.1 with HTTP; Thu, 16 Jun 2011 13:22:41 -0700 (PDT)
In-Reply-To: <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 16 Jun 2011 15:22:41 -0500
X-Google-Sender-Auth: jWbYH5TZ4GGbRNAsogXUDhoj6BA
Message-ID: <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com>
To: ifette@google.com
Content-Type: multipart/alternative; boundary=0016364269551e75c704a5da090b
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 20:23:20 -0000

--0016364269551e75c704a5da090b
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Ian,

I should have been more clear. I understand why the client and server have
to validate each other, it's the text of the paragraph in the draft that I'm
confused about and I posted here because I think the draft text at least
needs clarification.

    "Finally, the server has to prove to the client that it received the
    client's WebSocket handshake, ..."

- Good so far

    "...so that the server doesn't accept connections that are not
    WebSocket connections."

- What does proving to the client have to do with the _server_ refusing
non-websockets connections? Perhaps this is supposed to be "...so that the
client will not procede with connections to non-WebSocket servers."

    "This prevents an attacker from tricking a WebSocket server by sending
    it carefully-crafted packets using |XMLHttpRequest| or a |form|
submission."

- Again, what does proving to the client have to do with tricking the
WebSocket server? Maybe this should really be "This prevents an attacker
from tricking a non-WebSocket server by sending it carefully-crafted
WebSocket packets because a non-WebSocket server will not return a correct
Sec-WebSocket-Accept value during the handshake".

Regards,

Joel Martin

2011/6/16 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>

> Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from
> the handshake to prove that the remote end is indeed a websocket server as
> you point out. The other part is that Sec-WebSocket-Accept takes the key
> from the Sec-WebSocket-Key header, which XHR cannot send and thus the server
> doesn't have the information necessary to generate the Accept value as there
> is no key from the client.
>
> The original question you link to is basically "why does the server have to
> answer a challenge", and it breaks down into two parts:
>
> 1. Force server to validate that the client is a WebSocket client (by
> making it use a value from Sec-WebSocket-Key along with the GUID, we ensure
> that the server actually checks for the presence of Sec-WebSocket-Key.)
> 2. Let the client validate that the server is actually a WebSocket server
> (by checking that Sec-WebSocket-Accept is properly computed).
>
> #1 lets the server be sure it's not responding to some random XHR request,
> #2 lets the browser know that it's safe to connect and that it's
> communicating to a WebSocket server and not some non-WS target.
>
> On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <hybi@martintribe.org> wrote:
>
>> I started to try and answer this StackOverflow question about the protocol
>> text and realized that I didn't understand it as well as I thought:
>>
>> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>>
>> The question is related to this paragraph (which has been in the drafts
>> for a while unchanged):
>>
>>     Finally, the server has to prove to the client that it received the
>>     client's WebSocket handshake, so that the server doesn't accept
>>     connections that are not WebSocket connections.  This prevents an
>>     attacker from tricking a WebSocket server by sending it carefully-
>>     crafted packets using |XMLHttpRequest| or a |form| submission.
>>
>> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
>> from being tricked into connecting to a non-WebSocket server. However, I'm
>> having difficulty understanding how the Sec-WebSocket-Accept header would
>> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
>> sent from the server. I am aware of the prohibition against "Sec-" headers
>> in the client to server direction. Is there a requirement that
>> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
>> user agents (and if so does this only apply in the browser case)?
>>
>> It's likely I just don't have enough context to understand the paragraph,
>> but perhaps it could be clarified a bit.
>>
>> Regards,
>>
>> Joel Martin
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
>

--0016364269551e75c704a5da090b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Ian,<div><br></div><div>I should have been more clear. I understand why the=
 client and server have to validate each other, it&#39;s the text of the pa=
ragraph in the draft that I&#39;m confused about and I posted here because =
I think the draft text at least needs clarification.<br>

<br></div><div><meta http-equiv=3D"content-type" content=3D"text/html; char=
set=3Dutf-8"><div><div>=C2=A0 =C2=A0 &quot;Finally, the server has to prove=
 to the client that it received the</div><div>=C2=A0 =C2=A0 client&#39;s We=
bSocket handshake, ...&quot;</div>

<div><br></div><div>- Good so far</div><div><br></div><div>=C2=A0 =C2=A0 &q=
uot;...so that the server doesn&#39;t accept=C2=A0connections that are not=
=C2=A0</div><div>=C2=A0 =C2=A0 WebSocket connections.&quot;</div><div><br><=
/div><div>- What does proving to the client have to do with the _server_ re=
fusing non-websockets connections? Perhaps this is supposed to be &quot;...=
so that the client will not procede with connections to non-WebSocket serve=
rs.&quot;</div>

<div><br></div><div>=C2=A0 =C2=A0 &quot;This prevents an=C2=A0attacker from=
 tricking a WebSocket server by sending</div><div>=C2=A0 =C2=A0 it carefull=
y-crafted packets using |XMLHttpRequest| or a |form| submission.&quot;</div=
></div><div><br></div>

<div>- Again, what does proving to the client have to do with tricking the =
WebSocket server? Maybe this should really be &quot;This prevents an attack=
er from tricking a non-WebSocket server by sending it carefully-crafted Web=
Socket packets because a non-WebSocket server will not return a correct Sec=
-WebSocket-Accept value during the handshake&quot;.</div>

<div><br></div></div><div>Regards,</div><div><br></div><div>Joel Martin</di=
v><div><br><div class=3D"gmail_quote">2011/6/16 Ian Fette (=E3=82=A4=E3=82=
=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <span dir=3D"ltr=
">&lt;<a href=3D"mailto:ifette@google.com">ifette@google.com</a>&gt;</span>=
<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Sec-WebSocket-Accept uses a GUID defined in=
 the protocol and the key from the handshake to prove that the remote end i=
s indeed a websocket server as you point out. The other part is that Sec-We=
bSocket-Accept takes the key from the=C2=A0Sec-WebSocket-Key header, which =
XHR cannot send and thus the server doesn&#39;t have the information necess=
ary to generate the Accept value as there is no key from the client.<div>


<br></div><div>The original question you link to is basically &quot;why doe=
s the server have to answer a challenge&quot;, and it breaks down into two =
parts:</div><div><br></div><div>1. Force server to validate that the client=
 is a WebSocket client (by making it use a value from Sec-WebSocket-Key alo=
ng with the GUID, we ensure that the server actually checks for the presenc=
e of Sec-WebSocket-Key.)</div>


<div>2. Let the client validate that the server is actually a WebSocket ser=
ver (by checking that Sec-WebSocket-Accept is properly computed).</div><div=
><br></div><div>#1 lets the server be sure it&#39;s not responding to some =
random XHR request,</div>


<div>#2 lets the browser know that it&#39;s safe to connect and that it&#39=
;s communicating to a WebSocket server and not some non-WS target.<br><br><=
div class=3D"gmail_quote"><div><div></div><div class=3D"h5">On Thu, Jun 16,=
 2011 at 8:54 AM, Joel Martin <span dir=3D"ltr">&lt;<a href=3D"mailto:hybi@=
martintribe.org" target=3D"_blank">hybi@martintribe.org</a>&gt;</span> wrot=
e:<br>


</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div></div><div class=3D"h5=
"><div><div>I started to try and answer this StackOverflow question about t=
he protocol text and realized that I didn&#39;t understand it as well as I =
thought:</div>




<a href=3D"http://stackoverflow.com/questions/6372252/why-does-the-server-i=
n-a-websocket-request-have-to-answer-a-challenge" target=3D"_blank">http://=
stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-requ=
est-have-to-answer-a-challenge</a><br>




</div><div><br></div><div>The question is related to this paragraph (which =
has been in the drafts for a while unchanged):</div><div><br></div><div><di=
v>=C2=A0 =C2=A0 Finally, the server has to prove to the client that it rece=
ived the</div>




<div>=C2=A0 =C2=A0 client&#39;s WebSocket handshake, so that the server doe=
sn&#39;t accept</div><div>=C2=A0 =C2=A0 connections that are not WebSocket =
connections. =C2=A0This prevents an</div><div>=C2=A0 =C2=A0 attacker from t=
ricking a WebSocket server by sending it carefully-</div>




<div>=C2=A0 =C2=A0 crafted packets using |XMLHttpRequest| or a |form| submi=
ssion.</div></div><div><br></div><div>I can see how the Sec-WebSocket-Accep=
t would prevent a WebSocket client from being tricked into connecting to a =
non-WebSocket server. However, I&#39;m having difficulty understanding how=
=C2=A0the=C2=A0Sec-WebSocket-Accept header=C2=A0would prevent a XMLHttpRequ=
est from succeeding to a WebSockets server since it is sent from the server=
. I am aware of the prohibition against &quot;Sec-&quot; headers in the cli=
ent to server direction. Is there a requirement that XMLHttpRequest respons=
es with unrecognized &quot;Sec-&quot; headers be rejected by user agents (a=
nd if so does this only apply in the browser case)?</div>




<div><br></div><div>It&#39;s likely I just don&#39;t have enough context to=
 understand the paragraph, but perhaps it could be clarified a bit.</div>

<div><br></div><div>Regards,</div><div><br></div><font color=3D"#888888"><d=
iv>Joel Martin</div>
</font><br></div></div><div class=3D"im">__________________________________=
_____________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>

--0016364269551e75c704a5da090b--

From ifette@google.com  Thu Jun 16 13:39:39 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA78E11E8234 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.527
X-Spam-Level: 
X-Spam-Status: No, score=-105.527 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-F5IpCSU6FG for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:39:38 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5784811E82D6 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:39:37 -0700 (PDT)
Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p5GKdbJI010993 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:39:37 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308256777; bh=A/ffpJpnrngEMcKqxFBgex5iJHc=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=U1HsUHwWnvM+SdjBgvwON6CYFq+641oHnNZNBgjxrjwNo6hQi1Z5WO5dqU61qTKdN JRYkZnofNx0H02ms/xmdg==
Received: from iwg8 (iwg8.prod.google.com [10.241.66.136]) by wpaz21.hot.corp.google.com with ESMTP id p5GKdaw2025895 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 16 Jun 2011 13:39:36 -0700
Received: by iwg8 with SMTP id 8so2045604iwg.14 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=XD/6fR3jIXRw2KjxdRS33oeATvrW74AoNHVm/TzgCKM=; b=GTgTy4kdrKZ++zEMmgUzGkIEN3hzLYui0OW4PFCVB7jAGS+xw8zUIXrEgHnBgEFWch 7o//y8POJyso3dziVmMw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=O+0AtLibYOXD8KZsVeLIxKu1ASGOOct3I8x14gUF7owZGNWMQKK3afwrvD2ugVrVRL +rknjwHHv6DIK4My75Hw==
MIME-Version: 1.0
Received: by 10.231.41.69 with SMTP id n5mr1185742ibe.83.1308256775957; Thu, 16 Jun 2011 13:39:35 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Thu, 16 Jun 2011 13:39:35 -0700 (PDT)
In-Reply-To: <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com>
Date: Thu, 16 Jun 2011 13:39:35 -0700
Message-ID: <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Joel Martin <hybi@martintribe.org>
Content-Type: multipart/alternative; boundary=0015177407d467ebab04a5da44ad
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 20:39:40 -0000

--0015177407d467ebab04a5da44ad
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Historically, many servers are lazy. They will not bother validating
whatever the client sends, and will just return some value and then get
exploited. By forcing the server to prove something to the client, we
essentially also force the server to validate at least part of the client's
handshake (rather than just hardcoding in some 101 Upgrade WS response). So=
,
by making the server prove something to the client, it's a way of forcing
the server to actually take some steps that have a side effect of protectin=
g
it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)

2011/6/16 Joel Martin <hybi@martintribe.org>

> Ian,
>
> I should have been more clear. I understand why the client and server hav=
e
> to validate each other, it's the text of the paragraph in the draft that =
I'm
> confused about and I posted here because I think the draft text at least
> needs clarification.
>
>     "Finally, the server has to prove to the client that it received the
>     client's WebSocket handshake, ..."
>
> - Good so far
>
>     "...so that the server doesn't accept connections that are not
>     WebSocket connections."
>
> - What does proving to the client have to do with the _server_ refusing
> non-websockets connections? Perhaps this is supposed to be "...so that th=
e
> client will not procede with connections to non-WebSocket servers."
>
>     "This prevents an attacker from tricking a WebSocket server by sendin=
g
>     it carefully-crafted packets using |XMLHttpRequest| or a |form|
> submission."
>
> - Again, what does proving to the client have to do with tricking the
> WebSocket server? Maybe this should really be "This prevents an attacker
> from tricking a non-WebSocket server by sending it carefully-crafted
> WebSocket packets because a non-WebSocket server will not return a correc=
t
> Sec-WebSocket-Accept value during the handshake".
>
> Regards,
>
> Joel Martin
>
> 2011/6/16 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>
>
> Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from
>> the handshake to prove that the remote end is indeed a websocket server =
as
>> you point out. The other part is that Sec-WebSocket-Accept takes the key
>> from the Sec-WebSocket-Key header, which XHR cannot send and thus the se=
rver
>> doesn't have the information necessary to generate the Accept value as t=
here
>> is no key from the client.
>>
>> The original question you link to is basically "why does the server have
>> to answer a challenge", and it breaks down into two parts:
>>
>> 1. Force server to validate that the client is a WebSocket client (by
>> making it use a value from Sec-WebSocket-Key along with the GUID, we ens=
ure
>> that the server actually checks for the presence of Sec-WebSocket-Key.)
>> 2. Let the client validate that the server is actually a WebSocket serve=
r
>> (by checking that Sec-WebSocket-Accept is properly computed).
>>
>> #1 lets the server be sure it's not responding to some random XHR reques=
t,
>> #2 lets the browser know that it's safe to connect and that it's
>> communicating to a WebSocket server and not some non-WS target.
>>
>> On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <hybi@martintribe.org>wrote=
:
>>
>>> I started to try and answer this StackOverflow question about the
>>> protocol text and realized that I didn't understand it as well as I tho=
ught:
>>>
>>> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-web=
socket-request-have-to-answer-a-challenge
>>>
>>> The question is related to this paragraph (which has been in the drafts
>>> for a while unchanged):
>>>
>>>     Finally, the server has to prove to the client that it received the
>>>     client's WebSocket handshake, so that the server doesn't accept
>>>     connections that are not WebSocket connections.  This prevents an
>>>     attacker from tricking a WebSocket server by sending it carefully-
>>>     crafted packets using |XMLHttpRequest| or a |form| submission.
>>>
>>> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
>>> from being tricked into connecting to a non-WebSocket server. However, =
I'm
>>> having difficulty understanding how the Sec-WebSocket-Accept header wou=
ld
>>> prevent a XMLHttpRequest from succeeding to a WebSockets server since i=
t is
>>> sent from the server. I am aware of the prohibition against "Sec-" head=
ers
>>> in the client to server direction. Is there a requirement that
>>> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected b=
y
>>> user agents (and if so does this only apply in the browser case)?
>>>
>>> It's likely I just don't have enough context to understand the paragrap=
h,
>>> but perhaps it could be clarified a bit.
>>>
>>> Regards,
>>>
>>> Joel Martin
>>>
>>> _______________________________________________
>>> hybi mailing list
>>> hybi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/hybi
>>>
>>>
>>
>

--0015177407d467ebab04a5da44ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Historically, many servers are lazy. They will not bother validating whatev=
er the client sends, and will just return some value and then get exploited=
. By forcing the server to prove something to the client, we essentially al=
so force the server to validate at least part of the client&#39;s handshake=
 (rather than just hardcoding in some 101 Upgrade WS response). So, by maki=
ng the server prove something to the client, it&#39;s a way of forcing the =
server to actually take some steps that have a side effect of protecting it=
 (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)<br>
<br><div class=3D"gmail_quote">2011/6/16 Joel Martin <span dir=3D"ltr">&lt;=
<a href=3D"mailto:hybi@martintribe.org">hybi@martintribe.org</a>&gt;</span>=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex;">
Ian,<div><br></div><div>I should have been more clear. I understand why the=
 client and server have to validate each other, it&#39;s the text of the pa=
ragraph in the draft that I&#39;m confused about and I posted here because =
I think the draft text at least needs clarification.<br>


<br></div><div><div><div class=3D"im"><div>=C2=A0 =C2=A0 &quot;Finally, the=
 server has to prove to the client that it received the</div></div><div>=C2=
=A0 =C2=A0 client&#39;s WebSocket handshake, ...&quot;</div>

<div><br></div><div>- Good so far</div><div><br></div><div>=C2=A0 =C2=A0 &q=
uot;...so that the server doesn&#39;t accept=C2=A0connections that are not=
=C2=A0</div><div>=C2=A0 =C2=A0 WebSocket connections.&quot;</div><div><br><=
/div><div>- What does proving to the client have to do with the _server_ re=
fusing non-websockets connections? Perhaps this is supposed to be &quot;...=
so that the client will not procede with connections to non-WebSocket serve=
rs.&quot;</div>
<div class=3D"im">

<div><br></div><div>=C2=A0 =C2=A0 &quot;This prevents an=C2=A0attacker from=
 tricking a WebSocket server by sending</div><div>=C2=A0 =C2=A0 it carefull=
y-crafted packets using |XMLHttpRequest| or a |form| submission.&quot;</div=
></div></div><div><br>
</div>

<div>- Again, what does proving to the client have to do with tricking the =
WebSocket server? Maybe this should really be &quot;This prevents an attack=
er from tricking a non-WebSocket server by sending it carefully-crafted Web=
Socket packets because a non-WebSocket server will not return a correct Sec=
-WebSocket-Accept value during the handshake&quot;.</div>


<div><br></div></div><div>Regards,</div><div><br></div><div>Joel Martin</di=
v><div><br><div class=3D"gmail_quote">2011/6/16 Ian Fette (=E3=82=A4=E3=82=
=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) <span dir=3D"ltr=
">&lt;<a href=3D"mailto:ifette@google.com" target=3D"_blank">ifette@google.=
com</a>&gt;</span><div>
<div></div><div class=3D"h5"><br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Sec-WebSocket-Accept uses a GUID defined in =
the protocol and the key from the handshake to prove that the remote end is=
 indeed a websocket server as you point out. The other part is that Sec-Web=
Socket-Accept takes the key from the=C2=A0Sec-WebSocket-Key header, which X=
HR cannot send and thus the server doesn&#39;t have the information necessa=
ry to generate the Accept value as there is no key from the client.<div>



<br></div><div>The original question you link to is basically &quot;why doe=
s the server have to answer a challenge&quot;, and it breaks down into two =
parts:</div><div><br></div><div>1. Force server to validate that the client=
 is a WebSocket client (by making it use a value from Sec-WebSocket-Key alo=
ng with the GUID, we ensure that the server actually checks for the presenc=
e of Sec-WebSocket-Key.)</div>



<div>2. Let the client validate that the server is actually a WebSocket ser=
ver (by checking that Sec-WebSocket-Accept is properly computed).</div><div=
><br></div><div>#1 lets the server be sure it&#39;s not responding to some =
random XHR request,</div>



<div>#2 lets the browser know that it&#39;s safe to connect and that it&#39=
;s communicating to a WebSocket server and not some non-WS target.<br><br><=
div class=3D"gmail_quote"><div><div></div><div>On Thu, Jun 16, 2011 at 8:54=
 AM, Joel Martin <span dir=3D"ltr">&lt;<a href=3D"mailto:hybi@martintribe.o=
rg" target=3D"_blank">hybi@martintribe.org</a>&gt;</span> wrote:<br>



</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div></div><div><div><div>I=
 started to try and answer this StackOverflow question about the protocol t=
ext and realized that I didn&#39;t understand it as well as I thought:</div=
>





<a href=3D"http://stackoverflow.com/questions/6372252/why-does-the-server-i=
n-a-websocket-request-have-to-answer-a-challenge" target=3D"_blank">http://=
stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-requ=
est-have-to-answer-a-challenge</a><br>





</div><div><br></div><div>The question is related to this paragraph (which =
has been in the drafts for a while unchanged):</div><div><br></div><div><di=
v>=C2=A0 =C2=A0 Finally, the server has to prove to the client that it rece=
ived the</div>





<div>=C2=A0 =C2=A0 client&#39;s WebSocket handshake, so that the server doe=
sn&#39;t accept</div><div>=C2=A0 =C2=A0 connections that are not WebSocket =
connections. =C2=A0This prevents an</div><div>=C2=A0 =C2=A0 attacker from t=
ricking a WebSocket server by sending it carefully-</div>





<div>=C2=A0 =C2=A0 crafted packets using |XMLHttpRequest| or a |form| submi=
ssion.</div></div><div><br></div><div>I can see how the Sec-WebSocket-Accep=
t would prevent a WebSocket client from being tricked into connecting to a =
non-WebSocket server. However, I&#39;m having difficulty understanding how=
=C2=A0the=C2=A0Sec-WebSocket-Accept header=C2=A0would prevent a XMLHttpRequ=
est from succeeding to a WebSockets server since it is sent from the server=
. I am aware of the prohibition against &quot;Sec-&quot; headers in the cli=
ent to server direction. Is there a requirement that XMLHttpRequest respons=
es with unrecognized &quot;Sec-&quot; headers be rejected by user agents (a=
nd if so does this only apply in the browser case)?</div>





<div><br></div><div>It&#39;s likely I just don&#39;t have enough context to=
 understand the paragraph, but perhaps it could be clarified a bit.</div>

<div><br></div><div>Regards,</div><div><br></div><font color=3D"#888888"><d=
iv>Joel Martin</div>
</font><br></div></div><div>_______________________________________________=
<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div></div></div><br></div>
</blockquote></div><br>

--0015177407d467ebab04a5da44ad--

From w@1wt.eu  Thu Jun 16 13:51:56 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DEF911E818C for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:51:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.082
X-Spam-Level: 
X-Spam-Status: No, score=-4.082 tagged_above=-999 required=5 tests=[AWL=-2.039, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxMTxgpOdxX0 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:51:55 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id D51E511E80E5 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:51:53 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5GKplYS030387; Thu, 16 Jun 2011 22:51:47 +0200
Date: Thu, 16 Jun 2011 22:51:47 +0200
From: Willy Tarreau <w@1wt.eu>
To: "Ian Fette (????????????????????????)" <ifette@google.com>
Message-ID: <20110616205147.GA29656@1wt.eu>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 20:51:56 -0000

On Thu, Jun 16, 2011 at 01:39:35PM -0700, Ian Fette (????????????????????????) wrote:
> Historically, many servers are lazy. They will not bother validating
> whatever the client sends, and will just return some value and then get
> exploited. By forcing the server to prove something to the client, we
> essentially also force the server to validate at least part of the client's
> handshake (rather than just hardcoding in some 101 Upgrade WS response). So,
> by making the server prove something to the client, it's a way of forcing
> the server to actually take some steps that have a side effect of protecting
> it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)

And also to ensure that the response was not delivered by a lazy cache.

Willy


From phil127@gmail.com  Thu Jun 16 13:56:23 2011
Return-Path: <phil127@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEB7B11E8234 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:56:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXmECROYT5ib for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 13:56:23 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id D320911E80CF for <hybi@ietf.org>; Thu, 16 Jun 2011 13:56:22 -0700 (PDT)
Received: by wyb29 with SMTP id 29so1522276wyb.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 13:56:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=t3QwQmjUocrpOUGwYTvK7tgYDhOPqqbLAiIn2mN99i8=; b=ZWBBvZpIgIqIh5YHXZbrCqb3M9D7UFSpoOld4BWDJnrm42hPsLKJOlDtJJFoGFz5ly rFJid4/cU+td7nNb/y02ic+0t5bDdZ6MfbcOc0t/zNYCQsenjUbyJtxnGFEtAfFEI6/1 ZpPeWG4VrAv2r2MVlnPRVMqaX+VcFQeWImjxY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=SuHl3rxQLqKa+UQLMaGO4/9fJcbqjYBteEjxDUI7C7Fe68QLBVmoQyA+FpJ6d0gnx0 PnN71zELlK1Z2NMpBZ4/eaISkXTpNykQyVGRdtdYa+S221RM61Z93G1wg1mE/UEN6aWm Jdi5jCzRbvWO/upTngdbz8ikTpOxL12cLiwz8=
Received: by 10.227.6.18 with SMTP id 18mr1402107wbx.66.1308257781885; Thu, 16 Jun 2011 13:56:21 -0700 (PDT)
Received: from [212.201.75.90] (pptp-212-201-75-90.pptp.stw-bonn.de [212.201.75.90]) by mx.google.com with ESMTPS id fm14sm437376wbb.24.2011.06.16.13.56.20 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 13:56:20 -0700 (PDT)
Message-ID: <4DFA6DE9.7090800@gmail.com>
Date: Thu, 16 Jun 2011 22:56:09 +0200
From: Philipp Serafin <phil127@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: ifette@google.com, Hybi <hybi@ietf.org>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com>	<4DFA08A5.3010608@weelya.com>	<BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com>	<4DFA1173.9050509@weelya.com>	<BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com>	<4DFA15E9.50800@weelya.com>	<BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com>	<BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com>	<BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
In-Reply-To: <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 20:56:23 -0000

I think it would be useful to explicitly state the kinds of exploits
that could happen though.

So far, it looks that the only situation where a XMLHTTP-treated-as-WS
request could do harm were when it could access a normally
origin-protected resource from a foreign origin. (From what I
understand, the handshake doesn't protect against attacks on
intermediaries, that's the job of the masking).

However, to properly origin-protect a resource, the server already needs
to check the sec-websocket-origin header - so it is already forced to do
validation.
On the other hand, if the operators of the server don't bother with
origin checks and allow the resource to be accessed cross-origin I don't
see any additional security risks in (trying to) access the resource via
a very kludgy XMLHTTP request than via a WS connection.

I know this has probably been the most-discussed topic on this list and
it's not my intention to cause any additional eye rolling. I just think
it should be taken care to clarify the reasoning behind the handshake,
since this will probably a lot of discussion in web developer forums
once WS is up and running.

Regards,
Philipp Serafin

Am 16.06.2011 22:39, schrieb Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£):
> Historically, many servers are lazy. They will not bother validating
> whatever the client sends, and will just return some value and then
> get exploited. By forcing the server to prove something to the client,
> we essentially also force the server to validate at least part of the
> client's handshake (rather than just hardcoding in some 101 Upgrade WS
> response). So, by making the server prove something to the client,
> it's a way of forcing the server to actually take some steps that have
> a side effect of protecting it (e.g. this /forces/ the server to parse
> the Sec-WebSocket-Key header.)


From buskanaka@gmail.com  Thu Jun 16 14:22:39 2011
Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1A211E82F9 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:22:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.487
X-Spam-Level: 
X-Spam-Status: No, score=-1.487 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ej9WelHDi3wH for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:22:36 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 125B111E8234 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:22:35 -0700 (PDT)
Received: by ewy19 with SMTP id 19so856215ewy.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:22:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=iJ2ha4/eaKabpx7TBrYyTwB2oa11j+8UzDi8F2S1Dv8=; b=JYIrwan8CqcNjIbWT5XpYfqksIpKzSc6cDmFZBUGawqTRFoqEWmejLoTD/2mETrOn+ FzZxedAKehmfuOiA6a9nuR+i8dLUrmFko6pezfZRIMZ9y82JNtPc+3NwQsHsK8da72DA KMhuaM1DvWD+uAWWVRHvQUvkzOguKmegPC/U0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Tf6AggYh5ypdB2A5luzP6bZR2xy5D9fw1x624/miEEm/YNEnsJQZTujj4vNki9WuLf pELzvOJd4/qTNAmjuWXNmtK+0UmLUJmZnnKYPGheKrp70pky5ga6bTtBmL3tkl1smftw G0ELQl5ufgSJh1NuFGbbQX5op0fsThhsui7AQ=
Received: by 10.14.11.1 with SMTP id 1mr594311eew.138.1308259355151; Thu, 16 Jun 2011 14:22:35 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.14.127.1 with HTTP; Thu, 16 Jun 2011 14:22:15 -0700 (PDT)
In-Reply-To: <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 16 Jun 2011 16:22:15 -0500
X-Google-Sender-Auth: YKhZRTF1vDPktfntIml_suDOv7Y
Message-ID: <BANLkTi=89XimRBVOteEkc2GPmx72hpaZQw@mail.gmail.com>
To: ifette@google.com
Content-Type: multipart/alternative; boundary=0016364c7d73234ed304a5dade68
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:22:39 -0000

--0016364c7d73234ed304a5dade68
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

I must be missing some key concept here because your answers have been what
I already know (and agree with), but they still seem out of sync with the
text of the paragraph.

The draft paragraph is talking about protecting WebSocket servers from
NON-WebSocket clients (i.e. XMLHttpRequest or forms) and implying that the
Sec-WebSocket-Accept somehow helps in that situation. I understand how a
XMLHttpRequest/form submission will not have Sec-WebSocket-Key so this
prevents a WebSockets server from answering a non-WebSocket request. But
what does sending a proper Sec-WebSocket-Accept have to do with this case?
The Sec-WebSocket-Accept value is so that a WebSockets client knows the
server is a real WebSocket server. Won't a non-WebSockets request just
ignore the Sec-WebSocket-Accept?

Regards,

Joel Martin

2011/6/16 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>

> Historically, many servers are lazy. They will not bother validating
> whatever the client sends, and will just return some value and then get
> exploited. By forcing the server to prove something to the client, we
> essentially also force the server to validate at least part of the client's
> handshake (rather than just hardcoding in some 101 Upgrade WS response). So,
> by making the server prove something to the client, it's a way of forcing
> the server to actually take some steps that have a side effect of protecting
> it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)
>
>
> 2011/6/16 Joel Martin <hybi@martintribe.org>
>
>> Ian,
>>
>> I should have been more clear. I understand why the client and server have
>> to validate each other, it's the text of the paragraph in the draft that I'm
>> confused about and I posted here because I think the draft text at least
>> needs clarification.
>>
>>     "Finally, the server has to prove to the client that it received the
>>     client's WebSocket handshake, ..."
>>
>> - Good so far
>>
>>     "...so that the server doesn't accept connections that are not
>>     WebSocket connections."
>>
>> - What does proving to the client have to do with the _server_ refusing
>> non-websockets connections? Perhaps this is supposed to be "...so that the
>> client will not procede with connections to non-WebSocket servers."
>>
>>     "This prevents an attacker from tricking a WebSocket server by sending
>>     it carefully-crafted packets using |XMLHttpRequest| or a |form|
>> submission."
>>
>>  - Again, what does proving to the client have to do with tricking the
>> WebSocket server? Maybe this should really be "This prevents an attacker
>> from tricking a non-WebSocket server by sending it carefully-crafted
>> WebSocket packets because a non-WebSocket server will not return a correct
>> Sec-WebSocket-Accept value during the handshake".
>>
>> Regards,
>>
>> Joel Martin
>>
>> 2011/6/16 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>
>>
>> Sec-WebSocket-Accept uses a GUID defined in the protocol and the key from
>>> the handshake to prove that the remote end is indeed a websocket server as
>>> you point out. The other part is that Sec-WebSocket-Accept takes the key
>>> from the Sec-WebSocket-Key header, which XHR cannot send and thus the server
>>> doesn't have the information necessary to generate the Accept value as there
>>> is no key from the client.
>>>
>>> The original question you link to is basically "why does the server have
>>> to answer a challenge", and it breaks down into two parts:
>>>
>>> 1. Force server to validate that the client is a WebSocket client (by
>>> making it use a value from Sec-WebSocket-Key along with the GUID, we ensure
>>> that the server actually checks for the presence of Sec-WebSocket-Key.)
>>> 2. Let the client validate that the server is actually a WebSocket server
>>> (by checking that Sec-WebSocket-Accept is properly computed).
>>>
>>> #1 lets the server be sure it's not responding to some random XHR
>>> request,
>>> #2 lets the browser know that it's safe to connect and that it's
>>> communicating to a WebSocket server and not some non-WS target.
>>>
>>> On Thu, Jun 16, 2011 at 8:54 AM, Joel Martin <hybi@martintribe.org>wrote:
>>>
>>>> I started to try and answer this StackOverflow question about the
>>>> protocol text and realized that I didn't understand it as well as I thought:
>>>>
>>>> http://stackoverflow.com/questions/6372252/why-does-the-server-in-a-websocket-request-have-to-answer-a-challenge
>>>>
>>>> The question is related to this paragraph (which has been in the drafts
>>>> for a while unchanged):
>>>>
>>>>     Finally, the server has to prove to the client that it received the
>>>>     client's WebSocket handshake, so that the server doesn't accept
>>>>     connections that are not WebSocket connections.  This prevents an
>>>>     attacker from tricking a WebSocket server by sending it carefully-
>>>>     crafted packets using |XMLHttpRequest| or a |form| submission.
>>>>
>>>> I can see how the Sec-WebSocket-Accept would prevent a WebSocket client
>>>> from being tricked into connecting to a non-WebSocket server. However, I'm
>>>> having difficulty understanding how the Sec-WebSocket-Accept header would
>>>> prevent a XMLHttpRequest from succeeding to a WebSockets server since it is
>>>> sent from the server. I am aware of the prohibition against "Sec-" headers
>>>> in the client to server direction. Is there a requirement that
>>>> XMLHttpRequest responses with unrecognized "Sec-" headers be rejected by
>>>> user agents (and if so does this only apply in the browser case)?
>>>>
>>>> It's likely I just don't have enough context to understand the
>>>> paragraph, but perhaps it could be clarified a bit.
>>>>
>>>> Regards,
>>>>
>>>> Joel Martin
>>>>
>>>> _______________________________________________
>>>> hybi mailing list
>>>> hybi@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/hybi
>>>>
>>>>
>>>
>>
>

--0016364c7d73234ed304a5dade68
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: base64

SSBtdXN0IGJlIG1pc3Npbmcgc29tZSBrZXkgY29uY2VwdCBoZXJlIGJlY2F1c2UgeW91ciBhbnN3
ZXJzIGhhdmUgYmVlbiB3aGF0IEkgYWxyZWFkeSBrbm93IChhbmQgYWdyZWUgd2l0aCksIGJ1dCB0
aGV5IHN0aWxsIHNlZW0gb3V0IG9mIHN5bmMgd2l0aCB0aGUgdGV4dCBvZiB0aGUgcGFyYWdyYXBo
LjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGRyYWZ0IHBhcmFncmFwaCBpcyB0YWxraW5nIGFib3V0
IHByb3RlY3RpbmcgV2ViU29ja2V0IHNlcnZlcnMgZnJvbSBOT04tV2ViU29ja2V0IGNsaWVudHMg
KGkuZS4gWE1MSHR0cFJlcXVlc3Qgb3IgZm9ybXMpIGFuZCBpbXBseWluZyB0aGF0IHRoZSBTZWMt
V2ViU29ja2V0LUFjY2VwdCBzb21laG93IGhlbHBzIGluIHRoYXQgc2l0dWF0aW9uLiBJIHVuZGVy
c3RhbmQgaG93IGEgWE1MSHR0cFJlcXVlc3QvZm9ybSBzdWJtaXNzaW9uIHdpbGwgbm90IGhhdmUm
bmJzcDs8bWV0YSBodHRwLWVxdWl2PSJjb250ZW50LXR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsg
Y2hhcnNldD11dGYtOCI+U2VjLVdlYlNvY2tldC1LZXkgc28gdGhpcyBwcmV2ZW50cyBhIFdlYlNv
Y2tldHMgc2VydmVyIGZyb20gYW5zd2VyaW5nIGEgbm9uLVdlYlNvY2tldCByZXF1ZXN0LiBCdXQg
d2hhdCBkb2VzIHNlbmRpbmcgYSBwcm9wZXIgU2VjLVdlYlNvY2tldC1BY2NlcHQgaGF2ZSB0byBk
byB3aXRoIHRoaXMgY2FzZT8gVGhlIFNlYy1XZWJTb2NrZXQtQWNjZXB0Jm5ic3A7dmFsdWUgaXMg
c28gdGhhdCBhIFdlYlNvY2tldHMgY2xpZW50IGtub3dzIHRoZSBzZXJ2ZXIgaXMgYSByZWFsIFdl
YlNvY2tldCBzZXJ2ZXIuIFdvbiYjMzk7dCBhIG5vbi1XZWJTb2NrZXRzIHJlcXVlc3QganVzdCBp
Z25vcmUgdGhlJm5ic3A7U2VjLVdlYlNvY2tldC1BY2NlcHQ/PC9kaXY+Cgo8ZGl2Pjxicj48L2Rp
dj48ZGl2PlJlZ2FyZHMsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5Kb2VsIE1hcnRpbjxicj48
YnI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjIwMTEvNi8xNiBJYW4gRmV0dGUgKBskQiUkJSIl
cyVVJSclQyVGJSMbKEIpIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmlmZXR0
ZUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWZldHRlQGdvb2dsZS5jb208L2E+Jmd0Ozwv
c3Bhbj48YnI+CgoKPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2lu
OjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+
SGlzdG9yaWNhbGx5LCBtYW55IHNlcnZlcnMgYXJlIGxhenkuIFRoZXkgd2lsbCBub3QgYm90aGVy
IHZhbGlkYXRpbmcgd2hhdGV2ZXIgdGhlIGNsaWVudCBzZW5kcywgYW5kIHdpbGwganVzdCByZXR1
cm4gc29tZSB2YWx1ZSBhbmQgdGhlbiBnZXQgZXhwbG9pdGVkLiBCeSBmb3JjaW5nIHRoZSBzZXJ2
ZXIgdG8gcHJvdmUgc29tZXRoaW5nIHRvIHRoZSBjbGllbnQsIHdlIGVzc2VudGlhbGx5IGFsc28g
Zm9yY2UgdGhlIHNlcnZlciB0byB2YWxpZGF0ZSBhdCBsZWFzdCBwYXJ0IG9mIHRoZSBjbGllbnQm
IzM5O3MgaGFuZHNoYWtlIChyYXRoZXIgdGhhbiBqdXN0IGhhcmRjb2RpbmcgaW4gc29tZSAxMDEg
VXBncmFkZSBXUyByZXNwb25zZSkuIFNvLCBieSBtYWtpbmcgdGhlIHNlcnZlciBwcm92ZSBzb21l
dGhpbmcgdG8gdGhlIGNsaWVudCwgaXQmIzM5O3MgYSB3YXkgb2YgZm9yY2luZyB0aGUgc2VydmVy
IHRvIGFjdHVhbGx5IHRha2Ugc29tZSBzdGVwcyB0aGF0IGhhdmUgYSBzaWRlIGVmZmVjdCBvZiBw
cm90ZWN0aW5nIGl0IChlLmcuIHRoaXMgL2ZvcmNlcy8gdGhlIHNlcnZlciB0byBwYXJzZSB0aGUg
U2VjLVdlYlNvY2tldC1LZXkgaGVhZGVyLik8ZGl2PgoKCjxkaXY+PC9kaXY+PGRpdj48YnI+Cjxi
cj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxMS82LzE2IEpvZWwgTWFydGluIDxzcGFuIGRp
cj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmh5YmlAbWFydGludHJpYmUub3JnIiB0YXJnZXQ9
Il9ibGFuayI+aHliaUBtYXJ0aW50cmliZS5vcmc8L2E+Jmd0Ozwvc3Bhbj48YnI+PGJsb2NrcXVv
dGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxl
ZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+CgoKCklhbiw8ZGl2Pjxicj48L2Rp
dj48ZGl2Pkkgc2hvdWxkIGhhdmUgYmVlbiBtb3JlIGNsZWFyLiBJIHVuZGVyc3RhbmQgd2h5IHRo
ZSBjbGllbnQgYW5kIHNlcnZlciBoYXZlIHRvIHZhbGlkYXRlIGVhY2ggb3RoZXIsIGl0JiMzOTtz
IHRoZSB0ZXh0IG9mIHRoZSBwYXJhZ3JhcGggaW4gdGhlIGRyYWZ0IHRoYXQgSSYjMzk7bSBjb25m
dXNlZCBhYm91dCBhbmQgSSBwb3N0ZWQgaGVyZSBiZWNhdXNlIEkgdGhpbmsgdGhlIGRyYWZ0IHRl
eHQgYXQgbGVhc3QgbmVlZHMgY2xhcmlmaWNhdGlvbi48YnI+CgoKCgoKPGJyPjwvZGl2PjxkaXY+
PGRpdj48ZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmcXVvdDtGaW5hbGx5LCB0aGUgc2VydmVyIGhh
cyB0byBwcm92ZSB0byB0aGUgY2xpZW50IHRoYXQgaXQgcmVjZWl2ZWQgdGhlPC9kaXY+PC9kaXY+
PGRpdj4mbmJzcDsgJm5ic3A7IGNsaWVudCYjMzk7cyBXZWJTb2NrZXQgaGFuZHNoYWtlLCAuLi4m
cXVvdDs8L2Rpdj4KCjxkaXY+PGJyPjwvZGl2PjxkaXY+LSBHb29kIHNvIGZhcjwvZGl2PjxkaXY+
PGJyPjwvZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyAmcXVvdDsuLi5zbyB0aGF0IHRoZSBzZXJ2ZXIg
ZG9lc24mIzM5O3QgYWNjZXB0Jm5ic3A7Y29ubmVjdGlvbnMgdGhhdCBhcmUgbm90Jm5ic3A7PC9k
aXY+PGRpdj4mbmJzcDsgJm5ic3A7IFdlYlNvY2tldCBjb25uZWN0aW9ucy4mcXVvdDs8L2Rpdj48
ZGl2Pjxicj48L2Rpdj48ZGl2Pi0gV2hhdCBkb2VzIHByb3ZpbmcgdG8gdGhlIGNsaWVudCBoYXZl
IHRvIGRvIHdpdGggdGhlIF9zZXJ2ZXJfIHJlZnVzaW5nIG5vbi13ZWJzb2NrZXRzIGNvbm5lY3Rp
b25zPyBQZXJoYXBzIHRoaXMgaXMgc3VwcG9zZWQgdG8gYmUgJnF1b3Q7Li4uc28gdGhhdCB0aGUg
Y2xpZW50IHdpbGwgbm90IHByb2NlZGUgd2l0aCBjb25uZWN0aW9ucyB0byBub24tV2ViU29ja2V0
IHNlcnZlcnMuJnF1b3Q7PC9kaXY+CgoKCjxkaXY+Cgo8ZGl2Pjxicj48L2Rpdj48ZGl2PiZuYnNw
OyAmbmJzcDsgJnF1b3Q7VGhpcyBwcmV2ZW50cyBhbiZuYnNwO2F0dGFja2VyIGZyb20gdHJpY2tp
bmcgYSBXZWJTb2NrZXQgc2VydmVyIGJ5IHNlbmRpbmc8L2Rpdj48ZGl2PiZuYnNwOyAmbmJzcDsg
aXQgY2FyZWZ1bGx5LWNyYWZ0ZWQgcGFja2V0cyB1c2luZyB8WE1MSHR0cFJlcXVlc3R8IG9yIGEg
fGZvcm18IHN1Ym1pc3Npb24uJnF1b3Q7PC9kaXY+PC9kaXY+PC9kaXY+PGRpdj48YnI+CgoKCjwv
ZGl2PgoKPGRpdj4tIEFnYWluLCB3aGF0IGRvZXMgcHJvdmluZyB0byB0aGUgY2xpZW50IGhhdmUg
dG8gZG8gd2l0aCB0cmlja2luZyB0aGUgV2ViU29ja2V0IHNlcnZlcj8gTWF5YmUgdGhpcyBzaG91
bGQgcmVhbGx5IGJlICZxdW90O1RoaXMgcHJldmVudHMgYW4gYXR0YWNrZXIgZnJvbSB0cmlja2lu
ZyBhIG5vbi1XZWJTb2NrZXQgc2VydmVyIGJ5IHNlbmRpbmcgaXQgY2FyZWZ1bGx5LWNyYWZ0ZWQg
V2ViU29ja2V0IHBhY2tldHMgYmVjYXVzZSBhIG5vbi1XZWJTb2NrZXQgc2VydmVyIHdpbGwgbm90
IHJldHVybiBhIGNvcnJlY3QgU2VjLVdlYlNvY2tldC1BY2NlcHQgdmFsdWUgZHVyaW5nIHRoZSBo
YW5kc2hha2UmcXVvdDsuPC9kaXY+CgoKCgoKPGRpdj48YnI+PC9kaXY+PC9kaXY+PGRpdj5SZWdh
cmRzLDwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Sm9lbCBNYXJ0aW48L2Rpdj48ZGl2Pjxicj48
ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+MjAxMS82LzE2IElhbiBGZXR0ZSAoGyRCJSQlIiVzJVUl
JyVDJUYlIxsoQikgPHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86aWZldHRlQGdv
b2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pZmV0dGVAZ29vZ2xlLmNvbTwvYT4mZ3Q7PC9zcGFu
PjxkaXY+CgoKCjxkaXY+PC9kaXY+PGRpdj48YnI+Cgo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxf
cXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xp
ZDtwYWRkaW5nLWxlZnQ6MWV4Ij5TZWMtV2ViU29ja2V0LUFjY2VwdCB1c2VzIGEgR1VJRCBkZWZp
bmVkIGluIHRoZSBwcm90b2NvbCBhbmQgdGhlIGtleSBmcm9tIHRoZSBoYW5kc2hha2UgdG8gcHJv
dmUgdGhhdCB0aGUgcmVtb3RlIGVuZCBpcyBpbmRlZWQgYSB3ZWJzb2NrZXQgc2VydmVyIGFzIHlv
dSBwb2ludCBvdXQuIFRoZSBvdGhlciBwYXJ0IGlzIHRoYXQgU2VjLVdlYlNvY2tldC1BY2NlcHQg
dGFrZXMgdGhlIGtleSBmcm9tIHRoZSZuYnNwO1NlYy1XZWJTb2NrZXQtS2V5IGhlYWRlciwgd2hp
Y2ggWEhSIGNhbm5vdCBzZW5kIGFuZCB0aHVzIHRoZSBzZXJ2ZXIgZG9lc24mIzM5O3QgaGF2ZSB0
aGUgaW5mb3JtYXRpb24gbmVjZXNzYXJ5IHRvIGdlbmVyYXRlIHRoZSBBY2NlcHQgdmFsdWUgYXMg
dGhlcmUgaXMgbm8ga2V5IGZyb20gdGhlIGNsaWVudC48ZGl2PgoKCgoKCgo8YnI+PC9kaXY+PGRp
dj5UaGUgb3JpZ2luYWwgcXVlc3Rpb24geW91IGxpbmsgdG8gaXMgYmFzaWNhbGx5ICZxdW90O3do
eSBkb2VzIHRoZSBzZXJ2ZXIgaGF2ZSB0byBhbnN3ZXIgYSBjaGFsbGVuZ2UmcXVvdDssIGFuZCBp
dCBicmVha3MgZG93biBpbnRvIHR3byBwYXJ0czo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjEu
IEZvcmNlIHNlcnZlciB0byB2YWxpZGF0ZSB0aGF0IHRoZSBjbGllbnQgaXMgYSBXZWJTb2NrZXQg
Y2xpZW50IChieSBtYWtpbmcgaXQgdXNlIGEgdmFsdWUgZnJvbSBTZWMtV2ViU29ja2V0LUtleSBh
bG9uZyB3aXRoIHRoZSBHVUlELCB3ZSBlbnN1cmUgdGhhdCB0aGUgc2VydmVyIGFjdHVhbGx5IGNo
ZWNrcyBmb3IgdGhlIHByZXNlbmNlIG9mIFNlYy1XZWJTb2NrZXQtS2V5Lik8L2Rpdj4KCgoKCgoK
PGRpdj4yLiBMZXQgdGhlIGNsaWVudCB2YWxpZGF0ZSB0aGF0IHRoZSBzZXJ2ZXIgaXMgYWN0dWFs
bHkgYSBXZWJTb2NrZXQgc2VydmVyIChieSBjaGVja2luZyB0aGF0IFNlYy1XZWJTb2NrZXQtQWNj
ZXB0IGlzIHByb3Blcmx5IGNvbXB1dGVkKS48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PiMxIGxl
dHMgdGhlIHNlcnZlciBiZSBzdXJlIGl0JiMzOTtzIG5vdCByZXNwb25kaW5nIHRvIHNvbWUgcmFu
ZG9tIFhIUiByZXF1ZXN0LDwvZGl2PgoKCgoKCgo8ZGl2PiMyIGxldHMgdGhlIGJyb3dzZXIga25v
dyB0aGF0IGl0JiMzOTtzIHNhZmUgdG8gY29ubmVjdCBhbmQgdGhhdCBpdCYjMzk7cyBjb21tdW5p
Y2F0aW5nIHRvIGEgV2ViU29ja2V0IHNlcnZlciBhbmQgbm90IHNvbWUgbm9uLVdTIHRhcmdldC48
YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2PjxkaXY+PC9kaXY+PGRpdj5PbiBU
aHUsIEp1biAxNiwgMjAxMSBhdCA4OjU0IEFNLCBKb2VsIE1hcnRpbiA8c3BhbiBkaXI9Imx0ciI+
Jmx0OzxhIGhyZWY9Im1haWx0bzpoeWJpQG1hcnRpbnRyaWJlLm9yZyIgdGFyZ2V0PSJfYmxhbmsi
Pmh5YmlAbWFydGludHJpYmUub3JnPC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4KCgoKCgoKPC9k
aXY+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjAg
MCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFkZGluZy1sZWZ0OjFleCI+PGRp
dj48ZGl2PjwvZGl2PjxkaXY+PGRpdj48ZGl2Pkkgc3RhcnRlZCB0byB0cnkgYW5kIGFuc3dlciB0
aGlzIFN0YWNrT3ZlcmZsb3cgcXVlc3Rpb24gYWJvdXQgdGhlIHByb3RvY29sIHRleHQgYW5kIHJl
YWxpemVkIHRoYXQgSSBkaWRuJiMzOTt0IHVuZGVyc3RhbmQgaXQgYXMgd2VsbCBhcyBJIHRob3Vn
aHQ6PC9kaXY+CgoKCgoKCgoKPGEgaHJlZj0iaHR0cDovL3N0YWNrb3ZlcmZsb3cuY29tL3F1ZXN0
aW9ucy82MzcyMjUyL3doeS1kb2VzLXRoZS1zZXJ2ZXItaW4tYS13ZWJzb2NrZXQtcmVxdWVzdC1o
YXZlLXRvLWFuc3dlci1hLWNoYWxsZW5nZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zdGFja292
ZXJmbG93LmNvbS9xdWVzdGlvbnMvNjM3MjI1Mi93aHktZG9lcy10aGUtc2VydmVyLWluLWEtd2Vi
c29ja2V0LXJlcXVlc3QtaGF2ZS10by1hbnN3ZXItYS1jaGFsbGVuZ2U8L2E+PGJyPgoKCgoKCgoK
CjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIHF1ZXN0aW9uIGlzIHJlbGF0ZWQgdG8gdGhp
cyBwYXJhZ3JhcGggKHdoaWNoIGhhcyBiZWVuIGluIHRoZSBkcmFmdHMgZm9yIGEgd2hpbGUgdW5j
aGFuZ2VkKTo8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXY+Jm5ic3A7ICZuYnNwOyBGaW5h
bGx5LCB0aGUgc2VydmVyIGhhcyB0byBwcm92ZSB0byB0aGUgY2xpZW50IHRoYXQgaXQgcmVjZWl2
ZWQgdGhlPC9kaXY+CgoKCgoKCgoKPGRpdj4mbmJzcDsgJm5ic3A7IGNsaWVudCYjMzk7cyBXZWJT
b2NrZXQgaGFuZHNoYWtlLCBzbyB0aGF0IHRoZSBzZXJ2ZXIgZG9lc24mIzM5O3QgYWNjZXB0PC9k
aXY+PGRpdj4mbmJzcDsgJm5ic3A7IGNvbm5lY3Rpb25zIHRoYXQgYXJlIG5vdCBXZWJTb2NrZXQg
Y29ubmVjdGlvbnMuICZuYnNwO1RoaXMgcHJldmVudHMgYW48L2Rpdj48ZGl2PiZuYnNwOyAmbmJz
cDsgYXR0YWNrZXIgZnJvbSB0cmlja2luZyBhIFdlYlNvY2tldCBzZXJ2ZXIgYnkgc2VuZGluZyBp
dCBjYXJlZnVsbHktPC9kaXY+CgoKCgoKCgoKPGRpdj4mbmJzcDsgJm5ic3A7IGNyYWZ0ZWQgcGFj
a2V0cyB1c2luZyB8WE1MSHR0cFJlcXVlc3R8IG9yIGEgfGZvcm18IHN1Ym1pc3Npb24uPC9kaXY+
PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGNhbiBzZWUgaG93IHRoZSBTZWMtV2ViU29ja2V0
LUFjY2VwdCB3b3VsZCBwcmV2ZW50IGEgV2ViU29ja2V0IGNsaWVudCBmcm9tIGJlaW5nIHRyaWNr
ZWQgaW50byBjb25uZWN0aW5nIHRvIGEgbm9uLVdlYlNvY2tldCBzZXJ2ZXIuIEhvd2V2ZXIsIEkm
IzM5O20gaGF2aW5nIGRpZmZpY3VsdHkgdW5kZXJzdGFuZGluZyBob3cmbmJzcDt0aGUmbmJzcDtT
ZWMtV2ViU29ja2V0LUFjY2VwdCBoZWFkZXImbmJzcDt3b3VsZCBwcmV2ZW50IGEgWE1MSHR0cFJl
cXVlc3QgZnJvbSBzdWNjZWVkaW5nIHRvIGEgV2ViU29ja2V0cyBzZXJ2ZXIgc2luY2UgaXQgaXMg
c2VudCBmcm9tIHRoZSBzZXJ2ZXIuIEkgYW0gYXdhcmUgb2YgdGhlIHByb2hpYml0aW9uIGFnYWlu
c3QgJnF1b3Q7U2VjLSZxdW90OyBoZWFkZXJzIGluIHRoZSBjbGllbnQgdG8gc2VydmVyIGRpcmVj
dGlvbi4gSXMgdGhlcmUgYSByZXF1aXJlbWVudCB0aGF0IFhNTEh0dHBSZXF1ZXN0IHJlc3BvbnNl
cyB3aXRoIHVucmVjb2duaXplZCAmcXVvdDtTZWMtJnF1b3Q7IGhlYWRlcnMgYmUgcmVqZWN0ZWQg
YnkgdXNlciBhZ2VudHMgKGFuZCBpZiBzbyBkb2VzIHRoaXMgb25seSBhcHBseSBpbiB0aGUgYnJv
d3NlciBjYXNlKT88L2Rpdj4KCgoKCgoKCgo8ZGl2Pjxicj48L2Rpdj48ZGl2Pkl0JiMzOTtzIGxp
a2VseSBJIGp1c3QgZG9uJiMzOTt0IGhhdmUgZW5vdWdoIGNvbnRleHQgdG8gdW5kZXJzdGFuZCB0
aGUgcGFyYWdyYXBoLCBidXQgcGVyaGFwcyBpdCBjb3VsZCBiZSBjbGFyaWZpZWQgYSBiaXQuPC9k
aXY+Cgo8ZGl2Pjxicj48L2Rpdj48ZGl2PlJlZ2FyZHMsPC9kaXY+PGRpdj48YnI+PC9kaXY+PGZv
bnQgY29sb3I9IiM4ODg4ODgiPjxkaXY+Sm9lbCBNYXJ0aW48L2Rpdj4KPC9mb250Pjxicj48L2Rp
dj48L2Rpdj48ZGl2Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fPGJyPgpoeWJpIG1haWxpbmcgbGlzdDxicj4KPGEgaHJlZj0ibWFpbHRvOmh5YmlAaWV0Zi5v
cmciIHRhcmdldD0iX2JsYW5rIj5oeWJpQGlldGYub3JnPC9hPjxicj4KPGEgaHJlZj0iaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oeWJpIiB0YXJnZXQ9Il9ibGFuayI+aHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oeWJpPC9hPjxicj4KPGJyPjwvZGl2
PjwvYmxvY2txdW90ZT48L2Rpdj48YnI+PC9kaXY+CjwvYmxvY2txdW90ZT48L2Rpdj48L2Rpdj48
L2Rpdj48YnI+PC9kaXY+CjwvYmxvY2txdW90ZT48L2Rpdj48YnI+CjwvZGl2PjwvZGl2PjwvYmxv
Y2txdW90ZT48L2Rpdj48YnI+CjwvZGl2Pgo=
--0016364c7d73234ed304a5dade68--

From buskanaka@gmail.com  Thu Jun 16 14:24:26 2011
Return-Path: <buskanaka@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59BFF11E82F9 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.276
X-Spam-Level: 
X-Spam-Status: No, score=-2.276 tagged_above=-999 required=5 tests=[AWL=0.701,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPgxiQ+4EbOy for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:24:25 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4D17E11E8234 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:24:25 -0700 (PDT)
Received: by eye13 with SMTP id 13so195746eye.31 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:24:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=Bd+3AWk2GbhzyQoRsaLu6IoNEulaxAxyt8NZaFiyQrE=; b=LK4eXgQSB0HsI5LeDPwXVGbx98D9HAizombRO3Gv/q9YjkGs92X7ICj6PpbloEtfRe f3N0QcQNwB+Pw2g1jGc9xMMElhdvuHIiZgk5g00uf0aDKlmOKMoMZwAOimhnvq1ksgoM iLtRhcWTs1/wzy6Rb0taffBdPVTLpS2O8zexc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=jPVs8ZEPC1+3hCH7av1sbYcwvboNLAH1Mm/zBR8FPMHeLhfjGo3xFg2UoAm82Lp/5c m66QG4K+ThsIiXbJwcekMR/RhemY1/aL557ZivgUH16L60Vaamkh9lnpoUqCeO/mzInK djZXLhIfFJstMEAJHEAuBfmcsbMauBMRBSbr4=
Received: by 10.14.29.71 with SMTP id h47mr631941eea.106.1308259464374; Thu, 16 Jun 2011 14:24:24 -0700 (PDT)
MIME-Version: 1.0
Sender: buskanaka@gmail.com
Received: by 10.14.127.1 with HTTP; Thu, 16 Jun 2011 14:24:04 -0700 (PDT)
In-Reply-To: <20110616205147.GA29656@1wt.eu>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com> <20110616205147.GA29656@1wt.eu>
From: Joel Martin <hybi@martintribe.org>
Date: Thu, 16 Jun 2011 16:24:04 -0500
X-Google-Sender-Auth: OAa3rp-y86w1D4q3t6w0UVP-Nv0
Message-ID: <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Content-Type: multipart/alternative; boundary=90e6ba5bbae5a5e9e804a5dae4ed
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:24:26 -0000

--90e6ba5bbae5a5e9e804a5dae4ed
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Jun 16, 2011 at 3:51 PM, Willy Tarreau <w@1wt.eu> wrote:

> On Thu, Jun 16, 2011 at 01:39:35PM -0700, Ian Fette
> (????????????????????????) wrote:
> > Historically, many servers are lazy. They will not bother validating
> > whatever the client sends, and will just return some value and then get
> > exploited. By forcing the server to prove something to the client, we
> > essentially also force the server to validate at least part of the
> client's
> > handshake (rather than just hardcoding in some 101 Upgrade WS response).
> So,
> > by making the server prove something to the client, it's a way of forcing
> > the server to actually take some steps that have a side effect of
> protecting
> > it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key header.)
>
> And also to ensure that the response was not delivered by a lazy cache.


Sure, that makes sense... for the WebSocket client connection case. But what
how does it help in the non-WebSocket client case (which the paragraph is
talking about).

Regards,

Joel Martin

--90e6ba5bbae5a5e9e804a5dae4ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jun 16, 2011 at 3:51 PM, Willy Tarreau <=
span dir=3D"ltr">&lt;<a href=3D"mailto:w@1wt.eu">w@1wt.eu</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">On Thu, Jun 16, 2011 at 01:39:35PM -0700, Ian Fette (????=
????????????????????) wrote:<br>
&gt; Historically, many servers are lazy. They will not bother validating<b=
r>
&gt; whatever the client sends, and will just return some value and then ge=
t<br>
&gt; exploited. By forcing the server to prove something to the client, we<=
br>
&gt; essentially also force the server to validate at least part of the cli=
ent&#39;s<br>
&gt; handshake (rather than just hardcoding in some 101 Upgrade WS response=
). So,<br>
&gt; by making the server prove something to the client, it&#39;s a way of =
forcing<br>
&gt; the server to actually take some steps that have a side effect of prot=
ecting<br>
&gt; it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key heade=
r.)<br>
<br>
</div>And also to ensure that the response was not delivered by a lazy cach=
e.</blockquote><div><br></div><div>Sure, that makes sense... for the WebSoc=
ket client connection case. But what how does it help in the non-WebSocket =
client case (which the paragraph is talking about).</div>

<div><br></div><div>Regards,</div><div><br></div><div>Joel Martin</div><div=
>=A0</div></div>

--90e6ba5bbae5a5e9e804a5dae4ed--

From ibc@aliax.net  Thu Jun 16 14:26:05 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E746F11E8315 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:26:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.659
X-Spam-Level: 
X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.018,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opt40E9Pj03O for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:26:05 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 31F3C11E82F9 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:26:05 -0700 (PDT)
Received: by qyk38 with SMTP id 38so217027qyk.10 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:26:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr1205766qca.154.1308259564405; Thu, 16 Jun 2011 14:26:04 -0700 (PDT)
Received: by 10.229.230.129 with HTTP; Thu, 16 Jun 2011 14:26:04 -0700 (PDT)
In-Reply-To: <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com> <20110616205147.GA29656@1wt.eu> <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com>
Date: Thu, 16 Jun 2011 23:26:04 +0200
Message-ID: <BANLkTi=ukP9oNddYvhJjzhVKNs3FWjXcnw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Joel Martin <hybi@martintribe.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:26:06 -0000

2011/6/16 Joel Martin <hybi@martintribe.org>:
> Sure, that makes sense... for the WebSocket client connection case. But w=
hat
> how does it help in the non-WebSocket client case (which the paragraph is
> talking about).

Since there is already open a new thread for this topic, could you
please discuss there about it instead of using this thread whose topic
is not that? :)

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ifette@google.com  Thu Jun 16 14:27:22 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0236111E8320 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.552
X-Spam-Level: 
X-Spam-Status: No, score=-105.552 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lkKzsRMjS4H for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:27:21 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E6D5E11E831E for <hybi@ietf.org>; Thu, 16 Jun 2011 14:27:20 -0700 (PDT)
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p5GLRJlp009810 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:27:19 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308259640; bh=G6wpFTIBa4xh75WCyt4+/tHS4Wg=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=g90Dgfr/JrM+0cHwUALEqe0JBUArCQKODGtf6zxf0X+nraDmRWQsArg1clySCdosa Nz/dqM5rSDLkNdyahhrWw==
Received: from iym10 (iym10.prod.google.com [10.241.52.10]) by hpaq7.eem.corp.google.com with ESMTP id p5GLRHUG024357 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Thu, 16 Jun 2011 14:27:18 -0700
Received: by iym10 with SMTP id 10so1727045iym.4 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:27:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+RDkjxz9c/vR5ZeJZytkc4mWY8rUYTUdlu1oqme/gOE=; b=Pmx2uHfBrLsDNJ9wBEmLfiVFlHTlileYM8KSzycq1E4gAZi6uRgba49mJTL2sldfIQ ragSHHiiOgQdND809u8w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=NYa9G62IaKpAXQIzYwoM/suuQG8gmz9i1+tMPtfCIWKe8kLUO8PaLxBe+DI9hIxSJs D1xt+cbgO7KoTDrSWPEA==
MIME-Version: 1.0
Received: by 10.231.60.73 with SMTP id o9mr1196066ibh.33.1308259636773; Thu, 16 Jun 2011 14:27:16 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Thu, 16 Jun 2011 14:27:16 -0700 (PDT)
In-Reply-To: <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com>
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com> <20110616205147.GA29656@1wt.eu> <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com>
Date: Thu, 16 Jun 2011 14:27:16 -0700
Message-ID: <BANLkTinW7NCJ3vkNt3Gqdv_vv9xDWWVP8w@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Joel Martin <hybi@martintribe.org>
Content-Type: multipart/alternative; boundary=0015176f0d28ec841504a5daee30
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:27:22 -0000

--0015176f0d28ec841504a5daee30
Content-Type: text/plain; charset=UTF-8

On Thu, Jun 16, 2011 at 2:24 PM, Joel Martin <hybi@martintribe.org> wrote:

> On Thu, Jun 16, 2011 at 3:51 PM, Willy Tarreau <w@1wt.eu> wrote:
>
>> On Thu, Jun 16, 2011 at 01:39:35PM -0700, Ian Fette
>> (????????????????????????) wrote:
>> > Historically, many servers are lazy. They will not bother validating
>> > whatever the client sends, and will just return some value and then get
>> > exploited. By forcing the server to prove something to the client, we
>> > essentially also force the server to validate at least part of the
>> client's
>> > handshake (rather than just hardcoding in some 101 Upgrade WS response).
>> So,
>> > by making the server prove something to the client, it's a way of
>> forcing
>> > the server to actually take some steps that have a side effect of
>> protecting
>> > it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key
>> header.)
>>
>> And also to ensure that the response was not delivered by a lazy cache.
>
>
> Sure, that makes sense... for the WebSocket client connection case. But
> what how does it help in the non-WebSocket client case (which the paragraph
> is talking about).
>

Sorry, I feel like we're talking past each other :) You ask how
Sec-WebSocket-Accept helps in the non-WS client case. Sec-WebSocket-Accept
serves two purposes -- one is to (as we seem to both agree on) let the
client validate that it's a WS server. The second purpose is to force the
server to validate that it's responding to a WebSocket client. (To compute
Accept the server has to read Key, Key can not be sent via XHR, therefore we
are ensuring that the server actually checks for -Key and thus protects
itself from non WS client.)


>
> Regards,
>
> Joel Martin
>
>

--0015176f0d28ec841504a5daee30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Thu, Jun 16, 2011 at 2:24 PM, Joel Martin <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:hybi@martintribe.org">hybi@martintribe=
.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"gmail_quote"><div><div></div><div class=3D"h5">On Thu, Jun 16=
, 2011 at 3:51 PM, Willy Tarreau <span dir=3D"ltr">&lt;<a href=3D"mailto:w@=
1wt.eu" target=3D"_blank">w@1wt.eu</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">


<div>On Thu, Jun 16, 2011 at 01:39:35PM -0700, Ian Fette (?????????????????=
???????) wrote:<br>
&gt; Historically, many servers are lazy. They will not bother validating<b=
r>
&gt; whatever the client sends, and will just return some value and then ge=
t<br>
&gt; exploited. By forcing the server to prove something to the client, we<=
br>
&gt; essentially also force the server to validate at least part of the cli=
ent&#39;s<br>
&gt; handshake (rather than just hardcoding in some 101 Upgrade WS response=
). So,<br>
&gt; by making the server prove something to the client, it&#39;s a way of =
forcing<br>
&gt; the server to actually take some steps that have a side effect of prot=
ecting<br>
&gt; it (e.g. this /forces/ the server to parse the Sec-WebSocket-Key heade=
r.)<br>
<br>
</div>And also to ensure that the response was not delivered by a lazy cach=
e.</blockquote><div><br></div></div></div><div>Sure, that makes sense... fo=
r the WebSocket client connection case. But what how does it help in the no=
n-WebSocket client case (which the paragraph is talking about).</div>
</div></blockquote><div><br></div><div>Sorry, I feel like we&#39;re talking=
 past each other :) You ask how Sec-WebSocket-Accept helps in the non-WS cl=
ient case. Sec-WebSocket-Accept serves two purposes -- one is to (as we see=
m to both agree on) let the client validate that it&#39;s a WS server. The =
second purpose is to force the server to validate that it&#39;s responding =
to a WebSocket client. (To compute Accept the server has to read Key, Key c=
an not be sent via XHR, therefore we are ensuring that the server actually =
checks for -Key and thus protects itself from non WS client.)</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"gmail_quote"=
>

<div><br></div><div>Regards,</div><div><br></div><div>Joel Martin</div><div=
>=C2=A0</div></div>
</blockquote></div><br>

--0015176f0d28ec841504a5daee30--

From dave@cridland.net  Thu Jun 16 14:32:39 2011
Return-Path: <dave@cridland.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA3A11E8328 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:32:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level: 
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[AWL=0.127,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8-N5frHKww0 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:32:39 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id B892311E8326 for <hybi@ietf.org>; Thu, 16 Jun 2011 14:32:38 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 8A0A41168087; Thu, 16 Jun 2011 22:32:33 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v68sHUjZJfNu; Thu, 16 Jun 2011 22:32:31 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 33C1F1168067; Thu, 16 Jun 2011 22:32:31 +0100 (BST)
References: <BANLkTim4pKwx6wYC3WwXFWET+gx0bnjigQ@mail.gmail.com> <4DFA08A5.3010608@weelya.com> <BANLkTi=JGeFmkYcwqQJ_xe=3CGrXwHxHPg@mail.gmail.com> <4DFA1173.9050509@weelya.com> <BANLkTi=LAiw+JvCOc3VPrXnmog7AkSWwCw@mail.gmail.com> <4DFA15E9.50800@weelya.com> <BANLkTikdUneox_4tpMm-EjXPQEEbN7sF4w@mail.gmail.com> <BANLkTik4y_fRd3pEuPdrwESb7ftdbuvk9w@mail.gmail.com> <BANLkTin2000Q8=LUuuUqkfkX_GRrYAnNDw@mail.gmail.com> <BANLkTi=w2SC5MFA21NrYhsV-ZyN5hzrSiQ@mail.gmail.com> <20110616205147.GA29656@1wt.eu> <BANLkTimE5SjYzE4Xd4t3XCvBF9AqSQPfww@mail.gmail.com> <BANLkTinW7NCJ3vkNt3Gqdv_vv9xDWWVP8w@mail.gmail.com>
In-Reply-To: <BANLkTinW7NCJ3vkNt3Gqdv_vv9xDWWVP8w@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <2961.1308259951.205664@puncture>
Date: Thu, 16 Jun 2011 22:32:31 +0100
From: Dave Cridland <dave@cridland.net>
To: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>, Server-Initiated HTTP <hybi@ietf.org>
Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [hybi] Websocket: two protocols into one, and Internet rules broken
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:32:39 -0000

On Thu Jun 16 22:27:16 2011, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£)  
wrote:
> Sorry, I feel like we're talking past each other :) You ask how
> Sec-WebSocket-Accept helps in the non-WS client case.  
> Sec-WebSocket-Accept
> serves two purposes -- one is to (as we seem to both agree on) let  
> the
> client validate that it's a WS server. The second purpose is to  
> force the
> server to validate that it's responding to a WebSocket client. (To  
> compute
> Accept the server has to read Key, Key can not be sent via XHR,  
> therefore we
> are ensuring that the server actually checks for -Key and thus  
> protects
> itself from non WS client.)

If I can rephrase, by requiring the Sec-WS-Key, you prevent a server  
being fooled by an XHR.

By requiring Sec-WS-Accept, you prevent a WS client being fooled by a  
lazy cache, etc.

In combination, though this means a server has to do Sec-WS-Accept  
magic in order to work with WS clients, and is thus forced into  
preventing XHR from working, even though the XHR won't be looking for  
Sec-WS-Accept.

Joel, does this make sense?

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From stpeter@stpeter.im  Thu Jun 16 14:50:59 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB311E80F9 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:50:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.499
X-Spam-Level: 
X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIAJfJmBP4x4 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 14:50:57 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B2B8211E80CF for <hybi@ietf.org>; Thu, 16 Jun 2011 14:50:57 -0700 (PDT)
Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 773F3400A5 for <hybi@ietf.org>; Thu, 16 Jun 2011 15:51:22 -0600 (MDT)
Message-ID: <4DFA7ABF.3030308@stpeter.im>
Date: Thu, 16 Jun 2011 15:50:55 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050401060503090609090305"
Subject: [hybi] -09: handshake
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 21:50:59 -0000

This is a cryptographically signed message in MIME format.

--------------ms050401060503090609090305
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Here are some comments on Section 5, again mostly editorial...

Section 5.1 uses the terms "/resource name/" whereas Section 3 uses the
term "resource-name".

Section 5.1 talks about a "/secure/ flag" but that term is not used in
Section 3. Perhaps modify the latter to say:

   The URI is called "secure" (and it said that "the secure flag is
   set") if the scheme component matches "wss" case-insensitively.

Change "may" to "MAY" in this sentence...

   Clients running in controlled environments, e.g. browsers on mobile
   handsets tied to specific carriers, may offload the management of the
   connection to another agent on the network.

It's not clear to me what we mean by "another agent". Is this, for
example, separate software that runs on the same handset as the
WebSocket, an application provided by the handset manufacturer or
service provider that the handset client interacts with via an API, some
kind of third-party service, or any of the above?

There are a few confusing phrases and long sentences here:

       If the client cannot determine the IP address of the remote host
       (for example because all communication is being done through a
       proxy server that performs DNS queries itself), then the client
       MUST assume for the purposes of this step that each host name
       refers to a distinct remote host, and should instead limit the
       total number of simultaneous connections that are not established
       to a reasonably low number (e.g., in a Web browser, simultaneous
       pending connections to a.example.com and b.example.com would be
       allowed, but if thirty connections are requested, that may not be
       allowed.  The limit should consider the number of tabs the user
       has open.

I suggest:

       If the client cannot determine the IP address of the remote host
       (for example because all communication is being done through a
       proxy server that performs DNS queries itself), then the client
       MUST assume for the purposes of this step that each host name
       refers to a distinct remote host.  Instead, the client SHOULD
       limit the total number of simultaneous pending connections to a
       reasonably low number (e.g., the client might allow simultaneous
       pending connections to a.example.com and b.example.com, but
       might not allow thirty simultaneous pending connections to
       various hosts).  In a Web browser context, the client SHOULD
       consider the number of tabs the user has open in setting a limit
       to the number of simultaneous pending connections.

I have one nit and one concern with this text:

       NOTE: This makes it harder for a script to perform a denial of
       service attack by just opening a large number of WebSocket
       connections to a remote host.  A server can further reduce the
       load on itself when attacked by making use of this by pausing
       before closing the connection, as that will reduce the rate at
       which the client reconnects.

Nit: change "by making use of this by pausing before closing the
connection" to "by pausing before closing the connection".

Concern: this specification says nothing about the reconnection logic.
You might adapt some of the text from Section 3.3 of RFC 6120:

###

3.3.  Reconnection

   It can happen that an XMPP server goes offline unexpectedly while
   servicing TCP connections from connected clients and remote servers.
   Because the number of such connections can be quite large, the
   reconnection algorithm employed by entities that seek to reconnect
   can have a significant impact on software performance and network
   congestion.  If an entity chooses to reconnect, it:

   o  SHOULD set the number of seconds that expire before reconnecting
      to an unpredictable number between 0 and 60 (this helps to ensure
      that not all entities attempt to reconnect at exactly the same
      number of seconds after being disconnected).

   o  SHOULD back off increasingly on the time between subsequent
      reconnection attempts (e.g., in accordance with "truncated binary
      exponential backoff" as described in [ETHERNET]) if the first
      reconnection attempt does not succeed.

###

A question about this text:

       Servers
       can refuse to accept connections from hosts with an excessive
       number of existing connections

Do we mean "hosts" here or instead "clients" or "IP addresses"?

   3.  _Proxy Usage_: If the client is configured to use a proxy when
       using the WebSocket protocol to connect to host /host/ and/or
       port /port/, then the client SHOULD connect to that proxy and ask
       it to open a TCP connection to the host given by /host/ and the
       port given by /port/.

Do we really mean "and/or"? I don't think you can connect to just a port.=
 :)

s/SOCKS/SOCKS5 [RFC1928]/

s/[RFC3548]/[RFC4648]/

Please also specify which flavor of base64 (Section 4 or Section 5 of
RFC 4648) and specify whether padding bits are included at the end of
the block.

It looks as if [I-D.ietf-websec-origin] is a normative reference, since
we're taking the ABNF for the "Sec-WebSocket-Origin" from that spec. I
don't think that should hold up publication of the WebSocket spec, but
if you're worried about that then please provide reviews of the same
origin spec on the WebSec list. :)

https://www.ietf.org/mailman/listinfo/websec

   10.  The request MAY include a header with the name "Sec-WebSocket-
        Protocol".  If present, this value indicates the subprotocol(s)
        the client wishes to speak, ordered by preference.

Please specify that the subprotocols are provided in a comma-separated
list. (And again in Section 5.2.1.)

   Once the client's opening handshake has been sent, the client MUST
   wait for a response from the server before sending any further data.

I don't see anywhere a definition of the server's behavior (e.g., it
MUST close the WebSocket if the client tries to send data before the
server sends a response).

In Section 5.2.2...

   At this point, the server may begin
   sending (and receiving) data.

I think at this point both parties (client and server) are allowed to
send data, right?

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms050401060503090609090305
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NjIxNTA1NVowIwYJKoZIhvcNAQkEMRYEFDY/hGPzdEr1wL2Rihu+/HzG9xzhMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQALnw0rET+DlzkBCaJgQxMlT83E/9UJeyx83uQmRgIqQTfKIbSXPU5DzBdn
AcUe5LiBpN5GJIMeUO4+lY92tQ6jbDdeIxm9xwP8BFWQeimJX6nVob9mqChOBO54m0fSnDXa
K2NPUaXduJV/sanmB5jg+soyQq2Q1INIVlCXFYI5/98e+RVq+OwCJ09zoWrhYcIJ0Ztt3sf+
9iuodDl+vBPUaTiNhEA3GQxJPWxU6rmtpIgOUfY6vr2Fh2iX1vjH8C3Hp3s9MZUGQDJYWVfL
f94SJ00Cu48sCf1nnuADGB2VTHxrUeGsTrmJ8Xlrhov5ZMq4MFZqY2PWtXH7bbFxF5QEAAAA
AAAA
--------------ms050401060503090609090305--

From stpeter@stpeter.im  Thu Jun 16 16:49:22 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D8A11E8119 for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 16:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJq3wdd9nqgZ for <hybi@ietfa.amsl.com>; Thu, 16 Jun 2011 16:49:22 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E580511E80E8 for <hybi@ietf.org>; Thu, 16 Jun 2011 16:49:21 -0700 (PDT)
Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BEE5C400A5 for <hybi@ietf.org>; Thu, 16 Jun 2011 17:49:46 -0600 (MDT)
Message-ID: <4DFA967D.5050308@stpeter.im>
Date: Thu, 16 Jun 2011 17:49:17 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070208030406070509080000"
Subject: [hybi] -09: sending, closing, errors, extensions
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 16 Jun 2011 23:49:22 -0000

This is a cryptographically signed message in MIME format.

--------------ms070208030406070509080000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

More comments...

Section 6.1 states:

   5.  If the data is being sent by the client, the frame(s) MUST be
       masked as defined in Section 4.3.

Section 6.2 states:

   Data frames received by a server from a client MUST be unmasked as
   described in Section 4.3.

The word "unmasked" makes it sound like this contradicts the text in
Section 6.1 -- as in, "must not be masked" as opposed to "the server
shall remove the masking applied by the client".

In Section 7, the text about the close /reason/ makes it sound as if an
application might choose to show UTF-8 encoded data to an end user. That
might lead the reader to think that language tagging might be necessary.
Is it?

In Section 8.2, there is no deterministic server behavior upon receiving
data that is not valid UTF-8. Why? What use cases would motivate
accepting such data instead of just closing the connection?

Section 9.1 says:

   Any extension-token used MUST either be a registered token
   (registration TBD), or have a prefix of "x-" to indicate a private-
   use token.

It's probably not a good idea to have "registration TBD" in a document
that is going for IETF Last Call. :) Presumably a forward pointer to
Section 11.6 would suffice.

Do we really want to encourage use of "x-"? See here for relevant
considerations (I plan to submit an updated version soon):

http://tools.ietf.org/id/draft-saintandre-xdash-considered-harmful-01.txt=


Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms070208030406070509080000
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NjIzNDkxN1owIwYJKoZIhvcNAQkEMRYEFFKxot/Lc9E5iIZXY47r0Ck9rayqMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQA/yhMZruKWXbI/AwL7FUmpQk+P5OnXWkcoxVbmmTIWyia66Fwci5DGsps6
W2hMPwZreO62xR0Dvwn3W8fzF075VSmDxgEHVK92WD/jb7g/dnlcxIk6D3omHUsBkji/W0JP
ykNRfO3eloktsNHjaMIciOH8tsa628K+OLuLOXtwLFXJ4uXMPjGHWMxtsgbd7tCTOSEJfehi
RBH1Lh7nRpU4M8ZirC6PPIx+v+BZobLuGFs65EfZdbV4rv+lqo6i22fIXJT2WB5FQLeJheY7
ciiVqzyVTENqGrUHMK9nR3RFvWKBDPWnNyxj5KLaQApTUQjfmAUMgiAA9/fv5BCr3ULJAAAA
AAAA
--------------ms070208030406070509080000--

From arman@noemax.com  Fri Jun 17 06:33:52 2011
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6DF11E8141 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 06:33:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jGLid9BzFSx for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 06:33:51 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 15BA611E8070 for <hybi@ietf.org>; Fri, 17 Jun 2011 06:33:50 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id ATY60454 for <hybi@ietf.org>; Fri, 17 Jun 2011 16:33:54 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: <hybi@ietf.org>
Date: Fri, 17 Jun 2011 16:32:48 +0300
Message-ID: <000401cc2cf3$106d37d0$3147a770$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acws8raLUlVMDYcyR/2WUi9MUdQf/g==
Content-Language: en-us
Subject: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 13:33:52 -0000

Hello,

Reading carefully the following paragraph I was left wondering what is =
exactly meant by the use of "fresh" and "uniformly at random":

"When preparing a masked frame, the client MUST pick a fresh masking key =
uniformly at random from the set of allowed 32-bit values. The =
unpredictability of the masking key is essential to prevent the author =
of malicious applications from selecting the bytes that appear on the =
wire."

Could we use a term other than "fresh" and also clarify what "uniformly =
at random" means? This is a "MUST" section so it should be absolutely =
clear and proper in its wording. As it has now it seems to possibly be a =
bit vulnerable to being read in "uniformly at random" ways and open to a =
"fresh" interpretation by each implementor :)

With best regards,
Arman

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf =
Of
> Peter Saint-Andre
> Sent: Friday, June 17, 2011 2:49 AM
> To: hybi@ietf.org
> Subject: [hybi] -09: sending, closing, errors, extensions
>=20
> More comments...
>=20
> Section 6.1 states:
>=20
>    5.  If the data is being sent by the client, the frame(s) MUST be
>        masked as defined in Section 4.3.
>=20
> Section 6.2 states:
>=20
>    Data frames received by a server from a client MUST be unmasked as
>    described in Section 4.3.
>=20
> The word "unmasked" makes it sound like this contradicts the text in =
Section
> 6.1 -- as in, "must not be masked" as opposed to "the server shall =
remove
> the masking applied by the client".
>=20
> In Section 7, the text about the close /reason/ makes it sound as if =
an
> application might choose to show UTF-8 encoded data to an end user. =
That
> might lead the reader to think that language tagging might be =
necessary.
> Is it?
>=20
> In Section 8.2, there is no deterministic server behavior upon =
receiving data
> that is not valid UTF-8. Why? What use cases would motivate accepting =
such
> data instead of just closing the connection?
>=20
> Section 9.1 says:
>=20
>    Any extension-token used MUST either be a registered token
>    (registration TBD), or have a prefix of "x-" to indicate a private-
>    use token.
>=20
> It's probably not a good idea to have "registration TBD" in a document =
that is
> going for IETF Last Call. :) Presumably a forward pointer to Section =
11.6 would
> suffice.
>=20
> Do we really want to encourage use of "x-"? See here for relevant
> considerations (I plan to submit an updated version soon):
>=20
> =
http://tools.ietf.org/id/draft-saintandre-xdash-considered-harmful-01.txt=

>=20
> Peter
>=20
> --
> Peter Saint-Andre
> https://stpeter.im/
>=20
>=20



From stpeter@stpeter.im  Fri Jun 17 09:48:51 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12F111E81A7 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 09:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.524
X-Spam-Level: 
X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty1HPI-zmmfP for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 09:48:51 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 0641211E80E2 for <hybi@ietf.org>; Fri, 17 Jun 2011 09:48:51 -0700 (PDT)
Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2431C400A5 for <hybi@ietf.org>; Fri, 17 Jun 2011 10:49:17 -0600 (MDT)
Message-ID: <4DFB8571.4090802@stpeter.im>
Date: Fri, 17 Jun 2011 10:48:49 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040401050303090304030805"
Subject: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 16:48:51 -0000

This is a cryptographically signed message in MIME format.

--------------ms040401050303090304030805
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

First, I am not a member of the security mafia.

However, the security considerations section seems incomplete to me. I
suggest that the author and WG spend some quality time with RFC 3552
(and with other RFCs that have good discussions of security) to make
this section more robust and complete.

Questions to ask and answer include (but are not limited to):

1. What is the threat model against the architecture assumed in this
document? (And to answer that question, it would help to more clearly
explain the architecture.)

2. How will the protocol address confidentiality?

3. How will the protocol address data integrity?

4. How will the protocol address peer entity authentication?

5. How does the protocol ensure strong security (RFC 3365)?

6. If certificates are to be used, how are they handled (RFC 6125 and
RFC 2818)?

7. What are the mandatory-to-implement TLS ciphersuites?

8. What are the security considerations related to technologies that are
reused in WebSocket (e.g., Base 64 and UTF-8)?

9. What information leaks are possible?

10. What denial of service attacks (RFC 4732) are possible and what
measures can be taken to prevent those attacks?

11. What is the relationship, if any, between the security of the
WebSocket protocol and the security of HTTP? In what ways does this
protocol build on HTTP from a security perspective, and in what ways
does it need additional security mechanisms?

I'm sure the reviewer from the IETF Security Directorate will come up
with more questions than that, so we need to be prepared.

A personal note: in revising RFC 3920 to produce RFC 6120, I put a great
deal of thought and time into writing the security considerations
section, which ended up being 20 pages long. That might be longer than
necessary here, but I think 2 pages is a bit shy of what we need.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms040401050303090304030805
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NzE2NDg0OVowIwYJKoZIhvcNAQkEMRYEFB5lnFxTTlIYFbJZSNYBNLnZJ3x+MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCuHv4G/3MpXDNz3a4i1MULs+aD0pgxH6fE+aPB7NF54t9gweC+Ykkg6zhq
NLWmdjqOd3Ci5yZMKML2xHTJ1e1s9mXjq4HyMUkWhGroo23uQv9i9fu2X8LmfZDBFez6Izww
ublHFdeowdTJ4Ri87Rp4yxWL2M5Tmblf4ZECMvyamJFUvJsbSYUBdHRzzkXjBZXPvpEo5CLe
Z/CUOBbU3QYWNBLI0gg62ZkQlllIfHHoYaLIBw+7pATJqoQTPn20BKx+WiuwUusxNn/q0rgH
V4gZ1N7gW3X0S70geLcRH2zQav5wGDzpvSQ2peovE9NkzmjJgjjL0kn4/q231GmO+MsTAAAA
AAAA
--------------ms040401050303090304030805--

From ifette@google.com  Fri Jun 17 09:56:21 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4180711E8213 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 09:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.57
X-Spam-Level: 
X-Spam-Status: No, score=-105.57 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oOrCvd-niZQ for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 09:56:20 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD3F11E820B for <hybi@ietf.org>; Fri, 17 Jun 2011 09:56:11 -0700 (PDT)
Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p5HGtsKc025592 for <hybi@ietf.org>; Fri, 17 Jun 2011 09:56:07 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308329770; bh=Xl8F579BL713uyw5mIGzjG+jds4=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=ZN2dxBvAYyR9nxq/zDEI8t9FEo8h1oNZIyYknUvZtI51sgUYuZOjjt8RqWiWbvf8Q OuwxZMMzPqjXeJ+6rrV3Q==
Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by kpbe11.cbf.corp.google.com with ESMTP id p5HGtJL6030336 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Fri, 17 Jun 2011 09:55:43 -0700
Received: by qyk30 with SMTP id 30so575814qyk.13 for <hybi@ietf.org>; Fri, 17 Jun 2011 09:55:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=GcFwSj37sRs3vBvaqhmVdk/4k9r4WjzPnFGI/O094yw=; b=jq9YyrwLjD2JjJzl+l1dC6++WMg1MoxcEkJB09Xu1NT1V4QDWNNKgaoMbP6CjdTF7C ejvOebidYd9A8T4A8dXQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=UgPye+7FiRFJ02sXBR/zaggw9o9Gu9Rfrw/H7DKFxQyH/yI/MAxy3fB198q2OpXJrP r2DnXu4zhcSrDf+4uacA==
MIME-Version: 1.0
Received: by 10.229.44.198 with SMTP id b6mr1923977qcf.67.1308329742863; Fri, 17 Jun 2011 09:55:42 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Fri, 17 Jun 2011 09:55:42 -0700 (PDT)
In-Reply-To: <4DFB8571.4090802@stpeter.im>
References: <4DFB8571.4090802@stpeter.im>
Date: Fri, 17 Jun 2011 09:55:42 -0700
Message-ID: <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: multipart/alternative; boundary=0016364184ff928cdd04a5eb4170
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 16:56:21 -0000

--0016364184ff928cdd04a5eb4170
Content-Type: text/plain; charset=UTF-8

I would hope that the discussions don't need to be so long. The security
model is based on that of HTTP. Whatever HTTP gives you WS gives you,
whatever HTTPS gives you WSS gives you. WS is at its core a less hacky more
performant version of what people are already doing today in javascript,
it's not some totally new concept.

-Ian

On Fri, Jun 17, 2011 at 9:48 AM, Peter Saint-Andre <stpeter@stpeter.im>wrote:

> First, I am not a member of the security mafia.
>
> However, the security considerations section seems incomplete to me. I
> suggest that the author and WG spend some quality time with RFC 3552
> (and with other RFCs that have good discussions of security) to make
> this section more robust and complete.
>
> Questions to ask and answer include (but are not limited to):
>
> 1. What is the threat model against the architecture assumed in this
> document? (And to answer that question, it would help to more clearly
> explain the architecture.)
>
> 2. How will the protocol address confidentiality?
>
> 3. How will the protocol address data integrity?
>
> 4. How will the protocol address peer entity authentication?
>
> 5. How does the protocol ensure strong security (RFC 3365)?
>
> 6. If certificates are to be used, how are they handled (RFC 6125 and
> RFC 2818)?
>
> 7. What are the mandatory-to-implement TLS ciphersuites?
>
> 8. What are the security considerations related to technologies that are
> reused in WebSocket (e.g., Base 64 and UTF-8)?
>
> 9. What information leaks are possible?
>
> 10. What denial of service attacks (RFC 4732) are possible and what
> measures can be taken to prevent those attacks?
>
> 11. What is the relationship, if any, between the security of the
> WebSocket protocol and the security of HTTP? In what ways does this
> protocol build on HTTP from a security perspective, and in what ways
> does it need additional security mechanisms?
>
> I'm sure the reviewer from the IETF Security Directorate will come up
> with more questions than that, so we need to be prepared.
>
> A personal note: in revising RFC 3920 to produce RFC 6120, I put a great
> deal of thought and time into writing the security considerations
> section, which ended up being 20 pages long. That might be longer than
> necessary here, but I think 2 pages is a bit shy of what we need.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

--0016364184ff928cdd04a5eb4170
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would hope that the discussions don&#39;t need to be so long. The securit=
y model is based on that of HTTP. Whatever HTTP gives you WS gives you, wha=
tever HTTPS gives you WSS gives you. WS is at its core a less hacky more pe=
rformant version of what people are already doing today in javascript, it&#=
39;s not some totally new concept.<div>
<br></div><div>-Ian<br><br><div class=3D"gmail_quote">On Fri, Jun 17, 2011 =
at 9:48 AM, Peter Saint-Andre <span dir=3D"ltr">&lt;<a href=3D"mailto:stpet=
er@stpeter.im">stpeter@stpeter.im</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex;">
First, I am not a member of the security mafia.<br>
<br>
However, the security considerations section seems incomplete to me. I<br>
suggest that the author and WG spend some quality time with RFC 3552<br>
(and with other RFCs that have good discussions of security) to make<br>
this section more robust and complete.<br>
<br>
Questions to ask and answer include (but are not limited to):<br>
<br>
1. What is the threat model against the architecture assumed in this<br>
document? (And to answer that question, it would help to more clearly<br>
explain the architecture.)<br>
<br>
2. How will the protocol address confidentiality?<br>
<br>
3. How will the protocol address data integrity?<br>
<br>
4. How will the protocol address peer entity authentication?<br>
<br>
5. How does the protocol ensure strong security (RFC 3365)?<br>
<br>
6. If certificates are to be used, how are they handled (RFC 6125 and<br>
RFC 2818)?<br>
<br>
7. What are the mandatory-to-implement TLS ciphersuites?<br>
<br>
8. What are the security considerations related to technologies that are<br=
>
reused in WebSocket (e.g., Base 64 and UTF-8)?<br>
<br>
9. What information leaks are possible?<br>
<br>
10. What denial of service attacks (RFC 4732) are possible and what<br>
measures can be taken to prevent those attacks?<br>
<br>
11. What is the relationship, if any, between the security of the<br>
WebSocket protocol and the security of HTTP? In what ways does this<br>
protocol build on HTTP from a security perspective, and in what ways<br>
does it need additional security mechanisms?<br>
<br>
I&#39;m sure the reviewer from the IETF Security Directorate will come up<b=
r>
with more questions than that, so we need to be prepared.<br>
<br>
A personal note: in revising RFC 3920 to produce RFC 6120, I put a great<br=
>
deal of thought and time into writing the security considerations<br>
section, which ended up being 20 pages long. That might be longer than<br>
necessary here, but I think 2 pages is a bit shy of what we need.<br>
<br>
Peter<br>
<font color=3D"#888888"><br>
--<br>
Peter Saint-Andre<br>
<a href=3D"https://stpeter.im/" target=3D"_blank">https://stpeter.im/</a><b=
r>
<br>
<br>
<br>
</font><br>_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
<br></blockquote></div><br></div>

--0016364184ff928cdd04a5eb4170--

From stpeter@stpeter.im  Fri Jun 17 10:25:42 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4FA21F8588 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 10:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.53
X-Spam-Level: 
X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnKoPth9HAli for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 10:25:41 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id DB13B21F84A6 for <hybi@ietf.org>; Fri, 17 Jun 2011 10:25:29 -0700 (PDT)
Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2133B400A5 for <hybi@ietf.org>; Fri, 17 Jun 2011 11:25:56 -0600 (MDT)
Message-ID: <4DFB8E07.60908@stpeter.im>
Date: Fri, 17 Jun 2011 11:25:27 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070902070604040508060708"
Subject: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 17:25:42 -0000

This is a cryptographically signed message in MIME format.

--------------ms070902070604040508060708
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sections 11.1 and 11.2 both say:

      Characters in the host component that are excluded by the syntax
      defined above MUST be converted from Unicode to ASCII by applying
      the IDNA ToASCII algorithm to the Unicode host name, with both the
      AllowUnassigned and UseSTD3ASCIIRules flags set, and using the
      result of this algorithm as the host in the URI.  [RFC3490]

RFC 3490 has been obsoleted by RFC 5890 and RFC 5891. We'll need to
modernize this text.

Sections 11. and 11.2 both say:

   Interoperability considerations.
      None.

However, the template in RFC 4395 says:

   Interoperability considerations.
      If you are aware of any details regarding your scheme that might
      impact interoperability, please identify them here.  For example:
      proprietary or uncommon encoding method; inability to support
      multibyte character sets; incompatibility with types or versions
      of any underlying protocol.

Now, Section 5.1 of the WebSocket spec says:

   2.   The Method of the request MUST be GET and the HTTP version MUST
        be at least 1.1.

So it seems that the interoperability considerations of our URI
registration requests might need to say something about incompability
with HTTP 1.0.

Section 11.6 mentions private use tokens beginning with "x-". Ick. :)

Typo in Section 11.10: "Paragraph 10 of Paragraph 4 of Section 5.1 "

Section 11.12 says that assignment of WebSocket Version Numbers shall be
"RFC Required", but then requests assignment of version numbers 0-8 to
prior submissions of this Internet-Draft. The requested assignments are
at odds with the stated policy.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms070902070604040508060708
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NzE3MjUyN1owIwYJKoZIhvcNAQkEMRYEFKsjEKQF/hVQGrBo9Nlw58YQwCyOMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBqahGhMAoc16Zb9apd3ZYD6KSWY8DEhJ7+JDYSnhwTuLKwzxr09Xdq4Oyt
KLGTWuDtbQAyaShwTX4RwrLRuViUg7hQaswtfZvD1qgkbRaUSNC+ulqbldfaMvfSWaGdh2Ay
k1dZzWN5+xs9w/jbjxek7OwSyCV+7iBgYYMov94VW46LBoJAlFE+oebJ/HK+97/SrKxQLwkc
xeI4jvxa95FsgN/sv1TVxgLS6WbO2lfrP6//C3GYPvl8gtmKjOPVoxtYGUfaXHMXj/Phb3Ui
MgDX89UgETkyn8JAZqYlv+kiYZWKYnL7IaIzSBXS4UXSKcUFFFOzqWKwMjfe2CKSnrVSAAAA
AAAA
--------------ms070902070604040508060708--

From stpeter@stpeter.im  Fri Jun 17 10:35:44 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92ED111E80DF for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 10:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.496
X-Spam-Level: 
X-Spam-Status: No, score=-101.496 tagged_above=-999 required=5 tests=[AWL=-0.974, BAYES_00=-2.599, SUBJ_ALL_CAPS=2.077, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQYAVnugKMDU for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 10:35:43 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9A611E8071 for <hybi@ietf.org>; Fri, 17 Jun 2011 10:35:43 -0700 (PDT)
Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id AF197400A5 for <hybi@ietf.org>; Fri, 17 Jun 2011 11:36:10 -0600 (MDT)
Message-ID: <4DFB906D.2000905@stpeter.im>
Date: Fri, 17 Jun 2011 11:35:41 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080409060907020400000608"
Subject: [hybi] -09: SHA-1
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 17:35:44 -0000

This is a cryptographically signed message in MIME format.

--------------ms080409060907020400000608
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

In finishing my review of -09, I noticed the normative reference to
[FIPS.180-2.2002] for SHA-1. The WG might want to think about whether
the existing attacks against SHA-1 might raise concerns about a lack of
collision resistance for the Sec-WebSocket-Key header (see RFC 4270 and
RFC 6194 for details). It's probably worth saying something about this
in the security considerations.

My review is now complete. Thanks for listening!

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms080409060907020400000608
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYx
NzE3MzU0MVowIwYJKoZIhvcNAQkEMRYEFHyC0k+fHp8jZTp4qq2Ow1giD9OiMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBaPENya20EppIPVu5qWTtlj1TUTglF1IpvXDz4dLurnOqmexnmmcGE80B5
5hpg8E3FGTA5ap+TX7g5IxlYB6Xpdq5t+cKUQ1sdTXZWKNNr2Q7esPynHk3E/aiFko5vpHl6
OR90BBAlxiy8ufAp734UJaJkVLpoYUvQjf819nCWJZ7H9IuxH9TmtMSJ+MOgKQizHgE4lOG5
G1WzTxwMoJZUnSoq/PnHCLyWGRlWz+ENMC9umRBENSMFg3+qV0mEbedu1lhw3MZFmyZpV61v
1OsKfv1h0HkGcuD99rNlr92tJ/qxvZi4t+pGrSU1eXot7Wu+wDBkVbMONAPztpImgo9VAAAA
AAAA
--------------ms080409060907020400000608--

From ifette@google.com  Fri Jun 17 13:07:26 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D444C9E805F for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 13:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.583
X-Spam-Level: 
X-Spam-Status: No, score=-105.583 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJsX+IqL+tsz for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 13:07:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BB5619E8030 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:07:25 -0700 (PDT)
Received: from kpbe16.cbf.corp.google.com (kpbe16.cbf.corp.google.com [172.25.105.80]) by smtp-out.google.com with ESMTP id p5HK7Oox013719 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:07:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308341244; bh=jaaKbvZXSfKBSYZel9xUwm7Fp2M=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=YGDOoA3Ef3FL9CrbyOTTyvJbs8NwllmVA6vQefZ+PDImEaH2GkgTUNanRewBjcut4 yX87JDJjRawX3zqtkqccQ==
Received: from iwl42 (iwl42.prod.google.com [10.241.67.234]) by kpbe16.cbf.corp.google.com with ESMTP id p5HK7NHs008896 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Fri, 17 Jun 2011 13:07:23 -0700
Received: by iwl42 with SMTP id 42so89848iwl.10 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:07:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=mvKgorNS8Lt8H8/ne9nmPAD3N3NhTfBO6/SEKfzR/JU=; b=s5sPX1WaEGIrY3X/ICuXE96ErymiwdZMoKqizEjDGp2s0+kZdlDw7HC38h0zG22XNe Nh0Gzg2NHcMkboFnt5IA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=R44r0xWikvvmkhh96NhmqL7vSD92FN8xeqhIno9P+wlf8yG9k7fOkHkWQuwH8w6eLA /IjEjWbw8ALLxQ4lC8fw==
MIME-Version: 1.0
Received: by 10.42.108.69 with SMTP id g5mr2548072icp.184.1308341242898; Fri, 17 Jun 2011 13:07:22 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Fri, 17 Jun 2011 13:07:22 -0700 (PDT)
In-Reply-To: <4DFB8E07.60908@stpeter.im>
References: <4DFB8E07.60908@stpeter.im>
Date: Fri, 17 Jun 2011 13:07:22 -0700
Message-ID: <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: multipart/alternative; boundary=20cf303bfb520728e704a5edef4b
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 20:07:26 -0000

--20cf303bfb520728e704a5edef4b
Content-Type: text/plain; charset=UTF-8

On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre <stpeter@stpeter.im>wrote:

> Sections 11.1 and 11.2 both say:
>
>      Characters in the host component that are excluded by the syntax
>      defined above MUST be converted from Unicode to ASCII by applying
>      the IDNA ToASCII algorithm to the Unicode host name, with both the
>      AllowUnassigned and UseSTD3ASCIIRules flags set, and using the
>      result of this algorithm as the host in the URI.  [RFC3490]
>
> RFC 3490 has been obsoleted by RFC 5890 and RFC 5891. We'll need to
> modernize this text.
>
> Sections 11. and 11.2 both say:
>
>   Interoperability considerations.
>      None.
>
> However, the template in RFC 4395 says:
>
>   Interoperability considerations.
>      If you are aware of any details regarding your scheme that might
>      impact interoperability, please identify them here.  For example:
>      proprietary or uncommon encoding method; inability to support
>      multibyte character sets; incompatibility with types or versions
>      of any underlying protocol.
>
> Now, Section 5.1 of the WebSocket spec says:
>
>   2.   The Method of the request MUST be GET and the HTTP version MUST
>        be at least 1.1.
>
> So it seems that the interoperability considerations of our URI
> registration requests might need to say something about incompability
> with HTTP 1.0.
>
> Section 11.6 mentions private use tokens beginning with "x-". Ick. :)
>
> Typo in Section 11.10: "Paragraph 10 of Paragraph 4 of Section 5.1 "
>

Sadly this one is not a typo - that's a deeply nested section... :(


>
> Section 11.12 says that assignment of WebSocket Version Numbers shall be
> "RFC Required", but then requests assignment of version numbers 0-8 to
> prior submissions of this Internet-Draft. The requested assignments are
> at odds with the stated policy.
>

RFC Required is different from Standards Action. RFC Publication (either as
an IETF submission or as an RFC editor independent submission) suffices.
Standards Action requires Standards Track RFCs approved by the IESG. My
understanding from this as that an I-D counts as an IETF submission?


>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

--20cf303bfb520728e704a5edef4b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-An=
dre <span dir=3D"ltr">&lt;<a href=3D"mailto:stpeter@stpeter.im">stpeter@stp=
eter.im</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Sections 11.1 and 11.2 both say:<br>
<br>
 =C2=A0 =C2=A0 =C2=A0Characters in the host component that are excluded by =
the syntax<br>
 =C2=A0 =C2=A0 =C2=A0defined above MUST be converted from Unicode to ASCII =
by applying<br>
 =C2=A0 =C2=A0 =C2=A0the IDNA ToASCII algorithm to the Unicode host name, w=
ith both the<br>
 =C2=A0 =C2=A0 =C2=A0AllowUnassigned and UseSTD3ASCIIRules flags set, and u=
sing the<br>
 =C2=A0 =C2=A0 =C2=A0result of this algorithm as the host in the URI. =C2=
=A0[RFC3490]<br>
<br>
RFC 3490 has been obsoleted by RFC 5890 and RFC 5891. We&#39;ll need to<br>
modernize this text.<br>
<br>
Sections 11. and 11.2 both say:<br>
<br>
 =C2=A0 Interoperability considerations.<br>
 =C2=A0 =C2=A0 =C2=A0None.<br>
<br>
However, the template in RFC 4395 says:<br>
<br>
 =C2=A0 Interoperability considerations.<br>
 =C2=A0 =C2=A0 =C2=A0If you are aware of any details regarding your scheme =
that might<br>
 =C2=A0 =C2=A0 =C2=A0impact interoperability, please identify them here. =
=C2=A0For example:<br>
 =C2=A0 =C2=A0 =C2=A0proprietary or uncommon encoding method; inability to =
support<br>
 =C2=A0 =C2=A0 =C2=A0multibyte character sets; incompatibility with types o=
r versions<br>
 =C2=A0 =C2=A0 =C2=A0of any underlying protocol.<br>
<br>
Now, Section 5.1 of the WebSocket spec says:<br>
<br>
 =C2=A0 2. =C2=A0 The Method of the request MUST be GET and the HTTP versio=
n MUST<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0be at least 1.1.<br>
<br>
So it seems that the interoperability considerations of our URI<br>
registration requests might need to say something about incompability<br>
with HTTP 1.0.<br>
<br>
Section 11.6 mentions private use tokens beginning with &quot;x-&quot;. Ick=
. :)<br>
<br>
Typo in Section 11.10: &quot;Paragraph 10 of Paragraph 4 of Section 5.1 &qu=
ot;<br></blockquote><div><br></div><div>Sadly this one is not a typo - that=
&#39;s a deeply nested section... :(</div><div>=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex;">

<br>
Section 11.12 says that assignment of WebSocket Version Numbers shall be<br=
>
&quot;RFC Required&quot;, but then requests assignment of version numbers 0=
-8 to<br>
prior submissions of this Internet-Draft. The requested assignments are<br>
at odds with the stated policy.<br></blockquote><div><br></div><div>RFC Req=
uired is different from Standards Action. RFC Publication (either as an IET=
F submission or as an RFC editor independent submission) suffices. Standard=
s Action requires Standards Track RFCs approved by the IESG. My understandi=
ng from this as that an I-D counts as an IETF submission?</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Peter<br>
<font color=3D"#888888"><br>
--<br>
Peter Saint-Andre<br>
<a href=3D"https://stpeter.im/" target=3D"_blank">https://stpeter.im/</a><b=
r>
<br>
<br>
<br>
</font><br>_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
<br></blockquote></div><br>

--20cf303bfb520728e704a5edef4b--

From dadkins@google.com  Fri Jun 17 13:53:26 2011
Return-Path: <dadkins@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DDB711E80B9 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 13:53:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wo-c6cvJUXr for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 13:53:25 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 986FF11E80B6 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:25 -0700 (PDT)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p5HKrOqt016641 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308344004; bh=FeJ9IFhUVSOQKfgpP4WYgqwZ8PA=; h=MIME-Version:Date:Message-ID:Subject:From:To:Content-Type; b=YaO/qxLxTcT13HV0IT08deU/5QnqHXoyauyhOpsEe85m9Vm7xmgio43vm6nGLj+jM vfVpD8Hd1X4WFYn4ESIcw==
Received: from yie30 (yie30.prod.google.com [10.243.66.30]) by wpaz13.hot.corp.google.com with ESMTP id p5HKrNxC017619 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:24 -0700
Received: by yie30 with SMTP id 30so2048636yie.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 13:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=CWejoFxArESJUgUQ/lUX/BFCpwaK+CzFWAZttEMAQcw=; b=Dp36VuZnWHZs5j8j3kiOmzLVtVQ9IWXpDavdBBDWnJ3+Yf/cXHPwMpDp89PfIYRAQ2 0o6Z1Evj9u4hxm4+vYnA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:content-type; b=UlQGoPfOvBe6KGa84t0FVKs1sTsv9k/rH564HW1bJRaATNdDOcxBStY+nqC+MOniNR L6RNgjcpyt20lvXfQdfw==
MIME-Version: 1.0
Received: by 10.150.240.8 with SMTP id n8mr1951725ybh.415.1308344003582; Fri, 17 Jun 2011 13:53:23 -0700 (PDT)
Received: by 10.150.143.1 with HTTP; Fri, 17 Jun 2011 13:53:23 -0700 (PDT)
Date: Fri, 17 Jun 2011 13:53:23 -0700
Message-ID: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
From: Dan Adkins <dadkins@google.com>
To: hybi@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
X-System-Of-Record: true
Subject: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 20:53:26 -0000

If the client does not specify a subprotocol, is the server allowed to
respond with one?

Section 1.3:
   The |Sec-WebSocket-Protocol| request-header field can be used to
   indicate what subprotocols (application-level protocols layered over
   the WebSocket protocol) are acceptable to the client.  The server
   selects one of the acceptable protocols and echoes that value in its
   handshake to indicate that it has selected that protocol.
...
  Option fields can also be included.  In this version of the protocol,
   the main option field is |Sec-WebSocket-Protocol|, which indicates
   the subprotocol that the server has selected.  Web browsers verify
   that the server included one of the values as was specified in the
   WebSocket client's handshake.  A server that speaks multiple
   subprotocols has to make sure it selects one based on the client's
   handshake and specifies it in its handshake.

>From this, it appears not.  But there's some ambiguity with the
mention of multiple subprotocols.

Section 5.2.2:
       /subprotocol/
          Either a single value or null, representing the subprotocol
          the server is ready to use.  If the server supports multiple
          subprotocols, then the value MUST be derived from the client's
          handshake, specifically by selecting one of the values from
          the "Sec-WebSocket-Protocol" field.  The absence of such a
          field is equivalent to the null value.  The empty string is
          not the same as the null value for these purposes, and is not
          a legal value for this field.  The ABNF for the value of this
          header is (token), where the definitions of constructs and
          rules are as given in [RFC2616].

So, we know what the server MUST do if the server supports multiple
subprotocols.  But what if the client didn't include that field?  Is
the server free to respond with the protocol of its choice?  That
seems strange that the server would be allowed to say to the client,
"we're speaking this protocol, like it or not," as the client has no
opportunity to respond.

Maybe I'm reading too much into this, but it does seem like there's a
bit of a hole in the spec as I can't find the answer to my original
question: if the client doesn't specify a subprotocol, can the server
dictate one?

-Dan

From simonp@opera.com  Fri Jun 17 14:32:59 2011
Return-Path: <simonp@opera.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E800311E80B6 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 14:32:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yywVdQvCjpHZ for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 14:32:59 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id D4FFF11E80A9 for <hybi@ietf.org>; Fri, 17 Jun 2011 14:32:58 -0700 (PDT)
Received: from simon-pieterss-macbook.local (c-5eeaaa13-74736162.cust.telenor.se [94.234.170.19]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p5HLWqJK015743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Jun 2011 21:32:54 GMT
Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "hybi@ietf.org" <hybi@ietf.org>, "Peter Saint-Andre" <stpeter@stpeter.im>
References: <4DFA7ABF.3030308@stpeter.im>
Date: Fri, 17 Jun 2011 23:32:55 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Simon Pieters" <simonp@opera.com>
Message-ID: <op.vw8os5zmidj3kv@simon-pieterss-macbook.local>
In-Reply-To: <4DFA7ABF.3030308@stpeter.im>
User-Agent: Opera Mail/11.11 (MacIntel)
Subject: Re: [hybi] -09: handshake
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 17 Jun 2011 21:33:00 -0000

On Thu, 16 Jun 2011 23:50:55 +0200, Peter Saint-Andre <stpeter@stpeter.im>  
wrote:

> I suggest:
>
>        If the client cannot determine the IP address of the remote host
>        (for example because all communication is being done through a
>        proxy server that performs DNS queries itself), then the client
>        MUST assume for the purposes of this step that each host name
>        refers to a distinct remote host.  Instead, the client SHOULD
>        limit the total number of simultaneous pending connections to a
>        reasonably low number (e.g., the client might allow simultaneous
>        pending connections to a.example.com and b.example.com, but
>        might not allow thirty simultaneous pending connections to
>        various hosts).  In a Web browser context, the client SHOULD
>        consider the number of tabs the user has open in setting a limit
>        to the number of simultaneous pending connections.

I think the wording on tabs should be dropped. Certainly it shouldn't be  
SHOULD. Tabs is a UI thing. "reasonably low number" is good enough.

-- 
Simon Pieters
Opera Software

From ietf@adambarth.com  Fri Jun 17 23:27:58 2011
Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C9E11E811E for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 23:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.295
X-Spam-Level: 
X-Spam-Status: No, score=-3.295 tagged_above=-999 required=5 tests=[AWL=-0.318, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlM0oaNL4p6v for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 23:27:58 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED4C011E807C for <hybi@ietf.org>; Fri, 17 Jun 2011 23:27:57 -0700 (PDT)
Received: by gwb20 with SMTP id 20so123460gwb.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 23:27:57 -0700 (PDT)
Received: by 10.236.154.4 with SMTP id g4mr2054785yhk.127.1308378476946; Fri, 17 Jun 2011 23:27:56 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id i6sm3352068anm.51.2011.06.17.23.27.55 (version=SSLv3 cipher=OTHER); Fri, 17 Jun 2011 23:27:55 -0700 (PDT)
Received: by yxt33 with SMTP id 33so2586275yxt.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 23:27:55 -0700 (PDT)
Received: by 10.90.249.28 with SMTP id w28mr3504183agh.40.1308378475134; Fri, 17 Jun 2011 23:27:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Fri, 17 Jun 2011 23:27:25 -0700 (PDT)
In-Reply-To: <000401cc2cf3$106d37d0$3147a770$@noemax.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 17 Jun 2011 23:27:25 -0700
Message-ID: <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com>
To: Arman Djusupov <arman@noemax.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 18 Jun 2011 06:27:58 -0000

The term "fresh" is a term of art in cryptography.  It means, roughly,
"not used previously."  The term "uniformly at random" means draw from
the uniform random distribution over the set of all 32-bit sequences.
Both qualifications are necessary for this purpose.

Adam


On Fri, Jun 17, 2011 at 6:32 AM, Arman Djusupov <arman@noemax.com> wrote:
> Hello,
>
> Reading carefully the following paragraph I was left wondering what is ex=
actly meant by the use of "fresh" and "uniformly at random":
>
> "When preparing a masked frame, the client MUST pick a fresh masking key =
uniformly at random from the set of allowed 32-bit values. The unpredictabi=
lity of the masking key is essential to prevent the author of malicious app=
lications from selecting the bytes that appear on the wire."
>
> Could we use a term other than "fresh" and also clarify what "uniformly a=
t random" means? This is a "MUST" section so it should be absolutely clear =
and proper in its wording. As it has now it seems to possibly be a bit vuln=
erable to being read in "uniformly at random" ways and open to a "fresh" in=
terpretation by each implementor :)
>
> With best regards,
> Arman
>
>> -----Original Message-----
>> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
>> Peter Saint-Andre
>> Sent: Friday, June 17, 2011 2:49 AM
>> To: hybi@ietf.org
>> Subject: [hybi] -09: sending, closing, errors, extensions
>>
>> More comments...
>>
>> Section 6.1 states:
>>
>> =A0 =A05. =A0If the data is being sent by the client, the frame(s) MUST =
be
>> =A0 =A0 =A0 =A0masked as defined in Section 4.3.
>>
>> Section 6.2 states:
>>
>> =A0 =A0Data frames received by a server from a client MUST be unmasked a=
s
>> =A0 =A0described in Section 4.3.
>>
>> The word "unmasked" makes it sound like this contradicts the text in Sec=
tion
>> 6.1 -- as in, "must not be masked" as opposed to "the server shall remov=
e
>> the masking applied by the client".
>>
>> In Section 7, the text about the close /reason/ makes it sound as if an
>> application might choose to show UTF-8 encoded data to an end user. That
>> might lead the reader to think that language tagging might be necessary.
>> Is it?
>>
>> In Section 8.2, there is no deterministic server behavior upon receiving=
 data
>> that is not valid UTF-8. Why? What use cases would motivate accepting su=
ch
>> data instead of just closing the connection?
>>
>> Section 9.1 says:
>>
>> =A0 =A0Any extension-token used MUST either be a registered token
>> =A0 =A0(registration TBD), or have a prefix of "x-" to indicate a privat=
e-
>> =A0 =A0use token.
>>
>> It's probably not a good idea to have "registration TBD" in a document t=
hat is
>> going for IETF Last Call. :) Presumably a forward pointer to Section 11.=
6 would
>> suffice.
>>
>> Do we really want to encourage use of "x-"? See here for relevant
>> considerations (I plan to submit an updated version soon):
>>
>> http://tools.ietf.org/id/draft-saintandre-xdash-considered-harmful-01.tx=
t
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

From ietf@adambarth.com  Fri Jun 17 23:31:10 2011
Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EFE11E8142 for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 23:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.281
X-Spam-Level: 
X-Spam-Status: No, score=-3.281 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2Nv2mzrHeNl for <hybi@ietfa.amsl.com>; Fri, 17 Jun 2011 23:31:09 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BD0FA11E807C for <hybi@ietf.org>; Fri, 17 Jun 2011 23:31:09 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2208315gxk.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 23:31:01 -0700 (PDT)
Received: by 10.151.93.13 with SMTP id v13mr2231746ybl.266.1308378661568; Fri, 17 Jun 2011 23:31:01 -0700 (PDT)
Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by mx.google.com with ESMTPS id c26sm3360198ana.21.2011.06.17.23.31.00 (version=SSLv3 cipher=OTHER); Fri, 17 Jun 2011 23:31:00 -0700 (PDT)
Received: by yie30 with SMTP id 30so2210802yie.31 for <hybi@ietf.org>; Fri, 17 Jun 2011 23:31:00 -0700 (PDT)
Received: by 10.90.197.15 with SMTP id u15mr3429602agf.148.1308378660076; Fri, 17 Jun 2011 23:31:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Fri, 17 Jun 2011 23:30:30 -0700 (PDT)
In-Reply-To: <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com>
References: <4DFB8571.4090802@stpeter.im> <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Fri, 17 Jun 2011 23:30:30 -0700
Message-ID: <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com>
To: ifette@google.com
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 18 Jun 2011 06:31:10 -0000

There's somewhat more to it than that, right?  For example, HTTP
doesn't use the origin security model, whereas WebSockets does.  Also,
HTTP punts on cross-protocol security issues, whereas WebSockets does
not.  Finally, HTTP has the benefit of being invented prior to the
deployment of much of today's network infrastructure.  That means the
network infrastructure needs to work around HTTP whereas WebSockets
needs to work around the network infrastructure.

Adam


2011/6/17 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>:
> I would hope that the discussions don't need to be so long. The security
> model is based on that of HTTP. Whatever HTTP gives you WS gives you,
> whatever HTTPS gives you WSS gives you. WS is at its core a less hacky more
> performant version of what people are already doing today in javascript,
> it's not some totally new concept.
> -Ian
>
> On Fri, Jun 17, 2011 at 9:48 AM, Peter Saint-Andre <stpeter@stpeter.im>
> wrote:
>>
>> First, I am not a member of the security mafia.
>>
>> However, the security considerations section seems incomplete to me. I
>> suggest that the author and WG spend some quality time with RFC 3552
>> (and with other RFCs that have good discussions of security) to make
>> this section more robust and complete.
>>
>> Questions to ask and answer include (but are not limited to):
>>
>> 1. What is the threat model against the architecture assumed in this
>> document? (And to answer that question, it would help to more clearly
>> explain the architecture.)
>>
>> 2. How will the protocol address confidentiality?
>>
>> 3. How will the protocol address data integrity?
>>
>> 4. How will the protocol address peer entity authentication?
>>
>> 5. How does the protocol ensure strong security (RFC 3365)?
>>
>> 6. If certificates are to be used, how are they handled (RFC 6125 and
>> RFC 2818)?
>>
>> 7. What are the mandatory-to-implement TLS ciphersuites?
>>
>> 8. What are the security considerations related to technologies that are
>> reused in WebSocket (e.g., Base 64 and UTF-8)?
>>
>> 9. What information leaks are possible?
>>
>> 10. What denial of service attacks (RFC 4732) are possible and what
>> measures can be taken to prevent those attacks?
>>
>> 11. What is the relationship, if any, between the security of the
>> WebSocket protocol and the security of HTTP? In what ways does this
>> protocol build on HTTP from a security perspective, and in what ways
>> does it need additional security mechanisms?
>>
>> I'm sure the reviewer from the IETF Security Directorate will come up
>> with more questions than that, so we need to be prepared.
>>
>> A personal note: in revising RFC 3920 to produce RFC 6120, I put a great
>> deal of thought and time into writing the security considerations
>> section, which ended up being 20 pages long. That might be longer than
>> necessary here, but I think 2 pages is a bit shy of what we need.
>>
>> Peter
>>
>> --
>> Peter Saint-Andre
>> https://stpeter.im/
>>
>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

From dilmah@google.com  Sat Jun 18 00:34:42 2011
Return-Path: <dilmah@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC29011E807C for <hybi@ietfa.amsl.com>; Sat, 18 Jun 2011 00:34:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UEl3ZRsWqbY3 for <hybi@ietfa.amsl.com>; Sat, 18 Jun 2011 00:34:42 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4097D11E8079 for <hybi@ietf.org>; Sat, 18 Jun 2011 00:34:41 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p5I7YeUL003893 for <hybi@ietf.org>; Sat, 18 Jun 2011 00:34:41 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308382481; bh=g04fn03ytWC/ZeejJDeKYSZwHdY=; h=MIME-Version:Sender:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=bPC/94o5N7rHfZGecrDM8y70xSxBiENiVar0cIpx5t+5Ue0XxELR8SfQtWPNqdiqE PUoUbd7hL4nClamR4oZFQ==
Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq3.eem.corp.google.com with ESMTP id p5I7YcC7030165 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Sat, 18 Jun 2011 00:34:39 -0700
Received: by qwj9 with SMTP id 9so2098897qwj.35 for <hybi@ietf.org>; Sat, 18 Jun 2011 00:34:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EEHYLibXHhpDGGYz3b8XWN0ihaD5Xhv8+WAFuFT5AoU=; b=tpMpvSTjAf+8O+yGXarQm6ZZZyMI+snaQhKlATVrXPDHmNzoYPaWStC1AZcUS12Tfy ija3cvxIx/E8FapqkDoQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Y8+pNi9388qT7+a2uUCUUXflYhMMaYrCcw+DoKApKZbRgi8X7M5s788Oy5YHUeh3XF CngHWxINTPIafrXzDGVg==
MIME-Version: 1.0
Received: by 10.229.78.96 with SMTP id j32mr2468045qck.121.1308382478365; Sat, 18 Jun 2011 00:34:38 -0700 (PDT)
Sender: dilmah@google.com
Received: by 10.229.18.69 with HTTP; Sat, 18 Jun 2011 00:34:38 -0700 (PDT)
In-Reply-To: <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com>
Date: Sat, 18 Jun 2011 11:34:38 +0400
X-Google-Sender-Auth: 4mYr9zMlwCE_KG_5TAyrxxc9CLY
Message-ID: <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com>
From: Denis Lagno <dilmah@chromium.org>
To: Adam Barth <ietf@adambarth.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 18 Jun 2011 07:34:42 -0000

On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth <ietf@adambarth.com> wrote:
> The term "fresh" is a term of art in cryptography. =A0It means, roughly,
> "not used previously."

So this implies that client must keep track of already used keys? it
imposes limit on length of connection?
True it or false, It should be explicitly clarified in the text.

From julian.reschke@gmx.de  Sat Jun 18 03:13:08 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3F211E8166 for <hybi@ietfa.amsl.com>; Sat, 18 Jun 2011 03:13:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.574
X-Spam-Level: 
X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Hqae9jrkOKf for <hybi@ietfa.amsl.com>; Sat, 18 Jun 2011 03:13:08 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 80C6311E808D for <hybi@ietf.org>; Sat, 18 Jun 2011 03:13:07 -0700 (PDT)
Received: (qmail invoked by alias); 18 Jun 2011 10:12:58 -0000
Received: from p508FC09F.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.192.159] by mail.gmx.net (mp047) with SMTP; 18 Jun 2011 12:12:58 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+/7lEDkV+/2tm7jxJw/TVzah8ROPaNLV/VMy2YsS 2nDjCX86b4GBRl
Message-ID: <4DFC7A25.3060403@gmx.de>
Date: Sat, 18 Jun 2011 12:12:53 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Subject: [hybi] hybi-09 refs
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 18 Jun 2011 10:13:08 -0000

Reference check yields:

Normative References:
ANSI.X3-4.1986: not checked
FIPS.180-2.2002: not checked
RFC1951: [INFORMATIONAL] ok
RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
RFC2616: [DRAFT STANDARD] ok
RFC2817: [PROPOSED STANDARD] ok
RFC2818: [INFORMATIONAL] ok
RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891
RFC3548: [INFORMATIONAL] obsoleted by RFC4648
RFC3629: [STANDARD] (-> STD0063) ok
RFC3864: [BEST CURRENT PRACTICE] (-> BCP0090) ok
RFC3986: [STANDARD] (-> STD0066) ok
RFC3987: [PROPOSED STANDARD] ok
RFC4086: [BEST CURRENT PRACTICE] (-> BCP0106) ok
RFC4648: [PROPOSED STANDARD] ok
RFC5226: [BEST CURRENT PRACTICE] (-> BCP0026) ok
RFC5234: [STANDARD] (-> STD0068) ok
RFC5246: [PROPOSED STANDARD] ok
RFC6066: [PROPOSED STANDARD] ok

Informative References:
draft-ietf-httpstate-cookie-20: Alternate version available: 23, later 
published as: RFC6265
draft-ietf-websec-origin-00: [2010-12-30 ID-Exists] ok
RFC1950: [INFORMATIONAL] ok
RFC5321: [DRAFT STANDARD] ok
RFC6202: [INFORMATIONAL] ok
REC-wsc-ui-20100812: [REC] ok
WSAPI: not checked

Note:

RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891
RFC3548: [INFORMATIONAL] obsoleted by RFC4648
draft-ietf-httpstate-cookie-20: Alternate version available: 23, later 
published as: RFC6265
WSAPI: not checked


The first three should be updated (with IDNA probably being tricky :-().

The last one is

    [WSAPI]    Hickson, I., "The Web Sockets API", August 2010,
               <http://dev.w3.org/html5/websockets/>.

and needs to be updated as well. To enable automated checking with 
<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>, 
I'd make it:

<reference anchor='WD-websockets'
            target='http://www.w3.org/TR/2011/WD-websockets-20110419/'>
   <front>
     <title>The WebSocket API</title>
     <author fullname='Ian Hickson' surname='Hickson' initials='I.'/>
     <date year='2011' month='April' day='19'/>
   </front>
   <seriesInfo name='W3C Working Draft' value='WD-websockets-20110419'/>
   <annotation>
     Latest version available at
     <eref target='http://www.w3.org/TR/websockets/'/>.
   </annotation>
</reference>

Pimping up the other W3C ref wouldn't hurt either:

<reference anchor='REC-wsc-ui'
            target='http://www.w3.org/TR/2010/REC-wsc-ui-20100812/'>
   <front>
     <title>Web Security Context: User Interface Guidelines</title>
     <author fullname='Anil Saldhana' surname='Saldhana' initials='A.'/>
     <author fullname='Thomas Roessler' surname='Roessler' initials='T.'/>
     <date year='2010' month='August' day='12'/>
   </front>
   <seriesInfo name='W3C Recommendation' value='REC-wsc-ui-20100812'/>
   <annotation>
     Latest version available at
     <eref target='http://www.w3.org/TR/wsc-ui/'/>.
   </annotation>
</reference>

Best regards, Julian

From ifette@google.com  Sat Jun 18 15:44:46 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBBC21F856A for <hybi@ietfa.amsl.com>; Sat, 18 Jun 2011 15:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.843
X-Spam-Level: 
X-Spam-Status: No, score=-104.843 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdMFqKuzYqt7 for <hybi@ietfa.amsl.com>; Sat, 18 Jun 2011 15:44:45 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2048D21F856B for <hybi@ietf.org>; Sat, 18 Jun 2011 15:44:44 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p5IMih7N014656 for <hybi@ietf.org>; Sat, 18 Jun 2011 15:44:43 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308437083; bh=099r6PSeVQx1Slx1P1Djs4Ju3jE=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=uwmrT33AIPBJ9HwMVs2eC1Lolx+bj+dgUZ8vpGtfhJduOrZlpmH6x3r5mtlOD7KDe 4Jfz+LKlnwx3EOv6xN9LA==
Received: from iyl8 (iyl8.prod.google.com [10.241.51.200]) by wpaz33.hot.corp.google.com with ESMTP id p5IMifE3030017 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Sat, 18 Jun 2011 15:44:42 -0700
Received: by iyl8 with SMTP id 8so3859598iyl.0 for <hybi@ietf.org>; Sat, 18 Jun 2011 15:44:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aek7qx2AQxLRCZRneFjADCyKmEhbIZqZFBTjmVRignY=; b=ABw3UmEPsSw9fNcPgY4H8IQvjj9ZVL2CcQWZWQFuuuPGA2ldLURH+jwg55m7ZSuu1b ljX1ogRcSjjkAsnltEKw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=K+qQdEGo8v7RZ+++qRnkSCFxPK6qkLjk9RvIYpLeTTtUdfWT4ECGZ0Q4wkHZP0Mcv1 fk3+o9ygNIueEGBvW61Q==
MIME-Version: 1.0
Received: by 10.231.60.73 with SMTP id o9mr3461715ibh.33.1308437081530; Sat, 18 Jun 2011 15:44:41 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Sat, 18 Jun 2011 15:44:41 -0700 (PDT)
In-Reply-To: <4DFC7A25.3060403@gmx.de>
References: <4DFC7A25.3060403@gmx.de>
Date: Sat, 18 Jun 2011 15:44:41 -0700
Message-ID: <BANLkTin93iRWq8eXf4y7XUfs1Vub+6DeKw@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: multipart/alternative; boundary=0015176f0d2874a08a04a6043f01
X-System-Of-Record: true
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] hybi-09 refs
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sat, 18 Jun 2011 22:44:46 -0000

--0015176f0d2874a08a04a6043f01
Content-Type: text/plain; charset=UTF-8

Julian, for the REC-wsc-ui, I used what came from
http://xml.resource.org/public/rfc/bibxml4/ - specifically
http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-wsc-ui-20100812.xml

I'm not entirely familiar with the formats and conventions, but if something
is amiss, perhaps you can get the maintainer of that database to make
necessary changes there so that others benefit as well?


On Sat, Jun 18, 2011 at 3:12 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> Reference check yields:
>
> Normative References:
> ANSI.X3-4.1986: not checked
> FIPS.180-2.2002: not checked
> RFC1951: [INFORMATIONAL] ok
> RFC2119: [BEST CURRENT PRACTICE] (-> BCP0014) ok
> RFC2616: [DRAFT STANDARD] ok
> RFC2817: [PROPOSED STANDARD] ok
> RFC2818: [INFORMATIONAL] ok
> RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891
> RFC3548: [INFORMATIONAL] obsoleted by RFC4648
> RFC3629: [STANDARD] (-> STD0063) ok
> RFC3864: [BEST CURRENT PRACTICE] (-> BCP0090) ok
> RFC3986: [STANDARD] (-> STD0066) ok
> RFC3987: [PROPOSED STANDARD] ok
> RFC4086: [BEST CURRENT PRACTICE] (-> BCP0106) ok
> RFC4648: [PROPOSED STANDARD] ok
> RFC5226: [BEST CURRENT PRACTICE] (-> BCP0026) ok
> RFC5234: [STANDARD] (-> STD0068) ok
> RFC5246: [PROPOSED STANDARD] ok
> RFC6066: [PROPOSED STANDARD] ok
>
> Informative References:
> draft-ietf-httpstate-cookie-**20: Alternate version available: 23, later
> published as: RFC6265
> draft-ietf-websec-origin-00: [2010-12-30 ID-Exists] ok
> RFC1950: [INFORMATIONAL] ok
> RFC5321: [DRAFT STANDARD] ok
> RFC6202: [INFORMATIONAL] ok
> REC-wsc-ui-20100812: [REC] ok
> WSAPI: not checked
>
> Note:
>
> RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891
> RFC3548: [INFORMATIONAL] obsoleted by RFC4648
> draft-ietf-httpstate-cookie-**20: Alternate version available: 23, later
> published as: RFC6265
> WSAPI: not checked
>
>
> The first three should be updated (with IDNA probably being tricky :-().
>
> The last one is
>
>   [WSAPI]    Hickson, I., "The Web Sockets API", August 2010,
>              <http://dev.w3.org/html5/**websockets/<http://dev.w3.org/html5/websockets/>
> >.
>
> and needs to be updated as well. To enable automated checking with <
> http://greenbytes.de/tech/**webdav/rfc2629xslt/**
> rfc2629xslt.html#checking-**references<http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checking-references>>,
> I'd make it:
>
> <reference anchor='WD-websockets'
>           target='http://www.w3.org/TR/**2011/WD-websockets-20110419/<http://www.w3.org/TR/2011/WD-websockets-20110419/>
> '>
>  <front>
>    <title>The WebSocket API</title>
>    <author fullname='Ian Hickson' surname='Hickson' initials='I.'/>
>    <date year='2011' month='April' day='19'/>
>  </front>
>  <seriesInfo name='W3C Working Draft' value='WD-websockets-20110419'**/>
>  <annotation>
>    Latest version available at
>    <eref target='http://www.w3.org/TR/**websockets/'/<http://www.w3.org/TR/websockets/'/>
> >.
>  </annotation>
> </reference>
>
> Pimping up the other W3C ref wouldn't hurt either:
>
> <reference anchor='REC-wsc-ui'
>           target='http://www.w3.org/TR/**2010/REC-wsc-ui-20100812/<http://www.w3.org/TR/2010/REC-wsc-ui-20100812/>
> '>
>  <front>
>    <title>Web Security Context: User Interface Guidelines</title>
>    <author fullname='Anil Saldhana' surname='Saldhana' initials='A.'/>
>    <author fullname='Thomas Roessler' surname='Roessler' initials='T.'/>
>    <date year='2010' month='August' day='12'/>
>  </front>
>  <seriesInfo name='W3C Recommendation' value='REC-wsc-ui-20100812'/>
>  <annotation>
>    Latest version available at
>    <eref target='http://www.w3.org/TR/**wsc-ui/'/<http://www.w3.org/TR/wsc-ui/'/>
> >.
>  </annotation>
> </reference>
>
> Best regards, Julian
> ______________________________**_________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman/listinfo/hybi>
>

--0015176f0d2874a08a04a6043f01
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Julian, for the REC-wsc-ui, I used what came from=C2=A0<a href=3D"http://xm=
l.resource.org/public/rfc/bibxml4/">http://xml.resource.org/public/rfc/bibx=
ml4/</a>=C2=A0- specifically=C2=A0<a href=3D"http://xml.resource.org/public=
/rfc/bibxml4/reference.W3C.REC-wsc-ui-20100812.xml">http://xml.resource.org=
/public/rfc/bibxml4/reference.W3C.REC-wsc-ui-20100812.xml</a><div>
<br></div><div><div><div>I&#39;m not entirely familiar with the formats and=
 conventions, but if something is amiss, perhaps you can get the maintainer=
 of that database to make necessary changes there so that others benefit as=
 well?</div>
<div><br></div><div><br><div class=3D"gmail_quote">On Sat, Jun 18, 2011 at =
3:12 AM, Julian Reschke <span dir=3D"ltr">&lt;<a href=3D"mailto:julian.resc=
hke@gmx.de">julian.reschke@gmx.de</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex;">
Reference check yields:<br>
<br>
Normative References:<br>
ANSI.X3-4.1986: not checked<br>
FIPS.180-2.2002: not checked<br>
RFC1951: [INFORMATIONAL] ok<br>
RFC2119: [BEST CURRENT PRACTICE] (-&gt; BCP0014) ok<br>
RFC2616: [DRAFT STANDARD] ok<br>
RFC2817: [PROPOSED STANDARD] ok<br>
RFC2818: [INFORMATIONAL] ok<br>
RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891<br>
RFC3548: [INFORMATIONAL] obsoleted by RFC4648<br>
RFC3629: [STANDARD] (-&gt; STD0063) ok<br>
RFC3864: [BEST CURRENT PRACTICE] (-&gt; BCP0090) ok<br>
RFC3986: [STANDARD] (-&gt; STD0066) ok<br>
RFC3987: [PROPOSED STANDARD] ok<br>
RFC4086: [BEST CURRENT PRACTICE] (-&gt; BCP0106) ok<br>
RFC4648: [PROPOSED STANDARD] ok<br>
RFC5226: [BEST CURRENT PRACTICE] (-&gt; BCP0026) ok<br>
RFC5234: [STANDARD] (-&gt; STD0068) ok<br>
RFC5246: [PROPOSED STANDARD] ok<br>
RFC6066: [PROPOSED STANDARD] ok<br>
<br>
Informative References:<br>
draft-ietf-httpstate-cookie-<u></u>20: Alternate version available: 23, lat=
er published as: RFC6265<br>
draft-ietf-websec-origin-00: [2010-12-30 ID-Exists] ok<br>
RFC1950: [INFORMATIONAL] ok<br>
RFC5321: [DRAFT STANDARD] ok<br>
RFC6202: [INFORMATIONAL] ok<br>
REC-wsc-ui-20100812: [REC] ok<br>
WSAPI: not checked<br>
<br>
Note:<br>
<br>
RFC3490: [PROPOSED STANDARD] obsoleted by RFC5890 RFC5891<br>
RFC3548: [INFORMATIONAL] obsoleted by RFC4648<br>
draft-ietf-httpstate-cookie-<u></u>20: Alternate version available: 23, lat=
er published as: RFC6265<br>
WSAPI: not checked<br>
<br>
<br>
The first three should be updated (with IDNA probably being tricky :-().<br=
>
<br>
The last one is<br>
<br>
 =C2=A0 [WSAPI] =C2=A0 =C2=A0Hickson, I., &quot;The Web Sockets API&quot;, =
August 2010,<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&lt;<a href=3D"http://dev.=
w3.org/html5/websockets/" target=3D"_blank">http://dev.w3.org/html5/<u></u>=
websockets/</a>&gt;.<br>
<br>
and needs to be updated as well. To enable automated checking with &lt;<a h=
ref=3D"http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629xslt.html#checki=
ng-references" target=3D"_blank">http://greenbytes.de/tech/<u></u>webdav/rf=
c2629xslt/<u></u>rfc2629xslt.html#checking-<u></u>references</a>&gt;, I&#39=
;d make it:<br>

<br>
&lt;reference anchor=3D&#39;WD-websockets&#39;<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 target=3D&#39;<a href=3D"http://www.w3.=
org/TR/2011/WD-websockets-20110419/" target=3D"_blank">http://www.w3.org/TR=
/<u></u>2011/WD-websockets-20110419/</a>&#39;&gt;<br>
 =C2=A0&lt;front&gt;<br>
 =C2=A0 =C2=A0&lt;title&gt;The WebSocket API&lt;/title&gt;<br>
 =C2=A0 =C2=A0&lt;author fullname=3D&#39;Ian Hickson&#39; surname=3D&#39;Hi=
ckson&#39; initials=3D&#39;I.&#39;/&gt;<br>
 =C2=A0 =C2=A0&lt;date year=3D&#39;2011&#39; month=3D&#39;April&#39; day=3D=
&#39;19&#39;/&gt;<br>
 =C2=A0&lt;/front&gt;<br>
 =C2=A0&lt;seriesInfo name=3D&#39;W3C Working Draft&#39; value=3D&#39;WD-we=
bsockets-20110419&#39;<u></u>/&gt;<br>
 =C2=A0&lt;annotation&gt;<br>
 =C2=A0 =C2=A0Latest version available at<br>
 =C2=A0 =C2=A0&lt;eref target=3D&#39;<a href=3D"http://www.w3.org/TR/websoc=
kets/&#39;/" target=3D"_blank">http://www.w3.org/TR/<u></u>websockets/&#39;=
/</a>&gt;.<br>
 =C2=A0&lt;/annotation&gt;<br>
&lt;/reference&gt;<br>
<br>
Pimping up the other W3C ref wouldn&#39;t hurt either:<br>
<br>
&lt;reference anchor=3D&#39;REC-wsc-ui&#39;<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 target=3D&#39;<a href=3D"http://www.w3.=
org/TR/2010/REC-wsc-ui-20100812/" target=3D"_blank">http://www.w3.org/TR/<u=
></u>2010/REC-wsc-ui-20100812/</a>&#39;&gt;<br>
 =C2=A0&lt;front&gt;<br>
 =C2=A0 =C2=A0&lt;title&gt;Web Security Context: User Interface Guidelines&=
lt;/title&gt;<br>
 =C2=A0 =C2=A0&lt;author fullname=3D&#39;Anil Saldhana&#39; surname=3D&#39;=
Saldhana&#39; initials=3D&#39;A.&#39;/&gt;<br>
 =C2=A0 =C2=A0&lt;author fullname=3D&#39;Thomas Roessler&#39; surname=3D&#3=
9;Roessler&#39; initials=3D&#39;T.&#39;/&gt;<br>
 =C2=A0 =C2=A0&lt;date year=3D&#39;2010&#39; month=3D&#39;August&#39; day=
=3D&#39;12&#39;/&gt;<br>
 =C2=A0&lt;/front&gt;<br>
 =C2=A0&lt;seriesInfo name=3D&#39;W3C Recommendation&#39; value=3D&#39;REC-=
wsc-ui-20100812&#39;/&gt;<br>
 =C2=A0&lt;annotation&gt;<br>
 =C2=A0 =C2=A0Latest version available at<br>
 =C2=A0 =C2=A0&lt;eref target=3D&#39;<a href=3D"http://www.w3.org/TR/wsc-ui=
/&#39;/" target=3D"_blank">http://www.w3.org/TR/<u></u>wsc-ui/&#39;/</a>&gt=
;.<br>
 =C2=A0&lt;/annotation&gt;<br>
&lt;/reference&gt;<br>
<br>
Best regards, Julian<br>
______________________________<u></u>_________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/hybi</a><br>
</blockquote></div><br></div></div></div>

--0015176f0d2874a08a04a6043f01--

From julian.reschke@gmx.de  Sun Jun 19 00:40:46 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC60821F85B4 for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 00:40:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.863
X-Spam-Level: 
X-Spam-Status: No, score=-102.863 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zU9JnDSRei2A for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 00:40:45 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4E18A21F8511 for <hybi@ietf.org>; Sun, 19 Jun 2011 00:40:44 -0700 (PDT)
Received: (qmail invoked by alias); 19 Jun 2011 07:40:42 -0000
Received: from p508FABF7.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.171.247] by mail.gmx.net (mp067) with SMTP; 19 Jun 2011 09:40:42 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1/Jm6A4oYPJF0H5eopQN3ZMgN0Tlh4NH49/WTJdOo 2bZcpdKf3UChVj
Message-ID: <4DFDA7F2.7010004@gmx.de>
Date: Sun, 19 Jun 2011 09:40:34 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: ifette@google.com
References: <4DFC7A25.3060403@gmx.de> <BANLkTin93iRWq8eXf4y7XUfs1Vub+6DeKw@mail.gmail.com>
In-Reply-To: <BANLkTin93iRWq8eXf4y7XUfs1Vub+6DeKw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] hybi-09 refs
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 19 Jun 2011 07:40:46 -0000

On 2011-06-19 00:44, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
> Julian, for the REC-wsc-ui, I used what came from
> http://xml.resource.org/public/rfc/bibxml4/ - specifically
> http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-wsc-ui-20100812.xml
>
> I'm not entirely familiar with the formats and conventions, but if
> something is amiss, perhaps you can get the maintainer of that database
> to make necessary changes there so that others benefit as well?

I fear the scripts that generate these are currently unmaintained.

(I'm generating the reference entries directly from the W3C TR database, 
and discussed the precise format last year with members of the W3C's 
publication team).

 > ...


Best regards, Julian

From alexey.melnikov@isode.com  Sun Jun 19 06:24:31 2011
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABEB111E80B5 for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 06:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.712
X-Spam-Level: 
X-Spam-Status: No, score=-101.712 tagged_above=-999 required=5 tests=[AWL=-0.509, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3B7WXSXoJ-Ru for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 06:24:31 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 74DAB11E8072 for <hybi@ietf.org>; Sun, 19 Jun 2011 06:24:30 -0700 (PDT)
Received: from [188.29.231.218] (188.29.231.218.threembb.co.uk [188.29.231.218])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <Tf34igA-uRny@rufus.isode.com>; Sun, 19 Jun 2011 14:24:27 +0100
Message-ID: <4DFDF876.2030907@isode.com>
Date: Sun, 19 Jun 2011 14:24:06 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Julian Reschke <julian.reschke@gmx.de>
References: <4DFC7A25.3060403@gmx.de> <BANLkTin93iRWq8eXf4y7XUfs1Vub+6DeKw@mail.gmail.com> <4DFDA7F2.7010004@gmx.de>
In-Reply-To: <4DFDA7F2.7010004@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] hybi-09 refs
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 19 Jun 2011 13:24:31 -0000

Julian Reschke wrote:

> On 2011-06-19 00:44, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=
=A7=E3=83=83=E3=83=86=E3=82=A3) wrote:
>
>> Julian, for the REC-wsc-ui, I used what came from
>> http://xml.resource.org/public/rfc/bibxml4/ - specifically
>> http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-wsc-ui-20100=
812.xml=20
>>
>>
>> I'm not entirely familiar with the formats and conventions, but if
>> something is amiss, perhaps you can get the maintainer of that database
>> to make necessary changes there so that others benefit as well?
>
> I fear the scripts that generate these are currently unmaintained.
>
> (I'm generating the reference entries directly from the W3C TR=20
> database, and discussed the precise format last year with members of=20
> the W3C's publication team).

I wouldn't worry too much about this, RFC Editor is quite good about=20
fixing/updating references.


From ibc@aliax.net  Sun Jun 19 08:14:27 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A9111E80B0 for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 08:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level: 
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fV7SCDxQ6y6h for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 08:14:26 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 82B5011E8070 for <hybi@ietf.org>; Sun, 19 Jun 2011 08:14:26 -0700 (PDT)
Received: by qyk9 with SMTP id 9so1266735qyk.10 for <hybi@ietf.org>; Sun, 19 Jun 2011 08:14:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr3218902qce.192.1308496465808; Sun, 19 Jun 2011 08:14:25 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Sun, 19 Jun 2011 08:14:25 -0700 (PDT)
In-Reply-To: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
Date: Sun, 19 Jun 2011 17:14:25 +0200
Message-ID: <BANLkTi=ajW-bkr7OuXWhU12qSHs7m4hFzQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Dan Adkins <dadkins@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Sun, 19 Jun 2011 15:14:27 -0000

2011/6/17 Dan Adkins <dadkins@google.com>:
> So, we know what the server MUST do if the server supports multiple
> subprotocols. =C2=A0But what if the client didn't include that field? =C2=
=A0Is
> the server free to respond with the protocol of its choice? =C2=A0That
> seems strange that the server would be allowed to say to the client,
> "we're speaking this protocol, like it or not," as the client has no
> opportunity to respond.
>
> Maybe I'm reading too much into this, but it does seem like there's a
> bit of a hole in the spec as I can't find the answer to my original
> question: if the client doesn't specify a subprotocol, can the server
> dictate one?

I agree. And I expect that subprotocol field will have not to much
real usage. Instead, a webdeveloper will make JavaScript to open a WS
connection with his server and start speaking the subprotocol even
without negociating it (as both the client side and server side will
be coded by same provider). It will be much like the web world, in
which each page is an independent world.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ietf@adambarth.com  Sun Jun 19 19:57:44 2011
Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F49911E80AA for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 19:57:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.269
X-Spam-Level: 
X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVYGs6BxmyKM for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 19:57:44 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA5FB11E809D for <hybi@ietf.org>; Sun, 19 Jun 2011 19:57:43 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2901994gxk.31 for <hybi@ietf.org>; Sun, 19 Jun 2011 19:57:43 -0700 (PDT)
Received: by 10.236.28.2 with SMTP id f2mr4856409yha.387.1308538663197; Sun, 19 Jun 2011 19:57:43 -0700 (PDT)
Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by mx.google.com with ESMTPS id g5sm3267836yhm.40.2011.06.19.19.57.41 (version=SSLv3 cipher=OTHER); Sun, 19 Jun 2011 19:57:41 -0700 (PDT)
Received: by yxt33 with SMTP id 33so3381833yxt.31 for <hybi@ietf.org>; Sun, 19 Jun 2011 19:57:41 -0700 (PDT)
Received: by 10.90.42.15 with SMTP id p15mr5066265agp.13.1308538661145; Sun, 19 Jun 2011 19:57:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Sun, 19 Jun 2011 19:57:11 -0700 (PDT)
In-Reply-To: <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com> <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 19 Jun 2011 19:57:11 -0700
Message-ID: <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com>
To: Denis Lagno <dilmah@chromium.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 02:57:44 -0000

On Sat, Jun 18, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org> wrote:
> On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth <ietf@adambarth.com> wrote:
>> The term "fresh" is a term of art in cryptography. =A0It means, roughly,
>> "not used previously."
>
> So this implies that client must keep track of already used keys? it
> imposes limit on length of connection?
> True it or false, It should be explicitly clarified in the text.

The normal practice in cryptography is to just use large enough values
such that the probably of collision is sufficiently small as to be
acceptable.  For example, if you use a 20 byte nonce, the probably of
collision is zero for all practical purposes.

This stuff is all extremely normal.

Adam

From gregw@intalio.com  Sun Jun 19 23:33:14 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9AF321F849A for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 23:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.755
X-Spam-Level: 
X-Spam-Status: No, score=-2.755 tagged_above=-999 required=5 tests=[AWL=0.222,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kXiWXv40uFzO for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 23:33:14 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2201221F856E for <hybi@ietf.org>; Sun, 19 Jun 2011 23:33:13 -0700 (PDT)
Received: by vxi40 with SMTP id 40so551641vxi.31 for <hybi@ietf.org>; Sun, 19 Jun 2011 23:33:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.76.4 with SMTP id g4mr3182466vdw.278.1308551592833; Sun, 19 Jun 2011 23:33:12 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Sun, 19 Jun 2011 23:33:12 -0700 (PDT)
Date: Mon, 20 Jun 2011 16:33:12 +1000
Message-ID: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 06:33:15 -0000

As part of my continuing campaign against including deflate-stream in
the specification as a standard extension, I did a quick test of how
well it works when applied to masked frames.

I took a days worth of traffic from an IRC channel and wrapped it up
as JSON messages sent as websocket frames.
There were 487 message that looked like:

     {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
had issues pulling from github a couple of times  last week"}

As an unmasked WS stream, it was 50675 bytes, and as a masked stream
is was 52623 bytes.
I then compressed both these streams with gzip and got 13306 bytes for
unmasked and 51704 bytes for the masked!!!!

So for this very typical example, masking was sufficiently random to
completely negate the benefits of compression.

So the deflate-stream "extension" is:

 + next to useless for inbound traffic
 + breaks all the rules of what an extension can do
 + is potentially vulnerable to injection as attackers can send
repeated patterns that may subvert masking
 + can be replaced by the in-frame compression extension already proposed.
 + was inserted in the draft with little or no discussion and without
clear consensus.

Can I call for a straw poll of who wants to keep this extension in the spec?



regards

From gregw@intalio.com  Sun Jun 19 23:42:47 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F9C21F8574 for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 23:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.792
X-Spam-Level: 
X-Spam-Status: No, score=-2.792 tagged_above=-999 required=5 tests=[AWL=0.185,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EExJy2GwfoeE for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 23:42:46 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 75A1821F8575 for <hybi@ietf.org>; Sun, 19 Jun 2011 23:42:46 -0700 (PDT)
Received: by vxi40 with SMTP id 40so555963vxi.31 for <hybi@ietf.org>; Sun, 19 Jun 2011 23:42:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.180.198 with SMTP id dq6mr1857943vdc.158.1308552165848; Sun, 19 Jun 2011 23:42:45 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Sun, 19 Jun 2011 23:42:45 -0700 (PDT)
In-Reply-To: <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com>
References: <4DFB8571.4090802@stpeter.im> <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com> <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com>
Date: Mon, 20 Jun 2011 16:42:45 +1000
Message-ID: <BANLkTinE7VZTZDyyMfw3CZSMevHw-GqTWw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Adam Barth <ietf@adambarth.com>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 06:42:47 -0000

Also HTTP has BASIC and DIGEST authentication, while WS does not
(although it could very easily support these).

cheers


2011/6/18 Adam Barth <ietf@adambarth.com>:
> There's somewhat more to it than that, right?  For example, HTTP
> doesn't use the origin security model, whereas WebSockets does.  Also,
> HTTP punts on cross-protocol security issues, whereas WebSockets does
> not.  Finally, HTTP has the benefit of being invented prior to the
> deployment of much of today's network infrastructure.  That means the
> network infrastructure needs to work around HTTP whereas WebSockets
> needs to work around the network infrastructure.
>
> Adam
>
>
> 2011/6/17 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>:
>> I would hope that the discussions don't need to be so long. The security
>> model is based on that of HTTP. Whatever HTTP gives you WS gives you,
>> whatever HTTPS gives you WSS gives you. WS is at its core a less hacky more
>> performant version of what people are already doing today in javascript,
>> it's not some totally new concept.
>> -Ian
>>
>> On Fri, Jun 17, 2011 at 9:48 AM, Peter Saint-Andre <stpeter@stpeter.im>
>> wrote:
>>>
>>> First, I am not a member of the security mafia.
>>>
>>> However, the security considerations section seems incomplete to me. I
>>> suggest that the author and WG spend some quality time with RFC 3552
>>> (and with other RFCs that have good discussions of security) to make
>>> this section more robust and complete.
>>>
>>> Questions to ask and answer include (but are not limited to):
>>>
>>> 1. What is the threat model against the architecture assumed in this
>>> document? (And to answer that question, it would help to more clearly
>>> explain the architecture.)
>>>
>>> 2. How will the protocol address confidentiality?
>>>
>>> 3. How will the protocol address data integrity?
>>>
>>> 4. How will the protocol address peer entity authentication?
>>>
>>> 5. How does the protocol ensure strong security (RFC 3365)?
>>>
>>> 6. If certificates are to be used, how are they handled (RFC 6125 and
>>> RFC 2818)?
>>>
>>> 7. What are the mandatory-to-implement TLS ciphersuites?
>>>
>>> 8. What are the security considerations related to technologies that are
>>> reused in WebSocket (e.g., Base 64 and UTF-8)?
>>>
>>> 9. What information leaks are possible?
>>>
>>> 10. What denial of service attacks (RFC 4732) are possible and what
>>> measures can be taken to prevent those attacks?
>>>
>>> 11. What is the relationship, if any, between the security of the
>>> WebSocket protocol and the security of HTTP? In what ways does this
>>> protocol build on HTTP from a security perspective, and in what ways
>>> does it need additional security mechanisms?
>>>
>>> I'm sure the reviewer from the IETF Security Directorate will come up
>>> with more questions than that, so we need to be prepared.
>>>
>>> A personal note: in revising RFC 3920 to produce RFC 6120, I put a great
>>> deal of thought and time into writing the security considerations
>>> section, which ended up being 20 pages long. That might be longer than
>>> necessary here, but I think 2 pages is a bit shy of what we need.
>>>
>>> Peter
>>>
>>> --
>>> Peter Saint-Andre
>>> https://stpeter.im/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> hybi mailing list
>>> hybi@ietf.org
>>> https://www.ietf.org/mailman/listinfo/hybi
>>>
>>
>>
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>>
>>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

From gregw@intalio.com  Sun Jun 19 23:57:15 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E8D9E800D for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 23:57:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.819
X-Spam-Level: 
X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=0.158,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4s+oRua7Av7W for <hybi@ietfa.amsl.com>; Sun, 19 Jun 2011 23:57:15 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 35F579E800C for <hybi@ietf.org>; Sun, 19 Jun 2011 23:57:15 -0700 (PDT)
Received: by vxi40 with SMTP id 40so562768vxi.31 for <hybi@ietf.org>; Sun, 19 Jun 2011 23:57:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.130 with SMTP id l2mr3131710vdv.78.1308553034618; Sun, 19 Jun 2011 23:57:14 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Sun, 19 Jun 2011 23:57:14 -0700 (PDT)
In-Reply-To: <4DF91FCA.8060403@stpeter.im>
References: <4DF91FCA.8060403@stpeter.im>
Date: Mon, 20 Jun 2011 16:57:14 +1000
Message-ID: <BANLkTinw1d61_wqBXg4mPHti-BhohW8SWg@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 06:57:15 -0000

On 16 June 2011 07:10, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> Section 1.1 has always struck me as strange. It sounds as if we're
> developing an IM protocol here! I suggest:
>
> =A0 Historically, creating Web applications that need bidirectional
> =A0 communication between a client and a server (e.g., instant messaging
> =A0 and gaming applications) has required an abuse of HTTP to poll the
> =A0 server for updates while sending upstream notifications as distinct
> =A0 HTTP calls. [RFC6202]


I don't think the usage of "abuse" can be justified.   There is
nothing abusive about long polling and it is entirely legal HTTP.
Besides that is too much of a subjective reason.

How about:

  Historically, creating Web applications that need bidirectional
  communication between a client and a server (e.g., instant messaging
  and gaming applications), has required the use of HTTP to poll or long
  poll the server for updates.  Such usage of HTTP is less efficient
and responsive
  that what is possible with a TCP/IP connection.



regards

From diogo.pereira@ist.utl.pt  Mon Jun 20 00:20:30 2011
Return-Path: <diogo.pereira@ist.utl.pt>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8541F11E80E0 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level: 
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xk8AmaBU-wXa for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:20:30 -0700 (PDT)
Received: from smtp1.ist.utl.pt (smtp1.ist.utl.pt [IPv6:2001:690:2100:1::15]) by ietfa.amsl.com (Postfix) with ESMTP id 7861511E80D6 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:20:28 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 8468B7000449 for <hybi@ietf.org>; Mon, 20 Jun 2011 08:20:24 +0100 (WEST)
X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt
Received: from smtp1.ist.utl.pt ([127.0.0.1]) by localhost (smtp1.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 2MXwY6j2LyXj for <hybi@ietf.org>; Mon, 20 Jun 2011 08:20:24 +0100 (WEST)
Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 6FCC67000448 for <hybi@ietf.org>; Mon, 20 Jun 2011 08:20:22 +0100 (WEST)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 7DD2A20010DC for <hybi@ietf.org>; Mon, 20 Jun 2011 08:20:22 +0100 (WEST)
Received: by iwn39 with SMTP id 39so637810iwn.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:20:21 -0700 (PDT)
Received: by 10.231.68.202 with SMTP id w10mr4928013ibi.63.1308554421093; Mon, 20 Jun 2011 00:20:21 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.36.136 with HTTP; Mon, 20 Jun 2011 00:19:51 -0700 (PDT)
In-Reply-To: <BANLkTinE7VZTZDyyMfw3CZSMevHw-GqTWw@mail.gmail.com>
References: <4DFB8571.4090802@stpeter.im> <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com> <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com> <BANLkTinE7VZTZDyyMfw3CZSMevHw-GqTWw@mail.gmail.com>
From: Diogo Pereira <diogo.pereira@ist.utl.pt>
Date: Mon, 20 Jun 2011 08:19:51 +0100
Message-ID: <BANLkTimq2CiSjiS=+yiLmhg9yxACgAZViA@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset=UTF-8
Cc: hybi@ietf.org
Subject: Re: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 07:20:30 -0000

2011/6/20 Greg Wilkins <gregw@intalio.com>:
> Also HTTP has BASIC and DIGEST authentication, while WS does not
> (although it could very easily support these).

I think this is implicitly allowed:

 "1.  If the status code received from the server is not 101, the
       client handles the response per HTTP procedures." (p. 30)

So in response to a 401 the client could resend the handshake request
with an Authorization header.

-- 
Diogo

From dilmah@google.com  Mon Jun 20 00:26:55 2011
Return-Path: <dilmah@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079B221F8497 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqmyXQwvPURb for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:26:54 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B9FD121F8496 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:26:53 -0700 (PDT)
Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p5K7QpvW024879 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:26:52 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308554812; bh=gMnWWa1zM24xe0xmRWiOVvhNq/I=; h=MIME-Version:Sender:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=h4bi48qIxJhGqObDMO+BKoho0HcFqPQVERKVvNHezdn3RuQOMpvQCJkizfIUpJhxF 91iB3EmqzUDT6dWG2luuA==
Received: from qwb8 (qwb8.prod.google.com [10.241.193.72]) by kpbe18.cbf.corp.google.com with ESMTP id p5K7QoVe016605 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 20 Jun 2011 00:26:50 -0700
Received: by qwb8 with SMTP id 8so489473qwb.11 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=F7CEKzXUtA8D7YEbrkUBMGhCSJwr3IUDFKkm9siahwc=; b=pDlOkLFXf+q+HJJ5SODiY7G+tzcULKm1yL4SADcdI2xuvP6Vo1h567qyevQsjKcQJn risAkseOPutE/s+LDhYw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OY6F06nLBUQZNb0SvcmY26KQm8TESA+5K/KobMyAtiVtz5CiwLZWyVX+Uo1Xx/paGf 6PFeM3cgjS60IzXVlsvQ==
MIME-Version: 1.0
Received: by 10.229.53.143 with SMTP id m15mr3728451qcg.83.1308554809844; Mon, 20 Jun 2011 00:26:49 -0700 (PDT)
Sender: dilmah@google.com
Received: by 10.229.18.69 with HTTP; Mon, 20 Jun 2011 00:26:49 -0700 (PDT)
In-Reply-To: <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com> <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com> <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com>
Date: Mon, 20 Jun 2011 11:26:49 +0400
X-Google-Sender-Auth: tIBwCdbK-pCzJ7LX0hpPx-vbpto
Message-ID: <BANLkTimf=ateLuDO7R7yhOE4AE2m770PAg@mail.gmail.com>
From: Denis Lagno <dilmah@chromium.org>
To: Adam Barth <ietf@adambarth.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 07:26:55 -0000

maybe I miss something but in the text "fresh" is applied to 32-bit values.=
.

On Mon, Jun 20, 2011 at 6:57 AM, Adam Barth <ietf@adambarth.com> wrote:
> On Sat, Jun 18, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org> wrote=
:
>> On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth <ietf@adambarth.com> wrote:
>>> The term "fresh" is a term of art in cryptography. =A0It means, roughly=
,
>>> "not used previously."
>>
>> So this implies that client must keep track of already used keys? it
>> imposes limit on length of connection?
>> True it or false, It should be explicitly clarified in the text.
>
> The normal practice in cryptography is to just use large enough values
> such that the probably of collision is sufficiently small as to be
> acceptable. =A0For example, if you use a 20 byte nonce, the probably of
> collision is zero for all practical purposes.
>
> This stuff is all extremely normal.
>
> Adam
>

From ietf@adambarth.com  Mon Jun 20 00:32:13 2011
Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F46611E80BB for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.257
X-Spam-Level: 
X-Spam-Status: No, score=-3.257 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7F-AAwZ5WxA for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:32:12 -0700 (PDT)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9511E80A9 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:32:12 -0700 (PDT)
Received: by gya6 with SMTP id 6so907022gya.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:32:12 -0700 (PDT)
Received: by 10.151.76.13 with SMTP id d13mr5112449ybl.444.1308555131975; Mon, 20 Jun 2011 00:32:11 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by mx.google.com with ESMTPS id c26sm5438984ana.21.2011.06.20.00.32.10 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 00:32:10 -0700 (PDT)
Received: by gxk19 with SMTP id 19so2987633gxk.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:32:10 -0700 (PDT)
Received: by 10.90.247.18 with SMTP id u18mr5293699agh.121.1308555130274; Mon, 20 Jun 2011 00:32:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Mon, 20 Jun 2011 00:31:40 -0700 (PDT)
In-Reply-To: <BANLkTimf=ateLuDO7R7yhOE4AE2m770PAg@mail.gmail.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com> <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com> <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com> <BANLkTimf=ateLuDO7R7yhOE4AE2m770PAg@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 20 Jun 2011 00:31:40 -0700
Message-ID: <BANLkTi=q3w6Z0odEWdzTkeNQ-7T1Svrkmg@mail.gmail.com>
To: Denis Lagno <dilmah@chromium.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 07:32:13 -0000

You can sensibly apply the term fresh to 1-bit values if you like.
The important aspect is independence from your previous choices.

Adam


On Mon, Jun 20, 2011 at 12:26 AM, Denis Lagno <dilmah@chromium.org> wrote:
> maybe I miss something but in the text "fresh" is applied to 32-bit value=
s..
>
> On Mon, Jun 20, 2011 at 6:57 AM, Adam Barth <ietf@adambarth.com> wrote:
>> On Sat, Jun 18, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org> wrot=
e:
>>> On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth <ietf@adambarth.com> wrote=
:
>>>> The term "fresh" is a term of art in cryptography. =A0It means, roughl=
y,
>>>> "not used previously."
>>>
>>> So this implies that client must keep track of already used keys? it
>>> imposes limit on length of connection?
>>> True it or false, It should be explicitly clarified in the text.
>>
>> The normal practice in cryptography is to just use large enough values
>> such that the probably of collision is sufficiently small as to be
>> acceptable. =A0For example, if you use a 20 byte nonce, the probably of
>> collision is zero for all practical purposes.
>>
>> This stuff is all extremely normal.
>>
>> Adam
>>
>

From dilmah@google.com  Mon Jun 20 00:34:40 2011
Return-Path: <dilmah@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2E6011E8095 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:34:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.977
X-Spam-Level: 
X-Spam-Status: No, score=-105.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kn0rEfWSbFuF for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 00:34:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5B011E8077 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:34:39 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p5K7YcY4004250 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:34:38 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308555278; bh=MQxTmekWAyt+UoFaHm844uf7MZM=; h=MIME-Version:Sender:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding; b=yFy9wC6ljjgSCMdLZUM2b7fWPndz38+Vm51kqP8ngJG0YTmh/WXQgvHWNiWQJLS00 ZKnXbsG9F+/3HNqvRjCxw==
Received: from qwh5 (qwh5.prod.google.com [10.241.194.197]) by hpaq3.eem.corp.google.com with ESMTP id p5K7Yasn019670 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 20 Jun 2011 00:34:37 -0700
Received: by qwh5 with SMTP id 5so1262532qwh.34 for <hybi@ietf.org>; Mon, 20 Jun 2011 00:34:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ORJpdRZGrAuyKOR3dvAaBB6spPrQC5hzuka58eqw0EE=; b=YOLqIov7+mTmxtoV4hL2hctcfwL7RoHjuZoR5pmSPzznBGoZ8CIIgLbcWTdgN+Cyzj USw3R7PqXQhH7Riouv0w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=tNzeiyBKlWphxBXTZkYKdwWLpPhzwaJ9T7vLWxCvuBryGxaljE68/gY/HmTXpWzzHd CPHuPyAogqhvmpTu4p0w==
MIME-Version: 1.0
Received: by 10.224.10.209 with SMTP id q17mr3853382qaq.273.1308555275815; Mon, 20 Jun 2011 00:34:35 -0700 (PDT)
Sender: dilmah@google.com
Received: by 10.229.18.69 with HTTP; Mon, 20 Jun 2011 00:34:35 -0700 (PDT)
In-Reply-To: <BANLkTi=q3w6Z0odEWdzTkeNQ-7T1Svrkmg@mail.gmail.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com> <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com> <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com> <BANLkTimf=ateLuDO7R7yhOE4AE2m770PAg@mail.gmail.com> <BANLkTi=q3w6Z0odEWdzTkeNQ-7T1Svrkmg@mail.gmail.com>
Date: Mon, 20 Jun 2011 11:34:35 +0400
X-Google-Sender-Auth: BRgV_rOSpj-C1G7OjstaP_X5gME
Message-ID: <BANLkTinkqF6dxTP6DdijJzNsxEXV1G+Nyg@mail.gmail.com>
From: Denis Lagno <dilmah@chromium.org>
To: Adam Barth <ietf@adambarth.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 07:34:40 -0000

oh, well, so you'd better avoid phrase "not used previously" in the
first place.  It was highly misleading.

On Mon, Jun 20, 2011 at 11:31 AM, Adam Barth <ietf@adambarth.com> wrote:
> You can sensibly apply the term fresh to 1-bit values if you like.
> The important aspect is independence from your previous choices.
>
> Adam
>
>
> On Mon, Jun 20, 2011 at 12:26 AM, Denis Lagno <dilmah@chromium.org> wrote=
:
>> maybe I miss something but in the text "fresh" is applied to 32-bit valu=
es..
>>
>> On Mon, Jun 20, 2011 at 6:57 AM, Adam Barth <ietf@adambarth.com> wrote:
>>> On Sat, Jun 18, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org> wro=
te:
>>>> On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth <ietf@adambarth.com> wrot=
e:
>>>>> The term "fresh" is a term of art in cryptography. =A0It means, rough=
ly,
>>>>> "not used previously."
>>>>
>>>> So this implies that client must keep track of already used keys? it
>>>> imposes limit on length of connection?
>>>> True it or false, It should be explicitly clarified in the text.
>>>
>>> The normal practice in cryptography is to just use large enough values
>>> such that the probably of collision is sufficiently small as to be
>>> acceptable. =A0For example, if you use a 20 byte nonce, the probably of
>>> collision is zero for all practical purposes.
>>>
>>> This stuff is all extremely normal.
>>>
>>> Adam
>>>
>>
>

From ietf@adambarth.com  Mon Jun 20 01:05:58 2011
Return-Path: <ietf@adambarth.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD9E21F84D4 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.246
X-Spam-Level: 
X-Spam-Status: No, score=-3.246 tagged_above=-999 required=5 tests=[AWL=-0.269, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bu33swXCOLVR for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:05:58 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 53CBA21F84CF for <hybi@ietf.org>; Mon, 20 Jun 2011 01:05:55 -0700 (PDT)
Received: by gwb20 with SMTP id 20so641275gwb.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:05:54 -0700 (PDT)
Received: by 10.150.197.19 with SMTP id u19mr5595238ybf.327.1308557154550; Mon, 20 Jun 2011 01:05:54 -0700 (PDT)
Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by mx.google.com with ESMTPS id y40sm3724515anp.34.2011.06.20.01.05.53 (version=SSLv3 cipher=OTHER); Mon, 20 Jun 2011 01:05:53 -0700 (PDT)
Received: by ywp31 with SMTP id 31so3002844ywp.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:05:53 -0700 (PDT)
Received: by 10.90.42.15 with SMTP id p15mr5339125agp.13.1308557153188; Mon, 20 Jun 2011 01:05:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.65.13 with HTTP; Mon, 20 Jun 2011 01:05:23 -0700 (PDT)
In-Reply-To: <BANLkTinkqF6dxTP6DdijJzNsxEXV1G+Nyg@mail.gmail.com>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com> <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com> <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com> <BANLkTimf=ateLuDO7R7yhOE4AE2m770PAg@mail.gmail.com> <BANLkTi=q3w6Z0odEWdzTkeNQ-7T1Svrkmg@mail.gmail.com> <BANLkTinkqF6dxTP6DdijJzNsxEXV1G+Nyg@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 20 Jun 2011 01:05:23 -0700
Message-ID: <BANLkTi=zmJCZZ5-D6zKE7DArQj2P1KJN7Q@mail.gmail.com>
To: Denis Lagno <dilmah@chromium.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:05:58 -0000

Yeah, that was a confusing way of putting it.  I meant that the
underlying coin-flips should not have been used previously.

Adam


On Mon, Jun 20, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org> wrote:
> oh, well, so you'd better avoid phrase "not used previously" in the
> first place. =A0It was highly misleading.
>
> On Mon, Jun 20, 2011 at 11:31 AM, Adam Barth <ietf@adambarth.com> wrote:
>> You can sensibly apply the term fresh to 1-bit values if you like.
>> The important aspect is independence from your previous choices.
>>
>> Adam
>>
>>
>> On Mon, Jun 20, 2011 at 12:26 AM, Denis Lagno <dilmah@chromium.org> wrot=
e:
>>> maybe I miss something but in the text "fresh" is applied to 32-bit val=
ues..
>>>
>>> On Mon, Jun 20, 2011 at 6:57 AM, Adam Barth <ietf@adambarth.com> wrote:
>>>> On Sat, Jun 18, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org> wr=
ote:
>>>>> On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth <ietf@adambarth.com> wro=
te:
>>>>>> The term "fresh" is a term of art in cryptography. =A0It means, roug=
hly,
>>>>>> "not used previously."
>>>>>
>>>>> So this implies that client must keep track of already used keys? it
>>>>> imposes limit on length of connection?
>>>>> True it or false, It should be explicitly clarified in the text.
>>>>
>>>> The normal practice in cryptography is to just use large enough values
>>>> such that the probably of collision is sufficiently small as to be
>>>> acceptable. =A0For example, if you use a 20 byte nonce, the probably o=
f
>>>> collision is zero for all practical purposes.
>>>>
>>>> This stuff is all extremely normal.
>>>>
>>>> Adam
>>>>
>>>
>>
>

From andy@warmcat.com  Mon Jun 20 01:11:53 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DD5A21F84EC for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:11:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.674
X-Spam-Level: 
X-Spam-Status: No, score=-2.674 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53SRQlSBIT3D for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:11:52 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id A6BEA21F84EB for <hybi@ietf.org>; Mon, 20 Jun 2011 01:11:52 -0700 (PDT)
Message-ID: <4DFF00C1.8090809@warmcat.com>
Date: Mon, 20 Jun 2011 09:11:45 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
In-Reply-To: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:11:53 -0000

On 06/20/2011 07:33 AM, Somebody in the thread at some point said:

Hi -

> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!
>
> So for this very typical example, masking was sufficiently random to
> completely negate the benefits of compression.

Isn't this just saying that it's dumb to mask-then-compress?

You could just compress-then-mask and get the 13Kbyte result directly 
and "safely".

-Andy

From gregw@intalio.com  Mon Jun 20 01:21:12 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61C811E80B4 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:21:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.688
X-Spam-Level: 
X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[AWL=-0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HX--iReFlhp1 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:21:11 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C0A7C11E8076 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:21:10 -0700 (PDT)
Received: by vws12 with SMTP id 12so398148vws.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:21:04 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.76.4 with SMTP id g4mr3293868vdw.278.1308558064305; Mon, 20 Jun 2011 01:21:04 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Mon, 20 Jun 2011 01:21:04 -0700 (PDT)
In-Reply-To: <4DFF00C1.8090809@warmcat.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com> <4DFF00C1.8090809@warmcat.com>
Date: Mon, 20 Jun 2011 18:21:04 +1000
Message-ID: <BANLkTinN=ae0v0D8F78stCWRNvrLL3xYfQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= <andy@warmcat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:21:12 -0000

On 20 June 2011 18:11, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" <andy@war=
mcat.com> wrote:
> On 06/20/2011 07:33 AM, Somebody in the thread at some point said:
>
> Hi -
>
>> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
>> is was 52623 bytes.
>> I then compressed both these streams with gzip and got 13306 bytes for
>> unmasked and 51704 bytes for the masked!!!!
>>
>> So for this very typical example, masking was sufficiently random to
>> completely negate the benefits of compression.
>
> Isn't this just saying that it's dumb to mask-then-compress?
>
> You could just compress-then-mask and get the 13Kbyte result directly and
> "safely".

That is exactly what I'm saying!

We should use a deflate-frame extension that does compress-then-mask,
rather than a deflate-stream "extension" that does mask-then-compress.

cheers

From andy@warmcat.com  Mon Jun 20 01:33:49 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55BD111E80D6 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHovAC0NlXFK for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:33:49 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id CA39111E8080 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:33:48 -0700 (PDT)
Message-ID: <4DFF05EB.4070201@warmcat.com>
Date: Mon, 20 Jun 2011 09:33:47 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>	<4DFF00C1.8090809@warmcat.com> <BANLkTinN=ae0v0D8F78stCWRNvrLL3xYfQ@mail.gmail.com>
In-Reply-To: <BANLkTinN=ae0v0D8F78stCWRNvrLL3xYfQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:33:49 -0000

On 06/20/2011 09:21 AM, Somebody in the thread at some point said:
> On 20 June 2011 18:11, "Andy Green (æž—å®‰å»¸)"<andy@warmcat.com>  wrote:
>> On 06/20/2011 07:33 AM, Somebody in the thread at some point said:
>>
>> Hi -
>>
>>> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
>>> is was 52623 bytes.
>>> I then compressed both these streams with gzip and got 13306 bytes for
>>> unmasked and 51704 bytes for the masked!!!!
>>>
>>> So for this very typical example, masking was sufficiently random to
>>> completely negate the benefits of compression.
>>
>> Isn't this just saying that it's dumb to mask-then-compress?
>>
>> You could just compress-then-mask and get the 13Kbyte result directly and
>> "safely".
>
> That is exactly what I'm saying!
>
> We should use a deflate-frame extension that does compress-then-mask,
> rather than a deflate-stream "extension" that does mask-then-compress.

Actually I have to agree with you although I started out intending to 
just let it lie.

For good reasons we changed masking to be payload-only, and added an "I 
am masked" bit, and subordinated the mask to after the header.  All good 
stuff.  So now masking action is strongly defined inside a frame context 
and won't detach easily to be applied to deflate-stream.

Then to fix this the choices are either:

  1) add a feature to deflate-stream that it is always masked using a 
new mask scheme altogether and defeat frame masking if we know the thing 
has deflate-stream on it

  2) just operate deflate-stream on payloads before any per-frame 
masking gets applied

1) sounds like re-inventing the scary masking wheel.

The only little issue with 2) is that deflate-stream operates at bit 
level, you'll have to spill the bits up to a byte every frame payload.

So unless I missed something somewhere, to fix deflate-stream masking 
bloat it does seem to want delfate-stream action to move to only 
applying on payloads, and before any masking is done there.

-Andy

From djc.ochtman@gmail.com  Mon Jun 20 01:38:04 2011
Return-Path: <djc.ochtman@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C30011E80FE for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.927
X-Spam-Level: 
X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLIDFa1UASzY for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:38:03 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C585511E80E9 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:38:03 -0700 (PDT)
Received: by qyk9 with SMTP id 9so1616615qyk.10 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:38:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=BENbKXcQ70TeknU/9gitffcit7Bu7ImcyVp0nFKUwSk=; b=XuZOTwKniPRB9TYZ6GLUlqG3jLH+h4hLKao9nb0Vl0/X71TXGgxmwvXaTUpkQMtRTm 5abdzPu5cMSO9vWR5AI5lgW+aM43ZQ8wgS/poXtJ6qA0prcQY85q/LOXxmIFfT1gN0D1 2hn1WfZGBO0OsS8o0WXNeaIS38fRL7zeh83bU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=NrOjInCQ0vhuEqOQR+qeBsIN11xOIcDaOBUBiJqlrFngXuQ8tDGFMP8Sl3mjMRHpP4 aWC7Uf4YkwDFl13jEF2sTx+Sz92yorzLvUsT79hrNvy6+MRb/3jpEs8tUGdrY+kfg5aU U8s3rZ6b18lUdpZ14C8jnce90MsflyvLVAx/0=
Received: by 10.229.91.15 with SMTP id k15mr3763538qcm.157.1308559083087; Mon, 20 Jun 2011 01:38:03 -0700 (PDT)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.229.89.67 with HTTP; Mon, 20 Jun 2011 01:37:43 -0700 (PDT)
In-Reply-To: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Mon, 20 Jun 2011 10:37:43 +0200
X-Google-Sender-Auth: uJzCVNRLy83nKSxINgThmZjCFtI
Message-ID: <BANLkTikzTaUgtVQ2k9tnN5bKXwY0nt=ZKw@mail.gmail.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset=UTF-8
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:38:04 -0000

On Mon, Jun 20, 2011 at 08:33, Greg Wilkins <gregw@intalio.com> wrote:
> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!

Are you sure you got this right? From the RFC:

"The masking does not affect the length of the payload data."

Which means it's a little strange that your unmasked WS stream has a
different size from the masked stream.

(Still, it's fairly intuitive that masking would result in worse
compression, so I would tend to agree that compress-then-mask
makes more sense than mask-then-compress.)

Cheers,

Dirkjan

From ibc@aliax.net  Mon Jun 20 01:40:34 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972C111E80D9 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:40:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level: 
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxh7fzcztxCq for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:40:33 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A307111E8102 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:40:33 -0700 (PDT)
Received: by qyk9 with SMTP id 9so1617796qyk.10 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:40:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr3707716qce.192.1308558858218; Mon, 20 Jun 2011 01:34:18 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Mon, 20 Jun 2011 01:34:18 -0700 (PDT)
In-Reply-To: <BANLkTimq2CiSjiS=+yiLmhg9yxACgAZViA@mail.gmail.com>
References: <4DFB8571.4090802@stpeter.im> <BANLkTinuHWwwbXs8b+K9=vN+M=2ZDyy0CQ@mail.gmail.com> <BANLkTim+YUp20v9-8uQVoCV9--gMA4wqLA@mail.gmail.com> <BANLkTinE7VZTZDyyMfw3CZSMevHw-GqTWw@mail.gmail.com> <BANLkTimq2CiSjiS=+yiLmhg9yxACgAZViA@mail.gmail.com>
Date: Mon, 20 Jun 2011 10:34:18 +0200
Message-ID: <BANLkTi=VpkfgVLvNzZZPNC79MTWtzKweNQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Diogo Pereira <diogo.pereira@ist.utl.pt>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] -09: security considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:40:34 -0000

2011/6/20 Diogo Pereira <diogo.pereira@ist.utl.pt>:
> 2011/6/20 Greg Wilkins <gregw@intalio.com>:
>> Also HTTP has BASIC and DIGEST authentication, while WS does not
>> (although it could very easily support these).
>
> I think this is implicitly allowed:
>
> =C2=A0"1. =C2=A0If the status code received from the server is not 101, t=
he
> =C2=A0 =C2=A0 =C2=A0 client handles the response per HTTP procedures." (p=
. 30)
>
> So in response to a 401 the client could resend the handshake request
> with an Authorization header.

The question is: should the browser prompt the human user for
user/pass as when a 401 is received before accessing to a web page?

Imagine this case:


- www.domain.org =3D> 1.1.1.1:80

- ws.domain.org =3D> 1.1.1.2:443

- I open http://www.domain.org in my browser, fill some login form and
retrieve websocket connection data, including an user and pass (for
Digest).

- My JavaScript is then provisioned (via JavaScript WebSocket API
????) with ws connection data: server ip, port, Digest user/passwd.

- My web browser starts the ws connection with ws.domain.org:443. It
receives 401 with Digest (so I need a nonce from the server before
using my user/passwd).

- JavaScript code automatically accepts the Digest chanllenge,
generates a Digest response with the provided user/passwd and the
retrieved Digest nonce, and re-send the HTTP GET request (all of this
without prompting the user).

- If the JavaScript code would not be proviosioned with user/pass,
then upon receipt of the 401 it should prompt the user.



So, if all this stuff is not clearly specified (and I think passing
user/pass to the JavaScript WebSocket connection API does not exist)
then using HTTP Digest (or Basic) will be not useful or feasible, and
I expect than using cookies and all that "pure just-web stuff" will be
the only way. Please, take into account that a websocket server could
run in a separate server, so using cookies mechanism is not so
feasible. Neither I think that cookies (a workaround to simulate
sessions in HTTP protocol) are the best way to go.

IMHO the draft should do much more effort in authentication process.
Please don't let the door open to ugly and/or propietary
authentication solutions.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From gregw@intalio.com  Mon Jun 20 01:41:13 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D14B11E8119 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:41:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.837
X-Spam-Level: 
X-Spam-Status: No, score=-2.837 tagged_above=-999 required=5 tests=[AWL=0.140,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L18twCjqyZoR for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 01:41:12 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFD011E8114 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:41:12 -0700 (PDT)
Received: by vws12 with SMTP id 12so409504vws.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 01:41:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.158.38 with SMTP id wr6mr1307917vdb.198.1308559271821; Mon, 20 Jun 2011 01:41:11 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Mon, 20 Jun 2011 01:41:11 -0700 (PDT)
In-Reply-To: <BANLkTikzTaUgtVQ2k9tnN5bKXwY0nt=ZKw@mail.gmail.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com> <BANLkTikzTaUgtVQ2k9tnN5bKXwY0nt=ZKw@mail.gmail.com>
Date: Mon, 20 Jun 2011 18:41:11 +1000
Message-ID: <BANLkTikTUECBd0Ow_5xhRoqZD8v4YHUMeQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Dirkjan Ochtman <dirkjan@ochtman.nl>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 08:41:13 -0000

On 20 June 2011 18:37, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> On Mon, Jun 20, 2011 at 08:33, Greg Wilkins <gregw@intalio.com> wrote:
>> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
>> is was 52623 bytes.
>> I then compressed both these streams with gzip and got 13306 bytes for
>> unmasked and 51704 bytes for the masked!!!!
>
> Are you sure you got this right? From the RFC:
>
> "The masking does not affect the length of the payload data."

But it does affect the length of the frame as it requires and extra 4
bytes per frame.

There were 487 frames, so that is 1948 extra bytes
52623-50675=1948


cheers

From ibc@aliax.net  Mon Jun 20 05:01:39 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D8D11E808A for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 05:01:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.66
X-Spam-Level: 
X-Spam-Status: No, score=-2.66 tagged_above=-999 required=5 tests=[AWL=0.017,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Sb7ke3aX8nj for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 05:01:38 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2331E11E807A for <hybi@ietf.org>; Mon, 20 Jun 2011 05:01:38 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1289907qwc.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 05:01:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr3905071qca.154.1308571296587; Mon, 20 Jun 2011 05:01:36 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Mon, 20 Jun 2011 05:01:36 -0700 (PDT)
Date: Mon, 20 Jun 2011 14:01:36 +0200
Message-ID: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 12:01:39 -0000

Hi, I would like to start a new thread for this topic as it seems that
the draft does not cover it at all (just suggests that an HTTP
response code other than 101 should be threated as RFC 2616 states:


  "1.  If the status code received from the server is not 101, the
        client handles the response per HTTP procedures." (p. 30)


The question is: should the browser prompt the human user for
user/pass as when a 401 is received in the WS handshake attemp?

Imagine this case:

- www.domain.org =3D> 1.1.1.1:80

- ws.domain.org =3D> 1.1.1.2:443

- I open http://www.domain.org in my browser, fill some login form and
retrieve websocket connection data, including an user and pass (for
Digest).

- My JavaScript is then provisioned (via JavaScript WebSocket API
????) with ws connection data: server ip, port, Digest user/passwd.

- My web browser starts the ws connection with ws.domain.org:443. It
receives 401 with Digest (so I need a nonce from the server before
using my user/passwd).

- JavaScript code automatically accepts the Digest chanllenge,
generates a Digest response with the provided user/passwd and the
retrieved Digest nonce, and re-send the HTTP GET request (all of this
without prompting the user) with the Authorization header.

- If the JavaScript code would not be proviosioned with user/pass,
then upon receipt of the 401 it should prompt the user (like a
JavaScript alert?).



So, if all this stuff is not clearly specified (and I think passing
user/pass to the JavaScript WebSocket connection API does not exist)
then using HTTP Digest (or Basic) will be not useful or feasible, and
I expect than using cookies and all that "pure just-web stuff" will be
the only way. Please, take into account that a websocket server could
run in a separate server, so using cookies mechanism is not so
feasible (it could or not depending the case). Neither I think that
cookies (a workaround to simulate
sessions in HTTP protocol) are the best way to go.

IMHO the draft should do much more effort in authentication process.
Please don't let the door open to ugly and/or propietary
authentication solutions.


My proposal is that the JavaScript WebSocket API should include a
method to pass authentication 'user' and 'password' (and optionally
'realm' so it would ignore the realm para in the 401 response when
using Digest rather than Basic auth).

In this way, I could open a webpage, perform usual login (maybe via a
HTML form as commonly extended) and then retrieve WS connection data
(WS URI), including user/pass/[realm].
So my JavaScript client would open a WS connection with the given
destination and in case of receiving a 401 it would re-send the HTTP
GET request with the appropriate Authorization header without
prompting the user.

This wouldn't be the only authentication mechanism, of course, but
IMHO it should be documented (and covered by the JS WebSocket API).

Regards.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From gezelter@rlgsc.com  Mon Jun 20 07:09:24 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38F4F11E8192 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:09:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Level: 
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4So6X0XzIvwS for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:09:23 -0700 (PDT)
Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by ietfa.amsl.com (Postfix) with SMTP id 7467211E8191 for <hybi@ietf.org>; Mon, 20 Jun 2011 07:09:23 -0700 (PDT)
Received: (qmail 9534 invoked from network); 20 Jun 2011 14:09:18 -0000
Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 20 Jun 2011 14:09:17 -0000
Received: (qmail 21046 invoked by uid 99); 20 Jun 2011 14:09:16 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 162.83.147.83
User-Agent: Web-Based Email 5.5.05
Message-Id: <20110620070915.ef1fc80126c74c6c202a919c41c7bb0b.f9a4892276.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Mon, 20 Jun 2011 07:09:15 -0700
Mime-Version: 1.0
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 14:09:24 -0000

As I have noted before, Greg's observation about the interaction of
masking and compression is undoubtedly correct.

To be effective, compression must be done when the steam of data is most
strongly correlated. In short, this should be BEFORE multiplexing,
encryption, and masking. Data on different multiplexed streams cannot be
assumed to be correlated, and correlation is needed for effective
compression.=20

Encrypting or masking data to create randomness similarly negates the
effectiveness of compression.=20

When dealing with correlated data (e.g., the contents of a printable
file, or even a PostScript file), I have seen compression factors of
100:1. If the data had first been encrypted, or randomly masked, the
ratio would have been likely 2:1 (what is often achieved by disk or tape
compression facilities), or even less than 1:1 (worst case).

Compression should be done within each sub-stream (assuming
multiplexing, which is not in the current specification), and in any
event, before encryption and masking.

- Bob Gezelter, http://www.rlgsc.com


From arman@noemax.com  Mon Jun 20 07:10:41 2011
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4404811E80C3 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:10:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BHFPLKimwLw for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:10:40 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3EE11E815C for <hybi@ietf.org>; Mon, 20 Jun 2011 07:10:40 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id DUE34339; Mon, 20 Jun 2011 17:10:39 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: "'Adam Barth'" <ietf@adambarth.com>, "'Denis Lagno'" <dilmah@chromium.org>
References: <000401cc2cf3$106d37d0$3147a770$@noemax.com> <BANLkTim_-kytRUdG-X51fFZY+Gj4mcypnQ@mail.gmail.com> <BANLkTi=m_gOTxRjTiyz4S713rUexFrr+wg@mail.gmail.com> <BANLkTindEVpt9DE4LXYVSOg7C3RCvewi4Q@mail.gmail.com> <BANLkTimf=ateLuDO7R7yhOE4AE2m770PAg@mail.gmail.com> <BANLkTi=q3w6Z0odEWdzTkeNQ-7T1Svrkmg@mail.gmail.com> <BANLkTinkqF6dxTP6DdijJzNsxEXV1G+Nyg@mail.gmail.com> <BANLkTi=zmJCZZ5-D6zKE7DArQj2P1KJN7Q@mail.gmail.com>
In-Reply-To: <BANLkTi=zmJCZZ5-D6zKE7DArQj2P1KJN7Q@mail.gmail.com>
Date: Mon, 20 Jun 2011 17:09:35 +0300
Message-ID: <001c01cc2f53$b3812c80$1a838580$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH3vjT229jiJ5oHR6yUCTCCNK8IUgIiwQM3AcOnDBwCe5cnugGI3L8pAixj/l4BDv0B5wHxewfjlAZsfSA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] "fresh" and "uniformly at random":
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 14:10:41 -0000

I think you actually mean that the implementation should not =
intentionally
reuse a mask or part of a mask.

With best regards,
Arman

> -----Original Message-----
> From: Adam Barth [mailto:ietf@adambarth.com]
> Sent: Monday, June 20, 2011 11:05 AM
> To: Denis Lagno
> Cc: Arman Djusupov; hybi@ietf.org
> Subject: Re: [hybi] "fresh" and "uniformly at random":
>=20
> Yeah, that was a confusing way of putting it.  I meant that the =
underlying
> coin-flips should not have been used previously.
>=20
> Adam
>=20
>=20
> On Mon, Jun 20, 2011 at 12:34 AM, Denis Lagno <dilmah@chromium.org>
> wrote:
> > oh, well, so you'd better avoid phrase "not used previously" in the
> > first place. =A0It was highly misleading.
> >
> > On Mon, Jun 20, 2011 at 11:31 AM, Adam Barth <ietf@adambarth.com>
> wrote:
> >> You can sensibly apply the term fresh to 1-bit values if you like.
> >> The important aspect is independence from your previous choices.
> >>
> >> Adam
> >>
> >>
> >> On Mon, Jun 20, 2011 at 12:26 AM, Denis Lagno <dilmah@chromium.org>
> wrote:
> >>> maybe I miss something but in the text "fresh" is applied to =
32-bit
> values..
> >>>
> >>> On Mon, Jun 20, 2011 at 6:57 AM, Adam Barth <ietf@adambarth.com>
> wrote:
> >>>> On Sat, Jun 18, 2011 at 12:34 AM, Denis Lagno =
<dilmah@chromium.org>
> wrote:
> >>>>> On Sat, Jun 18, 2011 at 10:27 AM, Adam Barth =
<ietf@adambarth.com>
> wrote:
> >>>>>> The term "fresh" is a term of art in cryptography. =A0It means,
> >>>>>> roughly, "not used previously."
> >>>>>
> >>>>> So this implies that client must keep track of already used =
keys?
> >>>>> it imposes limit on length of connection?
> >>>>> True it or false, It should be explicitly clarified in the text.
> >>>>
> >>>> The normal practice in cryptography is to just use large enough
> >>>> values such that the probably of collision is sufficiently small =
as
> >>>> to be acceptable. =A0For example, if you use a 20 byte nonce, the
> >>>> probably of collision is zero for all practical purposes.
> >>>>
> >>>> This stuff is all extremely normal.
> >>>>
> >>>> Adam
> >>>>
> >>>
> >>
> >


From arman@noemax.com  Mon Jun 20 07:52:28 2011
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08A311E808E for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eD7is4ASzg1d for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 07:52:23 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id B6EF111E80BE for <hybi@ietf.org>; Mon, 20 Jun 2011 07:52:23 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id DUU40622; Mon, 20 Jun 2011 17:52:22 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: "'Bob Gezelter'" <gezelter@rlgsc.com>, <hybi@ietf.org>
References: <20110620070915.ef1fc80126c74c6c202a919c41c7bb0b.f9a4892276.wbe@email03.secureserver.net>
In-Reply-To: <20110620070915.ef1fc80126c74c6c202a919c41c7bb0b.f9a4892276.wbe@email03.secureserver.net>
Date: Mon, 20 Jun 2011 17:51:17 +0300
Message-ID: <002a01cc2f59$878be970$96a3bc50$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKAhv+d7vI6B6bMaZMky64pplNS/pNdpCuA
Content-Language: en-us
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Mon, 20 Jun 2011 14:52:28 -0000

I don't think we should take the "mux" extension into account when
discussing the deflate-stream extension. Compressing "mux" channels is a
special case that should be covered by the "mux" extension specification. 

Combining all multiplexed streams into a single deflate channel is a good
idea because it is actually very cheap memory wise, otherwise compressing
each sub-channel with a separate DEFLATE stream could end up being very
expensive memory wise. You can expect over 200KB of memory needed per each
sub-channel, this basically kills the whole purpose of sub-channels which
are actually supposed to decrease the load on the server side. Two-three
thousands of compressed sub-channels would be enough to put the server on
its knees.

I consider the deflate-stream extension just as basic transport compression
which is offered "out of the box" by a WebSocket implementation,
irrespective of whether it supports multiplexing or not. 

With best regards,
Arman

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
> Bob Gezelter
> Sent: Monday, June 20, 2011 5:09 PM
> To: hybi@ietf.org
> Subject: Re: [hybi] deflate-stream and masking
> 
> As I have noted before, Greg's observation about the interaction of
masking
> and compression is undoubtedly correct.
> 
> To be effective, compression must be done when the steam of data is most
> strongly correlated. In short, this should be BEFORE multiplexing,
encryption,
> and masking. Data on different multiplexed streams cannot be assumed to
> be correlated, and correlation is needed for effective compression.
> 
> Encrypting or masking data to create randomness similarly negates the
> effectiveness of compression.
> 
> When dealing with correlated data (e.g., the contents of a printable file,
or
> even a PostScript file), I have seen compression factors of 100:1. If the
data
> had first been encrypted, or randomly masked, the ratio would have been
> likely 2:1 (what is often achieved by disk or tape compression
facilities), or
> even less than 1:1 (worst case).
> 
> Compression should be done within each sub-stream (assuming
> multiplexing, which is not in the current specification), and in any
event,
> before encryption and masking.
> 
> - Bob Gezelter, http://www.rlgsc.com
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


From stpeter@stpeter.im  Mon Jun 20 20:43:28 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3423A11E8147 for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 20:43:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Level: 
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ym06kt7NuwxB for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 20:43:27 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7F68F11E80DB for <hybi@ietf.org>; Mon, 20 Jun 2011 20:43:27 -0700 (PDT)
Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EB483400F9; Mon, 20 Jun 2011 21:44:02 -0600 (MDT)
Message-ID: <4E001354.3000604@stpeter.im>
Date: Mon, 20 Jun 2011 21:43:16 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <4DF91FCA.8060403@stpeter.im> <BANLkTinw1d61_wqBXg4mPHti-BhohW8SWg@mail.gmail.com>
In-Reply-To: <BANLkTinw1d61_wqBXg4mPHti-BhohW8SWg@mail.gmail.com>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080800020305070506000605"
Cc: "hybi@ietf.org" <hybi@ietf.org>
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 03:43:28 -0000

This is a cryptographically signed message in MIME format.

--------------ms080800020305070506000605
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/20/11 12:57 AM, Greg Wilkins wrote:
> On 16 June 2011 07:10, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>> Section 1.1 has always struck me as strange. It sounds as if we're
>> developing an IM protocol here! I suggest:
>>
>>   Historically, creating Web applications that need bidirectional
>>   communication between a client and a server (e.g., instant messaging=

>>   and gaming applications) has required an abuse of HTTP to poll the
>>   server for updates while sending upstream notifications as distinct
>>   HTTP calls. [RFC6202]
>=20
>=20
> I don't think the usage of "abuse" can be justified.   There is
> nothing abusive about long polling and it is entirely legal HTTP.
> Besides that is too much of a subjective reason.
>=20
> How about:
>=20
>   Historically, creating Web applications that need bidirectional
>   communication between a client and a server (e.g., instant messaging
>   and gaming applications), has required the use of HTTP to poll or lon=
g
>   poll the server for updates.  Such usage of HTTP is less efficient
> and responsive
>   that what is possible with a TCP/IP connection.

Sure. I tried to leave as much of the current text alone in my suggestion=
=2E

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms080800020305070506000605
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYy
MTAzNDMxNlowIwYJKoZIhvcNAQkEMRYEFIT9vz0dJAGvfVpnHBpM49Oo7q9YMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQBUZ9ssDDTTlFnQY7mh83vyMXdu0zAxFu/0WKso2zjAh5h7fd8j4WusFEAQ
rpJOwCtEjqlbEHZWiD2e1IJECe8GYSuzg43UsCc5/BJr8lCkl4qF7BBwRK2m9xpA1XItgu8K
y18pML9r7OBR6x5IWdjqXPW93znwi7SO/SkSdiOXebHTdqi94EbSo0EcAC+Tt5wKk819Vo+v
eIkzZyLdzzJESZ1/6BlUn1bfsw5kpaAW3frCeomevAhA8IuNV8tv0dnrQo9H0jjlfI6+vFZr
zVaw4IVjAeJFEXO0hD44FQZgBxFUqIXpQzD92rlBnkGqp1m3iKtUw8pZbgdMw+lTh7S/AAAA
AAAA
--------------ms080800020305070506000605--

From gregw@intalio.com  Mon Jun 20 21:21:09 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1F4A11E81BA for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 21:21:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.851
X-Spam-Level: 
X-Spam-Status: No, score=-2.851 tagged_above=-999 required=5 tests=[AWL=0.126,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GvTkXUeiL9-j for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 21:21:04 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E36111E81AB for <hybi@ietf.org>; Mon, 20 Jun 2011 21:21:03 -0700 (PDT)
Received: by vxi40 with SMTP id 40so1470548vxi.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 21:21:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.130 with SMTP id l2mr4708848vdv.78.1308630063486; Mon, 20 Jun 2011 21:21:03 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Mon, 20 Jun 2011 21:21:03 -0700 (PDT)
In-Reply-To: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>
Date: Tue, 21 Jun 2011 14:21:03 +1000
Message-ID: <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: hybi@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 04:21:09 -0000

Draft -09 still has examples that say:

Sec-WebSocket-Version: 8

I guess we also need to think about what we are going to do with this
field as we approach "final"

cheers




On 14 June 2011 09:37,  <internet-drafts@ietf.org> wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts direct=
ories. This draft is a work item of the BiDirectional or Server-Initiated H=
TTP Working Group of the IETF.
>
> =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : The WebSocket protocol
> =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Ian Fette
> =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-thewebsocketprot=
ocol-09.txt
> =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 68
> =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-06-13
>
> =A0 The WebSocket protocol enables two-way communication between a client
> =A0 running untrusted code running in a controlled environment to a
> =A0 remote host that has opted-in to communications from that code. =A0Th=
e
> =A0 security model used for this is the Origin-based security model
> =A0 commonly used by Web browsers. =A0The protocol consists of an opening
> =A0 handshake followed by basic message framing, layered over TCP. =A0(In
> =A0 theory, any transport protocol could be used so long as it provides
> =A0 for reliable transport, is byte clean, and supports relatively large
> =A0 message sizes. =A0However, for this document, we consider only TCP.)
> =A0 The goal of this technology is to provide a mechanism for browser-
> =A0 based applications that need two-way communication with servers that
> =A0 does not rely on opening multiple HTTP connections (e.g. using
> =A0 XMLHttpRequest or &lt;iframe&gt;s and long polling).
>
> =A0 Please send feedback to the hybi@ietf.org mailing list.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-=
09.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-0=
9.txt
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

From ifette@google.com  Mon Jun 20 21:23:19 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58C111E81BA for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 21:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.593
X-Spam-Level: 
X-Spam-Status: No, score=-105.593 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0VqG3pzqD9T for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 21:23:18 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CC9E811E81AB for <hybi@ietf.org>; Mon, 20 Jun 2011 21:23:18 -0700 (PDT)
Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p5L4NHmn012531 for <hybi@ietf.org>; Mon, 20 Jun 2011 21:23:17 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308630198; bh=xfqznEnG1emDogWamPGWXqB4aCk=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=ewmLPh6juSR0UHdh3UAGqj1zg+cU5wSYBEWbKIWRWgsJ41+6ovCzgSkZozDalVFq1 r3cDOdw3WCT9F3Y42KrNA==
Received: from iwn35 (iwn35.prod.google.com [10.241.68.99]) by hpaq13.eem.corp.google.com with ESMTP id p5L4N89U008008 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 20 Jun 2011 21:23:16 -0700
Received: by iwn35 with SMTP id 35so4636525iwn.22 for <hybi@ietf.org>; Mon, 20 Jun 2011 21:23:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LaeOFzCFFJNYsNPRzXyEEIiyiRN8lUpdEZcHzl+Ihkg=; b=idWkdB2kd5xc/NO9lQZo7EpTpQPHLY2yMRJfi+BrmkEBskMqBKIddO/R41j5uSrK7s kEoGfRUquKh1A73/ly2w==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=JSm5nfzuUOAP9EQ7lbFYASVQa6QVhh5Rs2AN4p8QPR0j4+DH3qcrjUHTp9r8Z4Jc8L IC4QWYZcXAZBoIfMKW9w==
MIME-Version: 1.0
Received: by 10.231.119.216 with SMTP id a24mr6086872ibr.58.1308630195220; Mon, 20 Jun 2011 21:23:15 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Mon, 20 Jun 2011 21:23:15 -0700 (PDT)
In-Reply-To: <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>
Date: Mon, 20 Jun 2011 21:23:15 -0700
Message-ID: <BANLkTikwcqZJu+YJS_Tk0cTEpHmdOd0naA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary=001636920a1aedafaa04a63135b2
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 04:23:19 -0000

--001636920a1aedafaa04a63135b2
Content-Type: text/plain; charset=UTF-8

The request MUST include a header with the name "Sec-WebSocket-
        Version".  The value of this header MUST be 8. _Note: Although a
        draft -09 was published, as -09 was comprised of editorial
        changes and not changes to the wire protocol, 9 was not used as
        a valid value for Sec-WebSocket-Version.  This value was
        reserved in the IANA registry but was not and will not be used.


Fette                   Expires December 15, 2011              [Page 30]

  <http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-09#page-31>Internet-Draft
          The WebSocket protocol                June 2011


        If subsequent changes to the wire protocol are necessary, 9 will
        be skipped to prevent confusion with the draft 9 protocol._


On Mon, Jun 20, 2011 at 9:21 PM, Greg Wilkins <gregw@intalio.com> wrote:

> Draft -09 still has examples that say:
>
> Sec-WebSocket-Version: 8
>
> I guess we also need to think about what we are going to do with this
> field as we approach "final"
>
> cheers
>
>
>
>
> On 14 June 2011 09:37,  <internet-drafts@ietf.org> wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the BiDirectional or
> Server-Initiated HTTP Working Group of the IETF.
> >
> >        Title           : The WebSocket protocol
> >        Author(s)       : Ian Fette
> >        Filename        : draft-ietf-hybi-thewebsocketprotocol-09.txt
> >        Pages           : 68
> >        Date            : 2011-06-13
> >
> >   The WebSocket protocol enables two-way communication between a client
> >   running untrusted code running in a controlled environment to a
> >   remote host that has opted-in to communications from that code.  The
> >   security model used for this is the Origin-based security model
> >   commonly used by Web browsers.  The protocol consists of an opening
> >   handshake followed by basic message framing, layered over TCP.  (In
> >   theory, any transport protocol could be used so long as it provides
> >   for reliable transport, is byte clean, and supports relatively large
> >   message sizes.  However, for this document, we consider only TCP.)
> >   The goal of this technology is to provide a mechanism for browser-
> >   based applications that need two-way communication with servers that
> >   does not rely on opening multiple HTTP connections (e.g. using
> >   XMLHttpRequest or &lt;iframe&gt;s and long polling).
> >
> >   Please send feedback to the hybi@ietf.org mailing list.
> >
> >
> > A URL for this Internet-Draft is:
> >
> http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> >
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-09.txt
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--001636920a1aedafaa04a63135b2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<span class=3D"Apple-style-span" style=3D"font-family: Times; font-size: 16=
px; "><pre class=3D"newpage" style=3D"font-size: 1em; margin-top: 0px; marg=
in-bottom: 0px; page-break-before: always; ">The request MUST include a hea=
der with the name &quot;Sec-WebSocket-
        Version&quot;.  The value of this header MUST be 8. _Note: Although=
 a
        draft -09 was published, as -09 was comprised of editorial
        changes and not changes to the wire protocol, 9 was not used as
        a valid value for Sec-WebSocket-Version.  This value was
        reserved in the IANA registry but was not and will not be used.



<span class=3D"grey" style=3D"color: rgb(119, 119, 119); ">Fette           =
        Expires December 15, 2011              [Page 30]</span>
</pre><pre class=3D"newpage" style=3D"font-size: 1em; margin-top: 0px; marg=
in-bottom: 0px; page-break-before: always; "><a name=3D"page-31" id=3D"page=
-31" href=3D"http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotoco=
l-09#page-31" class=3D"invisible" style=3D"text-decoration: none; color: wh=
ite; "> </a>
<span class=3D"grey" style=3D"color: rgb(119, 119, 119); ">Internet-Draft  =
         The WebSocket protocol                June 2011</span>


        If subsequent changes to the wire protocol are necessary, 9 will
        be skipped to prevent confusion with the draft 9 protocol._</pre></=
span><br><div class=3D"gmail_quote">On Mon, Jun 20, 2011 at 9:21 PM, Greg W=
ilkins <span dir=3D"ltr">&lt;<a href=3D"mailto:gregw@intalio.com">gregw@int=
alio.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">Draft -09 still has examples that say:<br>
<br>
Sec-WebSocket-Version: 8<br>
<br>
I guess we also need to think about what we are going to do with this<br>
field as we approach &quot;final&quot;<br>
<br>
cheers<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
On 14 June 2011 09:37, =C2=A0&lt;<a href=3D"mailto:internet-drafts@ietf.org=
">internet-drafts@ietf.org</a>&gt; wrote:<br>
&gt; A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories. This draft is a work item of the BiDirectional or Server-Initiate=
d HTTP Working Group of the IETF.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =
The WebSocket protocol<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Ian Fette<=
br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft=
-ietf-hybi-thewebsocketprotocol-09.txt<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : =
68<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0: 2011-06-13<br>
&gt;<br>
&gt; =C2=A0 The WebSocket protocol enables two-way communication between a =
client<br>
&gt; =C2=A0 running untrusted code running in a controlled environment to a=
<br>
&gt; =C2=A0 remote host that has opted-in to communications from that code.=
 =C2=A0The<br>
&gt; =C2=A0 security model used for this is the Origin-based security model=
<br>
&gt; =C2=A0 commonly used by Web browsers. =C2=A0The protocol consists of a=
n opening<br>
&gt; =C2=A0 handshake followed by basic message framing, layered over TCP. =
=C2=A0(In<br>
&gt; =C2=A0 theory, any transport protocol could be used so long as it prov=
ides<br>
&gt; =C2=A0 for reliable transport, is byte clean, and supports relatively =
large<br>
&gt; =C2=A0 message sizes. =C2=A0However, for this document, we consider on=
ly TCP.)<br>
&gt; =C2=A0 The goal of this technology is to provide a mechanism for brows=
er-<br>
&gt; =C2=A0 based applications that need two-way communication with servers=
 that<br>
&gt; =C2=A0 does not rely on opening multiple HTTP connections (e.g. using<=
br>
&gt; =C2=A0 XMLHttpRequest or &amp;lt;iframe&amp;gt;s and long polling).<br=
>
&gt;<br>
&gt; =C2=A0 Please send feedback to the <a href=3D"mailto:hybi@ietf.org">hy=
bi@ietf.org</a> mailing list.<br>
&gt;<br>
&gt;<br>
&gt; A URL for this Internet-Draft is:<br>
&gt; <a href=3D"http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebs=
ocketprotocol-09.txt" target=3D"_blank">http://www.ietf.org/internet-drafts=
/draft-ietf-hybi-thewebsocketprotocol-09.txt</a><br>
&gt;<br>
&gt; Internet-Drafts are also available by anonymous FTP at:<br>
&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts/" target=3D"_blank">ftp:=
//ftp.ietf.org/internet-drafts/</a><br>
&gt;<br>
&gt; This Internet-Draft can be retrieved at:<br>
&gt; <a href=3D"ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebso=
cketprotocol-09.txt" target=3D"_blank">ftp://ftp.ietf.org/internet-drafts/d=
raft-ietf-hybi-thewebsocketprotocol-09.txt</a><br>
&gt; _______________________________________________<br>
&gt; hybi mailing list<br>
&gt; <a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/hybi</a><br>
&gt;<br>
_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</div></div></blockquote></div><br>

--001636920a1aedafaa04a63135b2--

From gregw@intalio.com  Mon Jun 20 21:26:01 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6863421F848E for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 21:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.863
X-Spam-Level: 
X-Spam-Status: No, score=-2.863 tagged_above=-999 required=5 tests=[AWL=0.114,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tI--zCwCBKCt for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 21:26:00 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9132D21F848B for <hybi@ietf.org>; Mon, 20 Jun 2011 21:26:00 -0700 (PDT)
Received: by vxi40 with SMTP id 40so1472794vxi.31 for <hybi@ietf.org>; Mon, 20 Jun 2011 21:26:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.130 with SMTP id l2mr4713263vdv.78.1308630360011; Mon, 20 Jun 2011 21:26:00 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Mon, 20 Jun 2011 21:25:59 -0700 (PDT)
In-Reply-To: <BANLkTikwcqZJu+YJS_Tk0cTEpHmdOd0naA@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <BANLkTikwcqZJu+YJS_Tk0cTEpHmdOd0naA@mail.gmail.com>
Date: Tue, 21 Jun 2011 14:25:59 +1000
Message-ID: <BANLkTi=EW7squxBQafU+WkBH0ooK_b3J-A@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: ifette@google.com
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 04:26:01 -0000

2011/6/21 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>:
> The request MUST include a header with the name "Sec-WebSocket-
>         Version".  The value of this header MUST be 8. _Note: Although a
>         draft -09 was published, as -09 was comprised of editorial
>         changes and not changes to the wire protocol, 9 was not used as
>         a valid value for Sec-WebSocket-Version.  This value was
>         reserved in the IANA registry but was not and will not be used.


oops - I just saw that.

However we still need to decide if/when we will be dropping this field
or converting it to something like

   Sec-WebSocket-Version: 1.0

I know some think versioning is an anti pattern, but it has proved
invaluable in handling multiple client versions.


cheers

From ifette@google.com  Mon Jun 20 22:01:24 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC83611E809D for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 22:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.557
X-Spam-Level: 
X-Spam-Status: No, score=-105.557 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsSMGlhwQoak for <hybi@ietfa.amsl.com>; Mon, 20 Jun 2011 22:01:24 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id E9B9511E8081 for <hybi@ietf.org>; Mon, 20 Jun 2011 22:01:23 -0700 (PDT)
Received: from kpbe11.cbf.corp.google.com (kpbe11.cbf.corp.google.com [172.25.105.75]) by smtp-out.google.com with ESMTP id p5L51MJf004962 for <hybi@ietf.org>; Mon, 20 Jun 2011 22:01:22 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308632483; bh=+MPKnH1kRmcb++Lt5hxqQArHiak=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=d2HlQ86i8+hZ/D4ce23JUtOilmvE25attst9lUAudhkWC2oRUAu30HQqRZcqNg/aq Rd1zBa7uYT4cvhfo31RhA==
Received: from iyl8 (iyl8.prod.google.com [10.241.51.200]) by kpbe11.cbf.corp.google.com with ESMTP id p5L51LEM008807 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Mon, 20 Jun 2011 22:01:21 -0700
Received: by iyl8 with SMTP id 8so5870038iyl.14 for <hybi@ietf.org>; Mon, 20 Jun 2011 22:01:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=UHez+sc4oyaQHH7x9iTVtsrhjc5kA+++ZXopFdmz87k=; b=IGYTe9fQB+oSby6G4disddrEBsqis/dkiX+CkvXKGUDKHoUb0WlMs63r0t7gaCQzcp HZGgluYlNdKg5fbVTbGw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=rnJvtaro9K5TEmlvj+zUyX4JgeBvYQIxQyPqij18EVrGXDU+4Jhj3Hstwy9Fp6shwX Uf7OCmFQJ+aXv3LA8WAA==
MIME-Version: 1.0
Received: by 10.231.41.69 with SMTP id n5mr6110645ibe.83.1308632480780; Mon, 20 Jun 2011 22:01:20 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Mon, 20 Jun 2011 22:01:20 -0700 (PDT)
In-Reply-To: <BANLkTi=EW7squxBQafU+WkBH0ooK_b3J-A@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <BANLkTikwcqZJu+YJS_Tk0cTEpHmdOd0naA@mail.gmail.com> <BANLkTi=EW7squxBQafU+WkBH0ooK_b3J-A@mail.gmail.com>
Date: Mon, 20 Jun 2011 22:01:20 -0700
Message-ID: <BANLkTi=PQZG5nGihX0bam9qNVP84BnCcBQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary=0015177407d428914804a631be09
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 05:01:24 -0000

--0015177407d428914804a631be09
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that we should keep it, but I don't think we should force it to 1.0
or anything. I think we should just leave it at 8 (or at a later version if
that's necessitated).

-Ian

2011/6/20 Greg Wilkins <gregw@intalio.com>

> 2011/6/21 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> > The request MUST include a header with the name "Sec-WebSocket-
> >         Version".  The value of this header MUST be 8. _Note: Although =
a
> >         draft -09 was published, as -09 was comprised of editorial
> >         changes and not changes to the wire protocol, 9 was not used as
> >         a valid value for Sec-WebSocket-Version.  This value was
> >         reserved in the IANA registry but was not and will not be used.
>
>
> oops - I just saw that.
>
> However we still need to decide if/when we will be dropping this field
> or converting it to something like
>
>   Sec-WebSocket-Version: 1.0
>
> I know some think versioning is an anti pattern, but it has proved
> invaluable in handling multiple client versions.
>
>
> cheers
>

--0015177407d428914804a631be09
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think that we should keep it, but I don&#39;t think we should force it to=
 1.0 or anything. I think we should just leave it at 8 (or at a later versi=
on if that&#39;s necessitated).=C2=A0<div><br></div><div>-Ian<br><br><div c=
lass=3D"gmail_quote">
2011/6/20 Greg Wilkins <span dir=3D"ltr">&lt;<a href=3D"mailto:gregw@intali=
o.com">gregw@intalio.com</a>&gt;</span><br><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">=
2011/6/21 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) &lt;<a href=3D"mailto:ifette@google.com">ifette@google.=
com</a>&gt;:<br>

<div class=3D"im">&gt; The request MUST include a header with the name &quo=
t;Sec-WebSocket-<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version&quot;. =C2=A0The value of this hea=
der MUST be 8. _Note: Although a<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft -09 was published, as -09 was compri=
sed of editorial<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 changes and not changes to the wire protoc=
ol, 9 was not used as<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 a valid value for Sec-WebSocket-Version. =
=C2=A0This value was<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 reserved in the IANA registry but was not =
and will not be used.<br>
<br>
<br>
</div>oops - I just saw that.<br>
<br>
However we still need to decide if/when we will be dropping this field<br>
or converting it to something like<br>
<br>
 =C2=A0 Sec-WebSocket-Version: 1.0<br>
<br>
I know some think versioning is an anti pattern, but it has proved<br>
invaluable in handling multiple client versions.<br>
<br>
<br>
cheers<br>
</blockquote></div><br></div>

--0015177407d428914804a631be09--

From djc.ochtman@gmail.com  Tue Jun 21 00:25:02 2011
Return-Path: <djc.ochtman@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53AD711E80BC for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 00:25:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.94
X-Spam-Level: 
X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVusOYsGeI47 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 00:25:01 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD6711E80A7 for <hybi@ietf.org>; Tue, 21 Jun 2011 00:25:01 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1905313qwc.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 00:25:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=xZRLD3hCyaYB/rbGqqSAAwCU3pZzU/AFINhzOmIoUY0=; b=SONdY6DjZhJo1gadzIh+FPQxdtKYcijcLZxfv8AZImv0MtLPmBhtqV3LJKS7RRgHON PMjsGfYAkIeMbPzksB9GqhV/ONUeqJRzqqZZU8JQMWlfq8D4NFc+CvW3/SxCrFxbmqYs zSNhENhGn0MejQzKeCWfOsgRMZF7kAO6hqcz8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=TAnjONdfbkvjj0bxr8ZpZmGjr0CJzqHSUvP+tGT1/m5sADmfuwwZx8urxx062gY9Gz QKV9aV4eAjDG8kB0aqKGQO9wWHzdsjxP2FWTEbZF3ObEe4eu0C/MQGu5CHf1yb01uz3W osAV3+OAZptq7uyDzLlxsk9ay22M8ajeHkkXs=
Received: by 10.229.101.148 with SMTP id c20mr3158087qco.195.1308641100656; Tue, 21 Jun 2011 00:25:00 -0700 (PDT)
MIME-Version: 1.0
Sender: djc.ochtman@gmail.com
Received: by 10.229.89.67 with HTTP; Tue, 21 Jun 2011 00:24:36 -0700 (PDT)
In-Reply-To: <BANLkTi=PQZG5nGihX0bam9qNVP84BnCcBQ@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <BANLkTikwcqZJu+YJS_Tk0cTEpHmdOd0naA@mail.gmail.com> <BANLkTi=EW7squxBQafU+WkBH0ooK_b3J-A@mail.gmail.com> <BANLkTi=PQZG5nGihX0bam9qNVP84BnCcBQ@mail.gmail.com>
From: Dirkjan Ochtman <dirkjan@ochtman.nl>
Date: Tue, 21 Jun 2011 09:24:36 +0200
X-Google-Sender-Auth: 60bEGtxPRYonbMRSRtV1MdPtsPo
Message-ID: <BANLkTin4gJtX=kNxcSS=pR_Esf1O3y7ssQ@mail.gmail.com>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 07:25:02 -0000

2011/6/21 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
> I think that we should keep it, but I don't think we should force it to 1=
.0
> or anything. I think we should just leave it at 8 (or at a later version =
if
> that's necessitated).

You haven't responded to my email at the start of this thread about
incompatibilities between 08 and 09...

Cheers,

Dirkjan

From ifette@google.com  Tue Jun 21 00:40:04 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F4611E8084 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 00:40:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.602
X-Spam-Level: 
X-Spam-Status: No, score=-105.602 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4PCWMZE0-mC for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 00:40:03 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BFF7811E807B for <hybi@ietf.org>; Tue, 21 Jun 2011 00:40:03 -0700 (PDT)
Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p5L7e2Hf013851 for <hybi@ietf.org>; Tue, 21 Jun 2011 00:40:02 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308642003; bh=Y+YQzV719AhBU9JsxRBzPaL1/7U=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=r1AnAQ12TaD6tGWgnikJ2swX2n5ZY8JVGApOTd4dPjX576ngx+iM0uNcb4aFaqvG4 cU/QQRU4KIOksFAz9RyHg==
Received: from qyk30 (qyk30.prod.google.com [10.241.83.158]) by hpaq6.eem.corp.google.com with ESMTP id p5L7d1K4018980 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 00:40:01 -0700
Received: by qyk30 with SMTP id 30so1846594qyk.20 for <hybi@ietf.org>; Tue, 21 Jun 2011 00:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dmHkh/BR2Hhsa8Mf3iRL3xls30r0TevsCb2CGE2MIQ0=; b=iEMy8IR8gJ2hHNSzVDZpQy9xVAzxeukTDY8UoiLf/kYPMI7dJd3ZLn0RgCuGRQahRS PsoZbnTQLkdRrokp9iBQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=vaBTcI7E1nZz0wXEL1bL869MI/TrcH6Uza3Vn9oHbjhaPvT+IJmrzsHScYoycYsCya nfIlFcV0EjcJ1kEy8KRA==
MIME-Version: 1.0
Received: by 10.229.6.196 with SMTP id a4mr4699255qca.143.1308642000740; Tue, 21 Jun 2011 00:40:00 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Tue, 21 Jun 2011 00:40:00 -0700 (PDT)
In-Reply-To: <BANLkTin4gJtX=kNxcSS=pR_Esf1O3y7ssQ@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <BANLkTikwcqZJu+YJS_Tk0cTEpHmdOd0naA@mail.gmail.com> <BANLkTi=EW7squxBQafU+WkBH0ooK_b3J-A@mail.gmail.com> <BANLkTi=PQZG5nGihX0bam9qNVP84BnCcBQ@mail.gmail.com> <BANLkTin4gJtX=kNxcSS=pR_Esf1O3y7ssQ@mail.gmail.com>
Date: Tue, 21 Jun 2011 00:40:00 -0700
Message-ID: <BANLkTikXX-MaddDSXcCxryDHF1=NBi+8nA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Dirkjan Ochtman <dirkjan@ochtman.nl>
Content-Type: multipart/alternative; boundary=0015175cb12097a0e204a633f5e2
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 07:40:04 -0000

--0015175cb12097a0e204a633f5e2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The changes were all in error handling, and were relatively minor. I believ=
e
they match what implementations were doing anyways, and was told by
implementors that bumping the version number for such minor things was a
pain to them. Also, -08 was out for all of a week? Hopefully there's no rea=
l
implementations of that draft. I don't mean to dismiss your concern, it's a
fair point, but hopefully the tradeoff is acceptable.


On Tue, Jun 21, 2011 at 12:24 AM, Dirkjan Ochtman <dirkjan@ochtman.nl>wrote=
:

> 2011/6/21 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> > I think that we should keep it, but I don't think we should force it to
> 1.0
> > or anything. I think we should just leave it at 8 (or at a later versio=
n
> if
> > that's necessitated).
>
> You haven't responded to my email at the start of this thread about
> incompatibilities between 08 and 09...
>
> Cheers,
>
> Dirkjan
>

--0015175cb12097a0e204a633f5e2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The changes were all in error handling, and were relatively minor. I believ=
e they match what implementations were doing anyways, and was told by imple=
mentors that bumping the version number for such minor things was a pain to=
 them. Also, -08 was out for all of a week? Hopefully there&#39;s no real i=
mplementations of that draft. I don&#39;t mean to dismiss your concern, it&=
#39;s a fair point, but hopefully the tradeoff is acceptable.<div>
<br></div><div><div><div><br><div class=3D"gmail_quote">On Tue, Jun 21, 201=
1 at 12:24 AM, Dirkjan Ochtman <span dir=3D"ltr">&lt;<a href=3D"mailto:dirk=
jan@ochtman.nl">dirkjan@ochtman.nl</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex;">
<div class=3D"im">2011/6/21 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=
=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) &lt;<a href=3D"mailto:ifette@google.c=
om">ifette@google.com</a>&gt;:<br>
</div><div class=3D"im">&gt; I think that we should keep it, but I don&#39;=
t think we should force it to 1.0<br>
&gt; or anything. I think we should just leave it at 8 (or at a later versi=
on if<br>
&gt; that&#39;s necessitated).<br>
<br>
</div>You haven&#39;t responded to my email at the start of this thread abo=
ut<br>
incompatibilities between 08 and 09...<br>
<br>
Cheers,<br>
<font color=3D"#888888"><br>
Dirkjan<br>
</font></blockquote></div><br></div></div></div>

--0015175cb12097a0e204a633f5e2--

From duerst@it.aoyama.ac.jp  Tue Jun 21 00:50:48 2011
Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30B9811E80E5 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 00:50:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.868
X-Spam-Level: 
X-Spam-Status: No, score=-99.868 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5p0rYTUqzkD for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 00:50:47 -0700 (PDT)
Received: from acintmta01.acbb.aoyama.ac.jp (acintmta01.acbb.aoyama.ac.jp [133.2.20.33]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8FA11E80BD for <hybi@ietf.org>; Tue, 21 Jun 2011 00:50:46 -0700 (PDT)
Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta01.acbb.aoyama.ac.jp (secret/secret) with SMTP id p5L7od6J020968 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:50:39 +0900
Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 446b_5e96_286e46e2_9bdb_11e0_9ce4_001d0969ab06; Tue, 21 Jun 2011 16:50:39 +0900
Received: from [IPv6:::1] ([133.2.210.5]:44080) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15206AE> for <hybi@ietf.org> from <duerst@it.aoyama.ac.jp>; Tue, 21 Jun 2011 16:50:34 +0900
Message-ID: <4E004D3D.3020305@it.aoyama.ac.jp>
Date: Tue, 21 Jun 2011 16:50:21 +0900
From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>
In-Reply-To: <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 07:50:48 -0000

On 2011/06/21 13:21, Greg Wilkins wrote:
> Draft -09 still has examples that say:
>
> Sec-WebSocket-Version: 8
>
> I guess we also need to think about what we are going to do with this
> field as we approach "final"

One way to handle this is to add RFC Editor notes to the relevant text 
pieces to tell the RFC Editor to remove the text (and therewith the 
Sec-WebSocket-Version header). This makes sure we always have a version 
indicator even in the last draft (because we're never sure it will be 
the last) but won't have a version in the final base protocol.

Regards,    Martin.


From ifette@google.com  Tue Jun 21 01:17:01 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5360A11E80BC for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 01:17:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.739
X-Spam-Level: 
X-Spam-Status: No, score=-104.739 tagged_above=-999 required=5 tests=[AWL=-0.729, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmNXjfBXIf-P for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 01:17:00 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C272A11E80F0 for <hybi@ietf.org>; Tue, 21 Jun 2011 01:16:59 -0700 (PDT)
Received: from kpbe13.cbf.corp.google.com (kpbe13.cbf.corp.google.com [172.25.105.77]) by smtp-out.google.com with ESMTP id p5L8Gw7u024962 for <hybi@ietf.org>; Tue, 21 Jun 2011 01:16:58 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308644218; bh=4lDxg1c3cFfPf8P/JnKZBWLn7mQ=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=QYsKyGZCdv+qTGBUo3/JaKtFcHmrG/PfZ+icHR2ax1RFRZzWiBES8f9VXih/ql/aX wVr9Mgmlt4YYC7ozWbhqA==
Received: from qyk29 (qyk29.prod.google.com [10.241.83.157]) by kpbe13.cbf.corp.google.com with ESMTP id p5L8GuJA004970 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 01:16:56 -0700
Received: by qyk29 with SMTP id 29so1936796qyk.19 for <hybi@ietf.org>; Tue, 21 Jun 2011 01:16:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1Snak03mCnDk0KnjziFChR9OsWbAkhcpggroSXQr2DA=; b=UZ2PEoXQ2XxlKb8w7bEkcAnhTdnFex7IsZ6gjflFvsRu5MCWTIAxxZC5YaabL1Vcay OStsPlPP2rcIm6ma0KYA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=ppL4R2MHvFUutk39ADYr3hCjQdhRjSGMSS7YHpc7TQlWtmk8FPNUIpd8HKF7NFen7m MlI8MI3QmJQbo5WmLReA==
MIME-Version: 1.0
Received: by 10.229.44.198 with SMTP id b6mr4674421qcf.67.1308644215942; Tue, 21 Jun 2011 01:16:55 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Tue, 21 Jun 2011 01:16:55 -0700 (PDT)
In-Reply-To: <4E004D3D.3020305@it.aoyama.ac.jp>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp>
Date: Tue, 21 Jun 2011 01:16:55 -0700
Message-ID: <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= <duerst@it.aoyama.ac.jp>
Content-Type: multipart/alternative; boundary=0016364184ffa0ed3104a6347939
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 08:17:01 -0000

--0016364184ffa0ed3104a6347939
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think we should keep the version header, even in the final. It would not
surprise me if there were future versions, this gives us a convenient way t=
o
support that. (Also, -00 didn't have Version - it didn't show up until -04,
so its presence is also a nice way to determine final from some pre-final
versions.)

-Ian

On Tue, Jun 21, 2011 at 12:50 AM, "Martin J. D=C3=BCrst"
<duerst@it.aoyama.ac.jp>wrote:

> On 2011/06/21 13:21, Greg Wilkins wrote:
>
>> Draft -09 still has examples that say:
>>
>> Sec-WebSocket-Version: 8
>>
>> I guess we also need to think about what we are going to do with this
>> field as we approach "final"
>>
>
> One way to handle this is to add RFC Editor notes to the relevant text
> pieces to tell the RFC Editor to remove the text (and therewith the
> Sec-WebSocket-Version header). This makes sure we always have a version
> indicator even in the last draft (because we're never sure it will be the
> last) but won't have a version in the final base protocol.
>
> Regards,    Martin.
>
>
> ______________________________**_________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman=
/listinfo/hybi>
>

--0016364184ffa0ed3104a6347939
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think we should keep the version header, even in the final. It would not =
surprise me if there were future versions, this gives us a convenient way t=
o support that. (Also, -00 didn&#39;t have Version - it didn&#39;t show up =
until -04, so its presence is also a nice way to determine final from some =
pre-final versions.)<div>
<div><br></div><div>-Ian<br><div><br><div class=3D"gmail_quote">On Tue, Jun=
 21, 2011 at 12:50 AM, &quot;Martin J. D=C3=BCrst&quot; <span dir=3D"ltr">&=
lt;<a href=3D"mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>&gt;=
</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;"><div class=3D"im">On 2011/06/21 13:21, Greg=
 Wilkins wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Draft -09 still has examples that say:<br>
<br>
Sec-WebSocket-Version: 8<br>
<br>
I guess we also need to think about what we are going to do with this<br>
field as we approach &quot;final&quot;<br>
</blockquote>
<br></div>
One way to handle this is to add RFC Editor notes to the relevant text piec=
es to tell the RFC Editor to remove the text (and therewith the Sec-WebSock=
et-Version header). This makes sure we always have a version indicator even=
 in the last draft (because we&#39;re never sure it will be the last) but w=
on&#39;t have a version in the final base protocol.<br>

<br>
Regards, =C2=A0 =C2=A0Martin.<div><div></div><div class=3D"h5"><br>
<br>
______________________________<u></u>_________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/hybi</a><br>
</div></div></blockquote></div><br></div></div></div>

--0016364184ffa0ed3104a6347939--

From salvatore.loreto@ericsson.com  Tue Jun 21 01:30:26 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EB779E8008 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 01:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aH+heZe0liq5 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 01:30:25 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id EE00D9E800A for <hybi@ietf.org>; Tue, 21 Jun 2011 01:30:24 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-54-4e00569f6a98
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B7.5F.09774.F96500E4; Tue, 21 Jun 2011 10:30:24 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 21 Jun 2011 10:30:23 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 2D2E724D8	for <hybi@ietf.org>; Tue, 21 Jun 2011 11:30:23 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EA5F850F8D	for <hybi@ietf.org>; Tue, 21 Jun 2011 11:30:22 +0300 (EEST)
Received: from n211.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 92B5150DE8	for <hybi@ietf.org>; Tue, 21 Jun 2011 11:30:22 +0300 (EEST)
Message-ID: <4E00569E.4030400@ericsson.com>
Date: Tue, 21 Jun 2011 11:30:22 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>	<BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>	<4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com>
In-Reply-To: <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------000606000304020903040500"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 08:30:26 -0000

--------------000606000304020903040500
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

we are not going to remove the version header in the final.

To be clear when we introduced the version header the idea was that it 
would be removed in the final;
however when developers started to use it, they found it useful
and since then we have heard only people asking to keep it even in the 
final,
while nobody has asked to remove it, neither during the wglc.



cheers
/Sal


-- 
Salvatore Loreto
www.sloreto.com



On 6/21/11 11:16 AM, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
> I think we should keep the version header, even in the final. It would 
> not surprise me if there were future versions, this gives us a 
> convenient way to support that. (Also, -00 didn't have Version - it 
> didn't show up until -04, so its presence is also a nice way to 
> determine final from some pre-final versions.)
>
> -Ian
>
> On Tue, Jun 21, 2011 at 12:50 AM, "Martin J. DÃ¼rst" 
> <duerst@it.aoyama.ac.jp <mailto:duerst@it.aoyama.ac.jp>> wrote:
>
>     On 2011/06/21 13:21, Greg Wilkins wrote:
>
>         Draft -09 still has examples that say:
>
>         Sec-WebSocket-Version: 8
>
>         I guess we also need to think about what we are going to do
>         with this
>         field as we approach "final"
>
>
>     One way to handle this is to add RFC Editor notes to the relevant
>     text pieces to tell the RFC Editor to remove the text (and
>     therewith the Sec-WebSocket-Version header). This makes sure we
>     always have a version indicator even in the last draft (because
>     we're never sure it will be the last) but won't have a version in
>     the final base protocol.
>
>     Regards,    Martin.
>
>
>     _______________________________________________
>     hybi mailing list
>     hybi@ietf.org <mailto:hybi@ietf.org>
>     https://www.ietf.org/mailman/listinfo/hybi
>
>



--------------000606000304020903040500
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    we are not going to remove the version header in the final.<br>
    <br>
    To be clear when we introduced the version header the idea was that
    it would be removed in the final;<br>
    however when developers started to use it, they found it useful<br>
    and since then we have heard only people asking to keep it even in
    the final,<br>
    while nobody has asked to remove it, neither during the wglc.<br>
    <br>
    <br>
    <br>
    cheers<br>
    /Sal<br>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Salvatore Loreto
<a class="moz-txt-link-abbreviated" href="http://www.sloreto.com">www.sloreto.com</a></pre>
    <br>
    <br>
    On 6/21/11 11:16 AM, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
    <blockquote
      cite="mid:BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com"
      type="cite">I think we should keep the version header, even in the
      final. It would not surprise me if there were future versions,
      this gives us a convenient way to support that. (Also, -00 didn't
      have Version - it didn't show up until -04, so its presence is
      also a nice way to determine final from some pre-final versions.)
      <div>
        <div><br>
        </div>
        <div>-Ian<br>
          <div><br>
            <div class="gmail_quote">On Tue, Jun 21, 2011 at 12:50 AM,
              "Martin J. DÃ¼rst" <span dir="ltr">&lt;<a
                  moz-do-not-send="true"
                  href="mailto:duerst@it.aoyama.ac.jp">duerst@it.aoyama.ac.jp</a>&gt;</span>
              wrote:<br>
              <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
                0.8ex; border-left: 1px solid rgb(204, 204, 204);
                padding-left: 1ex;">
                <div class="im">On 2011/06/21 13:21, Greg Wilkins wrote:<br>
                  <blockquote class="gmail_quote" style="margin: 0pt 0pt
                    0pt 0.8ex; border-left: 1px solid rgb(204, 204,
                    204); padding-left: 1ex;">
                    Draft -09 still has examples that say:<br>
                    <br>
                    Sec-WebSocket-Version: 8<br>
                    <br>
                    I guess we also need to think about what we are
                    going to do with this<br>
                    field as we approach "final"<br>
                  </blockquote>
                  <br>
                </div>
                One way to handle this is to add RFC Editor notes to the
                relevant text pieces to tell the RFC Editor to remove
                the text (and therewith the Sec-WebSocket-Version
                header). This makes sure we always have a version
                indicator even in the last draft (because we're never
                sure it will be the last) but won't have a version in
                the final base protocol.<br>
                <br>
                Regards, Â  Â Martin.
                <div>
                  <div class="h5"><br>
                    <br>
                    _______________________________________________<br>
                    hybi mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:hybi@ietf.org" target="_blank">hybi@ietf.org</a><br>
                    <a moz-do-not-send="true"
                      href="https://www.ietf.org/mailman/listinfo/hybi"
                      target="_blank">https://www.ietf.org/mailman/listinfo/hybi</a><br>
                  </div>
                </div>
              </blockquote>
            </div>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    <br>
  </body>
</html>

--------------000606000304020903040500--

From ibc@aliax.net  Tue Jun 21 02:04:27 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D579E801E for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:04:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcEjQAz7FwVt for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:04:27 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3BDB59E8017 for <hybi@ietf.org>; Tue, 21 Jun 2011 02:04:27 -0700 (PDT)
Received: by qyk29 with SMTP id 29so3120897qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 02:04:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr4836143qca.154.1308647066467; Tue, 21 Jun 2011 02:04:26 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 02:04:26 -0700 (PDT)
In-Reply-To: <4E00569E.4030400@ericsson.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com> <4E00569E.4030400@ericsson.com>
Date: Tue, 21 Jun 2011 11:04:26 +0200
Message-ID: <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 09:04:27 -0000

2011/6/21 Salvatore Loreto <salvatore.loreto@ericsson.com>:
> we are not going to remove the version header in the final.
>
> To be clear when we introduced the version header the idea was that it wo=
uld
> be removed in the final;
> however when developers started to use it, they found it useful
> and since then we have heard only people asking to keep it even in the
> final, while nobody has asked to remove it, neither during the wglc.

IMHO that is because developers are already trying to use WebSocket
and they get confussed with so many versions of the draft (more than
80 in total) and different handshake mechanisms and core protocols
(framing, masking...). So many websocket servers use some ugly version
detection system (by inspecting headers, and so) so they can
accommodate to the client's websocket version.

So, having a header Sec-WebSocket-Version would make life easier for
developers, right. But this is still a hack. I've never seen a
protocol specification upgrading a "version" field in the protocol
messages for each new draft revision. Just never. The protocol version
should be specified in the final RFC, not before.

IMHO this WG is becoming to much "special" and, instead of learning
from the History of Internet protocols, authors are improvising most
of the stuff present in the draft. WebSocket is not just a new
protocol, it is probably "The Protocol" for the next years. Please
don't experiment with such an important specification.

The specification should be written in a way that it becomes a RFC as
best as possible, rather than trying to satisfy impatient developers
during the spec creation process.

Just my opinion. Regards.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From julian.reschke@gmx.de  Tue Jun 21 02:31:18 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1946421F858B for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:31:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.696
X-Spam-Level: 
X-Spam-Status: No, score=-102.696 tagged_above=-999 required=5 tests=[AWL=-0.397, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljMcM4Jepsqs for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:31:17 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 3896A21F858A for <hybi@ietf.org>; Tue, 21 Jun 2011 02:31:17 -0700 (PDT)
Received: (qmail invoked by alias); 21 Jun 2011 09:31:15 -0000
Received: from p508FDB5A.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.219.90] by mail.gmx.net (mp059) with SMTP; 21 Jun 2011 11:31:15 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX185cqF3XjA52p7PMFzaZyg6C1Y2Q/poq17KSsCxgK ofLfrGJtvnKeUv
Message-ID: <4E0064D9.8050707@gmx.de>
Date: Tue, 21 Jun 2011 11:31:05 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>	<BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>	<4E004D3D.3020305@it.aoyama.ac.jp>	<BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com>	<4E00569E.4030400@ericsson.com> <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com>
In-Reply-To: <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 09:31:18 -0000

On 2011-06-21 11:04, IÃ±aki Baz Castillo wrote:
> ...
> So, having a header Sec-WebSocket-Version would make life easier for
> developers, right. But this is still a hack. I've never seen a
> protocol specification upgrading a "version" field in the protocol
> messages for each new draft revision. Just never. The protocol version
> should be specified in the final RFC, not before.
> ...

We did that for the Atom format.

> ...
> The specification should be written in a way that it becomes a RFC as
> best as possible, rather than trying to satisfy impatient developers
> during the spec creation process.
> ...

I do not disagree with that.

Implementing a draft is an experiment; an important one.

But once we go to RFC the protocol version number should be bumped to 
something sane...

From salvatore.loreto@ericsson.com  Tue Jun 21 02:37:51 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B59C9E8047 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:37:51 -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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdV2MpvZEXcP for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:37:50 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 5E0A39E8046 for <hybi@ietf.org>; Tue, 21 Jun 2011 02:37:50 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-c6-4e00666dfb6f
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4B.79.20773.D66600E4; Tue, 21 Jun 2011 11:37:49 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Tue, 21 Jun 2011 11:37:48 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id F2CA424D8	for <hybi@ietf.org>; Tue, 21 Jun 2011 12:37:48 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B1B8D50EFB	for <hybi@ietf.org>; Tue, 21 Jun 2011 12:37:48 +0300 (EEST)
Received: from n211.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6E51050B7D	for <hybi@ietf.org>; Tue, 21 Jun 2011 12:37:48 +0300 (EEST)
Message-ID: <4E00666C.6050007@ericsson.com>
Date: Tue, 21 Jun 2011 12:37:48 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com>	<BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com>	<4E004D3D.3020305@it.aoyama.ac.jp>	<BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com>	<4E00569E.4030400@ericsson.com>	<BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com> <4E0064D9.8050707@gmx.de>
In-Reply-To: <4E0064D9.8050707@gmx.de>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 09:37:51 -0000

my comment was about keeping the Sec-WebSocket-Version header.

What number (and format) should be put there at the end, in the final 
RFC, it is a different story.

/Sal

-- 
Salvatore Loreto
www.sloreto.com





On 6/21/11 12:31 PM, Julian Reschke wrote:
> On 2011-06-21 11:04, IÃ±aki Baz Castillo wrote:
>> ...
>> So, having a header Sec-WebSocket-Version would make life easier for
>> developers, right. But this is still a hack. I've never seen a
>> protocol specification upgrading a "version" field in the protocol
>> messages for each new draft revision. Just never. The protocol version
>> should be specified in the final RFC, not before.
>> ...
> We did that for the Atom format.
>
>> ...
>> The specification should be written in a way that it becomes a RFC as
>> best as possible, rather than trying to satisfy impatient developers
>> during the spec creation process.
>> ...
> I do not disagree with that.
>
> Implementing a draft is an experiment; an important one.
>
> But once we go to RFC the protocol version number should be bumped to
> something sane...
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi



From ibc@aliax.net  Tue Jun 21 02:56:28 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFF09E804A for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:56:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPxGmx-ZwBOj for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 02:56:27 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 87C019E8046 for <hybi@ietf.org>; Tue, 21 Jun 2011 02:56:27 -0700 (PDT)
Received: by qyk29 with SMTP id 29so3148556qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 02:56:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr4740422qcq.230.1308650186936; Tue, 21 Jun 2011 02:56:26 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 02:56:26 -0700 (PDT)
In-Reply-To: <4E00666C.6050007@ericsson.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com> <4E00569E.4030400@ericsson.com> <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com> <4E0064D9.8050707@gmx.de> <4E00666C.6050007@ericsson.com>
Date: Tue, 21 Jun 2011 11:56:26 +0200
Message-ID: <BANLkTik+the09ZcuuyYp4nWEKztTNWmMwA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Salvatore Loreto <salvatore.loreto@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 09:56:28 -0000

2011/6/21 Salvatore Loreto <salvatore.loreto@ericsson.com>:
> my comment was about keeping the Sec-WebSocket-Version header.

I agree.

> What number (and format) should be put there at the end, in the final RFC=
,
> it is a different story.

What I mean is that, IMHO, it should be "1.0" (or whatever other
agreed value) from now until the draft becomes an RFC, rather than
incrementing such a value in each draft technical modification.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From tyoshino@google.com  Tue Jun 21 04:02:18 2011
Return-Path: <tyoshino@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69B1A11E80C1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 04:02:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.569
X-Spam-Level: 
X-Spam-Status: No, score=-105.569 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptGx+nlVrnOn for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 04:02:17 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A456411E807C for <hybi@ietf.org>; Tue, 21 Jun 2011 04:02:17 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p5LB2GIU031256 for <hybi@ietf.org>; Tue, 21 Jun 2011 04:02:16 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308654136; bh=0QqNjS1xY6Kt5FntR23r6ZG/q2U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iTNIyJ+8JOWnNzHqTpf3t6GleeNHBWTFcCKvm17Vlzse9+G+j45D5LNg9f4gKDP62 SETyGnmpvt4U/KbkxvE7A==
Received: from gye5 (gye5.prod.google.com [10.243.50.5]) by wpaz33.hot.corp.google.com with ESMTP id p5LB2FdU024732 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 04:02:15 -0700
Received: by gye5 with SMTP id 5so2420828gye.15 for <hybi@ietf.org>; Tue, 21 Jun 2011 04:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=24DTqg5E2Qsnxj38fkcyLJ51qbWQ8spTAYJ3uiU1qxQ=; b=Dph74dR1FWCNlQ+fx3EgJ3Ts5XZMUMzHG3/VU5cRdmTIGggREVRSbr4cGpKmA7/m+0 42pwyQMq2Hqf0YWPwteg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Hr8miJJ5s4mCtCT2JoOOrkLi4JmkxvA+pJXO1OOoFFJK5xfT2/kFKbNkAQrRPs9aZ6 Iq1y/cyJu2Z4swJ/g9mA==
Received: by 10.151.60.17 with SMTP id n17mr1384561ybk.342.1308654134993; Tue, 21 Jun 2011 04:02:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.50.13 with HTTP; Tue, 21 Jun 2011 04:01:54 -0700 (PDT)
In-Reply-To: <BANLkTi=ajW-bkr7OuXWhU12qSHs7m4hFzQ@mail.gmail.com>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com> <BANLkTi=ajW-bkr7OuXWhU12qSHs7m4hFzQ@mail.gmail.com>
From: Takeshi Yoshino <tyoshino@google.com>
Date: Tue, 21 Jun 2011 20:01:54 +0900
Message-ID: <BANLkTi=igdtepNewwhk6F_Hro740Ye0ztbZzAGLgYL5NoWg1AQ@mail.gmail.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=000325553b56d9a32f04a636c8a9
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 11:02:18 -0000

--000325553b56d9a32f04a636c8a9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi

I think we should keep subprotocol negotiation optional to allow user who i=
s
not interested in subprotocol to exclude it.
I would
- allow absence of "Sec-WebSocket-Protocol" from client to server
- give it meaning of "client won't use opening handshake's subprotocol
negotiation"

As I listed in this thread
http://www.ietf.org/mail-archive/web/hybi/current/msg07448.html some of
endpoint behavior are still a bit under-specified.

As I=F1aki noted, subprotocol negotiation can also be done over application
layer. The only benefit of subprotocol field in the opening handshake is
that we can finish subprotocol negotiation in the first round-trip time (in
an extreme case, this can also be done by embedding subprotocol choice in
URL string and replying by the first frame from server).

On Mon, Jun 20, 2011 at 00:14, I=F1aki Baz Castillo <ibc@aliax.net> wrote:

> 2011/6/17 Dan Adkins <dadkins@google.com>:
> > So, we know what the server MUST do if the server supports multiple
> > subprotocols.  But what if the client didn't include that field?  Is
>

That's not well specified yet. The following sentence in 5.2.2 seems to be
implying that if the server supports multiple subprotocols, the client must
send Sec-WebSocket-Protocol.

       /subprotocol/
          Either a single value or null, representing the subprotocol
          the server is ready to use.  If the server supports multiple
          subprotocols, then the value MUST be derived from the client's
          handshake, specifically by selecting one of the values from
          the "Sec-WebSocket-Protocol" field.  The absence of such a
          field is equivalent to the null value.  The empty string is


> > the server free to respond with the protocol of its choice?  That
> > seems strange that the server would be allowed to say to the client,
> > "we're speaking this protocol, like it or not," as the client has no
> > opportunity to respond.
>

I think the server would
- reject the connection or
- speak some pre-specified default subprotocol (but doesn't send out
"Sec-WebSocket-Protocol")

It's up to the design of the application.


> > Maybe I'm reading too much into this, but it does seem like there's a
> > bit of a hole in the spec as I can't find the answer to my original
> > question: if the client doesn't specify a subprotocol, can the server
> > dictate one?
>

That's not well specified yet.

--000325553b56d9a32f04a636c8a9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi<div><br></div><div>I think we should keep subprotocol negotiation option=
al to allow user who is not interested in subprotocol to exclude it.</div><=
div><div>I would</div><div>- allow absence of &quot;Sec-WebSocket-Protocol&=
quot; from client to server</div>

<div>- give it meaning of &quot;client won&#39;t use opening handshake&#39;=
s subprotocol negotiation&quot;</div></div><div><br></div><div>As I listed =
in this thread=A0<a href=3D"http://www.ietf.org/mail-archive/web/hybi/curre=
nt/msg07448.html">http://www.ietf.org/mail-archive/web/hybi/current/msg0744=
8.html</a>=A0some of endpoint behavior are still a bit under-specified.</di=
v>

<div><br></div><div>As I=F1aki noted, subprotocol negotiation can also be d=
one over application layer. The only benefit of subprotocol field in the op=
ening handshake is that we can finish subprotocol negotiation in the first =
round-trip time (in an extreme case, this can also be done=A0by embedding s=
ubprotocol choice in URL string and replying by the first frame from server=
).</div>

<div><br></div><div>On Mon, Jun 20, 2011 at 00:14, I=F1aki Baz Castillo <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;</=
span> wrote:</div><div><div class=3D"gmail_quote"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex;">

2011/6/17 Dan Adkins &lt;<a href=3D"mailto:dadkins@google.com">dadkins@goog=
le.com</a>&gt;:<br>
<div class=3D"im">&gt; So, we know what the server MUST do if the server su=
pports multiple<br>
&gt; subprotocols. =A0But what if the client didn&#39;t include that field?=
 =A0Is<br></div></blockquote><div><br></div><div><div>That&#39;s not well s=
pecified yet. The following sentence in 5.2.2 seems to be implying that if =
the server supports multiple subprotocols, the client must send Sec-WebSock=
et-Protocol.</div>

<div><br></div><div><div>=A0 =A0 =A0 =A0/subprotocol/</div><div>=A0 =A0 =A0=
 =A0 =A0 Either a single value or null, representing the subprotocol</div><=
div>=A0 =A0 =A0 =A0 =A0 the server is ready to use. =A0If the server suppor=
ts multiple</div><div>=A0 =A0 =A0 =A0 =A0 subprotocols, then the value MUST=
 be derived from the client&#39;s</div>

<div>=A0 =A0 =A0 =A0 =A0 handshake, specifically by selecting one of the va=
lues from</div><div>=A0 =A0 =A0 =A0 =A0 the &quot;Sec-WebSocket-Protocol&qu=
ot; field. =A0The absence of such a</div><div>=A0 =A0 =A0 =A0 =A0 field is =
equivalent to the null value. =A0The empty string is</div>

</div></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im"=
>
&gt; the server free to respond with the protocol of its choice? =A0That<br=
>
&gt; seems strange that the server would be allowed to say to the client,<b=
r>
&gt; &quot;we&#39;re speaking this protocol, like it or not,&quot; as the c=
lient has no<br>
&gt; opportunity to respond.<br></div></blockquote><div><br></div><div>I th=
ink the server would</div><div>- reject the connection or</div><div>- speak=
 some pre-specified default subprotocol (but doesn&#39;t send out &quot;Sec=
-WebSocket-Protocol&quot;)</div>

<div><br></div><div>It&#39;s up to the design of the application.</div><div=
>=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bord=
er-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">&gt; Maybe I&#3=
9;m reading too much into this, but it does seem like there&#39;s a<br>


&gt; bit of a hole in the spec as I can&#39;t find the answer to my origina=
l<br>
&gt; question: if the client doesn&#39;t specify a subprotocol, can the ser=
ver<br>
&gt; dictate one?<br></div></blockquote><div><br></div><div><div>That&#39;s=
 not well specified yet.</div></div><div><br></div></div></div>

--000325553b56d9a32f04a636c8a9--

From ibc@aliax.net  Tue Jun 21 04:47:48 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1FFA11E808D for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 04:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFEuxgcV1w2m for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 04:47:48 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0BD0311E807C for <hybi@ietf.org>; Tue, 21 Jun 2011 04:47:47 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2450706qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 04:47:31 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr4844848qcq.230.1308656850849; Tue, 21 Jun 2011 04:47:30 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 04:47:30 -0700 (PDT)
In-Reply-To: <BANLkTi=igdtepNewwhk6F_Hro740Ye0ztbZzAGLgYL5NoWg1AQ@mail.gmail.com>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com> <BANLkTi=ajW-bkr7OuXWhU12qSHs7m4hFzQ@mail.gmail.com> <BANLkTi=igdtepNewwhk6F_Hro740Ye0ztbZzAGLgYL5NoWg1AQ@mail.gmail.com>
Date: Tue, 21 Jun 2011 13:47:30 +0200
Message-ID: <BANLkTi=MzK_L1UZY1B3twP5pENbnAsgL-Q@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Takeshi Yoshino <tyoshino@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 11:47:48 -0000

2011/6/21 Takeshi Yoshino <tyoshino@google.com>:
> As I=C3=B1aki noted, subprotocol negotiation can also be done over applic=
ation
> layer. The only benefit of subprotocol field in the opening handshake is
> that we can finish subprotocol negotiation in the first round-trip time (=
in
> an extreme case, this can also be done=C2=A0by embedding subprotocol choi=
ce in
> URL string and replying by the first frame from server).

In fact, if Sec-WebSocket-Protocol header was not exist, I expect
nobody would miss it. WebSocket services will be served by providers
also providing the JavaScript code. Maybe a webpage includes a
JavaScript code to connect to a chat and other code to connect to a
like-RSS system. Webdevelopers will just enable two different WS URI
(ws://mydomain.org/chat and ws://mydomain.org/rss) and the JavaScript
client will just connect to each one. No need of negotiation.

Honestly I don't see the benefict of standarizing or negotiating
subprotocols on top of WebSocket. Or maybe what I want to say is that
I don't believe it will succeed (as web developers are anarchic by
nature and they want to know exacty *nothing* about standars,
protocols, IANA registry names and so on).

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From salvatore.loreto@ericsson.com  Tue Jun 21 05:20:34 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D10711E80A5 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level: 
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6noTFZlinmdY for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:20:34 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3943811E808D for <hybi@ietf.org>; Tue, 21 Jun 2011 05:20:33 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-cd-4e008c90952f
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C7.DD.20773.09C800E4; Tue, 21 Jun 2011 14:20:32 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Tue, 21 Jun 2011 14:20:31 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id B2C6724D8	for <hybi@ietf.org>; Tue, 21 Jun 2011 15:20:31 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 726ED50EBE	for <hybi@ietf.org>; Tue, 21 Jun 2011 15:20:31 +0300 (EEST)
Received: from n211.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2EFC250DE8	for <hybi@ietf.org>; Tue, 21 Jun 2011 15:20:31 +0300 (EEST)
Message-ID: <4E008C8F.1010707@ericsson.com>
Date: Tue, 21 Jun 2011 15:20:31 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com>
In-Reply-To: <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060004030006080909030305"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 12:20:34 -0000

--------------060004030006080909030305
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit

On 6/17/11 11:07 PM, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
>
>
>     Section 11.12 says that assignment of WebSocket Version Numbers
>     shall be
>     "RFC Required", but then requests assignment of version numbers 0-8 to
>     prior submissions of this Internet-Draft. The requested
>     assignments are
>     at odds with the stated policy.
>
>
> RFC Required is different from Standards Action. RFC Publication 
> (either as an IETF submission or as an RFC editor independent 
> submission) suffices. Standards Action requires Standards Track RFCs 
> approved by the IESG. My understanding from this as that an I-D counts 
> as an IETF submission?

not completely sure...
Peter what do you think?

--------------060004030006080909030305
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: 8bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 6/17/11 11:07 PM, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
    <blockquote
      cite="mid:BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com"
      type="cite">
      <blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex;
        border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
        <br>
        Section 11.12 says that assignment of WebSocket Version Numbers
        shall be<br>
        "RFC Required", but then requests assignment of version numbers
        0-8 to<br>
        prior submissions of this Internet-Draft. The requested
        assignments are<br>
        at odds with the stated policy.<br>
      </blockquote>
      <div><br>
      </div>
      <div>RFC Required is different from Standards Action. RFC
        Publication (either as an IETF submission or as an RFC editor
        independent submission) suffices. Standards Action requires
        Standards Track RFCs approved by the IESG. My understanding from
        this as that an I-D counts as an IETF submission?</div>
    </blockquote>
    <br>
    not completely sure... <br>
    Peter what do you think?<br>
  </body>
</html>

--------------060004030006080909030305--

From dave@cridland.net  Tue Jun 21 05:30:33 2011
Return-Path: <dave@cridland.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF0A211E807A for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.197
X-Spam-Level: 
X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.102,  BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+tCvQ1us1I0 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:30:33 -0700 (PDT)
Received: from peirce.dave.cridland.net (peirce.dave.cridland.net [IPv6:2001:470:1f09:882:2e0:81ff:fe29:d16a]) by ietfa.amsl.com (Postfix) with ESMTP id E20A311E8079 for <hybi@ietf.org>; Tue, 21 Jun 2011 05:30:32 -0700 (PDT)
Received: from localhost (peirce.dave.cridland.net [127.0.0.1]) by peirce.dave.cridland.net (Postfix) with ESMTP id 6221D1168087; Tue, 21 Jun 2011 13:30:29 +0100 (BST)
X-Virus-Scanned: Debian amavisd-new at peirce.dave.cridland.net
Received: from peirce.dave.cridland.net ([127.0.0.1]) by localhost (peirce.dave.cridland.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFiouRMHu5v6; Tue, 21 Jun 2011 13:30:26 +0100 (BST)
Received: from puncture (puncture.dave.cridland.net [IPv6:2001:470:1f09:882:221:85ff:fe3f:1696]) by peirce.dave.cridland.net (Postfix) with ESMTPA id 5018F1168067; Tue, 21 Jun 2011 13:30:26 +0100 (BST)
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com>
In-Reply-To: <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com>
MIME-Version: 1.0
Message-Id: <4898.1308659426.327742@puncture>
Date: Tue, 21 Jun 2011 13:30:26 +0100
From: Dave Cridland <dave@cridland.net>
To: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>, Server-Initiated HTTP <hybi@ietf.org>, Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; delsp="yes"; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8Bit
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 12:30:33 -0000

On Fri Jun 17 21:07:22 2011, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£)  
wrote:
> On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre  
> <stpeter@stpeter.im>wrote:
> > Section 11.12 says that assignment of WebSocket Version Numbers  
> shall be
> > "RFC Required", but then requests assignment of version numbers  
> 0-8 to
> > prior submissions of this Internet-Draft. The requested  
> assignments are
> > at odds with the stated policy.
> >
> 
> RFC Required is different from Standards Action. RFC Publication  
> (either as
> an IETF submission or as an RFC editor independent submission)  
> suffices.
> Standards Action requires Standards Track RFCs approved by the  
> IESG. My
> understanding from this as that an I-D counts as an IETF submission?

Yes, but it only counts as an RFC once it's published...

The solution is to assign these to this document, but note in this  
section that versions 1-8 are older versions.

One might even ask IANA to maintain a note saying that, when creating  
the registry.

That all said, it's not clear to me this really needs a registry, or  
why one might want to allow independant stream RFCs to define a new  
version number - that effectively means that the next version of  
WebSockets might not be an IETF protocol at all. In contrast with the  
other registries - which seem reasonable - allowing random people to  
invent new and conflicting versions seems like a recipe for chaos.

I'd have thought that we want standards-track here, and in any case,  
the version numbers would be handled by Obsoletes/Updates perfectly  
well.

Am I missing something?

Dave.
-- 
Dave Cridland - mailto:dave@cridland.net - xmpp:dwd@dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

From ibc@aliax.net  Tue Jun 21 05:53:47 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E67811E8083 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=0.016,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EjfME9qZR+2N for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6794411E8078 for <hybi@ietf.org>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2123781qwc.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 05:53:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr4986298qce.192.1308660825773; Tue, 21 Jun 2011 05:53:45 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 05:53:45 -0700 (PDT)
In-Reply-To: <4898.1308659426.327742@puncture>
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com> <4898.1308659426.327742@puncture>
Date: Tue, 21 Jun 2011 14:53:45 +0200
Message-ID: <BANLkTinEc5o3D=GeUvQ_wQEn+PmgOm+0wQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Dave Cridland <dave@cridland.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 12:53:47 -0000

2011/6/21 Dave Cridland <dave@cridland.net>:
> That all said, it's not clear to me this really needs a registry, or why =
one
> might want to allow independant stream RFCs to define a new version numbe=
r -
> that effectively means that the next version of WebSockets might not be a=
n
> IETF protocol at all. In contrast with the other registries - which seem
> reasonable - allowing random people to invent new and conflicting version=
s
> seems like a recipe for chaos.

I agree. WebSocket draft/RFC should registry an unique protocol
version (i.e. "1.0"). If a future extension is created, it should not
involve a new protocol version, but instead a like "Require" mechanism
within the core protocol so a client or a server can require an
extension and, if the other party supports it use it, if not, fail the
connection with the appropiated mechanism (i.e: "extension not
supported"). The protocol version cannot change for each new
extension.

For example, in SIP protocol (whose version is "2.0" and that's all)
there are "Require" and "Supported" headers. If a client sends a
request with "Require: xxxxxx" and the server does not support it, the
server replies 420 "Bad Extension":

   http://tools.ietf.org/html/rfc3261#section-21.4.15

Such mechanism is already defined in SIP 2.0, so increasing the
protocol version number is never required.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From gregw@intalio.com  Tue Jun 21 06:00:36 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7511E80C1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:00:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.722
X-Spam-Level: 
X-Spam-Status: No, score=-2.722 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1onOY5Ox9ljM for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:00:35 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8E44C11E8083 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:00:35 -0700 (PDT)
Received: by vws12 with SMTP id 12so1606488vws.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:00:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.76.4 with SMTP id g4mr5385300vdw.278.1308661234879; Tue, 21 Jun 2011 06:00:34 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Tue, 21 Jun 2011 06:00:34 -0700 (PDT)
In-Reply-To: <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com> <4E00569E.4030400@ericsson.com> <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com>
Date: Tue, 21 Jun 2011 23:00:34 +1000
Message-ID: <BANLkTikhrkKjCbxJMuXLUMXSnXFmJ_2jjg@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:00:36 -0000

On 21 June 2011 19:04, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
> IMHO this WG is becoming to much "special"

Well there is something a bit special about this protocol.

We are encouraged to put draft implementations out into the wild so
that we can get some wider experience and feedback (working code
etc.).  But to do this means that the draft protocol is enabled in
browsers that are widely distributed, but also have a wide range of
update policies. It is not uncommon for a browser not to be updated
for many years, or put on a mobile device and never updated.

The result is that draft versions implemented are likely to be in
circulation for a long time.

Having the draft version in the handshake has proven a very workable
solution that prevents the heuristic version determination that was
previously necessary.  Is there any alternative solution?

From gezelter@rlgsc.com  Tue Jun 21 06:10:50 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BFDD11E80B1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.67
X-Spam-Level: 
X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1LH7qWd2-PB for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:10:49 -0700 (PDT)
Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 6925711E808D for <hybi@ietf.org>; Tue, 21 Jun 2011 06:10:49 -0700 (PDT)
Received: (qmail 28147 invoked from network); 21 Jun 2011 13:10:37 -0000
Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 21 Jun 2011 13:10:37 -0000
Received: (qmail 2628 invoked by uid 99); 21 Jun 2011 13:10:37 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 162.83.149.110
User-Agent: Web-Based Email 5.5.05
Message-Id: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Tue, 21 Jun 2011 06:10:36 -0700
Mime-Version: 1.0
Subject: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:10:50 -0000

I?aki, Julian, Salvatore, and all,

Some may consider version number information an anti-pattern, but I
believe that this belief is misplaced.

Version numbering becomes a problem when it is a stalking horse for poor
design and very incompatible dialects. It is these fundamental
incompatibilities that are the true anti-pattern. Properly implemented
version number identification is an important tool for troubleshooting
problems caused by the need to maintain backward compatible operations
with a wide collection of client and server systems, who almost
certainly cannot be upgraded on a synchronized schedule.

Indeed, systems that externally implement version number based
restrictions experience far fewer problems than systems without such
checks.

I would suggest that the final accepted RFC use a major/minor revision
scheme of 1.0. A future RFC would have a revision number of 2.0.
Intermediate drafts would have a minor version increment (e.g., 1.1,
1.2, ...).

- Bob Gezelter, http://www.rlgsc.com


From phil127@gmail.com  Tue Jun 21 06:11:18 2011
Return-Path: <phil127@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53CA511E8113 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:11:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.449
X-Spam-Level: 
X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QrP5ieFTak4 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:11:17 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90B0811E8111 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:11:17 -0700 (PDT)
Received: by wwe5 with SMTP id 5so2411436wwe.13 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:11:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=XujMmXul7PFh9GyQheTZlEePQakDE1Zo8TkfFAJM/Ts=; b=tO0e9CVy34sLVmBMGw8TdQ3fcOOMQ/7AvXGtkgmF3HYQh1av/qZRTP32SOfXEmy8X2 gw1zLzyiVcvY3EIqYQwSZAMV78mrxojejYvSKSyEvfO9PDHZh7zmxq7LmMHUcISTsk+M 2B0HNKtWGAfiYorjDyW502TRPi58MqDqKuWYw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=Urh3POyewOMJygNOAlzulrKMkcEZc1ExC1gkPHSD4v/+or0YKtXIgoFoyPyiP1TU+n IOjMWO5zYaAvrdSl7nl+IwJD2SasZ3svFMc2YvJAeX2W0F1OhiBR3tn2DVCVws3uv7A/ IGR9EBshgq5Py/5hKbXB6RQlCDfhc2Hxpezh0=
Received: by 10.227.55.7 with SMTP id s7mr4847895wbg.65.1308661869423; Tue, 21 Jun 2011 06:11:09 -0700 (PDT)
Received: from [212.201.79.69] (pptp-212-201-79-69.pptp.stw-bonn.de [212.201.79.69]) by mx.google.com with ESMTPS id m8sm3995029wbh.28.2011.06.21.06.11.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2011 06:11:08 -0700 (PDT)
Message-ID: <4E00985E.9060301@gmail.com>
Date: Tue, 21 Jun 2011 15:10:54 +0200
From: Philipp Serafin <phil127@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>	<BANLkTi=ajW-bkr7OuXWhU12qSHs7m4hFzQ@mail.gmail.com>	<BANLkTi=igdtepNewwhk6F_Hro740Ye0ztbZzAGLgYL5NoWg1AQ@mail.gmail.com> <BANLkTi=MzK_L1UZY1B3twP5pENbnAsgL-Q@mail.gmail.com>
In-Reply-To: <BANLkTi=MzK_L1UZY1B3twP5pENbnAsgL-Q@mail.gmail.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:11:18 -0000

Am 21.06.2011 13:47, schrieb IÃ±aki Baz Castillo:
> In fact, if Sec-WebSocket-Protocol header was not exist, I expect
> nobody would miss it. WebSocket services will be served by providers
> also providing the JavaScript code. Maybe a webpage includes a
> JavaScript code to connect to a chat and other code to connect to a
> like-RSS system. Webdevelopers will just enable two different WS URI
> (ws://mydomain.org/chat and ws://mydomain.org/rss) and the JavaScript
> client will just connect to each one. No need of negotiation.
>
> Honestly I don't see the benefict of standarizing or negotiating
> subprotocols on top of WebSocket. Or maybe what I want to say is that
> I don't believe it will succeed (as web developers are anarchic by
> nature and they want to know exacty *nothing* about standars,
> protocols, IANA registry names and so on).
Wasn't the whole idea of WS sub-protocols that they are *not* maintained
by IANA or any other registry?

I agree that registration would be a burden that very few non-evangelist
web developers would take on for an arguably very small benefit.
However, if developers are allowed to use their own names "ad-hoc" (and
hopefully adhering to some kind of namespacing scheme), I believe this
could be very useful for frameworks and standardized web APIs developed
on top of WS - think of "OAuth-over-WS", "OpenID-over-WS" or
"XMPP-over-WS".

I believe there are strong use-cases for both using WS with sub
protocols and without, so both should be possible.

Regards,
Philipp Serafin

From ibc@aliax.net  Tue Jun 21 06:15:53 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6878311E80C1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:15:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level: 
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCX-F57jkQ1R for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:15:52 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0B811E808D for <hybi@ietf.org>; Tue, 21 Jun 2011 06:15:52 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2521115qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:15:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr5011193qce.192.1308662150171; Tue, 21 Jun 2011 06:15:50 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 06:15:50 -0700 (PDT)
In-Reply-To: <BANLkTikhrkKjCbxJMuXLUMXSnXFmJ_2jjg@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com> <4E00569E.4030400@ericsson.com> <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com> <BANLkTikhrkKjCbxJMuXLUMXSnXFmJ_2jjg@mail.gmail.com>
Date: Tue, 21 Jun 2011 15:15:50 +0200
Message-ID: <BANLkTik1qS=HS887b6DKPzCr-fEKZvv_jw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:15:53 -0000

2011/6/21 Greg Wilkins <gregw@intalio.com>:
> Having the draft version in the handshake has proven a very workable
> solution that prevents the heuristic version determination that was
> previously necessary. =C2=A0Is there any alternative solution?

Having experimental working implementations in order to improve a spec
or detect/fix issues is great. Relying on such implementations is not
so great, even less when you are talking about widely extended web
browsers. In other words, I don't consider "polite" to experiment with
the rest of the world just to realize of issues in a no mature
specification (which is still a draft).

IMHO browser vendors could provide an experimental version with
WebSocket support so developers and people in this WG can test it
against the current specification. Ok, there it could make sense a
*temporal* header like "X-WebSocket-TMP-Version". But such
version/revision value should have no relationship with the final
protocol version (i.e. "1.0") which will be submitted to the IETF.
This is, don't mix experiments with the final spec.

Just my opinion. Regards.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Tue Jun 21 06:19:47 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E536611E80C1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:19:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level: 
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw2xHjpFu4dn for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:19:47 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFB911E8083 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:19:47 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2524569qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:19:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr5082459qca.154.1308662386796; Tue, 21 Jun 2011 06:19:46 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 06:19:46 -0700 (PDT)
In-Reply-To: <4E00985E.9060301@gmail.com>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com> <BANLkTi=ajW-bkr7OuXWhU12qSHs7m4hFzQ@mail.gmail.com> <BANLkTi=igdtepNewwhk6F_Hro740Ye0ztbZzAGLgYL5NoWg1AQ@mail.gmail.com> <BANLkTi=MzK_L1UZY1B3twP5pENbnAsgL-Q@mail.gmail.com> <4E00985E.9060301@gmail.com>
Date: Tue, 21 Jun 2011 15:19:46 +0200
Message-ID: <BANLkTimzZ5psGpn0MwWJr2pqoTfrFmYzjA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Philipp Serafin <phil127@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:19:48 -0000

2011/6/21 Philipp Serafin <phil127@gmail.com>:
> I believe there are strong use-cases for both using WS with sub
> protocols and without, so both should be possible.

Then the spec should improve *a lot* the usage case of the
Sec-WebSocket-Subprotocol header (i.e. what happens when the HTTP
handshake request does not contain such a header?).

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From mcmanus@ducksong.com  Tue Jun 21 06:25:22 2011
Return-Path: <mcmanus@ducksong.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476D721F843F for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:25:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uz5OlyjmqmLz for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:25:21 -0700 (PDT)
Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4C421F843D for <hybi@ietf.org>; Tue, 21 Jun 2011 06:25:21 -0700 (PDT)
Received: by linode.ducksong.com (Postfix, from userid 1000) id 6E4E010193; Tue, 21 Jun 2011 09:25:19 -0400 (EDT)
Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 0AEA510154; Tue, 21 Jun 2011 09:25:15 -0400 (EDT)
From: Patrick McManus <mcmanus@ducksong.com>
To: =?ISO-8859-1?Q?I=F1aki?= Baz Castillo <ibc@aliax.net>
In-Reply-To: <BANLkTik1qS=HS887b6DKPzCr-fEKZvv_jw@mail.gmail.com>
References: <20110613233745.27187.94588.idtracker@ietfa.amsl.com> <BANLkTinWuzj3V12eerjX0f13yYNdynTOjQ@mail.gmail.com> <4E004D3D.3020305@it.aoyama.ac.jp> <BANLkTi=T2YLpH4U=qduv_qFZVO3EyLPAUw@mail.gmail.com> <4E00569E.4030400@ericsson.com> <BANLkTikm33-EQDaRwJM8yJ34QgmrxN7FgQ@mail.gmail.com> <BANLkTikhrkKjCbxJMuXLUMXSnXFmJ_2jjg@mail.gmail.com> <BANLkTik1qS=HS887b6DKPzCr-fEKZvv_jw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 21 Jun 2011 09:25:09 -0400
Message-ID: <1308662709.1944.278.camel@ds9>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.2 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-09.txt
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:25:22 -0000

It is likely that firefox 6 will be shipped with a websockets -09
implementation with the API prefixed under Moz*.

Hopefully Firefox 7 will be shipped with -09 under the normal WebSocket
namespace - we're waiting for the binary issue with the API to be fully
sorted out. That depends on what happens on the JS side of the fence.

On Tue, 2011-06-21 at 15:15 +0200, IÃ±aki Baz Castillo wrote:
> 2011/6/21 Greg Wilkins <gregw@intalio.com>:
> > Having the draft version in the handshake has proven a very workable
> > solution that prevents the heuristic version determination that was
> > previously necessary.  Is there any alternative solution?
> 
> Having experimental working implementations in order to improve a spec
> or detect/fix issues is great. Relying on such implementations is not
> so great, even less when you are talking about widely extended web
> browsers. In other words, I don't consider "polite" to experiment with
> the rest of the world just to realize of issues in a no mature
> specification (which is still a draft).
> 
> IMHO browser vendors could provide an experimental version with
> WebSocket support so developers and people in this WG can test it
> against the current specification. Ok, there it could make sense a
> *temporal* header like "X-WebSocket-TMP-Version". But such
> version/revision value should have no relationship with the final
> protocol version (i.e. "1.0") which will be submitted to the IETF.
> This is, don't mix experiments with the final spec.
> 
> Just my opinion. Regards.
> 
> 
> 



From ibc@aliax.net  Tue Jun 21 06:41:34 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B9511E80C1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level: 
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPBmGZSN3DTz for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:41:34 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D2BB111E8078 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:41:33 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2163437qwc.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:41:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr5106885qca.154.1308663693321; Tue, 21 Jun 2011 06:41:33 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 06:41:33 -0700 (PDT)
In-Reply-To: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net>
References: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net>
Date: Tue, 21 Jun 2011 15:41:33 +0200
Message-ID: <BANLkTimWWfsZQqJDaJ3J8PWh+qGDLLktQA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Bob Gezelter <gezelter@rlgsc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:41:34 -0000

2011/6/21 Bob Gezelter <gezelter@rlgsc.com>:
> I would suggest that the final accepted RFC use a major/minor revision
> scheme of 1.0. A future RFC would have a revision number of 2.0.
> Intermediate drafts would have a minor version increment (e.g., 1.1,
> 1.2, ...).

When you say "a future RFC would have a revision number of 2.0" I hope
you are talking after not less than 10 years ;)

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Tue Jun 21 06:43:07 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE7B11E8092 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.662
X-Spam-Level: 
X-Spam-Status: No, score=-2.662 tagged_above=-999 required=5 tests=[AWL=0.015,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKILiPvwCr4X for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:43:06 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8DD8911E8113 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:43:06 -0700 (PDT)
Received: by qwc23 with SMTP id 23so2164669qwc.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 06:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr5108639qca.154.1308663785620; Tue, 21 Jun 2011 06:43:05 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 06:43:05 -0700 (PDT)
In-Reply-To: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com>
Date: Tue, 21 Jun 2011 15:43:05 +0200
Message-ID: <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:43:07 -0000

Hi, any comment about this please? IMHO this topic is important. If
I'm wrong I would like to know it :)


2011/6/20 I=C3=B1aki Baz Castillo <ibc@aliax.net>:
> Hi, I would like to start a new thread for this topic as it seems that
> the draft does not cover it at all (just suggests that an HTTP
> response code other than 101 should be threated as RFC 2616 states:
>
>
> =C2=A0"1. =C2=A0If the status code received from the server is not 101, t=
he
> =C2=A0 =C2=A0 =C2=A0 =C2=A0client handles the response per HTTP procedure=
s." (p. 30)
>
>
> The question is: should the browser prompt the human user for
> user/pass as when a 401 is received in the WS handshake attemp?
>
> Imagine this case:
>
> - www.domain.org =3D> 1.1.1.1:80
>
> - ws.domain.org =3D> 1.1.1.2:443
>
> - I open http://www.domain.org in my browser, fill some login form and
> retrieve websocket connection data, including an user and pass (for
> Digest).
>
> - My JavaScript is then provisioned (via JavaScript WebSocket API
> ????) with ws connection data: server ip, port, Digest user/passwd.
>
> - My web browser starts the ws connection with ws.domain.org:443. It
> receives 401 with Digest (so I need a nonce from the server before
> using my user/passwd).
>
> - JavaScript code automatically accepts the Digest chanllenge,
> generates a Digest response with the provided user/passwd and the
> retrieved Digest nonce, and re-send the HTTP GET request (all of this
> without prompting the user) with the Authorization header.
>
> - If the JavaScript code would not be proviosioned with user/pass,
> then upon receipt of the 401 it should prompt the user (like a
> JavaScript alert?).
>
>
>
> So, if all this stuff is not clearly specified (and I think passing
> user/pass to the JavaScript WebSocket connection API does not exist)
> then using HTTP Digest (or Basic) will be not useful or feasible, and
> I expect than using cookies and all that "pure just-web stuff" will be
> the only way. Please, take into account that a websocket server could
> run in a separate server, so using cookies mechanism is not so
> feasible (it could or not depending the case). Neither I think that
> cookies (a workaround to simulate
> sessions in HTTP protocol) are the best way to go.
>
> IMHO the draft should do much more effort in authentication process.
> Please don't let the door open to ugly and/or propietary
> authentication solutions.
>
>
> My proposal is that the JavaScript WebSocket API should include a
> method to pass authentication 'user' and 'password' (and optionally
> 'realm' so it would ignore the realm para in the 401 response when
> using Digest rather than Basic auth).
>
> In this way, I could open a webpage, perform usual login (maybe via a
> HTML form as commonly extended) and then retrieve WS connection data
> (WS URI), including user/pass/[realm].
> So my JavaScript client would open a WS connection with the given
> destination and in case of receiving a 401 it would re-send the HTTP
> GET request with the appropriate Authorization header without
> prompting the user.
>
> This wouldn't be the only authentication mechanism, of course, but
> IMHO it should be documented (and covered by the JS WebSocket API).
>
> Regards.
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From stpeter@stpeter.im  Tue Jun 21 06:56:19 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DF9D11E8125 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.239
X-Spam-Level: 
X-Spam-Status: No, score=-102.239 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ISLbVJmNjC74 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 06:56:18 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CF6DC11E80AE for <hybi@ietf.org>; Tue, 21 Jun 2011 06:56:18 -0700 (PDT)
Received: from squire.local (dsl-179-111.dynamic-dsl.frii.net [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6AA06400F9; Tue, 21 Jun 2011 07:56:55 -0600 (MDT)
Message-ID: <4E00A2FE.8010601@stpeter.im>
Date: Tue, 21 Jun 2011 07:56:14 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bob Gezelter <gezelter@rlgsc.com>
References: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net>
In-Reply-To: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms050006040501050106030905"
Cc: hybi@ietf.org
Subject: Re: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 13:56:19 -0000

This is a cryptographically signed message in MIME format.

--------------ms050006040501050106030905
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/21/11 7:10 AM, Bob Gezelter wrote:
> I?aki, Julian, Salvatore, and all,
>=20
> Some may consider version number information an anti-pattern, but I
> believe that this belief is misplaced.
>=20
> Version numbering becomes a problem when it is a stalking horse for poo=
r
> design and very incompatible dialects. It is these fundamental
> incompatibilities that are the true anti-pattern. Properly implemented
> version number identification is an important tool for troubleshooting
> problems caused by the need to maintain backward compatible operations
> with a wide collection of client and server systems, who almost
> certainly cannot be upgraded on a synchronized schedule.
>=20
> Indeed, systems that externally implement version number based
> restrictions experience far fewer problems than systems without such
> checks.
>=20
> I would suggest that the final accepted RFC use a major/minor revision
> scheme of 1.0. A future RFC would have a revision number of 2.0.
> Intermediate drafts would have a minor version increment (e.g., 1.1,
> 1.2, ...).

Once again I recommend borrowing from the text in RFC 6120 if
appropriate, see Section 4.7.5...

###

   The numbering scheme for XMPP versions is "<major>.<minor>".  The
   major and minor numbers MUST be treated as separate integers and each
   number MAY be incremented higher than a single digit.  Thus, "XMPP
   2.4" would be a lower version than "XMPP 2.13", which in turn would
   be lower than "XMPP 12.3".  Leading zeros (e.g., "XMPP 6.01") MUST be
   ignored by recipients and MUST NOT be sent.

   The major version number will be incremented only if the stream and
   stanza formats or obligatory actions have changed so dramatically
   that an older version entity would not be able to interoperate with a
   newer version entity if it simply ignored the elements and attributes
   it did not understand and took the actions defined in the older
   specification.

   The minor version number will be incremented only if significant new
   capabilities have been added to the core protocol (e.g., a newly
   defined value of the 'type' attribute for message, presence, or IQ
   stanzas).  The minor version number MUST be ignored by an entity with
   a smaller minor version number, but MAY be used for informational
   purposes by the entity with the larger minor version number (e.g.,
   the entity with the larger minor version number would simply note
   that its correspondent would not be able to understand that value of
   the 'type' attribute and therefore would not send it).

###

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms050006040501050106030905
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYy
MTEzNTYxNFowIwYJKoZIhvcNAQkEMRYEFLSl3u5vTUldROdEAODyX/IKqiM5MF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQCvokzX+5bKURGXQIlWeHUFBIy1qSMgcXPQzrHSkrEMy5zS+/TFIUllpzNS
Zq60G/IsuwSP3scueHew4tJ/iwl2QnxWweu5agBRolJlYweF1C04WuLwL/MWN9yZtBzS5vtc
cQfG6Qu00b+BAJ23xI0DDl00aruL/FgvYvkh6tkUiUUOqY2PXZPzAnfEXOOJHQ3aT8qFn8fl
cLzUe0koLpoXmjXr0kLJEuadpCho05FjZt9YSznhfe0LqZxLJv/FoURpKWrdgxtfrX0izYZU
sgvzlkWU7irVgmWNp9dpuPR0Va2lfcaf7JXPf3VyzwUHTXVTyaxmjnwClkTqYtUUW9lQAAAA
AAAA
--------------ms050006040501050106030905--

From stpeter@stpeter.im  Tue Jun 21 10:45:25 2011
Return-Path: <stpeter@stpeter.im>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D941011E82C6 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 10:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.685
X-Spam-Level: 
X-Spam-Status: No, score=-102.685 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlW7euS1QoG1 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 10:45:25 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 286F411E808B for <hybi@ietf.org>; Tue, 21 Jun 2011 10:45:25 -0700 (PDT)
Received: from dhcp-64-101-72-207.cisco.com (dhcp-64-101-72-207.cisco.com [64.101.72.207]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 8511E40126; Tue, 21 Jun 2011 11:46:02 -0600 (MDT)
Message-ID: <4E00D8B2.6090409@stpeter.im>
Date: Tue, 21 Jun 2011 11:45:22 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: Dave Cridland <dave@cridland.net>
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com> <4898.1308659426.327742@puncture>
In-Reply-To: <4898.1308659426.327742@puncture>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080005080606030407020302"
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 17:45:26 -0000

This is a cryptographically signed message in MIME format.

--------------ms080005080606030407020302
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 6/21/11 6:30 AM, Dave Cridland wrote:
> On Fri Jun 17 21:07:22 2011, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=
=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote:
>> On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre
>> <stpeter@stpeter.im>wrote:
>> > Section 11.12 says that assignment of WebSocket Version Numbers
>> shall be
>> > "RFC Required", but then requests assignment of version numbers 0-8 =
to
>> > prior submissions of this Internet-Draft. The requested assignments =
are
>> > at odds with the stated policy.
>> >
>>
>> RFC Required is different from Standards Action. RFC Publication
>> (either as
>> an IETF submission or as an RFC editor independent submission) suffice=
s.
>> Standards Action requires Standards Track RFCs approved by the IESG. M=
y
>> understanding from this as that an I-D counts as an IETF submission?
>=20
> Yes, but it only counts as an RFC once it's published...
>=20
> The solution is to assign these to this document, but note in this
> section that versions 1-8 are older versions.
>=20
> One might even ask IANA to maintain a note saying that, when creating
> the registry.
>=20
> That all said, it's not clear to me this really needs a registry, or wh=
y
> one might want to allow independant stream RFCs to define a new version=

> number - that effectively means that the next version of WebSockets
> might not be an IETF protocol at all. In contrast with the other
> registries - which seem reasonable - allowing random people to invent
> new and conflicting versions seems like a recipe for chaos.
>=20
> I'd have thought that we want standards-track here, and in any case, th=
e
> version numbers would be handled by Obsoletes/Updates perfectly well.

Seems reasonable, yes.

Peter

--=20
Peter Saint-Andre
https://stpeter.im/




--------------ms080005080606030407020302
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITzjCC
BjQwggQcoAMCAQICASMwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoT
DVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNp
Z25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA3
MTAyNDIxMDMzM1oXDTE3MTAyNDIxMDMzM1owgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWdu
aW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENs
aWVudCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALmjSW4SPiDKlAinvVeL
ZOVfItiuP1aRHL530E7QUc9icCwL33+PH+Js1HAh8CgWFl34sOxx1FJyS/C4VLPRsqDfP72j
tzCVUAL0DAxZ7wgzQvFz7x61jGxfhYhqYb1+PPOLkYBbkRIrPMg3dLEdKmXIYJYXDH+mB/V/
jLo73/Kb7h/rNoNg/oHHSv5Jolyvp5IY2btfcTBfW/telEFj5rDTX2juTvZ3Qhf3XQX5ca3Q
7A10zrUV/cWJOJ7F5RltbEIaboZmX5JBUb3FhUiAdBotehAX6DbDOuYoJtVxmGof6GuVGcPo
98K4TJf8FHo+UA9EOVDp/W7fCqKT4sXk/XkCAwEAAaOCAa0wggGpMA8GA1UdEwEB/wQFMAMB
Af8wDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBR7iZySlyShhEcCy3T8LvSs3DLl8zAfBgNV
HSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu8jBmBggrBgEFBQcBAQRaMFgwJwYIKwYBBQUH
MAGGG2h0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9jYTAtBggrBgEFBQcwAoYhaHR0cDovL3d3
dy5zdGFydHNzbC5jb20vc2ZzY2EuY3J0MFsGA1UdHwRUMFIwJ6AloCOGIWh0dHA6Ly93d3cu
c3RhcnRzc2wuY29tL3Nmc2NhLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20v
c2ZzY2EuY3JsMIGABgNVHSAEeTB3MHUGCysGAQQBgbU3AQIBMGYwLgYIKwYBBQUHAgEWImh0
dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUHAgEWKGh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwDQYJKoZIhvcNAQELBQADggIBAGpd
SbdLFMhirxK37V4gE00+uW74UdAXtDgQI3AsRZWtaRtKHgAxFBSteqz4kDkeAjH/1b+K8tQR
6cxSI2nho7qOaPW/UpzOfSS/MeKK/9vfM2lfs+uItXH7LWtvS9wD1erfH1a+BXHCrCp4LA1l
fADDhRIiGTSS3i0Zu5xV3INNRHrCCCl6patltQ8RZTqzDMri7ombgIxjN51Zo7xV77EZcThV
0GA8iIN+7T53uHhUJpjfLIztHs/69OclRvHux9hCflfOm7GY5Sc4nqjfES+5XPArGGWiQSEk
ez37QfXqsxO3oCHK4b3DFZysG4uyOuC/WL80ab3muQ3tgwjBhq0D3JZN5kvu5gSuNZPa1WrV
hEgXkd6C7s5stqB6/htVpshG08jRz9DEutGM9oKQ1ncTivbfPNx7pILoHWvvT7N5i/puVoNu
bPUmLXh/2wA6wzAzuuoONiIL14Xpw6jLSnqpaLWElo2yTIFZ/CU/nCvvpW1Dj1457P3Ci9bD
0RPkWSR+CuucpgxrEmaw4UOLxflzuYYaq1RJwygOO5K0s2bAWOcXpgteyUOnQ3d/EjJAWRri
2v0ubiq+4H3KUOMlbznlPAY/1T8YyyJPM88+Ueahe/AW1zoUwZayNcTnuM7cq6yBV8Wr3GOI
LFXhtT0UVuJLChPMJKVKVsa7qNorlLkMMIIGxzCCBa+gAwIBAgICAIswDQYJKoZIhvcNAQEF
BQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJT
ZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBD
bGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAeFw0xMDEwMTQwMTM2MzRa
Fw0xMjEwMTQxMjAxMDdaMIHAMSAwHgYDVQQNExcyNzQ1ODEtOU5YMDRxeExEYjBvNDY5VDEL
MAkGA1UEBhMCVVMxETAPBgNVBAgTCENvbG9yYWRvMQ8wDQYDVQQHEwZEZW52ZXIxLDAqBgNV
BAsTI1N0YXJ0Q29tIFRydXN0ZWQgQ2VydGlmaWNhdGUgTWVtYmVyMRowGAYDVQQDExFQZXRl
ciBTYWludC1BbmRyZTEhMB8GCSqGSIb3DQEJARYSc3RwZXRlckBzdHBldGVyLmltMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuERvnrkpQTx9wbJfgxbNKEYvt0IilecZRUM6
wrbCzIUPCocuYhaAJcQoqIyHaKybPQ7f+DIGIAolAa3dHnNdlsXP2smTft/ZNpj10PIG5bil
NAqLUYwmLJaEaqY7BMW8423U3blW43/luLJk/Pq4OsWcw7AK3LeVh1U/HOgqhin26N3h72X1
nbLEpZFrgcp8egmWtXLCbLBDMqUK3j6wjLldni79muzYEVqU0A5GqSeb8Wc4kIx8VI5yL24J
KzinG2iVRP5ZDEbOZETzBXJabUsV56XSxqPG9DK6ke+ybCiL/wKV1HFqdtFB1y25lfvHgOP2
gyEApBKEDNjgLmKyyQIDAQABo4IC+zCCAvcwCQYDVR0TBAIwADALBgNVHQ8EBAMCBLAwHQYD
VR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBS2EW2iNB+g0EibKJLBdv8I
eLovVDAfBgNVHSMEGDAWgBR7iZySlyShhEcCy3T8LvSs3DLl8zAdBgNVHREEFjAUgRJzdHBl
dGVyQHN0cGV0ZXIuaW0wggFCBgNVHSAEggE5MIIBNTCCATEGCysGAQQBgbU3AQICMIIBIDAu
BggrBgEFBQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEF
BQcCARYoaHR0cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjCBtwYIKwYB
BQUHAgIwgaowFBYNU3RhcnRDb20gTHRkLjADAgEBGoGRTGltaXRlZCBMaWFiaWxpdHksIHNl
ZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRpZmlj
YXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFydHNz
bC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0c3Ns
LmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1
My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5z
dGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNVHRIE
HDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBADVtbXJG
tKAr55xc/OUM546gXUybI72Bank0w739Mv+9BBNtq9rMEvCnLmSKhBi76c1mdXh6zXs8RQDo
6nR/aPabE3llF2T4z80smi9jfnl3y9dpu9TcgDoqDLZ7a2lBlW656XAAQzHjvLp2MC7/mxlg
PYH2axa+q40mAYM20GbNsAEGbWQT1IqIh0BcLLsgbaMJHbyG/57zd9JLyMX3Vry1L1fJRQr3
GeLxMV5RtxN+mBgxrwFz/cOc09COiFExlsHgekpB5O43gqsAU16MXypyoSt4MrSfKTMHIGx6
2RF/M6vqUlvhi28gk2ZUvQ/+OX5+gjcZyooEzAAn4RuOKNswggbHMIIFr6ADAgECAgIAizAN
BgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4x
KzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMT
L1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTEw
MTAxNDAxMzYzNFoXDTEyMTAxNDEyMDEwN1owgcAxIDAeBgNVBA0TFzI3NDU4MS05TlgwNHF4
TERiMG80NjlUMQswCQYDVQQGEwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRl
bnZlcjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0aWZpY2F0ZSBNZW1iZXIxGjAY
BgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcNAQkBFhJzdHBldGVyQHN0cGV0
ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4RG+euSlBPH3Bsl+DFs0o
Ri+3QiKV5xlFQzrCtsLMhQ8Khy5iFoAlxCiojIdorJs9Dt/4MgYgCiUBrd0ec12Wxc/ayZN+
39k2mPXQ8gbluKU0CotRjCYsloRqpjsExbzjbdTduVbjf+W4smT8+rg6xZzDsArct5WHVT8c
6CqGKfbo3eHvZfWdssSlkWuBynx6CZa1csJssEMypQrePrCMuV2eLv2a7NgRWpTQDkapJ5vx
ZziQjHxUjnIvbgkrOKcbaJVE/lkMRs5kRPMFclptSxXnpdLGo8b0MrqR77JsKIv/ApXUcWp2
0UHXLbmV+8eA4/aDIQCkEoQM2OAuYrLJAgMBAAGjggL7MIIC9zAJBgNVHRMEAjAAMAsGA1Ud
DwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFLYRbaI0
H6DQSJsoksF2/wh4ui9UMB8GA1UdIwQYMBaAFHuJnJKXJKGERwLLdPwu9KzcMuXzMB0GA1Ud
EQQWMBSBEnN0cGV0ZXJAc3RwZXRlci5pbTCCAUIGA1UdIASCATkwggE1MIIBMQYLKwYBBAGB
tTcBAgIwggEgMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3ku
cGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUu
cGRmMIG3BggrBgEFBQcCAjCBqjAUFg1TdGFydENvbSBMdGQuMAMCAQEagZFMaW1pdGVkIExp
YWJpbGl0eSwgc2VlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRD
b20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8v
d3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMGMGA1UdHwRcMFowK6ApoCeGJWh0dHA6Ly93
d3cuc3RhcnRzc2wuY29tL2NydHUzLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRz
c2wuY29tL2NydHUzLWNybC5jcmwwgY4GCCsGAQUFBwEBBIGBMH8wOQYIKwYBBQUHMAGGLWh0
dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbS9zdWIvY2xhc3MzL2NsaWVudC9jYTBCBggrBgEFBQcw
AoY2aHR0cDovL3d3dy5zdGFydHNzbC5jb20vY2VydHMvc3ViLmNsYXNzMy5jbGllbnQuY2Eu
Y3J0MCMGA1UdEgQcMBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzANBgkqhkiG9w0BAQUF
AAOCAQEANW1tcka0oCvnnFz85QznjqBdTJsjvYFqeTTDvf0y/70EE22r2swS8KcuZIqEGLvp
zWZ1eHrNezxFAOjqdH9o9psTeWUXZPjPzSyaL2N+eXfL12m71NyAOioMtntraUGVbrnpcABD
MeO8unYwLv+bGWA9gfZrFr6rjSYBgzbQZs2wAQZtZBPUioiHQFwsuyBtowkdvIb/nvN30kvI
xfdWvLUvV8lFCvcZ4vExXlG3E36YGDGvAXP9w5zT0I6IUTGWweB6SkHk7jeCqwBTXoxfKnKh
K3gytJ8pMwcgbHrZEX8zq+pSW+GLbyCTZlS9D/45fn6CNxnKigTMACfhG44o2zGCA80wggPJ
AgEBMIGTMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UE
CxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRD
b20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMAkGBSsOAwIa
BQCgggIOMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDYy
MTE3NDUyMlowIwYJKoZIhvcNAQkEMRYEFGbE7AeaIWL1kf3oU/fCII1D52TjMF8GCSqGSIb3
DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggq
hkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBpAYJKwYBBAGCNxAEMYGWMIGT
MIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2Vj
dXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh
c3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAgCLMIGmBgsqhkiG9w0BCRAC
CzGBlqCBkzCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV
BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0
Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgIAizANBgkqhkiG
9w0BAQEFAASCAQAyKE4d+AycaFfq4AIwkYxG3r6miBel6tSPMZRHo7UpLvX34ZUCSedSZP9a
npvU5dDagnMCdnhaWEJtO6P2dDDEXgp6f2ii8pJw6AncyrjolqCmarEHJdzFxqNefTgj7MqD
+t71Uq+54iSAb7D5mt+pFL3S0eSB9j95JgcnXpegwZ8Qd/WhpOKheHjgnJ8hzjze7lQ9nTjP
6MSL9kx7W3+sig8pP2JsTbUno0F/dNxcFtnidUhRsQp+6TrPqLagU1M4vmN8FBCkNYR/xP7f
HFIi8PFjVWqbdmSwErHJzD6iQtztOvRF3zip2HzzagQHM0DHNI5liCSOG79zmb88oraPAAAA
AAAA
--------------ms080005080606030407020302--

From alessandro.alinone@lightstreamer.com  Tue Jun 21 11:10:38 2011
Return-Path: <alessandro.alinone@lightstreamer.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 990C011E8153 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 11:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level: 
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vByASWp8C8BS for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 11:10:37 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8F7C811E8185 for <hybi@ietf.org>; Tue, 21 Jun 2011 11:10:37 -0700 (PDT)
Received: by vxi40 with SMTP id 40so19877vxi.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 11:10:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightstreamer.com; s=google; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=Vj+b+PVs4oklBJOZ5HKQgZTPKzK9VKy1DeM0sHWb9QY=; b=fPjHDfppkglZdp4zYfJNQjHh3BizNU/xrkYgvk414Dq2bevRdHaBnHQ9urJHhrwxt8 xszOEHHeDuMSG0E+Vv1TdwQLAIWgNOKlIda7zZyMGXte5VujKCjTF6moFZ4w7GpCKfR3 Rpe55QU1HlWUfYJV+8B7iW2fZ8ol9Ls3pkHJw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=lightstreamer.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; b=GxnbYNIm8ge5zCOhSUuqojHNZR3RTAxdzk2xiO5ShwpdYeMxXcQx7YUCBRsO/t5qAc Y3Uv4qC+h9i/MVeKBrvK7FJUsDPKaB2rkHZNzMzd9HAJKIQc4hzQDbgFvrZeEgYZuA+7 oNfTQ2ZymQs9rr+30BU2GLOnUkvOWba44Mgak=
Received: by 10.52.97.130 with SMTP id ea2mr9752637vdb.268.1308679820580; Tue, 21 Jun 2011 11:10:20 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by mx.google.com with ESMTPS id r12sm987773vcq.36.2011.06.21.11.10.19 (version=SSLv3 cipher=OTHER); Tue, 21 Jun 2011 11:10:20 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2758446qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 11:10:19 -0700 (PDT)
Received: by 10.229.53.82 with SMTP id l18mr4060791qcg.286.1308679819352; Tue, 21 Jun 2011 11:10:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.250.74 with HTTP; Tue, 21 Jun 2011 11:10:04 -0700 (PDT)
From: Alessandro Alinone <alessandro.alinone@lightstreamer.com>
Date: Tue, 21 Jun 2011 20:10:04 +0200
Message-ID: <BANLkTi=ZtT5jrhZNevt8j_O5T+q0A2XD3A@mail.gmail.com>
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=0015175ccf1ec1da6b04a63cc3e5
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 18:10:38 -0000

--0015175ccf1ec1da6b04a63cc3e5
Content-Type: text/plain; charset=ISO-8859-1

Hi,

I think that limiting the historical mention to HTTP polling and long
polling is a bit restrictive. We have been using HTTP streaming
very successfully for 11 years now, in many production scenarios (via
various techniques made available in the course of history, including:
ILAYER streaming on glorious Netscape 4; FRAME streaming on other very old
browsers; IFRAME streaming on old browsers; XHR streaming on some newer
browsers). So I propose to rephrase the "Background" section including HTTP
streaming.

Thanks,

Alessandro

-- 
Alessandro Alinone
co-CEO and CTO
www.lightstreamer.com :: Weswit Srl


On 6/20/11 12:57 AM, Greg Wilkins wrote:

> On 16 June 2011 07:10, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>> Section 1.1 has always struck me as strange. It sounds as if we're
>> developing an IM protocol here! I suggest:
>>
>>   Historically, creating Web applications that need bidirectional
>>   communication between a client and a server (e.g., instant messaging
>>   and gaming applications) has required an abuse of HTTP to poll the
>>   server for updates while sending upstream notifications as distinct
>>   HTTP calls. [RFC6202]
>
>
> I don't think the usage of "abuse" can be justified.   There is
> nothing abusive about long polling and it is entirely legal HTTP.
> Besides that is too much of a subjective reason.
>
> How about:
>
>   Historically, creating Web applications that need bidirectional
>   communication between a client and a server (e.g., instant messaging
>   and gaming applications), has required the use of HTTP to poll or long
>   poll the server for updates.  Such usage of HTTP is less efficient
> and responsive
>   that what is possible with a TCP/IP connection.

Sure. I tried to leave as much of the current text alone in my suggestion.

Peter

-- 
Peter Saint-Andrehttps://stpeter.im/

--0015175ccf1ec1da6b04a63cc3e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hi,<div><br></div><div>I think that limiting the historical mention to HTTP=
 polling and long polling is a bit restrictive. We have been using HTTP str=
eaming very=A0successfully=A0for 11 years now, in many production scenarios=
 (via various techniques made available in the course of history, including=
: ILAYER streaming on glorious Netscape 4; FRAME streaming on other very ol=
d browsers; IFRAME streaming on old browsers; XHR streaming on some newer b=
rowsers). So I propose to rephrase the &quot;Background&quot; section inclu=
ding HTTP streaming.</div>

<div><br></div><div>Thanks,</div><div><br></div><div>Alessandro</div><div><=
br></div><div><div>--=A0</div>Alessandro Alinone<br>co-CEO and CTO<br><div>=
<a href=3D"http://www.lightstreamer.com" target=3D"_blank">www.lightstreame=
r.com</a> :: Weswit Srl</div>

<div><br></div><div><span class=3D"Apple-style-span" style=3D"font-family: =
monospace; white-space: pre-wrap; font-size: medium; "><br></span></div><di=
v><span class=3D"Apple-style-span" style=3D"font-family: monospace; white-s=
pace: pre-wrap; font-size: medium; ">On 6/20/11 12:57 AM, Greg Wilkins wrot=
e:</span></div>

<div><span class=3D"Apple-style-span" style=3D"font-family: &#39;Times New =
Roman&#39;; font-size: medium; "><pre style=3D"white-space: pre-wrap; word-=
wrap: break-word; width: 954px; ">&gt; On 16 June 2011 07:10, Peter Saint-A=
ndre &lt;stpeter at <a href=3D"http://stpeter.im">stpeter.im</a>&gt; wrote:
&gt;&gt; Section 1.1 has always struck me as strange. It sounds as if we&#3=
9;re
&gt;&gt; developing an IM protocol here! I suggest:
&gt;&gt;
&gt;&gt;   Historically, creating Web applications that need bidirectional
&gt;&gt;   communication between a client and a server (e.g., instant messa=
ging
&gt;&gt;   and gaming applications) has required an abuse of HTTP to poll t=
he
&gt;&gt;   server for updates while sending upstream notifications as disti=
nct
&gt;&gt;   HTTP calls. [RFC6202]
&gt;=20
&gt;=20
&gt; I don&#39;t think the usage of &quot;abuse&quot; can be justified.   T=
here is
&gt; nothing abusive about long polling and it is entirely legal HTTP.
&gt; Besides that is too much of a subjective reason.
&gt;=20
&gt; How about:
&gt;=20
&gt;   Historically, creating Web applications that need bidirectional
&gt;   communication between a client and a server (e.g., instant messaging
&gt;   and gaming applications), has required the use of HTTP to poll or lo=
ng
&gt;   poll the server for updates.  Such usage of HTTP is less efficient
&gt; and responsive
&gt;   that what is possible with a TCP/IP connection.

Sure. I tried to leave as much of the current text alone in my suggestion.

Peter

--=20
Peter Saint-Andre
<a rel=3D"nofollow" href=3D"https://stpeter.im/">https://stpeter.im/</a>
</pre><div><br></div></span></div></div>

--0015175ccf1ec1da6b04a63cc3e5--

From bruce@callenish.com  Tue Jun 21 14:41:32 2011
Return-Path: <bruce@callenish.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF1811E80CA for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 14:41:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Pw1z12r6-QD for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 14:41:30 -0700 (PDT)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 4936F11E80B7 for <hybi@ietf.org>; Tue, 21 Jun 2011 14:41:30 -0700 (PDT)
Received: from [24.108.133.142] (helo=[192.168.145.100]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from <bruce@callenish.com>) id 1QZ8hM-0004Gn-UD; Tue, 21 Jun 2011 14:41:28 -0700
Message-ID: <4E010FF9.1000207@callenish.com>
Date: Tue, 21 Jun 2011 14:41:13 -0700
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
In-Reply-To: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 21:41:32 -0000

Although I agree with you that deflate-stream is a bad idea and 
recognize that the decision to include it was made before it had been 
determined that masking applies only to payload data (so deflate-stream 
has to be done on masked data), I think it might be difficult to get 
agreement to remove it as a known extension in the spec at this point.

But just because it is a known extension does not mean it needs to be 
implemented. My suggestion is that everyone that thinks it is a bad idea 
should remove deflate-stream from their implementations and add in 
deflate-frame. So long as deflate-frame is available I don't imagine 
there will be a groundswell of consumer desire for the far less useful 
deflate-stream.

On 19/06/2011 11:33 PM, Greg Wilkins wrote:
> As part of my continuing campaign against including deflate-stream in
> the specification as a standard extension, I did a quick test of how
> well it works when applied to masked frames.
>
> I took a days worth of traffic from an IRC channel and wrapped it up
> as JSON messages sent as websocket frames.
> There were 487 message that looked like:
>
>       {channel:"#webtide", username:"tbecker", text:"joakime: jenkins
> had issues pulling from github a couple of times  last week"}
>
> As an unmasked WS stream, it was 50675 bytes, and as a masked stream
> is was 52623 bytes.
> I then compressed both these streams with gzip and got 13306 bytes for
> unmasked and 51704 bytes for the masked!!!!
>
> So for this very typical example, masking was sufficiently random to
> completely negate the benefits of compression.
>
> So the deflate-stream "extension" is:
>
>   + next to useless for inbound traffic
>   + breaks all the rules of what an extension can do
>   + is potentially vulnerable to injection as attackers can send
> repeated patterns that may subvert masking
>   + can be replaced by the in-frame compression extension already proposed.
>   + was inserted in the draft with little or no discussion and without
> clear consensus.
>
> Can I call for a straw poll of who wants to keep this extension in the spec?
>
>
>
> regards
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


From alexey.melnikov@isode.com  Tue Jun 21 15:02:34 2011
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 020A311E812C for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 15:02:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.718
X-Spam-Level: 
X-Spam-Status: No, score=-101.718 tagged_above=-999 required=5 tests=[AWL=-0.515, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFeEhyeDgUVp for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 15:02:33 -0700 (PDT)
Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3E3AF11E80D5 for <hybi@ietf.org>; Tue, 21 Jun 2011 15:02:33 -0700 (PDT)
Received: from [188.29.183.175] (188.29.183.175.threembb.co.uk [188.29.183.175])  by rufus.isode.com (submission channel) via TCP with ESMTPA  id <TgEU9ABqW8bV@rufus.isode.com>; Tue, 21 Jun 2011 23:02:30 +0100
Message-ID: <4E0114E4.7070008@isode.com>
Date: Tue, 21 Jun 2011 23:02:12 +0100
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
To: Peter Saint-Andre <stpeter@stpeter.im>, Dave Cridland <dave@cridland.net>
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com> <4898.1308659426.327742@puncture> <4E00D8B2.6090409@stpeter.im>
In-Reply-To: <4E00D8B2.6090409@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-transfer-encoding: quoted-printable
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 22:02:34 -0000

Peter Saint-Andre wrote:

>On 6/21/11 6:30 AM, Dave Cridland wrote:
> =20
>
>>On Fri Jun 17 21:07:22 2011, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=
=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote:
>>   =20
>>
>>>On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre
>>><stpeter@stpeter.im>wrote:
>>>     =20
>>>
>>>>Section 11.12 says that assignment of WebSocket Version Numbers shall be
>>>>       =20
>>>>
>>>>"RFC Required", but then requests assignment of version numbers 0-8 to
>>>>prior submissions of this Internet-Draft. The requested assignments are
>>>>at odds with the stated policy.
>>>>       =20
>>>>
>>>RFC Required is different from Standards Action. RFC Publication
>>>(either as
>>>an IETF submission or as an RFC editor independent submission) suffices.
>>>Standards Action requires Standards Track RFCs approved by the IESG. My
>>>understanding from this as that an I-D counts as an IETF submission?
>>>     =20
>>>
>>Yes, but it only counts as an RFC once it's published...
>>
>>The solution is to assign these to this document, but note in this
>>section that versions 1-8 are older versions.
>>
>>One might even ask IANA to maintain a note saying that, when creating
>>the registry.
>>
>>That all said, it's not clear to me this really needs a registry, or why
>>one might want to allow independant stream RFCs to define a new version
>>number - that effectively means that the next version of WebSockets
>>might not be an IETF protocol at all. In contrast with the other
>>registries - which seem reasonable - allowing random people to invent
>>new and conflicting versions seems like a recipe for chaos.
>>
>>I'd have thought that we want standards-track here, and in any case, the
>>version numbers would be handled by Obsoletes/Updates perfectly well.
>>   =20
>>
>
>Seems reasonable, yes.
>
I tend to agree with the "cause chaos" argument, so Standards Track RFC or I=
ETF Consensus (i.e. any RFC in the IETF Stream) is Ok.

I would still prefer to have a registry, as some people (especially people n=
ot doing IETF standards for long time) are not as skilled as others in navig=
ating chains of references. But I don't feel strongly enough about this.

My 2p.



From gregw@intalio.com  Tue Jun 21 16:31:39 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EFD11E8101 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:31:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.869
X-Spam-Level: 
X-Spam-Status: No, score=-2.869 tagged_above=-999 required=5 tests=[AWL=0.108,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LeQMD5mjSFu for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:31:38 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4503A11E8104 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:31:38 -0700 (PDT)
Received: by vxi40 with SMTP id 40so276855vxi.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:31:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.180.198 with SMTP id dq6mr4949970vdc.158.1308699097090; Tue, 21 Jun 2011 16:31:37 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Tue, 21 Jun 2011 16:31:37 -0700 (PDT)
In-Reply-To: <4E010FF9.1000207@callenish.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com> <4E010FF9.1000207@callenish.com>
Date: Wed, 22 Jun 2011 09:31:37 +1000
Message-ID: <BANLkTikSQi2j9xRx8itVwvXOvTpzvqR0bw@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Bruce Atherton <bruce@callenish.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 23:31:39 -0000

On 22 June 2011 07:41, Bruce Atherton <bruce@callenish.com> wrote:
> Although I agree with you that deflate-stream is a bad idea and recognize
> that the decision to include it was made before it had been determined that
> masking applies only to payload data (so deflate-stream has to be done on
> masked data), I think it might be difficult to get agreement to remove it as
> a known extension in the spec at this point.

Firstly - I really object to this repeated anti-pattern.... some
"feature" is slipped into the draft without much discussion and no
clear consensus, and then we have to argue to have it removed.  The
status quo is to have the non consensus "feature".
I think a lot of the angst in this WG has been due to this repeated
anti-pattern.

But for this particular issue, I see no reason why it cannot be
removed.  Servers have always been free to refuse an extension, so no
application can be written that depends on it's existence.   Clients
are free to keep asking for it, but that does not mean we have to
define it.


> But just because it is a known extension does not mean it needs to be
> implemented. My suggestion is that everyone that thinks it is a bad idea
> should remove deflate-stream from their implementations and add in
> deflate-frame. So long as deflate-frame is available I don't imagine there
> will be a groundswell of consumer desire for the far less useful
> deflate-stream.

the problem is more than just not using it (I have no plans of
implementing it for my server).

It is the only exemplar of an extension we have in the specification
and as an example to follow it is terrible!  It does not follow any of
the rules we set out for extensions and will just encourage developers
to think they can do a x-my-new-wire-protocol and send whatever they
like over the wire.    If people want to do arbitrary new wire
protocols, then they should open their own port. (I know that this
argument also applies to ws, but we have got to significant length to
make sure our protocol is compatible with a HTTP upgrade).


regards

From gregw@intalio.com  Tue Jun 21 16:36:06 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEF011E80FB for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.726
X-Spam-Level: 
X-Spam-Status: No, score=-2.726 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6qasAw40mAk for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:36:05 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8A911E8083 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:35:57 -0700 (PDT)
Received: by vxi40 with SMTP id 40so279250vxi.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:35:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.115.232 with SMTP id jr8mr22040vdb.38.1308699357068; Tue, 21 Jun 2011 16:35:57 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Tue, 21 Jun 2011 16:35:56 -0700 (PDT)
In-Reply-To: <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com>
Date: Wed, 22 Jun 2011 09:35:56 +1000
Message-ID: <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 23:36:06 -0000

On 21 June 2011 23:43, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
> Hi, any comment about this please? IMHO this topic is important. If
> I'm wrong I would like to know it :)

In many respects, this is a thread that should probably occur within
the W3C and WHATWG lists, as how browsers handle credential collection
is much more of an issue for them than the IETF..   Note that I think
they are in final call on their APIs as well.

It is true that the current version of the draft no longer denies the
ability of a client to handle 401 responses, so that is perhaps all
that we need.     However it might be that we should consider if we
recommend support for BASIC and DIGEST.

cheers







>
> 2011/6/20 I=F1aki Baz Castillo <ibc@aliax.net>:
>> Hi, I would like to start a new thread for this topic as it seems that
>> the draft does not cover it at all (just suggests that an HTTP
>> response code other than 101 should be threated as RFC 2616 states:
>>
>>
>> =A0"1. =A0If the status code received from the server is not 101, the
>> =A0 =A0 =A0 =A0client handles the response per HTTP procedures." (p. 30)
>>
>>
>> The question is: should the browser prompt the human user for
>> user/pass as when a 401 is received in the WS handshake attemp?
>>
>> Imagine this case:
>>
>> - www.domain.org =3D> 1.1.1.1:80
>>
>> - ws.domain.org =3D> 1.1.1.2:443
>>
>> - I open http://www.domain.org in my browser, fill some login form and
>> retrieve websocket connection data, including an user and pass (for
>> Digest).
>>
>> - My JavaScript is then provisioned (via JavaScript WebSocket API
>> ????) with ws connection data: server ip, port, Digest user/passwd.
>>
>> - My web browser starts the ws connection with ws.domain.org:443. It
>> receives 401 with Digest (so I need a nonce from the server before
>> using my user/passwd).
>>
>> - JavaScript code automatically accepts the Digest chanllenge,
>> generates a Digest response with the provided user/passwd and the
>> retrieved Digest nonce, and re-send the HTTP GET request (all of this
>> without prompting the user) with the Authorization header.
>>
>> - If the JavaScript code would not be proviosioned with user/pass,
>> then upon receipt of the 401 it should prompt the user (like a
>> JavaScript alert?).
>>
>>
>>
>> So, if all this stuff is not clearly specified (and I think passing
>> user/pass to the JavaScript WebSocket connection API does not exist)
>> then using HTTP Digest (or Basic) will be not useful or feasible, and
>> I expect than using cookies and all that "pure just-web stuff" will be
>> the only way. Please, take into account that a websocket server could
>> run in a separate server, so using cookies mechanism is not so
>> feasible (it could or not depending the case). Neither I think that
>> cookies (a workaround to simulate
>> sessions in HTTP protocol) are the best way to go.
>>
>> IMHO the draft should do much more effort in authentication process.
>> Please don't let the door open to ugly and/or propietary
>> authentication solutions.
>>
>>
>> My proposal is that the JavaScript WebSocket API should include a
>> method to pass authentication 'user' and 'password' (and optionally
>> 'realm' so it would ignore the realm para in the 401 response when
>> using Digest rather than Basic auth).
>>
>> In this way, I could open a webpage, perform usual login (maybe via a
>> HTML form as commonly extended) and then retrieve WS connection data
>> (WS URI), including user/pass/[realm].
>> So my JavaScript client would open a WS connection with the given
>> destination and in case of receiving a 401 it would re-send the HTTP
>> GET request with the appropriate Authorization header without
>> prompting the user.
>>
>> This wouldn't be the only authentication mechanism, of course, but
>> IMHO it should be documented (and covered by the JS WebSocket API).
>>
>> Regards.
>>
>> --
>> I=F1aki Baz Castillo
>> <ibc@aliax.net>
>>
>
>
>
> --
> I=F1aki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

From gregw@intalio.com  Tue Jun 21 16:40:25 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B734111E8152 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:40:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.873
X-Spam-Level: 
X-Spam-Status: No, score=-2.873 tagged_above=-999 required=5 tests=[AWL=0.104,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSbdd8Z2Bq1n for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:40:25 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1298611E8135 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:40:24 -0700 (PDT)
Received: by vxi40 with SMTP id 40so281725vxi.31 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:40:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.169.66 with SMTP id ac2mr3639063vdc.238.1308699624242; Tue, 21 Jun 2011 16:40:24 -0700 (PDT)
Received: by 10.52.108.9 with HTTP; Tue, 21 Jun 2011 16:40:24 -0700 (PDT)
In-Reply-To: <4E00A2FE.8010601@stpeter.im>
References: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net> <4E00A2FE.8010601@stpeter.im>
Date: Wed, 22 Jun 2011 09:40:24 +1000
Message-ID: <BANLkTin35icuwjNVbJc4fAsA0ezGj8HqJQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Bob Gezelter <gezelter@rlgsc.com>
Subject: Re: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 23:40:25 -0000

On 21 June 2011 23:56, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> On 6/21/11 7:10 AM, Bob Gezelter wrote:
> Once again I recommend borrowing from the text in RFC 6120 if
> appropriate, see Section 4.7.5...


+1

although I think we must now also say that a single integer should
considered a minor version with major version being 0.
So 8 =3D=3D 0.8

cheers



> ###
>
> =A0 The numbering scheme for XMPP versions is "<major>.<minor>". =A0The
> =A0 major and minor numbers MUST be treated as separate integers and each
> =A0 number MAY be incremented higher than a single digit. =A0Thus, "XMPP
> =A0 2.4" would be a lower version than "XMPP 2.13", which in turn would
> =A0 be lower than "XMPP 12.3". =A0Leading zeros (e.g., "XMPP 6.01") MUST =
be
> =A0 ignored by recipients and MUST NOT be sent.
>
> =A0 The major version number will be incremented only if the stream and
> =A0 stanza formats or obligatory actions have changed so dramatically
> =A0 that an older version entity would not be able to interoperate with a
> =A0 newer version entity if it simply ignored the elements and attributes
> =A0 it did not understand and took the actions defined in the older
> =A0 specification.
>
> =A0 The minor version number will be incremented only if significant new
> =A0 capabilities have been added to the core protocol (e.g., a newly
> =A0 defined value of the 'type' attribute for message, presence, or IQ
> =A0 stanzas). =A0The minor version number MUST be ignored by an entity wi=
th
> =A0 a smaller minor version number, but MAY be used for informational
> =A0 purposes by the entity with the larger minor version number (e.g.,
> =A0 the entity with the larger minor version number would simply note
> =A0 that its correspondent would not be able to understand that value of
> =A0 the 'type' attribute and therefore would not send it).

From ifette@google.com  Tue Jun 21 16:56:20 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3758421F8503 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.775
X-Spam-Level: 
X-Spam-Status: No, score=-104.775 tagged_above=-999 required=5 tests=[AWL=-0.765, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHRImv8KmZw9 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 16:56:19 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B7F621F8501 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:56:19 -0700 (PDT)
Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p5LNuHaW027793 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:56:18 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308700578; bh=9nyvHtGkm0x2sGktXC7gfFiL5Kw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=XQm+ClA4ABAI7JAQs8UdZLIV7QgrU4Vs4kcE4wnYEn/i19jg/O7I4GVCe6MHAj2NM nlt2EM6YhJQH+d4aTmYSQ==
Received: from iym1 (iym1.prod.google.com [10.241.52.1]) by hpaq12.eem.corp.google.com with ESMTP id p5LNtXLu023282 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 16:56:16 -0700
Received: by iym1 with SMTP id 1so278620iym.29 for <hybi@ietf.org>; Tue, 21 Jun 2011 16:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=dlFvssLmojNJFA8JRJdDPGRWuWrc3BbFctRBwP/tYXs=; b=YJyx+9XQwBy7DnZYx8G3DNJcoM/r23B7DOfONz4kf0wWGTfWuOwapwlu+ScoQe/t7D sS9BZHGKHeXRyep2y+WA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=hDg0pqF4LmSCnBFCGcorXD41CrAvSZNgVVbGos9v/R3IDY+gHqsbtB7B2D2wUrYFmk M6gj3NVwE6Ke6O4rHMKg==
MIME-Version: 1.0
Received: by 10.231.119.216 with SMTP id a24mr26214ibr.58.1308700575752; Tue, 21 Jun 2011 16:56:15 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Tue, 21 Jun 2011 16:56:15 -0700 (PDT)
In-Reply-To: <4E0114E4.7070008@isode.com>
References: <4DFB8E07.60908@stpeter.im> <BANLkTi=6_1H_cTTXRh00v1LM=E_1LUCq9g@mail.gmail.com> <4898.1308659426.327742@puncture> <4E00D8B2.6090409@stpeter.im> <4E0114E4.7070008@isode.com>
Date: Tue, 21 Jun 2011 16:56:15 -0700
Message-ID: <BANLkTimN1gXv3noUrnwLGcV-YHhM+YPtFQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Content-Type: multipart/alternative; boundary=001636920a1aef631004a6419809
X-System-Of-Record: true
Cc: Server-Initiated HTTP <hybi@ietf.org>
Subject: Re: [hybi] -09: IANA considerations
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 21 Jun 2011 23:56:20 -0000

--001636920a1aef631004a6419809
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I guess my problem is that I think people have found it useful during
development to have this field, and I believe it's not unlikely that there
will be further development on a next version at some time in the future. I
would like people doing such experimentation to be able to use a
Sec-WebSocket-Version > 9 without the risk of collision. First Come First
Served would actually work fine for something like this, and would perhaps
alleviate these issues? That way people can experiment in the future, if
there's a next version that goes through multiple drafts it will be able to
re-use that field, and we don't have to come up with additional mechanisms.

(To be clear, I'm not talking about revving the protocol version to support
extensions, I'm talking about core changes.)

I really don't think it matters if Sec-WebSocket-Version:8 is the first
widely supported version and the next one happens to be
Sec-WebSocket-Version:325. The numbering scheme is not important.

On Tue, Jun 21, 2011 at 3:02 PM, Alexey Melnikov
<alexey.melnikov@isode.com>wrote:

> Peter Saint-Andre wrote:
>
>  On 6/21/11 6:30 AM, Dave Cridland wrote:
>>
>>
>>> On Fri Jun 17 21:07:22 2011, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=
=83=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote:
>>>
>>>
>>>> On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre
>>>> <stpeter@stpeter.im>wrote:
>>>>
>>>>
>>>>> Section 11.12 says that assignment of WebSocket Version Numbers shall
>>>>> be
>>>>>
>>>>> "RFC Required", but then requests assignment of version numbers 0-8 t=
o
>>>>> prior submissions of this Internet-Draft. The requested assignments a=
re
>>>>> at odds with the stated policy.
>>>>>
>>>>>
>>>> RFC Required is different from Standards Action. RFC Publication
>>>> (either as
>>>> an IETF submission or as an RFC editor independent submission) suffice=
s.
>>>> Standards Action requires Standards Track RFCs approved by the IESG. M=
y
>>>> understanding from this as that an I-D counts as an IETF submission?
>>>>
>>>>
>>> Yes, but it only counts as an RFC once it's published...
>>>
>>> The solution is to assign these to this document, but note in this
>>> section that versions 1-8 are older versions.
>>>
>>> One might even ask IANA to maintain a note saying that, when creating
>>> the registry.
>>>
>>> That all said, it's not clear to me this really needs a registry, or wh=
y
>>> one might want to allow independant stream RFCs to define a new version
>>> number - that effectively means that the next version of WebSockets
>>> might not be an IETF protocol at all. In contrast with the other
>>> registries - which seem reasonable - allowing random people to invent
>>> new and conflicting versions seems like a recipe for chaos.
>>>
>>> I'd have thought that we want standards-track here, and in any case, th=
e
>>> version numbers would be handled by Obsoletes/Updates perfectly well.
>>>
>>>
>>
>> Seems reasonable, yes.
>>
>>  I tend to agree with the "cause chaos" argument, so Standards Track RFC
> or IETF Consensus (i.e. any RFC in the IETF Stream) is Ok.
>
> I would still prefer to have a registry, as some people (especially peopl=
e
> not doing IETF standards for long time) are not as skilled as others in
> navigating chains of references. But I don't feel strongly enough about
> this.
>
> My 2p.
>
>
>
> ______________________________**_________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman=
/listinfo/hybi>
>

--001636920a1aef631004a6419809
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I guess my problem is that I think people have found it useful during devel=
opment to have this field, and I believe it&#39;s not unlikely that there w=
ill be further development on a next version at some time in the future. I =
would like people doing such experimentation to be able to use a Sec-WebSoc=
ket-Version &gt; 9 without the risk of collision. First Come First Served w=
ould actually work fine for something like this, and would perhaps alleviat=
e these issues? That way people can experiment in the future, if there&#39;=
s a next version that goes through multiple drafts it will be able to re-us=
e that field, and we don&#39;t have to come up with additional mechanisms.<=
div>
<br></div><div>(To be clear, I&#39;m not talking about revving the protocol=
 version to support extensions, I&#39;m talking about core changes.)</div><=
div><br></div><div>I really don&#39;t think it matters if Sec-WebSocket-Ver=
sion:8 is the first widely supported version and the next one happens to be=
 Sec-WebSocket-Version:325. The numbering scheme is not important.<br>
<br><div class=3D"gmail_quote">On Tue, Jun 21, 2011 at 3:02 PM, Alexey Meln=
ikov <span dir=3D"ltr">&lt;<a href=3D"mailto:alexey.melnikov@isode.com">ale=
xey.melnikov@isode.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_=
quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex;">
<div><div></div><div class=3D"h5">Peter Saint-Andre wrote:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On 6/21/11 6:30 AM, Dave Cridland wrote:<br>
=C2=A0<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Fri Jun 17 21:07:22 2011, Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=
=95=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) wrote:<br>
 =C2=A0 <br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
On Fri, Jun 17, 2011 at 10:25 AM, Peter Saint-Andre<br>
&lt;<a href=3D"mailto:stpeter@stpeter.im" target=3D"_blank">stpeter@stpeter=
.im</a>&gt;wrote:<br>
 =C2=A0 =C2=A0 <br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Section 11.12 says that assignment of WebSocket Version Numbers shall be<br=
>
 =C2=A0 =C2=A0 =C2=A0 <br>
&quot;RFC Required&quot;, but then requests assignment of version numbers 0=
-8 to<br>
prior submissions of this Internet-Draft. The requested assignments are<br>
at odds with the stated policy.<br>
 =C2=A0 =C2=A0 =C2=A0 <br>
</blockquote>
RFC Required is different from Standards Action. RFC Publication<br>
(either as<br>
an IETF submission or as an RFC editor independent submission) suffices.<br=
>
Standards Action requires Standards Track RFCs approved by the IESG. My<br>
understanding from this as that an I-D counts as an IETF submission?<br>
 =C2=A0 =C2=A0 <br>
</blockquote>
Yes, but it only counts as an RFC once it&#39;s published...<br>
<br>
The solution is to assign these to this document, but note in this<br>
section that versions 1-8 are older versions.<br>
<br>
One might even ask IANA to maintain a note saying that, when creating<br>
the registry.<br>
<br>
That all said, it&#39;s not clear to me this really needs a registry, or wh=
y<br>
one might want to allow independant stream RFCs to define a new version<br>
number - that effectively means that the next version of WebSockets<br>
might not be an IETF protocol at all. In contrast with the other<br>
registries - which seem reasonable - allowing random people to invent<br>
new and conflicting versions seems like a recipe for chaos.<br>
<br>
I&#39;d have thought that we want standards-track here, and in any case, th=
e<br>
version numbers would be handled by Obsoletes/Updates perfectly well.<br>
 =C2=A0 <br>
</blockquote>
<br>
Seems reasonable, yes.<br>
<br>
</blockquote></div></div>
I tend to agree with the &quot;cause chaos&quot; argument, so Standards Tra=
ck RFC or IETF Consensus (i.e. any RFC in the IETF Stream) is Ok.<br>
<br>
I would still prefer to have a registry, as some people (especially people =
not doing IETF standards for long time) are not as skilled as others in nav=
igating chains of references. But I don&#39;t feel strongly enough about th=
is.<br>

<br>
My 2p.<div><div></div><div class=3D"h5"><br>
<br>
<br>
______________________________<u></u>_________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/hybi</a><br>
</div></div></blockquote></div><br></div>

--001636920a1aef631004a6419809--

From ibc@aliax.net  Tue Jun 21 17:01:18 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DADFE21F85B6 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3aX+e-Ms9ih for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:01:18 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 3D89B21F85B5 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:01:18 -0700 (PDT)
Received: by qyk29 with SMTP id 29so208425qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:01:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr8148qce.192.1308700877650; Tue, 21 Jun 2011 17:01:17 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 17:01:17 -0700 (PDT)
In-Reply-To: <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com>
Date: Wed, 22 Jun 2011 02:01:17 +0200
Message-ID: <BANLkTimafQ1AHSi5VgYnk7oJmhox9Np-sg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 00:01:19 -0000

2011/6/22 Greg Wilkins <gregw@intalio.com>:
> In many respects, this is a thread that should probably occur within
> the W3C and WHATWG lists, as how browsers handle credential collection
> is much more of an issue for them than the IETF.. =C2=A0 Note that I thin=
k
> they are in final call on their APIs as well.

Yes, maybe. However, if WebSocket draft doesn't mandate support of
HTTP authentication, how could W3C mandate it?


> It is true that the current version of the draft no longer denies the
> ability of a client to handle 401 responses, so that is perhaps all
> that we need. =C2=A0 =C2=A0 However it might be that we should consider i=
f we
> recommend support for BASIC and DIGEST.

I strongly recommend discarding BASIC and mandating just DIGEST. SIP
protocol also uses HTTP authentication (RFC 2617) but mandates DIGEST
and disallows BASIC (for obvious reasons):

RFC 3261 (SIP Protocol):

22 Usage of HTTP Authentication
   [...]
   Note that due to its weak security, the usage of "Basic"
   authentication has been deprecated.  Servers MUST NOT accept
   credentials using the "Basic" authorization scheme, and servers also
   MUST NOT challenge with "Basic".


Regards.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ifette@google.com  Tue Jun 21 17:04:37 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C239721F85B6 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:04:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.49
X-Spam-Level: 
X-Spam-Status: No, score=-105.49 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYaoA7QXTYLF for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:04:36 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 362A421F85B4 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:04:36 -0700 (PDT)
Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p5M04Z2t001282 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:04:35 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308701075; bh=XP5EeKdUEij0sBSKyaaPlDXI6AE=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=HlPsFY+qZrSjrs1iWPxT0VGm15qsOTBOEUluE6DXNf7xZFo9mxbFdkUw/p5dWzGSK SOn0mNhcmUuI90X12wtVA==
Received: from iyi20 (iyi20.prod.google.com [10.241.51.20]) by hpaq5.eem.corp.google.com with ESMTP id p5M04WAB020817 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 17:04:33 -0700
Received: by iyi20 with SMTP id 20so393752iyi.35 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:04:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lX3PaER6IZ+o67UffQT+zd5cL4kHi7IonYs7KKyjpEE=; b=S8a/wV7PQ9TumU9X5gT2acmfB/nBee/9a778CzIQ9nkXD9nNlKzVgeXq2ADtOpbK9F nT7omPSHXjpJI4imB/Tw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=SHtvJ97AYxePYy0FS/AQwlwAZ0R+GM2SP9nMKhr125eebyBt1ad8UPtm4rZ/PvWORd v9ywjexMtwPLVS2KvVWQ==
MIME-Version: 1.0
Received: by 10.42.159.68 with SMTP id k4mr40958icx.117.1308701072199; Tue, 21 Jun 2011 17:04:32 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Tue, 21 Jun 2011 17:04:32 -0700 (PDT)
In-Reply-To: <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com>
Date: Tue, 21 Jun 2011 17:04:32 -0700
Message-ID: <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary=90e6ba6137b286918704a641b63b
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 00:04:37 -0000

--90e6ba6137b286918704a641b63b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Speaking as an individual,

I would not want to support this from the browser side. We finally are
starting to kill in browsers HTTP AUTH dialogs created by subresources
(images etc). Frankly it's a very poor user experience. I think most people
will use WS the way they use XHR + long polling, namely they will be on an
established page, do their authentication however they do their
authentication, set a cookie and move on. In some small corner of the
universe, a small set of applications may continue to use HTTP AUTH, but I
don't feel compelled to go out of the way to make its use any easier than i=
f
I had requested javascript from another origin which popped up an auth
dialog. (Rather, I would probably block that as a browser).

-Ian

On Tue, Jun 21, 2011 at 4:35 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 21 June 2011 23:43, I=C3=B1aki Baz Castillo <ibc@aliax.net> wrote:
> > Hi, any comment about this please? IMHO this topic is important. If
> > I'm wrong I would like to know it :)
>
> In many respects, this is a thread that should probably occur within
> the W3C and WHATWG lists, as how browsers handle credential collection
> is much more of an issue for them than the IETF..   Note that I think
> they are in final call on their APIs as well.
>
> It is true that the current version of the draft no longer denies the
> ability of a client to handle 401 responses, so that is perhaps all
> that we need.     However it might be that we should consider if we
> recommend support for BASIC and DIGEST.
>
> cheers
>
>
>
>
>
>
>
> >
> > 2011/6/20 I=C3=B1aki Baz Castillo <ibc@aliax.net>:
> >> Hi, I would like to start a new thread for this topic as it seems that
> >> the draft does not cover it at all (just suggests that an HTTP
> >> response code other than 101 should be threated as RFC 2616 states:
> >>
> >>
> >>  "1.  If the status code received from the server is not 101, the
> >>        client handles the response per HTTP procedures." (p. 30)
> >>
> >>
> >> The question is: should the browser prompt the human user for
> >> user/pass as when a 401 is received in the WS handshake attemp?
> >>
> >> Imagine this case:
> >>
> >> - www.domain.org =3D> 1.1.1.1:80
> >>
> >> - ws.domain.org =3D> 1.1.1.2:443
> >>
> >> - I open http://www.domain.org in my browser, fill some login form and
> >> retrieve websocket connection data, including an user and pass (for
> >> Digest).
> >>
> >> - My JavaScript is then provisioned (via JavaScript WebSocket API
> >> ????) with ws connection data: server ip, port, Digest user/passwd.
> >>
> >> - My web browser starts the ws connection with ws.domain.org:443. It
> >> receives 401 with Digest (so I need a nonce from the server before
> >> using my user/passwd).
> >>
> >> - JavaScript code automatically accepts the Digest chanllenge,
> >> generates a Digest response with the provided user/passwd and the
> >> retrieved Digest nonce, and re-send the HTTP GET request (all of this
> >> without prompting the user) with the Authorization header.
> >>
> >> - If the JavaScript code would not be proviosioned with user/pass,
> >> then upon receipt of the 401 it should prompt the user (like a
> >> JavaScript alert?).
> >>
> >>
> >>
> >> So, if all this stuff is not clearly specified (and I think passing
> >> user/pass to the JavaScript WebSocket connection API does not exist)
> >> then using HTTP Digest (or Basic) will be not useful or feasible, and
> >> I expect than using cookies and all that "pure just-web stuff" will be
> >> the only way. Please, take into account that a websocket server could
> >> run in a separate server, so using cookies mechanism is not so
> >> feasible (it could or not depending the case). Neither I think that
> >> cookies (a workaround to simulate
> >> sessions in HTTP protocol) are the best way to go.
> >>
> >> IMHO the draft should do much more effort in authentication process.
> >> Please don't let the door open to ugly and/or propietary
> >> authentication solutions.
> >>
> >>
> >> My proposal is that the JavaScript WebSocket API should include a
> >> method to pass authentication 'user' and 'password' (and optionally
> >> 'realm' so it would ignore the realm para in the 401 response when
> >> using Digest rather than Basic auth).
> >>
> >> In this way, I could open a webpage, perform usual login (maybe via a
> >> HTML form as commonly extended) and then retrieve WS connection data
> >> (WS URI), including user/pass/[realm].
> >> So my JavaScript client would open a WS connection with the given
> >> destination and in case of receiving a 401 it would re-send the HTTP
> >> GET request with the appropriate Authorization header without
> >> prompting the user.
> >>
> >> This wouldn't be the only authentication mechanism, of course, but
> >> IMHO it should be documented (and covered by the JS WebSocket API).
> >>
> >> Regards.
> >>
> >> --
> >> I=C3=B1aki Baz Castillo
> >> <ibc@aliax.net>
> >>
> >
> >
> >
> > --
> > I=C3=B1aki Baz Castillo
> > <ibc@aliax.net>
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
> >
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--90e6ba6137b286918704a641b63b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Speaking as an individual,<div><br></div><div>I would not want to support t=
his from the browser side. We finally are starting to kill in browsers HTTP=
 AUTH dialogs created by subresources (images etc). Frankly it&#39;s a very=
 poor user experience. I think most people will use WS the way they use XHR=
 + long polling, namely they will be on an established page, do their authe=
ntication however they do their authentication, set a cookie and move on. I=
n some small corner of the universe, a small set of applications may contin=
ue to use HTTP AUTH, but I don&#39;t feel compelled to go out of the way to=
 make its use any easier than if I had requested javascript from another or=
igin which popped up an auth dialog. (Rather, I would probably block that a=
s a browser).</div>
<div><br></div><div>-Ian<br><br><div class=3D"gmail_quote">On Tue, Jun 21, =
2011 at 4:35 PM, Greg Wilkins <span dir=3D"ltr">&lt;<a href=3D"mailto:gregw=
@intalio.com">gregw@intalio.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex;">
<div class=3D"im">On 21 June 2011 23:43, I=C3=B1aki Baz Castillo &lt;<a hre=
f=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt; wrote:<br>
&gt; Hi, any comment about this please? IMHO this topic is important. If<br=
>
&gt; I&#39;m wrong I would like to know it :)<br>
<br>
</div>In many respects, this is a thread that should probably occur within<=
br>
the W3C and WHATWG lists, as how browsers handle credential collection<br>
is much more of an issue for them than the IETF.. =C2=A0 Note that I think<=
br>
they are in final call on their APIs as well.<br>
<br>
It is true that the current version of the draft no longer denies the<br>
ability of a client to handle 401 responses, so that is perhaps all<br>
that we need. =C2=A0 =C2=A0 However it might be that we should consider if =
we<br>
recommend support for BASIC and DIGEST.<br>
<br>
cheers<br>
<div><div></div><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
<br>
<br>
&gt;<br>
&gt; 2011/6/20 I=C3=B1aki Baz Castillo &lt;<a href=3D"mailto:ibc@aliax.net"=
>ibc@aliax.net</a>&gt;:<br>
&gt;&gt; Hi, I would like to start a new thread for this topic as it seems =
that<br>
&gt;&gt; the draft does not cover it at all (just suggests that an HTTP<br>
&gt;&gt; response code other than 101 should be threated as RFC 2616 states=
:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; =C2=A0&quot;1. =C2=A0If the status code received from the server i=
s not 101, the<br>
&gt;&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0client handles the response per HTTP pr=
ocedures.&quot; (p. 30)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; The question is: should the browser prompt the human user for<br>
&gt;&gt; user/pass as when a 401 is received in the WS handshake attemp?<br=
>
&gt;&gt;<br>
&gt;&gt; Imagine this case:<br>
&gt;&gt;<br>
&gt;&gt; - <a href=3D"http://www.domain.org" target=3D"_blank">www.domain.o=
rg</a> =3D&gt; <a href=3D"http://1.1.1.1:80" target=3D"_blank">1.1.1.1:80</=
a><br>
&gt;&gt;<br>
&gt;&gt; - <a href=3D"http://ws.domain.org" target=3D"_blank">ws.domain.org=
</a> =3D&gt; <a href=3D"http://1.1.1.2:443" target=3D"_blank">1.1.1.2:443</=
a><br>
&gt;&gt;<br>
&gt;&gt; - I open <a href=3D"http://www.domain.org" target=3D"_blank">http:=
//www.domain.org</a> in my browser, fill some login form and<br>
&gt;&gt; retrieve websocket connection data, including an user and pass (fo=
r<br>
&gt;&gt; Digest).<br>
&gt;&gt;<br>
&gt;&gt; - My JavaScript is then provisioned (via JavaScript WebSocket API<=
br>
&gt;&gt; ????) with ws connection data: server ip, port, Digest user/passwd=
.<br>
&gt;&gt;<br>
&gt;&gt; - My web browser starts the ws connection with <a href=3D"http://w=
s.domain.org:443" target=3D"_blank">ws.domain.org:443</a>. It<br>
&gt;&gt; receives 401 with Digest (so I need a nonce from the server before=
<br>
&gt;&gt; using my user/passwd).<br>
&gt;&gt;<br>
&gt;&gt; - JavaScript code automatically accepts the Digest chanllenge,<br>
&gt;&gt; generates a Digest response with the provided user/passwd and the<=
br>
&gt;&gt; retrieved Digest nonce, and re-send the HTTP GET request (all of t=
his<br>
&gt;&gt; without prompting the user) with the Authorization header.<br>
&gt;&gt;<br>
&gt;&gt; - If the JavaScript code would not be proviosioned with user/pass,=
<br>
&gt;&gt; then upon receipt of the 401 it should prompt the user (like a<br>
&gt;&gt; JavaScript alert?).<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; So, if all this stuff is not clearly specified (and I think passin=
g<br>
&gt;&gt; user/pass to the JavaScript WebSocket connection API does not exis=
t)<br>
&gt;&gt; then using HTTP Digest (or Basic) will be not useful or feasible, =
and<br>
&gt;&gt; I expect than using cookies and all that &quot;pure just-web stuff=
&quot; will be<br>
&gt;&gt; the only way. Please, take into account that a websocket server co=
uld<br>
&gt;&gt; run in a separate server, so using cookies mechanism is not so<br>
&gt;&gt; feasible (it could or not depending the case). Neither I think tha=
t<br>
&gt;&gt; cookies (a workaround to simulate<br>
&gt;&gt; sessions in HTTP protocol) are the best way to go.<br>
&gt;&gt;<br>
&gt;&gt; IMHO the draft should do much more effort in authentication proces=
s.<br>
&gt;&gt; Please don&#39;t let the door open to ugly and/or propietary<br>
&gt;&gt; authentication solutions.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; My proposal is that the JavaScript WebSocket API should include a<=
br>
&gt;&gt; method to pass authentication &#39;user&#39; and &#39;password&#39=
; (and optionally<br>
&gt;&gt; &#39;realm&#39; so it would ignore the realm para in the 401 respo=
nse when<br>
&gt;&gt; using Digest rather than Basic auth).<br>
&gt;&gt;<br>
&gt;&gt; In this way, I could open a webpage, perform usual login (maybe vi=
a a<br>
&gt;&gt; HTML form as commonly extended) and then retrieve WS connection da=
ta<br>
&gt;&gt; (WS URI), including user/pass/[realm].<br>
&gt;&gt; So my JavaScript client would open a WS connection with the given<=
br>
&gt;&gt; destination and in case of receiving a 401 it would re-send the HT=
TP<br>
&gt;&gt; GET request with the appropriate Authorization header without<br>
&gt;&gt; prompting the user.<br>
&gt;&gt;<br>
&gt;&gt; This wouldn&#39;t be the only authentication mechanism, of course,=
 but<br>
&gt;&gt; IMHO it should be documented (and covered by the JS WebSocket API)=
.<br>
&gt;&gt;<br>
&gt;&gt; Regards.<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt; I=C3=B1aki Baz Castillo<br>
&gt;&gt; &lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; I=C3=B1aki Baz Castillo<br>
&gt; &lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
&gt; _______________________________________________<br>
&gt; hybi mailing list<br>
&gt; <a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/hybi</a><br>
&gt;<br>
_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</div></div></blockquote></div><br></div>

--90e6ba6137b286918704a641b63b--

From ibc@aliax.net  Tue Jun 21 17:20:42 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D61D9E800F for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:20:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJV1+yQpjQRm for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:20:38 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5CF99E8004 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2954748qyk.10 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr13397qcq.230.1308702037140; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Tue, 21 Jun 2011 17:20:37 -0700 (PDT)
In-Reply-To: <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com>
Date: Wed, 22 Jun 2011 02:20:37 +0200
Message-ID: <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 00:20:42 -0000

2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
> I would not want to support this from the browser side. We finally are
> starting to kill in browsers HTTP AUTH dialogs created by subresources
> (images etc). Frankly it's a very poor user experience. I think most peop=
le
> will use WS the way they use XHR + long polling, namely they will be on a=
n
> established page, do their authentication however they do their
> authentication, set a cookie and move on. In some small corner of the
> universe, a small set of applications may continue to use HTTP AUTH, but =
I
> don't feel compelled to go out of the way to make its use any easier than=
 if
> I had requested javascript from another origin which popped up an auth
> dialog. (Rather, I would probably block that as a browser).

So what about if the websocket server is not the same as the web
server from which the JS code has been got? Would the WS handshake
request include a Cookie header (that replied in the HTTP 200 OK from
the server? so, should the separate websocket server do some magic
with the Cookie value to verify ist validity?

Many web servers store the sessions data in memory so, which kind of
exotic mechanism should use the separate websocket server to validate
the given Cookie? use a shared database or shared memory (i.e.
memcached) for storing sessions?

Honestly I'm a bit afraid about your assumption in which clearly you
assume that the websocket server listens in the same host as the web
server. I strongly think that the protocol should define a well
specified and feasible authentication mechanism instead of assuming
that develovers will do some kind of magic in server side (a protocol
should not require that).

Regards.

PS: I agree that prompting the user with HTTP authentication dialog is
a pain, but I'm not suggesting that for websocket. In other thread I
explained how the JavaScript code retrieved by the browser (after user
login using whatever mechanism) could containg the WS URI connection
along with authentication information (i.e. user and pass for Digest
auth). Then the browser contacts the websocket server (don't assume
it's co-located with the web server), receives the 401 containing the
realm and nonce to use, and generates a new WS handshake request with
proper authentication credentials. This would prompt nothing to the
user.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ifette@google.com  Tue Jun 21 17:56:11 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2DF421F851F for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.545
X-Spam-Level: 
X-Spam-Status: No, score=-105.545 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kenWesY5+QUN for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 17:56:11 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id F352221F8523 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:10 -0700 (PDT)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p5M0uAa7019840 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:10 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308704170; bh=74TWAiYzbVNP494xdqf6r70zZaU=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=kQcF7qvakdCxrwOXfcdmrbpjPFZ7xpD/X8SPzax/YihPM50ZSd69oll/rD91U51JW eod9CTYdbOppHWmEoGyMA==
Received: from iyl8 (iyl8.prod.google.com [10.241.51.200]) by wpaz13.hot.corp.google.com with ESMTP id p5M0u8n8020314 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:09 -0700
Received: by iyl8 with SMTP id 8so350806iyl.0 for <hybi@ietf.org>; Tue, 21 Jun 2011 17:56:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=aysEvAUP4WqjnQ+79Oke7GALBRuT996GF0vkEPBJB2o=; b=px06DKSo0u1/rG8+KKAbJU4UnwnzXwqTo2cAjZ/Cxe9L1UHTZ+xumGOrKvYosgZaEm zp+qc+18xVQtYsAaQuFg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=WzyJFBLe24+tTcHCbWkRcYZSdPe7Z9nx8gmtqCAUAp/U77lUU+AwuPan3jTgSERna0 svP+Rf38TMDfcjFbsfZQ==
MIME-Version: 1.0
Received: by 10.42.159.68 with SMTP id k4mr84233icx.117.1308704168538; Tue, 21 Jun 2011 17:56:08 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Tue, 21 Jun 2011 17:56:08 -0700 (PDT)
In-Reply-To: <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com>
Date: Tue, 21 Jun 2011 17:56:08 -0700
Message-ID: <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=90e6ba6137b214f0d904a6426f37
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 00:56:11 -0000

--90e6ba6137b214f0d904a6426f37
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 21, 2011 at 5:20 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> 2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> > I would not want to support this from the browser side. We finally are
> > starting to kill in browsers HTTP AUTH dialogs created by subresources
> > (images etc). Frankly it's a very poor user experience. I think most
> people
> > will use WS the way they use XHR + long polling, namely they will be on
> an
> > established page, do their authentication however they do their
> > authentication, set a cookie and move on. In some small corner of the
> > universe, a small set of applications may continue to use HTTP AUTH, bu=
t
> I
> > don't feel compelled to go out of the way to make its use any easier th=
an
> if
> > I had requested javascript from another origin which popped up an auth
> > dialog. (Rather, I would probably block that as a browser).
>
> So what about if the websocket server is not the same as the web
> server from which the JS code has been got? Would the WS handshake
> request include a Cookie header (that replied in the HTTP 200 OK from
> the server? so, should the separate websocket server do some magic
> with the Cookie value to verify ist validity?
>

How would you do it if you weren't using WebSockets but instead XHR? I doub=
t
you would use HTTP auth...


>
> Many web servers store the sessions data in memory so, which kind of
> exotic mechanism should use the separate websocket server to validate
> the given Cookie? use a shared database or shared memory (i.e.
> memcached) for storing sessions?
>
> Honestly I'm a bit afraid about your assumption in which clearly you
> assume that the websocket server listens in the same host as the web
> server.


I'm not assuming they're on the same host. Certainly at Google that would
not be the case.


> I strongly think that the protocol should define a well
> specified and feasible authentication mechanism instead of assuming
> that develovers will do some kind of magic in server side (a protocol
> should not require that).
>
> Regards.
>
> PS: I agree that prompting the user with HTTP authentication dialog is
> a pain, but I'm not suggesting that for websocket. In other thread I
> explained how the JavaScript code retrieved by the browser (after user
> login using whatever mechanism) could containg the WS URI connection
> along with authentication information (i.e. user and pass for Digest
> auth). Then the browser contacts the websocket server (don't assume
> it's co-located with the web server), receives the 401 containing the
> realm and nonce to use, and generates a new WS handshake request with
> proper authentication credentials. This would prompt nothing to the
> user.
>


I agree that a better solution would be to do whatever authentication you
need when the user goes to the website, and then once the user is
authenticated open the WS connection and pass some sort of credential. That
could be via cookies if it's on the same origin, or it could be passed over
the established WS connection. I don't know that it should be defined in th=
e
WS API though, as different sites might want to use vastly different
authentication mechanisms (client-side certs, passwords, oauth, ...). It's
much more flexible to leave it to the application.


>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>

--90e6ba6137b214f0d904a6426f37
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jun 21, 2011 at 5:20 PM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) &lt;<a href=3D"mailto:ifette@google.com">ifette@google.=
com</a>&gt;:<br>
<div class=3D"im">&gt; I would not want to support this from the browser si=
de. We finally are<br>
&gt; starting to kill in browsers HTTP AUTH dialogs created by subresources=
<br>
&gt; (images etc). Frankly it&#39;s a very poor user experience. I think mo=
st people<br>
&gt; will use WS the way they use XHR + long polling, namely they will be o=
n an<br>
&gt; established page, do their authentication however they do their<br>
&gt; authentication, set a cookie and move on. In some small corner of the<=
br>
&gt; universe, a small set of applications may continue to use HTTP AUTH, b=
ut I<br>
&gt; don&#39;t feel compelled to go out of the way to make its use any easi=
er than if<br>
&gt; I had requested javascript from another origin which popped up an auth=
<br>
&gt; dialog. (Rather, I would probably block that as a browser).<br>
<br>
</div>So what about if the websocket server is not the same as the web<br>
server from which the JS code has been got? Would the WS handshake<br>
request include a Cookie header (that replied in the HTTP 200 OK from<br>
the server? so, should the separate websocket server do some magic<br>
with the Cookie value to verify ist validity?<br></blockquote><div><br></di=
v><div>How would you do it if you weren&#39;t using WebSockets but instead =
XHR? I doubt you would use HTTP auth...</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;">

<br>
Many web servers store the sessions data in memory so, which kind of<br>
exotic mechanism should use the separate websocket server to validate<br>
the given Cookie? use a shared database or shared memory (i.e.<br>
memcached) for storing sessions?<br>
<br>
Honestly I&#39;m a bit afraid about your assumption in which clearly you<br=
>
assume that the websocket server listens in the same host as the web<br>
server. </blockquote><div><br></div><div>I&#39;m not assuming they&#39;re o=
n the same host. Certainly at Google that would not be the case.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex;">
I strongly think that the protocol should define a well<br>
specified and feasible authentication mechanism instead of assuming<br>
that develovers will do some kind of magic in server side (a protocol<br>
should not require that).<br>
<br>
Regards.<br>
<br>
PS: I agree that prompting the user with HTTP authentication dialog is<br>
a pain, but I&#39;m not suggesting that for websocket. In other thread I<br=
>
explained how the JavaScript code retrieved by the browser (after user<br>
login using whatever mechanism) could containg the WS URI connection<br>
along with authentication information (i.e. user and pass for Digest<br>
auth). Then the browser contacts the websocket server (don&#39;t assume<br>
it&#39;s co-located with the web server), receives the 401 containing the<b=
r>
realm and nonce to use, and generates a new WS handshake request with<br>
proper authentication credentials. This would prompt nothing to the<br>
user.<br></blockquote><div><br></div><div><br></div><div>I agree that a bet=
ter solution would be to do whatever authentication you need when the user =
goes to the website, and then once the user is authenticated open the WS co=
nnection and pass some sort of credential. That could be via cookies if it&=
#39;s on the same origin, or it could be passed over the established WS con=
nection. I don&#39;t know that it should be defined in the WS API though, a=
s different sites might want to use vastly different authentication mechani=
sms (client-side certs, passwords, oauth, ...). It&#39;s much more flexible=
 to leave it to the application.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color=3D"#888888"><br>
--<br>
</font><div><div></div><div class=3D"h5">I=C3=B1aki Baz Castillo<br>
&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
</div></div></blockquote></div><br>

--90e6ba6137b214f0d904a6426f37--

From ifette@google.com  Tue Jun 21 18:21:10 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D55F711E80B7 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 18:21:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.555
X-Spam-Level: 
X-Spam-Status: No, score=-105.555 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SB0RyV-UtQ0a for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 18:21:07 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9B511E8087 for <hybi@ietf.org>; Tue, 21 Jun 2011 18:21:05 -0700 (PDT)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p5M1L5EJ006107 for <hybi@ietf.org>; Tue, 21 Jun 2011 18:21:05 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308705665; bh=lH6PaRPxjxzvFME6gulqsUjAins=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=CyqqOp5quimR87u6nxN5d3l1io1Nv9grZAWS1RYPQkQMiO6GUbyfRvzR4AR86B1us jiBP29tcsDwXr33MJQi3Q==
Received: from qwb8 (qwb8.prod.google.com [10.241.193.72]) by wpaz1.hot.corp.google.com with ESMTP id p5M1L4r2018043 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 21 Jun 2011 18:21:04 -0700
Received: by qwb8 with SMTP id 8so262480qwb.39 for <hybi@ietf.org>; Tue, 21 Jun 2011 18:21:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=i950bEAFw9za49i1njICGbv0EtqtvvlE99zbPT7MCVI=; b=w4XPbdl8Hs6fzelUW6Tl+D2kcinOYNQ27zDt+bbPCut03q7soWhmrGBbnGDQvHfete /cYvEitnQKpXCUpXORrw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=yIUbPza+qwvx7M/UPFFBJcV4JpuhtKS1AN8bZGP42UPKDKHrww0xYms05gNECrJULl gm3uPvsGAIbs21bw6NHw==
MIME-Version: 1.0
Received: by 10.229.44.198 with SMTP id b6mr53661qcf.67.1308705663779; Tue, 21 Jun 2011 18:21:03 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Tue, 21 Jun 2011 18:21:03 -0700 (PDT)
In-Reply-To: <BANLkTin35icuwjNVbJc4fAsA0ezGj8HqJQ@mail.gmail.com>
References: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net> <4E00A2FE.8010601@stpeter.im> <BANLkTin35icuwjNVbJc4fAsA0ezGj8HqJQ@mail.gmail.com>
Date: Tue, 21 Jun 2011 18:21:03 -0700
Message-ID: <BANLkTikr4Arf2Lv7aaSc_WuXCfzo7y0+mw@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: multipart/alternative; boundary=0016364184ff34844a04a642c8cb
X-System-Of-Record: true
Cc: hybi@ietf.org, Bob Gezelter <gezelter@rlgsc.com>
Subject: Re: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 01:21:10 -0000

--0016364184ff34844a04a642c8cb
Content-Type: text/plain; charset=UTF-8

Is there any real reason for using major and minor version numbers? Has any
protocol actually been able to use minor version numbers for anything useful
(e.g. both sides understand the major version but only one side understands
the minor version and it's still useful? 1.1 was a minor version upgrade to
HTTP and yet for all practical purposes it may as well have been 2.0.)

On Tue, Jun 21, 2011 at 4:40 PM, Greg Wilkins <gregw@intalio.com> wrote:

> On 21 June 2011 23:56, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> > On 6/21/11 7:10 AM, Bob Gezelter wrote:
> > Once again I recommend borrowing from the text in RFC 6120 if
> > appropriate, see Section 4.7.5...
>
>
> +1
>
> although I think we must now also say that a single integer should
> considered a minor version with major version being 0.
> So 8 == 0.8
>
> cheers
>
>
>
> > ###
> >
> >   The numbering scheme for XMPP versions is "<major>.<minor>".  The
> >   major and minor numbers MUST be treated as separate integers and each
> >   number MAY be incremented higher than a single digit.  Thus, "XMPP
> >   2.4" would be a lower version than "XMPP 2.13", which in turn would
> >   be lower than "XMPP 12.3".  Leading zeros (e.g., "XMPP 6.01") MUST be
> >   ignored by recipients and MUST NOT be sent.
> >
> >   The major version number will be incremented only if the stream and
> >   stanza formats or obligatory actions have changed so dramatically
> >   that an older version entity would not be able to interoperate with a
> >   newer version entity if it simply ignored the elements and attributes
> >   it did not understand and took the actions defined in the older
> >   specification.
> >
> >   The minor version number will be incremented only if significant new
> >   capabilities have been added to the core protocol (e.g., a newly
> >   defined value of the 'type' attribute for message, presence, or IQ
> >   stanzas).  The minor version number MUST be ignored by an entity with
> >   a smaller minor version number, but MAY be used for informational
> >   purposes by the entity with the larger minor version number (e.g.,
> >   the entity with the larger minor version number would simply note
> >   that its correspondent would not be able to understand that value of
> >   the 'type' attribute and therefore would not send it).
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--0016364184ff34844a04a642c8cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Is there any real reason for using major and minor version numbers? Has any=
 protocol actually been able to use minor version numbers for anything usef=
ul (e.g. both sides understand the major version but only one side understa=
nds the minor version and it&#39;s still useful? 1.1 was a minor version up=
grade to HTTP and yet for all practical purposes it may as well have been 2=
.0.)<br>
<br><div class=3D"gmail_quote">On Tue, Jun 21, 2011 at 4:40 PM, Greg Wilkin=
s <span dir=3D"ltr">&lt;<a href=3D"mailto:gregw@intalio.com" target=3D"_bla=
nk">gregw@intalio.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 21 June 2011 23:56, Peter Saint-Andr=
e &lt;<a href=3D"mailto:stpeter@stpeter.im" target=3D"_blank">stpeter@stpet=
er.im</a>&gt; wrote:<br>


&gt; On 6/21/11 7:10 AM, Bob Gezelter wrote:<br>
</div><div>&gt; Once again I recommend borrowing from the text in RFC 6120 =
if<br>
&gt; appropriate, see Section 4.7.5...<br>
<br>
<br>
</div>+1<br>
<br>
although I think we must now also say that a single integer should<br>
considered a minor version with major version being 0.<br>
So 8 =3D=3D 0.8<br>
<br>
cheers<br>
<div><br>
<br>
<br>
&gt; ###<br>
&gt;<br>
&gt; =C2=A0 The numbering scheme for XMPP versions is &quot;&lt;major&gt;.&=
lt;minor&gt;&quot;. =C2=A0The<br>
&gt; =C2=A0 major and minor numbers MUST be treated as separate integers an=
d each<br>
&gt; =C2=A0 number MAY be incremented higher than a single digit. =C2=A0Thu=
s, &quot;XMPP<br>
&gt; =C2=A0 2.4&quot; would be a lower version than &quot;XMPP 2.13&quot;, =
which in turn would<br>
&gt; =C2=A0 be lower than &quot;XMPP 12.3&quot;. =C2=A0Leading zeros (e.g.,=
 &quot;XMPP 6.01&quot;) MUST be<br>
&gt; =C2=A0 ignored by recipients and MUST NOT be sent.<br>
&gt;<br>
&gt; =C2=A0 The major version number will be incremented only if the stream=
 and<br>
&gt; =C2=A0 stanza formats or obligatory actions have changed so dramatical=
ly<br>
&gt; =C2=A0 that an older version entity would not be able to interoperate =
with a<br>
&gt; =C2=A0 newer version entity if it simply ignored the elements and attr=
ibutes<br>
&gt; =C2=A0 it did not understand and took the actions defined in the older=
<br>
&gt; =C2=A0 specification.<br>
&gt;<br>
&gt; =C2=A0 The minor version number will be incremented only if significan=
t new<br>
&gt; =C2=A0 capabilities have been added to the core protocol (e.g., a newl=
y<br>
&gt; =C2=A0 defined value of the &#39;type&#39; attribute for message, pres=
ence, or IQ<br>
&gt; =C2=A0 stanzas). =C2=A0The minor version number MUST be ignored by an =
entity with<br>
&gt; =C2=A0 a smaller minor version number, but MAY be used for information=
al<br>
&gt; =C2=A0 purposes by the entity with the larger minor version number (e.=
g.,<br>
&gt; =C2=A0 the entity with the larger minor version number would simply no=
te<br>
&gt; =C2=A0 that its correspondent would not be able to understand that val=
ue of<br>
&gt; =C2=A0 the &#39;type&#39; attribute and therefore would not send it).<=
br>
</div><div><div></div><div>_______________________________________________<=
br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</div></div></blockquote></div><br>

--0016364184ff34844a04a642c8cb--

From gezelter@rlgsc.com  Tue Jun 21 18:58:11 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCD5721F8595 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 18:58:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.134
X-Spam-Level: 
X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKDLJ5YVe-vL for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 18:58:11 -0700 (PDT)
Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 2647621F852D for <hybi@ietf.org>; Tue, 21 Jun 2011 18:58:11 -0700 (PDT)
Received: (qmail 21499 invoked from network); 22 Jun 2011 01:58:10 -0000
Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 22 Jun 2011 01:58:10 -0000
Received: (qmail 25746 invoked by uid 99); 22 Jun 2011 01:58:10 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 162.83.149.110
User-Agent: Web-Based Email 5.5.05
Message-Id: <20110621185808.ef1fc80126c74c6c202a919c41c7bb0b.5fa1e42ad8.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: ifette@google.com
Date: Tue, 21 Jun 2011 18:58:08 -0700
Mime-Version: 1.0
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 01:58:12 -0000

Ian,

I admittedly do not have a list at my fingertips (at least for
protocols). With APIs, the difference between major and minor is a
question of upward compatibility (as was said in the follow-on to my
suggestion with regards to XMPP).

An incompatible change is signaled by a change in the major revision
level. A compatible change is signaled by a change in the minor revision
level. I have seen clients that depended on the difference between HTTP
1.0 and HTTP 1.1, and would not work with the newer protocol level.

Separately, major/minor version numbers are very useful when
troubleshooting problems, particularly when dealing with servers (or
clients) that are not under one's control.

- Bob Gezelter, http://www.rlgsc.com

> -------- Original Message --------
> Subject: Re: [hybi] WebSocket Version Numbers
> From: Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>
> Date: Tue, June 21, 2011 6:21 pm
> To: Greg Wilkins <gregw@intalio.com>
> Cc: Peter Saint-Andre <stpeter@stpeter.im>, hybi@ietf.org,        Bob
> Gezelter <gezelter@rlgsc.com>
>=20
>=20
> Is there any real reason for using major and minor version numbers? Has a=
ny
> protocol actually been able to use minor version numbers for anything use=
ful
> (e.g. both sides understand the major version but only one side understan=
ds
> the minor version and it's still useful? 1.1 was a minor version upgrade =
to
> HTTP and yet for all practical purposes it may as well have been 2.0.)
>=20
>
[Earlier exchanges removed in the interest of brevity]




From francis@aspl.es  Tue Jun 21 22:34:12 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49FC11E80A3 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 22:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.584
X-Spam-Level: **
X-Spam-Status: No, score=2.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172,  HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJ8HxQ6mAZvG for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 22:34:12 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 347DB11E80A0 for <hybi@ietf.org>; Tue, 21 Jun 2011 22:34:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 517E51170003 for <hybi@ietf.org>; Wed, 22 Jun 2011 07:34:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJalbJZEolYV for <hybi@ietf.org>; Wed, 22 Jun 2011 07:34:03 +0200 (CEST)
Received: from [192.168.0.153] (unknown [89.7.176.101]) (Authenticated sender: acinom) by mail.aspl.es (Postfix) with ESMTPA id 1DC851170001 for <hybi@ietf.org>; Wed, 22 Jun 2011 07:34:03 +0200 (CEST)
From: Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?= <francis@aspl.es>
To: hybi@ietf.org
Content-Type: text/plain
Date: Wed, 22 Jun 2011 07:34:20 +0200
Message-Id: <1308720860.5393.18.camel@tot.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Subject: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 05:34:12 -0000

Hi,

Current frame design allows to send a very big single frame size (63
bits). In terms of memory a websocket server will have problems with
this because he must buffer all content until he can deliver the entire
message to the app level (assuming message based API).

I think we need a way for servers (and possibly clients) to notify each
other which is the max frame size each part is willing to accept so each
site administrator can configure this according to its resources,
application type, number of connections, etc.

I think a simple header notified at the websocket handshake will provide
this valuable control to each party:

   Max-Frame-Size: 4096

This will cause each party to fragment application level messages if it
is found bigger than Max-Frame-Size.

In the same direction, if not provided Max-Frame-Size, it looks
reasonable to assume a default value for this header. Again, 4096 bytes
looks like a good value.

What do you think?






From w@1wt.eu  Tue Jun 21 23:05:20 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6BD21F8585 for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 23:05:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.695
X-Spam-Level: 
X-Spam-Status: No, score=-4.695 tagged_above=-999 required=5 tests=[AWL=-2.952, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKk0haTfer4c for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 23:05:19 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7850421F8584 for <hybi@ietf.org>; Tue, 21 Jun 2011 23:05:19 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5M65EsT020854; Wed, 22 Jun 2011 08:05:14 +0200
Date: Wed, 22 Jun 2011 08:05:14 +0200
From: Willy Tarreau <w@1wt.eu>
To: Francis Brosnan =?iso-8859-1?Q?Bl=E1zquez?= <francis@aspl.es>
Message-ID: <20110622060514.GF18843@1wt.eu>
References: <1308720860.5393.18.camel@tot.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1308720860.5393.18.camel@tot.local>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 06:05:20 -0000

Hi,

On Wed, Jun 22, 2011 at 07:34:20AM +0200, Francis Brosnan Blázquez wrote:
> Hi,
> 
> Current frame design allows to send a very big single frame size (63
> bits). In terms of memory a websocket server will have problems with
> this because he must buffer all content until he can deliver the entire
> message to the app level (assuming message based API).
> 
> I think we need a way for servers (and possibly clients) to notify each
> other which is the max frame size each part is willing to accept so each
> site administrator can configure this according to its resources,
> application type, number of connections, etc.
> 
> I think a simple header notified at the websocket handshake will provide
> this valuable control to each party:
> 
>    Max-Frame-Size: 4096
> 
> This will cause each party to fragment application level messages if it
> is found bigger than Max-Frame-Size.
> 
> In the same direction, if not provided Max-Frame-Size, it looks
> reasonable to assume a default value for this header. Again, 4096 bytes
> looks like a good value.
> 
> What do you think?

There is nothing in the protocol which makes whole frame buffering mandatory
and in fact it's designed so that it can work as a stream instead. While the
app server may decide to buffer some frames before delivering them, it should
never do so for large ones, because 1) it will not be able to do so past one
point, and 2) it will only add important latency. It's exactly the same as
with large POST requests : for large posts, it's common to call the app and
pass it the fd and say "read the data from that fd and for XXX bytes". That's
what makes file upload possible, otherwise you would not be able to use web
interfaces to send mails.

Regards,
Willy


From julian.reschke@gmx.de  Tue Jun 21 23:06:43 2011
Return-Path: <julian.reschke@gmx.de>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34EB21F85BC for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 23:06:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.821
X-Spam-Level: 
X-Spam-Status: No, score=-102.821 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujIs1Tlv21ns for <hybi@ietfa.amsl.com>; Tue, 21 Jun 2011 23:06:39 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id CEE2121F85BA for <hybi@ietf.org>; Tue, 21 Jun 2011 23:06:38 -0700 (PDT)
Received: (qmail invoked by alias); 22 Jun 2011 06:06:35 -0000
Received: from p508FCA80.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.202.128] by mail.gmx.net (mp005) with SMTP; 22 Jun 2011 08:06:35 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18NO9x1hsUND5YVwt1C0iN1vHcxHYONGOgGbuRM1s ubyN+xntGHZwYQ
Message-ID: <4E018660.20109@gmx.de>
Date: Wed, 22 Jun 2011 08:06:24 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10
MIME-Version: 1.0
To: ifette@google.com
References: <20110621061036.ef1fc80126c74c6c202a919c41c7bb0b.7a63d337a6.wbe@email03.secureserver.net>	<4E00A2FE.8010601@stpeter.im>	<BANLkTin35icuwjNVbJc4fAsA0ezGj8HqJQ@mail.gmail.com> <BANLkTikr4Arf2Lv7aaSc_WuXCfzo7y0+mw@mail.gmail.com>
In-Reply-To: <BANLkTikr4Arf2Lv7aaSc_WuXCfzo7y0+mw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: hybi@ietf.org, Bob Gezelter <gezelter@rlgsc.com>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] WebSocket Version Numbers
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 06:06:43 -0000

On 2011-06-22 03:21, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
> Is there any real reason for using major and minor version numbers? Has
> any protocol actually been able to use minor version numbers for
> anything useful (e.g. both sides understand the major version but only
> one side understands the minor version and it's still useful? 1.1 was a
> minor version upgrade to HTTP and yet for all practical purposes it may
> as well have been 2.0.)

Hmm, no. HTTP reserves major version number changes to changes that 
affect the message format. HTTP/1.1 consumers are not expected to parse 
HTTP/2.0 messages.

Best regards, Julian

From len.holgate@gmail.com  Wed Jun 22 01:19:29 2011
Return-Path: <len.holgate@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE79B21F8485 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7w2jkpAmMF9F for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:19:29 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id EF81521F8483 for <hybi@ietf.org>; Wed, 22 Jun 2011 01:19:28 -0700 (PDT)
Received: by fxm15 with SMTP id 15so501099fxm.31 for <hybi@ietf.org>; Wed, 22 Jun 2011 01:19:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :x-mimeole; bh=IbEgWIf9ioE7/YxyI6oaJyvqJ0wjezHDyy1aAkXAZlU=; b=XSazyx4gAAOS7BdYP78ZE/05A4PviL6zpl0NV4lO3BuBENuz28J046GSfQZQRWAhvu /Q3pUEc0OcXHXnjna9Kt0sp40O9LQ2v0ky7NAmIFHFiyrGyzTp15WinXsgJw2KgioUUi 2kToV36ZTrYafoa5Oc5AgeHuHCBsis0eA7yfY=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=MXawsAcN14RDF/3uNNmWMimo22zg4M1z5LZc9onzoGa6OWv3PC1kSeH1HGUnMxcl6C Qx14x9zKztnKBVBbE9KHsVhy+VXQNdG5+5CEg2PoTvJb4tEGGG309MOyylW9wq4w22/U gHRp9VroPKbVisRGG2HE+UnZBOSsNx/eRmMjk=
Received: by 10.223.6.11 with SMTP id 11mr491526fax.100.1308730767991; Wed, 22 Jun 2011 01:19:27 -0700 (PDT)
Received: from Venus (cpc7-glfd6-2-0-cust20.6-2.cable.virginmedia.com [86.27.227.21]) by mx.google.com with ESMTPS id r10sm163413fah.2.2011.06.22.01.19.26 (version=SSLv3 cipher=OTHER); Wed, 22 Jun 2011 01:19:27 -0700 (PDT)
From: "Len Holgate" <len.holgate@gmail.com>
To: <hybi@ietf.org>
Date: Wed, 22 Jun 2011 09:19:24 +0100
Message-ID: <018501cc30b5$1939e460$0a00a8c0@Venus>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
Thread-Index: AcwwtRgNrQapyP4iQXS63kCCaiIeJA==
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
Subject: [hybi] Masking of Control Frames that have a zero length payload.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 08:19:29 -0000

Hi,

I haven't been able to find a previous discussion on this list about this
point, forgive me if it's already been covered.

4.3 Client-to-Server Masking 

States that "The client MUST mask all frames sent to the server."

4.5 Control Frames 

States that "All control frames MUST have a payload length of 125 bytes or
less..."

4.5.1 Close

States that "The Close frame MAY contain a body (the "application data"
portion of the frame)

Which implies to me that control frames with a zero length payload may exist
but if these are sent from client to server then these MUST still be masked,
which results in the inclusion of a masking key which is not used for
anything and simply increases the length of the frame for no reason.

Perhaps the inclusion of the rationale behind client to server masking would
clear this up - including the masking key when no data needs to be masked
makes the control frame unique and unpredictable and perhaps this is the
reason, but at present it's unclear as to why the above is desirable.

Len


From jat@google.com  Wed Jun 22 01:27:27 2011
Return-Path: <jat@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CE89E8005 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:27:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.976
X-Spam-Level: 
X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wi5EuApFG4Sz for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:27:27 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 055C19E8004 for <hybi@ietf.org>; Wed, 22 Jun 2011 01:27:26 -0700 (PDT)
Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p5M8RQ8M024326 for <hybi@ietf.org>; Wed, 22 Jun 2011 01:27:26 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308731246; bh=/MFi7xm1rDQ7gpwvbniwpM+ZZXE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NcrDk2TAmRSMe6oKUM2m9h6JoYaHSxMu3HK2qqD5FeI6egJi5rItsfb8eMav5YKul 0EwUap+yvnvDNX0xy+mSQ==
Received: from gyd8 (gyd8.prod.google.com [10.243.49.200]) by wpaz29.hot.corp.google.com with ESMTP id p5M8R7ef005372 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 01:27:25 -0700
Received: by gyd8 with SMTP id 8so343764gyd.40 for <hybi@ietf.org>; Wed, 22 Jun 2011 01:27:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=2upztOuYQWFDFtfu9hhZoLj7HicZj5nIeoZyN4SMr58=; b=HQkAZT0vs2PHFam4z8YLOAiwKvK+pbd5uunV1D9HDAH3pvUTVia2SmrxBmAM+1fMpU /FauQXHARQf2hL6TtQQA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=aeLrmEfPx2zqXflhTTbtpjNFgnMZo4z3zjl5pzJaWsQ/6D3x1Gt7uY3P3lj1GleWW9 GJxTaP2E24/riKU8YJTg==
Received: by 10.150.236.7 with SMTP id j7mr580258ybh.287.1308731245097; Wed, 22 Jun 2011 01:27:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.49.7 with HTTP; Wed, 22 Jun 2011 01:27:05 -0700 (PDT)
In-Reply-To: <018501cc30b5$1939e460$0a00a8c0@Venus>
References: <018501cc30b5$1939e460$0a00a8c0@Venus>
From: John Tamplin <jat@google.com>
Date: Wed, 22 Jun 2011 04:27:05 -0400
Message-ID: <BANLkTi=p5=rVTS9coxyu5NjMPucXqFC23Q@mail.gmail.com>
To: Len Holgate <len.holgate@gmail.com>
Content-Type: multipart/alternative; boundary=000e0cd240c0f8737e04a648bced
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Masking of Control Frames that have a zero length payload.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 08:27:27 -0000

--000e0cd240c0f8737e04a648bced
Content-Type: text/plain; charset=UTF-8

On Wed, Jun 22, 2011 at 4:19 AM, Len Holgate <len.holgate@gmail.com> wrote:

> I haven't been able to find a previous discussion on this list about this
> point, forgive me if it's already been covered.
>
> 4.3 Client-to-Server Masking
>
> States that "The client MUST mask all frames sent to the server."
>
> 4.5 Control Frames
>
> States that "All control frames MUST have a payload length of 125 bytes or
> less..."
>
> 4.5.1 Close
>
> States that "The Close frame MAY contain a body (the "application data"
> portion of the frame)
>
> Which implies to me that control frames with a zero length payload may
> exist
> but if these are sent from client to server then these MUST still be
> masked,
> which results in the inclusion of a masking key which is not used for
> anything and simply increases the length of the frame for no reason.
>
> Perhaps the inclusion of the rationale behind client to server masking
> would
> clear this up - including the masking key when no data needs to be masked
> makes the control frame unique and unpredictable and perhaps this is the
> reason, but at present it's unclear as to why the above is desirable.
>

IMHO, the utility of a zero-length frame seems low enough that it doesn't
warrant adding a special case to leave off the mask if the payload length is
zero.

-- 
John A. Tamplin
Software Engineer (GWT), Google

--000e0cd240c0f8737e04a648bced
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 22, 2011 at 4:19 AM, Len Holgate <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:len.holgate@gmail.com">len.holgate@gma=
il.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I haven&#39;t been able to find a previous discussion on this list about th=
is<br>
point, forgive me if it&#39;s already been covered.<br>
<br>
4.3 Client-to-Server Masking<br>
<br>
States that &quot;The client MUST mask all frames sent to the server.&quot;=
<br>
<br>
4.5 Control Frames<br>
<br>
States that &quot;All control frames MUST have a payload length of 125 byte=
s or<br>
less...&quot;<br>
<br>
4.5.1 Close<br>
<br>
States that &quot;The Close frame MAY contain a body (the &quot;application=
 data&quot;<br>
portion of the frame)<br>
<br>
Which implies to me that control frames with a zero length payload may exis=
t<br>
but if these are sent from client to server then these MUST still be masked=
,<br>
which results in the inclusion of a masking key which is not used for<br>
anything and simply increases the length of the frame for no reason.<br>
<br>
Perhaps the inclusion of the rationale behind client to server masking woul=
d<br>
clear this up - including the masking key when no data needs to be masked<b=
r>
makes the control frame unique and unpredictable and perhaps this is the<br=
>
reason, but at present it&#39;s unclear as to why the above is desirable.<b=
r></blockquote></div><div><br></div>IMHO, the utility of a zero-length fram=
e seems low enough that it doesn&#39;t warrant adding a special case to lea=
ve off the mask if the payload length is zero.<br clear=3D"all">

<br>-- <br>John A. Tamplin<br>Software Engineer (GWT), Google<br>

--000e0cd240c0f8737e04a648bced--

From Norio.Kobota@jp.sony.com  Wed Jun 22 01:55:11 2011
Return-Path: <Norio.Kobota@jp.sony.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADA6C11E809A for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:55:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.394
X-Spam-Level: 
X-Spam-Status: No, score=-0.394 tagged_above=-999 required=5 tests=[AWL=0.101,  BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553,  RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpXgC8OtYcdf for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 01:55:11 -0700 (PDT)
Received: from ms4.sony.co.jp (ms4.sony.co.jp [IPv6:2001:cf8:0:56::198]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8289E800F for <hybi@ietf.org>; Wed, 22 Jun 2011 01:55:09 -0700 (PDT)
Received: from mta8.sony.co.jp (mta8.sony.co.jp [IPv6:2001:cf8:0:191::15]) by ms4.sony.co.jp (R8/Sony) with ESMTP id p5M8t7QA012352 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:55:07 +0900 (JST)
Received: from mta8.sony.co.jp (localhost [127.0.0.1]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p5M8t7O3017628 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:55:07 +0900 (JST)
Received: from jptkyxbh102.jp.sony.com ([43.15.31.4]) by mta8.sony.co.jp (R8/Sony) with ESMTP id p5M8t6Qr017419 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:55:07 +0900 (JST)
Received: from jptkyxim101.jp.sony.com ([43.15.31.5]) by jptkyxbh102.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675);  Wed, 22 Jun 2011 17:55:00 +0900
Received: from [43.0.235.115] ([43.0.235.115]) by jptkyxim101.jp.sony.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 22 Jun 2011 17:55:01 +0900
Message-ID: <4E01ADE7.7050800@jp.sony.com>
Date: Wed, 22 Jun 2011 17:55:03 +0900
From: Norio Kobota <norio.kobota@jp.sony.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: hybi@ietf.org
References: <1308720860.5393.18.camel@tot.local>
In-Reply-To: <1308720860.5393.18.camel@tot.local>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-OriginalArrivalTime: 22 Jun 2011 08:55:01.0202 (UTC) FILETIME=[12107320:01CC30BA]
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 08:55:11 -0000

Hi,

I think that 63 bits-length is too big for single frame, too.
But there is no need to provide any header in handshake.

The websocket frame format has a FIN bit for fragment message.
So we can use this bit when we want to send very long message.

I think that the websocket frame format can be more simple.

+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| Payload len |    Extended payload length    |
|I|S|S|S|  (4)  |A|     (7)     |             (16)              |
|N|V|V|V|       |S|             |   (if payload len==126)       |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+-------------------------------+
| Masking-key, if MASK set to 1 | Masking-key (continued)       |
+-------------------------------+-------------------------------+
|          Payload Data...                                      |
+---------------------------------------------------------------+
|          Payload Data (continued)                             |
+---------------------------------------------------------------+
or
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R| opcode|M| reserve     |    Payload length             |
|I|S|S|S|  (4)  |A| (7)         |    (16)                       |
|N|V|V|V|       |S|             |                               |
| |1|2|3|       |K|             |                               |
+-+-+-+-+-------+-+-------------+-------------------------------+
| Masking-key, if MASK set to 1 | Masking-key (continued)       |
+-------------------------------+-------------------------------+
|          Payload Data                                         |
+---------------------------------------------------------------+
|          Payload Data (continued)                             |
+---------------------------------------------------------------+

Regards, nori

(2011/06/22 14:34), Francis Brosnan Blázquez wrote:
> Hi,
>
> Current frame design allows to send a very big single frame size (63
> bits). In terms of memory a websocket server will have problems with
> this because he must buffer all content until he can deliver the entire
> message to the app level (assuming message based API).
>
> I think we need a way for servers (and possibly clients) to notify each
> other which is the max frame size each part is willing to accept so each
> site administrator can configure this according to its resources,
> application type, number of connections, etc.
>
> I think a simple header notified at the websocket handshake will provide
> this valuable control to each party:
>
>     Max-Frame-Size: 4096
>
> This will cause each party to fragment application level messages if it
> is found bigger than Max-Frame-Size.
>
> In the same direction, if not provided Max-Frame-Size, it looks
> reasonable to assume a default value for this header. Again, 4096 bytes
> looks like a good value.
>
> What do you think?
>
>
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>


From ifette@google.com  Wed Jun 22 02:03:52 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABD511E809A for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:03:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.676
X-Spam-Level: 
X-Spam-Status: No, score=-104.676 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5OLqnpSp-4hB for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:03:52 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id AF49C11E8098 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:03:51 -0700 (PDT)
Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p5M93os8022631 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:03:50 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308733430; bh=YbKgVe3X6icgtahcrjMbDil2veE=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=PVbt+mpzUWHOH5/x/G/5lY7zE2O++yhwGK5tqYjTICMK0vfYPUmNam5rZdevEGLr+ /Q9YiqYjd6U8Ni9VR+TNA==
Received: from iyn35 (iyn35.prod.google.com [10.241.52.99]) by wpaz9.hot.corp.google.com with ESMTP id p5M93ms6007786 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 02:03:49 -0700
Received: by iyn35 with SMTP id 35so659581iyn.24 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:03:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=ZQsHjLQWbqT7aJvNfFxE1KUrB8wu6Yzo1Org1VbiCog=; b=TcwC4hHbPVADDOrnfwN0K95rLf/grLPInuEM4eUdiVbNm73ypx6FqQ3f8swxS6xWtf OfKMBymTjjYMdDy6/LTg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=GdYoQJsQfO39o4x0i/9fp2eZQ81l7Imd5wdbxu3CABSHYNW/iihwFJUtGrAn+hWqA6 GkOubnC04d/R/oshTvSg==
MIME-Version: 1.0
Received: by 10.231.60.73 with SMTP id o9mr445752ibh.33.1308733427584; Wed, 22 Jun 2011 02:03:47 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Wed, 22 Jun 2011 02:03:47 -0700 (PDT)
In-Reply-To: <4E01ADE7.7050800@jp.sony.com>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com>
Date: Wed, 22 Jun 2011 02:03:47 -0700
Message-ID: <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Norio Kobota <norio.kobota@jp.sony.com>
Content-Type: multipart/alternative; boundary=0015176f0d280e90e004a6493fe4
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 09:03:52 -0000

--0015176f0d280e90e004a6493fe4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We spent almost a year before we got to the point on agreeing on framing.
We're now in last call. It's not the time to re-open such lengthy
conversations based on individual preferences (e.g. you're not saying
anything the group hasn't already considered).

As for negotiation, that's a very complex topic, which, while interesting,
is not necessary for the base protocol to function. I would suggest that if
you're interested you propose text for an extension that would handle
negotiation of such parameters as optimal/max frame sizes etc.

-Ian

On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota <norio.kobota@jp.sony.com>wro=
te:

> Hi,
>
> I think that 63 bits-length is too big for single frame, too.
> But there is no need to provide any header in handshake.
>
> The websocket frame format has a FIN bit for fragment message.
> So we can use this bit when we want to send very long message.
>
> I think that the websocket frame format can be more simple.
>
> +-+-+-+-+-------+-+-----------**--+---------------------------**----+
> |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
> |I|S|S|S|  (4)  |A|     (7)     |             (16)              |
> |N|V|V|V|       |S|             |   (if payload len=3D=3D126)       |
> | |1|2|3|       |K|             |                               |
> +-+-+-+-+-------+-+-----------**--+---------------------------**----+
> | Masking-key, if MASK set to 1 | Masking-key (continued)       |
> +-----------------------------**--+---------------------------**----+
> |          Payload Data...                                      |
> +-----------------------------**------------------------------**----+
> |          Payload Data (continued)                             |
> +-----------------------------**------------------------------**----+
> or
> +-+-+-+-+-------+-+-----------**--+---------------------------**----+
> |F|R|R|R| opcode|M| reserve     |    Payload length             |
> |I|S|S|S|  (4)  |A| (7)         |    (16)                       |
> |N|V|V|V|       |S|             |                               |
> | |1|2|3|       |K|             |                               |
> +-+-+-+-+-------+-+-----------**--+---------------------------**----+
> | Masking-key, if MASK set to 1 | Masking-key (continued)       |
> +-----------------------------**--+---------------------------**----+
> |          Payload Data                                         |
> +-----------------------------**------------------------------**----+
> |          Payload Data (continued)                             |
> +-----------------------------**------------------------------**----+
>
> Regards, nori
>
>
> (2011/06/22 14:34), Francis Brosnan Bl=C3=A1zquez wrote:
>
>> Hi,
>>
>> Current frame design allows to send a very big single frame size (63
>> bits). In terms of memory a websocket server will have problems with
>> this because he must buffer all content until he can deliver the entire
>> message to the app level (assuming message based API).
>>
>> I think we need a way for servers (and possibly clients) to notify each
>> other which is the max frame size each part is willing to accept so each
>> site administrator can configure this according to its resources,
>> application type, number of connections, etc.
>>
>> I think a simple header notified at the websocket handshake will provide
>> this valuable control to each party:
>>
>>    Max-Frame-Size: 4096
>>
>> This will cause each party to fragment application level messages if it
>> is found bigger than Max-Frame-Size.
>>
>> In the same direction, if not provided Max-Frame-Size, it looks
>> reasonable to assume a default value for this header. Again, 4096 bytes
>> looks like a good value.
>>
>> What do you think?
>>
>>
>>
>>
>>
>> ______________________________**_________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailma=
n/listinfo/hybi>
>>
>>
>>
> ______________________________**_________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman=
/listinfo/hybi>
>

--0015176f0d280e90e004a6493fe4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

We spent almost a year before we got to the point on agreeing on framing. W=
e&#39;re now in last call. It&#39;s not the time to re-open such lengthy co=
nversations based on individual preferences (e.g. you&#39;re not saying any=
thing the group hasn&#39;t already considered).<div>
<br></div><div>As for negotiation, that&#39;s a very complex topic, which, =
while interesting, is not necessary for the base protocol to function. I wo=
uld suggest that if you&#39;re interested you propose text for an extension=
 that would handle negotiation of such parameters as optimal/max frame size=
s etc.</div>
<div><br></div><div>-Ian<br><br><div class=3D"gmail_quote">On Wed, Jun 22, =
2011 at 1:55 AM, Norio Kobota <span dir=3D"ltr">&lt;<a href=3D"mailto:norio=
.kobota@jp.sony.com">norio.kobota@jp.sony.com</a>&gt;</span> wrote:<br><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex;">
Hi,<br>
<br>
I think that 63 bits-length is too big for single frame, too.<br>
But there is no need to provide any header in handshake.<br>
<br>
The websocket frame format has a FIN bit for fragment message.<br>
So we can use this bit when we want to send very long message.<br>
<br>
I think that the websocket frame format can be more simple.<br>
<br>
+-+-+-+-+-------+-+-----------<u></u>--+---------------------------<u></u>-=
---+<br>
|F|R|R|R| opcode|M| Payload len | =C2=A0 =C2=A0Extended payload length =C2=
=A0 =C2=A0|<br>
|I|S|S|S| =C2=A0(4) =C2=A0|A| =C2=A0 =C2=A0 (7) =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (16) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0|<br>
|N|V|V|V| =C2=A0 =C2=A0 =C2=A0 |S| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 (if payload len=3D=3D126) =C2=A0 =C2=A0 =C2=A0 |<br>
| |1|2|3| =C2=A0 =C2=A0 =C2=A0 |K| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
+-+-+-+-+-------+-+-----------<u></u>--+---------------------------<u></u>-=
---+<br>
| Masking-key, if MASK set to 1 | Masking-key (continued) =C2=A0 =C2=A0 =C2=
=A0 |<br>
+-----------------------------<u></u>--+---------------------------<u></u>-=
---+<br>
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload Data... =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
+-----------------------------<u></u>------------------------------<u></u>-=
---+<br>
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload Data (continued) =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 |<br>
+-----------------------------<u></u>------------------------------<u></u>-=
---+<br>
or<br>
+-+-+-+-+-------+-+-----------<u></u>--+---------------------------<u></u>-=
---+<br>
|F|R|R|R| opcode|M| reserve =C2=A0 =C2=A0 | =C2=A0 =C2=A0Payload length =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
|I|S|S|S| =C2=A0(4) =C2=A0|A| (7) =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=
=A0(16) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 |<br>
|N|V|V|V| =C2=A0 =C2=A0 =C2=A0 |S| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
| |1|2|3| =C2=A0 =C2=A0 =C2=A0 |K| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
+-+-+-+-+-------+-+-----------<u></u>--+---------------------------<u></u>-=
---+<br>
| Masking-key, if MASK set to 1 | Masking-key (continued) =C2=A0 =C2=A0 =C2=
=A0 |<br>
+-----------------------------<u></u>--+---------------------------<u></u>-=
---+<br>
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload Data =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
+-----------------------------<u></u>------------------------------<u></u>-=
---+<br>
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload Data (continued) =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 |<br>
+-----------------------------<u></u>------------------------------<u></u>-=
---+<br>
<br>
Regards, nori<div><div></div><div class=3D"h5"><br>
<br>
(2011/06/22 14:34), Francis Brosnan Bl=C3=A1zquez wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Current frame design allows to send a very big single frame size (63<br>
bits). In terms of memory a websocket server will have problems with<br>
this because he must buffer all content until he can deliver the entire<br>
message to the app level (assuming message based API).<br>
<br>
I think we need a way for servers (and possibly clients) to notify each<br>
other which is the max frame size each part is willing to accept so each<br=
>
site administrator can configure this according to its resources,<br>
application type, number of connections, etc.<br>
<br>
I think a simple header notified at the websocket handshake will provide<br=
>
this valuable control to each party:<br>
<br>
 =C2=A0 =C2=A0Max-Frame-Size: 4096<br>
<br>
This will cause each party to fragment application level messages if it<br>
is found bigger than Max-Frame-Size.<br>
<br>
In the same direction, if not provided Max-Frame-Size, it looks<br>
reasonable to assume a default value for this header. Again, 4096 bytes<br>
looks like a good value.<br>
<br>
What do you think?<br>
<br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/hybi</a><br>
<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/hybi</a><br>
</div></div></blockquote></div><br></div>

--0015176f0d280e90e004a6493fe4--

From andy@warmcat.com  Wed Jun 22 02:18:30 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D597111E80B9 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:18:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oemInERU7fiT for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:18:30 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5C14D11E8098 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:18:30 -0700 (PDT)
Message-ID: <4E01B364.9020608@warmcat.com>
Date: Wed, 22 Jun 2011 10:18:28 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Greg Wilkins <gregw@intalio.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>	<4E010FF9.1000207@callenish.com> <BANLkTikSQi2j9xRx8itVwvXOvTpzvqR0bw@mail.gmail.com>
In-Reply-To: <BANLkTikSQi2j9xRx8itVwvXOvTpzvqR0bw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 09:18:31 -0000

On 06/22/2011 12:31 AM, Somebody in the thread at some point said:

> the problem is more than just not using it (I have no plans of
> implementing it for my server).
>
> It is the only exemplar of an extension we have in the specification
> and as an example to follow it is terrible!  It does not follow any of

I don't think we even need to go there... "performance is worthless on 
masked data" should be enough to see something needs to happen somewhere 
about it.

-Andy

From arman@noemax.com  Wed Jun 22 02:21:07 2011
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB15011E8098 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:21:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdM2jYbSdMoq for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:21:07 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 65BC611E807F for <hybi@ietf.org>; Wed, 22 Jun 2011 02:21:05 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id FPR34503; Wed, 22 Jun 2011 12:21:03 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: "'John Tamplin'" <jat@google.com>, "'Len Holgate'" <len.holgate@gmail.com>
References: <018501cc30b5$1939e460$0a00a8c0@Venus> <BANLkTi=p5=rVTS9coxyu5NjMPucXqFC23Q@mail.gmail.com>
In-Reply-To: <BANLkTi=p5=rVTS9coxyu5NjMPucXqFC23Q@mail.gmail.com>
Date: Wed, 22 Jun 2011 12:19:58 +0300
Message-ID: <004301cc30bd$93215850$b96408f0$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH+vxgWi2wQnl1x7vFTwQEstOhfWAJj77mmlFDcQQA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Masking of Control Frames that have a zero length	payload.
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 09:21:07 -0000

> IMHO, the utility of a zero-length frame seems low enough that it =
doesn't warrant adding a special case to leave off the mask if the =
payload length is zero.

In practice 0 length frames do appear quite often as terminal frames of =
messages when data is streamed from a source of unknown length. I see =
this happening when my implementation sends the output of an object =
serializer that flushes the stream and then suddenly closes it. If the =
message stream is closed when it doesn=E2=80=99t have any data buffered, =
there is no other option but to send the 0 length terminal frame for =
this message. Control frames are of course another case when the frame =
might contain no data.

However, I think that adding the mask to ALL frames uniformly is not a =
bad idea. It=E2=80=99s not a huge waste of bandwidth and does not cause =
any significant overhead, at the same time the random mask attached to =
the frame header increases the unpredictability of the payload which =
eliminates the remote chance that an attacker could produce some attack =
sequence by playing with opcodes and reserved flags when the API would =
permit using them (highly unlikely though). In any case, I do like the =
simplicity =E2=80=93 =E2=80=9CALL frames are masked and end of =
story=E2=80=9D, the fewer IF ELSE in the spec the better.

With best regards,
Arman



From ifette@google.com  Wed Jun 22 02:27:04 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5C211E80CF for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:27:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.73
X-Spam-Level: 
X-Spam-Status: No, score=-104.73 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUKgiqR+nL61 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:27:03 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4BD2C11E80C3 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:27:03 -0700 (PDT)
Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5M9Qr2F017771 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:26:53 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308734813; bh=hh3MOCaTUpe55PBFr7fCGjRRtak=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=XsZGp202/YYNZJnsqpldeu1spCpRFLZaVlvgJZ5s5TAFgZHv+5qHHu2pU2PJYUkNA wxH0j3rqfUxFHMDi1c+1Q==
Received: from iym10 (iym10.prod.google.com [10.241.52.10]) by hpaq11.eem.corp.google.com with ESMTP id p5M9Qoll014215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 02:26:51 -0700
Received: by iym10 with SMTP id 10so615978iym.20 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:26:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=H+Ap3pT9JVHgiVETZwmOiUv+ksghgzxg5UyD/zxBrQY=; b=soTvJllfOHwGlbwgVmp64EPUkeMd2OVmM46O4n4zUttQPxhzS9eCmoM42vyPsM0JBB hK62STSHF25Vcx85CGbw==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=gta6SDxSG6N4WeaPcEcmdq+ndB5IUJOvWLs+oxvGJ8b3PxLxWDhH2CWQrCKoTYGiDJ SN0k0ANgjZkbgsb1sYSg==
MIME-Version: 1.0
Received: by 10.231.41.69 with SMTP id n5mr467539ibe.83.1308734810186; Wed, 22 Jun 2011 02:26:50 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Wed, 22 Jun 2011 02:26:50 -0700 (PDT)
In-Reply-To: <4E01B364.9020608@warmcat.com>
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com> <4E010FF9.1000207@callenish.com> <BANLkTikSQi2j9xRx8itVwvXOvTpzvqR0bw@mail.gmail.com> <4E01B364.9020608@warmcat.com>
Date: Wed, 22 Jun 2011 02:26:50 -0700
Message-ID: <BANLkTikeAGR_2RUk=QBzW43Tsg-7Biu0JwwROVbKrGcv=LErGw@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= <andy@warmcat.com>
Content-Type: multipart/alternative; boundary=0015177407d477662d04a64991bb
X-System-Of-Record: true
Cc: Hybi <hybi@ietf.org>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 09:27:04 -0000

--0015177407d477662d04a64991bb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As an individual:

Yoshino-san sent out a proposal a while ago that did a much better job of
respecting the way extensions are supposed to work. Conceptually, I think
what we really should have is

WebSocket Frame [ Masked Data [ Compress [ Application Data ] ] ]

That is, the application data is first compressed, /then/ that compressed
data is masked and framed as per the rest of the spec.

http://www.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-00.tx=
t

-Ian

On Wed, Jun 22, 2011 at 2:18 AM, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)"=
 <andy@warmcat.com>wrote:

> On 06/22/2011 12:31 AM, Somebody in the thread at some point said:
>
>  the problem is more than just not using it (I have no plans of
>> implementing it for my server).
>>
>> It is the only exemplar of an extension we have in the specification
>> and as an example to follow it is terrible!  It does not follow any of
>>
>
> I don't think we even need to go there... "performance is worthless on
> masked data" should be enough to see something needs to happen somewhere
> about it.
>
> -Andy
>
> ______________________________**_________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/**listinfo/hybi<https://www.ietf.org/mailman=
/listinfo/hybi>
>

--0015177407d477662d04a64991bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

As an individual:<div><br></div><div>Yoshino-san sent out a proposal a whil=
e ago that did a much better job of respecting the way extensions are suppo=
sed to work. Conceptually, I think what we really should have is</div><div>
<br></div><div>WebSocket Frame [ Masked Data [ Compress [ Application Data =
] ] ]</div><div><br></div><div>That is, the application data is first compr=
essed, /then/ that compressed data is masked and framed as per the rest of =
the spec.</div>
<div><br></div><div><a href=3D"http://www.ietf.org/id/draft-tyoshino-hybi-w=
ebsocket-perframe-deflate-00.txt">http://www.ietf.org/id/draft-tyoshino-hyb=
i-websocket-perframe-deflate-00.txt</a></div><div><br></div><div>-Ian<br>
<br><div class=3D"gmail_quote">On Wed, Jun 22, 2011 at 2:18 AM, &quot;Andy =
Green (=E6=9E=97=E5=AE=89=E5=BB=B8)&quot; <span dir=3D"ltr">&lt;<a href=3D"=
mailto:andy@warmcat.com">andy@warmcat.com</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex;">
<div class=3D"im">On 06/22/2011 12:31 AM, Somebody in the thread at some po=
int said:<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
the problem is more than just not using it (I have no plans of<br>
implementing it for my server).<br>
<br>
It is the only exemplar of an extension we have in the specification<br>
and as an example to follow it is terrible! =C2=A0It does not follow any of=
<br>
</blockquote>
<br></div>
I don&#39;t think we even need to go there... &quot;performance is worthles=
s on masked data&quot; should be enough to see something needs to happen so=
mewhere about it.<br><font color=3D"#888888">
<br>
-Andy</font><div><div></div><div class=3D"h5"><br>
______________________________<u></u>_________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org" target=3D"_blank">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/<u></u>listinfo/hybi</a><br>
</div></div></blockquote></div><br></div>

--0015177407d477662d04a64991bb--

From andy@warmcat.com  Wed Jun 22 02:44:14 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 722BB11E80CF for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:44:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.513
X-Spam-Level: 
X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ArHi9RC38h5U for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:44:13 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id B909011E807F for <hybi@ietf.org>; Wed, 22 Jun 2011 02:44:13 -0700 (PDT)
Message-ID: <4E01B8B9.7010201@warmcat.com>
Date: Wed, 22 Jun 2011 10:41:13 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: ifette@google.com
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>	<4E010FF9.1000207@callenish.com>	<BANLkTikSQi2j9xRx8itVwvXOvTpzvqR0bw@mail.gmail.com>	<4E01B364.9020608@warmcat.com> <BANLkTikeAGR_2RUk=QBzW43Tsg-7Biu0JwwROVbKrGcv=LErGw@mail.gmail.com>
In-Reply-To: <BANLkTikeAGR_2RUk=QBzW43Tsg-7Biu0JwwROVbKrGcv=LErGw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Hybi <hybi@ietf.org>, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 09:44:14 -0000

On 06/22/2011 10:26 AM, Somebody in the thread at some point said:
> As an individual:
>
> Yoshino-san sent out a proposal a while ago that did a much better job
> of respecting the way extensions are supposed to work. Conceptually, I
> think what we really should have is
>
> WebSocket Frame [ Masked Data [ Compress [ Application Data ] ] ]
>
> That is, the application data is first compressed, /then/ that
> compressed data is masked and framed as per the rest of the spec.
>
> http://www.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-00.txt

Although I don't really understand what those references devolve down to 
what zlib code and options, it looks like it solves exactly this problem.

-Andy

From francis@aspl.es  Wed Jun 22 02:52:41 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54AA711E8098 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.884
X-Spam-Level: ****
X-Spam-Status: No, score=4.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HocKs4jfa2Sf for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 02:52:40 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 24F1411E80D7 for <hybi@ietf.org>; Wed, 22 Jun 2011 02:52:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 0F7B21170003; Wed, 22 Jun 2011 11:52:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U-Y5jAZxfzEe; Wed, 22 Jun 2011 11:52:33 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 31E821170001; Wed, 22 Jun 2011 11:52:33 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Norio Kobota <norio.kobota@jp.sony.com>
In-Reply-To: <4E01ADE7.7050800@jp.sony.com>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 11:52:33 +0200
Message-ID: <1308736353.11941.584.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 09:52:41 -0000

Hi Norio,

I'm talking about a very different issue: if the server that is going to
receive a big message that can't buffer, and assuming the absence of a
max frame size notification, he only can pass incomplete parts of an
unfinished frame to the app level...that is, if the websocket header
tells you are going to receive 200MB, but you can only buffer 64k, the
server will be forced to pass to the app level this frame fragments...

Is this the pattern expected by the list?

> Hi,
> 
> I think that 63 bits-length is too big for single frame, too.
> But there is no need to provide any header in handshake.
> 
> The websocket frame format has a FIN bit for fragment message.
> So we can use this bit when we want to send very long message.
> 
> 
-- 
Francis Brosnan Blázquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).


From ibc@aliax.net  Wed Jun 22 03:07:01 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB8011E8098 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:07:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miXZf72jwkzf for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:07:00 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 22D3E11E80CF for <hybi@ietf.org>; Wed, 22 Jun 2011 03:07:00 -0700 (PDT)
Received: by qyk29 with SMTP id 29so458600qyk.10 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:06:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr306752qcq.230.1308737219289; Wed, 22 Jun 2011 03:06:59 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Wed, 22 Jun 2011 03:06:59 -0700 (PDT)
In-Reply-To: <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com>
Date: Wed, 22 Jun 2011 12:06:59 +0200
Message-ID: <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:07:01 -0000

2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
>> So what about if the websocket server is not the same as the web
>> server from which the JS code has been got? Would the WS handshake
>> request include a Cookie header (that replied in the HTTP 200 OK from
>> the server? so, should the separate websocket server do some magic
>> with the Cookie value to verify ist validity?
>
> How would you do it if you weren't using WebSockets but instead XHR? I do=
ubt
> you would use HTTP auth...

Usually XHR is sent to the same web server (so using Cookie is very
suitable), am I wrong?
Note however I'm not an expert in XHR so maybe I miss something.



> I agree that a better solution would be to do whatever authentication you
> need when the user goes to the website, and then once the user is
> authenticated open the WS connection and pass some sort of credential. Th=
at
> could be via cookies if it's on the same origin, or it could be passed ov=
er
> the established WS connection. I don't know that it should be defined in =
the
> WS API though, as different sites might want to use vastly different
> authentication mechanisms (client-side certs, passwords, oauth, ...). It'=
s
> much more flexible to leave it to the application.

Ok, but take into account that not all the WS connections would be
preceded by an access to a web page. Let's imagine a desktop wigdet
(or an Android app!) that directly open a WS connection (without
opening first a web page, so the client cannot authenticate via an
HTML form in "any custom way"). What to do then? How to prompt the
user for credentials? which authentication mechanism to use? So there
would be needed:

- An API for promting the user for credentials.
- A specified authentication mechanism for "pure websocket" connection
(without depending on a previous HTTP/HTML access).

Have the WG considered this case?


IMHO authentication should occur at protocol level, rather than at
application level. This is true in all the protocols of Internet but
HTTP, which is a jungle. But HTTP usually means displaying a web page
with some HTML form in which the user can interact by setting his
credentials, press "submit" and that's all. Such kind of
authentication level is not possible in WebSocket as a WebSocket
renders nothing to the user, a WebSocket server does reply a web page.

I still see the need to mandate the support of HTTP Digest
authentication in WebSocket (which involves an API and a section in
current specification.

Regards.




--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From francis@aspl.es  Wed Jun 22 03:12:13 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66A811E8098 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:12:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 4.884
X-Spam-Level: ****
X-Spam-Status: No, score=4.884 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172, HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T13K9Oy0HKQd for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:12:13 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id A1E8211E807F for <hybi@ietf.org>; Wed, 22 Jun 2011 03:12:12 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id E8B641170003; Wed, 22 Jun 2011 12:11:43 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU2Zy5bRj565; Wed, 22 Jun 2011 12:11:42 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 7DAFB1170001; Wed, 22 Jun 2011 12:11:42 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: ifette@google.com
In-Reply-To: <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com> <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 12:11:43 +0200
Message-ID: <1308737503.11941.641.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:12:13 -0000

Hi Ian,

> We spent almost a year before we got to the point on agreeing on
> framing. We're now in last call. It's not the time to re-open such
> lengthy conversations based on individual preferences 

I'm not trying to reconsider framing; that's ok. I'm talking about
providing a way to each party to advice is buffering capabilities which
has nothing to do with the framing format. 

> (e.g. you're not saying anything the group hasn't already considered).

Possibly but the problem is yet not addressed. I think this will cause
lot of wrong patterns and a security problem at the server side like
passing to the app level not completed frame (unfragemented or not) but
just octects because the server was unable to buffer.

That is, assuming a 2MB message, with a 64KB buffer limit, the app level
may receive a first indication that a frame was received, only 64kb, and
subsequent indications of pending content without header?

If this is the pattern accepted, this will make easy do stream injection
for those servers that won't buffer 20MB content until pass a complete
frame to the app level..

> As for negotiation, that's a very complex topic, which, while
> interesting, is not necessary for the base protocol to function. I
> would suggest that if you're interested you propose text for an
> extension that would handle negotiation of such parameters as
> optimal/max frame sizes etc.

Ok, I'll wait for your comments since I believe this is not an
individual preference but a risk at the server side. The idea is to
ensure server side delivers complete frames to the app level, not
octects without header..

> -Ian
> 
> On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota
> <norio.kobota@jp.sony.com> wrote:
>         Hi,
>         
>         I think that 63 bits-length is too big for single frame, too.
>         But there is no need to provide any header in handshake.
>         
>         The websocket frame format has a FIN bit for fragment message.
>         So we can use this bit when we want to send very long message.
>         
>         I think that the websocket frame format can be more simple.
>         
>         +-+-+-+-+-------+-+-------------+-------------------------------+
>         |F|R|R|R| opcode|M| Payload len |    Extended payload length
>            |
>         |I|S|S|S|  (4)  |A|     (7)     |             (16)
>            |
>         |N|V|V|V|       |S|             |   (if payload len==126)
>         |
>         | |1|2|3|       |K|             |
>         |
>         +-+-+-+-+-------+-+-------------+-------------------------------+
>         | Masking-key, if MASK set to 1 | Masking-key (continued)
>         |
>         +-------------------------------+-------------------------------+
>         |          Payload Data...
>            |
>         +---------------------------------------------------------------+
>         |          Payload Data (continued)
>         |
>         +---------------------------------------------------------------+
>         or
>         +-+-+-+-+-------+-+-------------+-------------------------------+
>         |F|R|R|R| opcode|M| reserve     |    Payload length
>         |
>         |I|S|S|S|  (4)  |A| (7)         |    (16)
>         |
>         |N|V|V|V|       |S|             |
>         |
>         | |1|2|3|       |K|             |
>         |
>         +-+-+-+-+-------+-+-------------+-------------------------------+
>         | Masking-key, if MASK set to 1 | Masking-key (continued)
>         |
>         +-------------------------------+-------------------------------+
>         |          Payload Data
>         |
>         +---------------------------------------------------------------+
>         |          Payload Data (continued)
>         |
>         +---------------------------------------------------------------+
>         
>         Regards, nori
>         
>         
>         
>         (2011/06/22 14:34), Francis Brosnan Blázquez wrote:
>                 Hi,
>                 
>                 Current frame design allows to send a very big single
>                 frame size (63
>                 bits). In terms of memory a websocket server will have
>                 problems with
>                 this because he must buffer all content until he can
>                 deliver the entire
>                 message to the app level (assuming message based API).
>                 
>                 I think we need a way for servers (and possibly
>                 clients) to notify each
>                 other which is the max frame size each part is willing
>                 to accept so each
>                 site administrator can configure this according to its
>                 resources,
>                 application type, number of connections, etc.
>                 
>                 I think a simple header notified at the websocket
>                 handshake will provide
>                 this valuable control to each party:
>                 
>                    Max-Frame-Size: 4096
>                 
>                 This will cause each party to fragment application
>                 level messages if it
>                 is found bigger than Max-Frame-Size.
>                 
>                 In the same direction, if not provided Max-Frame-Size,
>                 it looks
>                 reasonable to assume a default value for this header.
>                 Again, 4096 bytes
>                 looks like a good value.
>                 
>                 What do you think?
>                 
>                 
>                 
>                 
>                 
>                 _______________________________________________
>                 hybi mailing list
>                 hybi@ietf.org
>                 https://www.ietf.org/mailman/listinfo/hybi
>                 
>                 
>         
>         _______________________________________________
>         hybi mailing list
>         hybi@ietf.org
>         https://www.ietf.org/mailman/listinfo/hybi
>         
> 
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

-- 
Francis Brosnan Blázquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).


From ifette@google.com  Wed Jun 22 03:16:57 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5D311E80CF for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:16:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.242
X-Spam-Level: 
X-Spam-Status: No, score=-104.242 tagged_above=-999 required=5 tests=[AWL=-0.980, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7kKpiiRvB3+2 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:16:55 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 27B8511E80D7 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:54 -0700 (PDT)
Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p5MAGM6W003020 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:23 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308737783; bh=Nvlorj8L+lWFxJq73Dx2Fn2uXAU=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=D+SrG1FD0Syl9pHCBTlFsVmp7VIoHAM5WtPqZxV0gC7OhYkbExqR59AvcvIL+ajlr Z1TmOBBRKEp5viW2dt6Hw==
Received: from iwc10 (iwc10.prod.google.com [10.241.65.138]) by kpbe17.cbf.corp.google.com with ESMTP id p5MAGBZB027907 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:11 -0700
Received: by iwc10 with SMTP id 10so686368iwc.37 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:16:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=pLLAvHFIrIrfQUHjT8xWY9Fieltygu5s2em3GMWVCRc=; b=yeRq4Jj+wMQTiOxt61Doj+2WFW6kqs9RBZz4VwiwIjl4o8EDlvejulafdfaiDb08Xg Z9Hio37N2+kmFozLPDvA==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=O1UO4B+bgN4PGPiuuaxOHJROuBIhmOJVLz/U3JVpWlnQhCyf59ND83Uj//p5qzOk/g E974zuBScE4AjQkWxznQ==
MIME-Version: 1.0
Received: by 10.42.151.138 with SMTP id e10mr593417icw.251.1308737765190; Wed, 22 Jun 2011 03:16:05 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Wed, 22 Jun 2011 03:16:05 -0700 (PDT)
In-Reply-To: <1308737503.11941.641.camel@vulcan.aspl.local>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com> <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com> <1308737503.11941.641.camel@vulcan.aspl.local>
Date: Wed, 22 Jun 2011 03:16:05 -0700
Message-ID: <BANLkTi=VR5kfDaOm7W7zfpQb-BfNEK-8n+_BGWYXy68N+1yP2w@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Francis Brosnan Blazquez <francis@aspl.es>
Content-Type: multipart/alternative; boundary=90e6ba10b06d992aaa04a64a4100
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:16:57 -0000

--90e6ba10b06d992aaa04a64a4100
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If a frame is sent that a server is unable to buffer for whatever reason, I
would expect the server to close the connection with error code 1004



On Wed, Jun 22, 2011 at 3:11 AM, Francis Brosnan Blazquez
<francis@aspl.es>wrote:

> Hi Ian,
>
> > We spent almost a year before we got to the point on agreeing on
> > framing. We're now in last call. It's not the time to re-open such
> > lengthy conversations based on individual preferences
>
> I'm not trying to reconsider framing; that's ok. I'm talking about
> providing a way to each party to advice is buffering capabilities which
> has nothing to do with the framing format.
>
> > (e.g. you're not saying anything the group hasn't already considered).
>
> Possibly but the problem is yet not addressed. I think this will cause
> lot of wrong patterns and a security problem at the server side like
> passing to the app level not completed frame (unfragemented or not) but
> just octects because the server was unable to buffer.
>
> That is, assuming a 2MB message, with a 64KB buffer limit, the app level
> may receive a first indication that a frame was received, only 64kb, and
> subsequent indications of pending content without header?
>
> If this is the pattern accepted, this will make easy do stream injection
> for those servers that won't buffer 20MB content until pass a complete
> frame to the app level..
>
> > As for negotiation, that's a very complex topic, which, while
> > interesting, is not necessary for the base protocol to function. I
> > would suggest that if you're interested you propose text for an
> > extension that would handle negotiation of such parameters as
> > optimal/max frame sizes etc.
>
> Ok, I'll wait for your comments since I believe this is not an
> individual preference but a risk at the server side. The idea is to
> ensure server side delivers complete frames to the app level, not
> octects without header..
>
> > -Ian
> >
> > On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota
> > <norio.kobota@jp.sony.com> wrote:
> >         Hi,
> >
> >         I think that 63 bits-length is too big for single frame, too.
> >         But there is no need to provide any header in handshake.
> >
> >         The websocket frame format has a FIN bit for fragment message.
> >         So we can use this bit when we want to send very long message.
> >
> >         I think that the websocket frame format can be more simple.
> >
> >         +-+-+-+-+-------+-+-------------+------------------------------=
-+
> >         |F|R|R|R| opcode|M| Payload len |    Extended payload length
> >            |
> >         |I|S|S|S|  (4)  |A|     (7)     |             (16)
> >            |
> >         |N|V|V|V|       |S|             |   (if payload len=3D=3D126)
> >         |
> >         | |1|2|3|       |K|             |
> >         |
> >         +-+-+-+-+-------+-+-------------+------------------------------=
-+
> >         | Masking-key, if MASK set to 1 | Masking-key (continued)
> >         |
> >         +-------------------------------+------------------------------=
-+
> >         |          Payload Data...
> >            |
> >         +--------------------------------------------------------------=
-+
> >         |          Payload Data (continued)
> >         |
> >         +--------------------------------------------------------------=
-+
> >         or
> >         +-+-+-+-+-------+-+-------------+------------------------------=
-+
> >         |F|R|R|R| opcode|M| reserve     |    Payload length
> >         |
> >         |I|S|S|S|  (4)  |A| (7)         |    (16)
> >         |
> >         |N|V|V|V|       |S|             |
> >         |
> >         | |1|2|3|       |K|             |
> >         |
> >         +-+-+-+-+-------+-+-------------+------------------------------=
-+
> >         | Masking-key, if MASK set to 1 | Masking-key (continued)
> >         |
> >         +-------------------------------+------------------------------=
-+
> >         |          Payload Data
> >         |
> >         +--------------------------------------------------------------=
-+
> >         |          Payload Data (continued)
> >         |
> >         +--------------------------------------------------------------=
-+
> >
> >         Regards, nori
> >
> >
> >
> >         (2011/06/22 14:34), Francis Brosnan Bl=C3=A1zquez wrote:
> >                 Hi,
> >
> >                 Current frame design allows to send a very big single
> >                 frame size (63
> >                 bits). In terms of memory a websocket server will have
> >                 problems with
> >                 this because he must buffer all content until he can
> >                 deliver the entire
> >                 message to the app level (assuming message based API).
> >
> >                 I think we need a way for servers (and possibly
> >                 clients) to notify each
> >                 other which is the max frame size each part is willing
> >                 to accept so each
> >                 site administrator can configure this according to its
> >                 resources,
> >                 application type, number of connections, etc.
> >
> >                 I think a simple header notified at the websocket
> >                 handshake will provide
> >                 this valuable control to each party:
> >
> >                    Max-Frame-Size: 4096
> >
> >                 This will cause each party to fragment application
> >                 level messages if it
> >                 is found bigger than Max-Frame-Size.
> >
> >                 In the same direction, if not provided Max-Frame-Size,
> >                 it looks
> >                 reasonable to assume a default value for this header.
> >                 Again, 4096 bytes
> >                 looks like a good value.
> >
> >                 What do you think?
> >
> >
> >
> >
> >
> >                 _______________________________________________
> >                 hybi mailing list
> >                 hybi@ietf.org
> >                 https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> >         _______________________________________________
> >         hybi mailing list
> >         hybi@ietf.org
> >         https://www.ietf.org/mailman/listinfo/hybi
> >
> >
> >
> > _______________________________________________
> > hybi mailing list
> > hybi@ietf.org
> > https://www.ietf.org/mailman/listinfo/hybi
>
> --
> Francis Brosnan Bl=C3=A1zquez <francis.brosnan@aspl.es>
> ASPL
> 91 134 14 22 - 91 134 14 45 - 91 116 07 57
>
> AVISO LEGAL
>
> Este mensaje se dirige exclusivamente a su destinatario. Los datos
> incluidos en el presente correo son confidenciales y sometidos a secreto
> profesional, se proh=C3=ADbe divulgarlos, en virtud de las leyes vigentes=
. Si
> usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
> por cualquier motivo, le rogamos que nos lo comunique por este medio y
> proceda a destruirlo o borrarlo.
>
> En virtud de lo dispuesto en la Ley Org=C3=A1nica 15/1999, de 13 de
> diciembre, de Protecci=C3=B3n de Datos de Car=C3=A1cter Personal, le info=
rmamos de
> que sus datos de car=C3=A1cter personal, recogidos de fuentes accesibles =
al
> p=C3=BAblico o datos que usted nos ha facilitado previamente, proceden de
> bases de datos propiedad de Advanced Software Production Line, S.L.
> (ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
> rectificaci=C3=B3n, cancelaci=C3=B3n y oposici=C3=B3n dispuestos en la me=
ncionada Ley
> Org=C3=A1nica, notific=C3=A1ndolo por escrito a:
> ASPL - Protecci=C3=B3n Datos, C/Antonio Su=C3=A1rez 10 A-102, 28802, Alca=
l=C3=A1 de
> Henares (Madrid).
>
>

--90e6ba10b06d992aaa04a64a4100
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

If a frame is sent that a server is unable to buffer for whatever reason, I=
 would expect the server to close the connection with error code=C2=A0<span=
 class=3D"Apple-style-span" style=3D"font-family: monospace; font-size: 16p=
x; white-space: pre; ">1004</span><div>
<font class=3D"Apple-style-span" face=3D"monospace" size=3D"3"><span class=
=3D"Apple-style-span" style=3D"white-space: pre;"><br></span></font></div><=
div><font class=3D"Apple-style-span" face=3D"monospace" size=3D"3"><span cl=
ass=3D"Apple-style-span" style=3D"white-space: pre;"><br>
</span></font><br><div class=3D"gmail_quote">On Wed, Jun 22, 2011 at 3:11 A=
M, Francis Brosnan Blazquez <span dir=3D"ltr">&lt;<a href=3D"mailto:francis=
@aspl.es">francis@aspl.es</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex;">
Hi Ian,<br>
<div class=3D"im"><br>
&gt; We spent almost a year before we got to the point on agreeing on<br>
&gt; framing. We&#39;re now in last call. It&#39;s not the time to re-open =
such<br>
&gt; lengthy conversations based on individual preferences<br>
<br>
</div>I&#39;m not trying to reconsider framing; that&#39;s ok. I&#39;m talk=
ing about<br>
providing a way to each party to advice is buffering capabilities which<br>
has nothing to do with the framing format.<br>
<div class=3D"im"><br>
&gt; (e.g. you&#39;re not saying anything the group hasn&#39;t already cons=
idered).<br>
<br>
</div>Possibly but the problem is yet not addressed. I think this will caus=
e<br>
lot of wrong patterns and a security problem at the server side like<br>
passing to the app level not completed frame (unfragemented or not) but<br>
just octects because the server was unable to buffer.<br>
<br>
That is, assuming a 2MB message, with a 64KB buffer limit, the app level<br=
>
may receive a first indication that a frame was received, only 64kb, and<br=
>
subsequent indications of pending content without header?<br>
<br>
If this is the pattern accepted, this will make easy do stream injection<br=
>
for those servers that won&#39;t buffer 20MB content until pass a complete<=
br>
<div class=3D"im">frame to the app level..<br>
<br>
</div><div class=3D"im">&gt; As for negotiation, that&#39;s a very complex =
topic, which, while<br>
&gt; interesting, is not necessary for the base protocol to function. I<br>
&gt; would suggest that if you&#39;re interested you propose text for an<br=
>
&gt; extension that would handle negotiation of such parameters as<br>
&gt; optimal/max frame sizes etc.<br>
<br>
</div>Ok, I&#39;ll wait for your comments since I believe this is not an<br=
>
individual preference but a risk at the server side. The idea is to<br>
ensure server side delivers complete frames to the app level, not<br>
octects without header..<br>
<div><div></div><div class=3D"h5"><br>
&gt; -Ian<br>
&gt;<br>
&gt; On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota<br>
&gt; &lt;<a href=3D"mailto:norio.kobota@jp.sony.com">norio.kobota@jp.sony.c=
om</a>&gt; wrote:<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think that 63 bits-length is too big for=
 single frame, too.<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 But there is no need to provide any header=
 in handshake.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 The websocket frame format has a FIN bit f=
or fragment message.<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 So we can use this bit when we want to sen=
d very long message.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think that the websocket frame format ca=
n be more simple.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-------+-+-------------+---------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |F|R|R|R| opcode|M| Payload len | =C2=A0 =
=C2=A0Extended payload length<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |I|S|S|S| =C2=A0(4) =C2=A0|A| =C2=A0 =C2=
=A0 (7) =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (16)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |N|V|V|V| =C2=A0 =C2=A0 =C2=A0 |S| =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 (if payload len=3D=3D126)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |1|2|3| =C2=A0 =C2=A0 =C2=A0 |K| =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-------+-+-------------+---------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Masking-key, if MASK set to 1 | Masking-=
key (continued)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------------------------------+---------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payloa=
d Data...<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------------------------------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payloa=
d Data (continued)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------------------------------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 or<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-------+-+-------------+---------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |F|R|R|R| opcode|M| reserve =C2=A0 =C2=A0 =
| =C2=A0 =C2=A0Payload length<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |I|S|S|S| =C2=A0(4) =C2=A0|A| (7) =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0(16)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |N|V|V|V| =C2=A0 =C2=A0 =C2=A0 |S| =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | |1|2|3| =C2=A0 =C2=A0 =C2=A0 |K| =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-+-+-+-+-------+-+-------------+---------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | Masking-key, if MASK set to 1 | Masking-=
key (continued)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-------------------------------+---------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payloa=
d Data<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------------------------------=
----------------------+<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payloa=
d Data (continued)<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 |<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 +-----------------------------------------=
----------------------+<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 Regards, nori<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 (2011/06/22 14:34), Francis Brosnan Bl=C3=
=A1zquez wrote:<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi,<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Current frame =
design allows to send a very big single<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 frame size (63=
<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bits). In term=
s of memory a websocket server will have<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 problems with<=
br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this because h=
e must buffer all content until he can<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 deliver the en=
tire<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 message to the=
 app level (assuming message based API).<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think we nee=
d a way for servers (and possibly<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 clients) to no=
tify each<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 other which is=
 the max frame size each part is willing<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 to accept so e=
ach<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 site administr=
ator can configure this according to its<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 resources,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 application ty=
pe, number of connections, etc.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 I think a simp=
le header notified at the websocket<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 handshake will=
 provide<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this valuable =
control to each party:<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0M=
ax-Frame-Size: 4096<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This will caus=
e each party to fragment application<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 level messages=
 if it<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 is found bigge=
r than Max-Frame-Size.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 In the same di=
rection, if not provided Max-Frame-Size,<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 it looks<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 reasonable to =
assume a default value for this header.<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Again, 4096 by=
tes<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 looks like a g=
ood value.<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 What do you th=
ink?<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ______________=
_________________________________<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hybi mailing l=
ist<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mai=
lto:hybi@ietf.org">hybi@ietf.org</a><br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"htt=
ps://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">https://www.ietf=
.org/mailman/listinfo/hybi</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 __________________________________________=
_____<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 hybi mailing list<br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:hybi@ietf.org">hybi@ietf=
.org</a><br>
&gt; =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"https://www.ietf.org/mailman/li=
stinfo/hybi" target=3D"_blank">https://www.ietf.org/mailman/listinfo/hybi</=
a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; hybi mailing list<br>
&gt; <a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blan=
k">https://www.ietf.org/mailman/listinfo/hybi</a><br>
<br>
</div></div><div><div></div><div class=3D"h5">--<br>
Francis Brosnan Bl=C3=A1zquez &lt;<a href=3D"mailto:francis.brosnan@aspl.es=
">francis.brosnan@aspl.es</a>&gt;<br>
ASPL<br>
91 134 14 22 - 91 134 14 45 - 91 116 07 57<br>
<br>
AVISO LEGAL<br>
<br>
Este mensaje se dirige exclusivamente a su destinatario. Los datos<br>
incluidos en el presente correo son confidenciales y sometidos a secreto<br=
>
profesional, se proh=C3=ADbe divulgarlos, en virtud de las leyes vigentes. =
Si<br>
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo<br=
>
por cualquier motivo, le rogamos que nos lo comunique por este medio y<br>
proceda a destruirlo o borrarlo.<br>
<br>
En virtud de lo dispuesto en la Ley Org=C3=A1nica 15/1999, de 13 de<br>
diciembre, de Protecci=C3=B3n de Datos de Car=C3=A1cter Personal, le inform=
amos de<br>
que sus datos de car=C3=A1cter personal, recogidos de fuentes accesibles al=
<br>
p=C3=BAblico o datos que usted nos ha facilitado previamente, proceden de<b=
r>
bases de datos propiedad de Advanced Software Production Line, S.L.<br>
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,<br>
rectificaci=C3=B3n, cancelaci=C3=B3n y oposici=C3=B3n dispuestos en la menc=
ionada Ley<br>
Org=C3=A1nica, notific=C3=A1ndolo por escrito a:<br>
ASPL - Protecci=C3=B3n Datos, C/Antonio Su=C3=A1rez 10 A-102, 28802, Alcal=
=C3=A1 de<br>
Henares (Madrid).<br>
<br>
</div></div></blockquote></div><br></div>

--90e6ba10b06d992aaa04a64a4100--

From francis@aspl.es  Wed Jun 22 03:35:00 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0865121F8490 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:35:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.584
X-Spam-Level: ***
X-Spam-Status: No, score=3.584 tagged_above=-999 required=5 tests=[AWL=1.300,  BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172,  HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e371O0yIpg2E for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:34:59 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 60D7E21F848C for <hybi@ietf.org>; Wed, 22 Jun 2011 03:34:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id D47F81170003; Wed, 22 Jun 2011 12:33:31 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWcmYBwPc9up; Wed, 22 Jun 2011 12:33:30 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id D808C1170001; Wed, 22 Jun 2011 12:33:30 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Willy Tarreau <w@1wt.eu>
In-Reply-To: <20110622060514.GF18843@1wt.eu>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 12:33:31 +0200
Message-ID: <1308738811.11941.704.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:35:00 -0000

Hi Willy,

> There is nothing in the protocol which makes whole frame buffering mandatory

I know, but I'm not talking about buffering, I'm talking about what to
do when you receive more content than you can buffer. 

With the current design, the server have the following options: close
the connection, or keep buffering or pass octects directly to the app
level without having a frame header (with previous frame closed)...all 3
options are really bad idea.

Assuming this escenario, it clear the sending part can send the content
already splitted so that the server can deliver complete frames to the
app level (not just bytes in the middle) and close the connection when
the advised buffer is exceeded...

Regards,

-- 
Francis Brosnan Blázquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).


From ibc@aliax.net  Wed Jun 22 03:43:05 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3211E80D7 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:43:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.663
X-Spam-Level: 
X-Spam-Status: No, score=-2.663 tagged_above=-999 required=5 tests=[AWL=0.014,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQhT7aXsTEOI for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:43:04 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAAC11E80EC for <hybi@ietf.org>; Wed, 22 Jun 2011 03:43:04 -0700 (PDT)
Received: by qyk9 with SMTP id 9so3214840qyk.10 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:42:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.90.83 with SMTP id h19mr317540qcm.268.1308739368469; Wed, 22 Jun 2011 03:42:48 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Wed, 22 Jun 2011 03:42:48 -0700 (PDT)
In-Reply-To: <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com>
Date: Wed, 22 Jun 2011 12:42:48 +0200
Message-ID: <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:43:05 -0000

2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
>> Ok, but take into account that not all the WS connections would be
>> preceded by an access to a web page. Let's imagine a desktop wigdet
>> (or an Android app!) that directly open a WS connection (without
>> opening first a web page, so the client cannot authenticate via an
>> HTML form in "any custom way"). What to do then? How to prompt the
>> user for credentials? which authentication mechanism to use? So there
>> would be needed:
>
> A desktop widget / android app / ... surely already faces this problem wi=
th
> whatever communication mechanism they use, and I would be frankly amazed =
if
> they expected to solve it with http auth...

So:

- Web developers don't like HTTP authentication in web pages and
prefer authentication at application level. I agree, it's nicer, but
it relies on the fact that HTTP usualy carries a web page (application
data) in which the user can fill a form, submit, and get
authentication and a Cookie for a session.

- This WG does not want to cover authentication mechanism at all for
WebSocket protocol, and instead leave it again at application level.
But here there is no a rendered web page in which the user can fill a
login form. So...

Assuming that any websocket connection would be preceded by a web
access (in which login and a session Cookie has been got) would be a
terrible error IMHO. So, does nobody agree that WS needs a built-in
authentication mechanism? Honestly I cannot understand. Hope I miss
something very important in this topic.


PS: Ian, could I know what you propose on this topic? For now you have
given reasons not to mandate HTTP auth. Could I know how will Google
authenticate WS connections in separate just-WS-servers? maybe
validating the Cookie header (initially retrieved from the web page)
against a centralized storage backend? or maybe you plan to build an
authentication mechanism within the WS carried subprotocol? (just
wondering, I don't want to know Google's internals).

Regards.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ifette@google.com  Wed Jun 22 03:53:01 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E201A11E80F2 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:53:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.367
X-Spam-Level: 
X-Spam-Status: No, score=-105.367 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qz62pdfPgLBN for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:53:01 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8AF11E80EC for <hybi@ietf.org>; Wed, 22 Jun 2011 03:53:00 -0700 (PDT)
Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p5MALjKP032019 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:21:45 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308738105; bh=tD78slwr6sjqclOrMuXaWvy5lLI=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=XTwMNdJmx3pzocIrdpAjPcJFDtIcHGqJnEAjpoONqvG9O7uRa+39bhXhXXTw3clkm fZb2h3WcDsEdNBM4CLj8w==
Received: from iyb26 (iyb26.prod.google.com [10.241.49.90]) by wpaz1.hot.corp.google.com with ESMTP id p5MALheO032429 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 03:21:44 -0700
Received: by iyb26 with SMTP id 26so616496iyb.9 for <hybi@ietf.org>; Wed, 22 Jun 2011 03:21:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OnvS48sPG16kJR3Ppn98Wom6qmg0dPjdlkVb1dgFJl4=; b=sn+iNiJq42edE6A1W1AxKwku2OsLbblo5VhMNGRg6t5lbnyLCt6yPuzOcG/pzXwOI4 FqvirxfwKqcJBG11rgQg==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=JXwNU1Mo6mxafS9hI8JfcdY4Lkn3abvNcE0HWvFq0vIeg4C0TIsHF24UOOF1CF0IfL rQFfRWdlLA2D9coEX7XQ==
MIME-Version: 1.0
Received: by 10.231.60.73 with SMTP id o9mr505938ibh.33.1308738103522; Wed, 22 Jun 2011 03:21:43 -0700 (PDT)
Received: by 10.231.33.8 with HTTP; Wed, 22 Jun 2011 03:21:43 -0700 (PDT)
In-Reply-To: <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com>
Date: Wed, 22 Jun 2011 03:21:43 -0700
Message-ID: <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=0015176f0d28c3b72604a64a5586
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:53:02 -0000

--0015176f0d28c3b72604a64a5586
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 22, 2011 at 3:06 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> 2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> >> So what about if the websocket server is not the same as the web
> >> server from which the JS code has been got? Would the WS handshake
> >> request include a Cookie header (that replied in the HTTP 200 OK from
> >> the server? so, should the separate websocket server do some magic
> >> with the Cookie value to verify ist validity?
> >
> > How would you do it if you weren't using WebSockets but instead XHR? I
> doubt
> > you would use HTTP auth...
>
> Usually XHR is sent to the same web server (so using Cookie is very
> suitable), am I wrong?
> Note however I'm not an expert in XHR so maybe I miss something.
>
>
>
XHR can be sent to a different origin. http://www.w3.org/TR/cors/


>
> > I agree that a better solution would be to do whatever authentication y=
ou
> > need when the user goes to the website, and then once the user is
> > authenticated open the WS connection and pass some sort of credential.
> That
> > could be via cookies if it's on the same origin, or it could be passed
> over
> > the established WS connection. I don't know that it should be defined i=
n
> the
> > WS API though, as different sites might want to use vastly different
> > authentication mechanisms (client-side certs, passwords, oauth, ...).
> It's
> > much more flexible to leave it to the application.
>
> Ok, but take into account that not all the WS connections would be
> preceded by an access to a web page. Let's imagine a desktop wigdet
> (or an Android app!) that directly open a WS connection (without
> opening first a web page, so the client cannot authenticate via an
> HTML form in "any custom way"). What to do then? How to prompt the
> user for credentials? which authentication mechanism to use? So there
> would be needed:
>

A desktop widget / android app / ... surely already faces this problem with
whatever communication mechanism they use, and I would be frankly amazed if
they expected to solve it with http auth...


>
> - An API for promting the user for credentials.
> - A specified authentication mechanism for "pure websocket" connection
> (without depending on a previous HTTP/HTML access).
>
> Have the WG considered this case?
>
>
> IMHO authentication should occur at protocol level, rather than at
> application level. This is true in all the protocols of Internet but
> HTTP, which is a jungle. But HTTP usually means displaying a web page
> with some HTML form in which the user can interact by setting his
> credentials, press "submit" and that's all. Such kind of
> authentication level is not possible in WebSocket as a WebSocket
> renders nothing to the user, a WebSocket server does reply a web page.
>
> I still see the need to mandate the support of HTTP Digest
> authentication in WebSocket (which involves an API and a section in
> current specification.
>
> Regards.
>
>
>
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>

--0015176f0d28c3b72604a64a5586
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 22, 2011 at 3:06 AM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">2011/6/22 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=
=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) &lt;<a href=3D"mailto:ifette@google.c=
om">ifette@google.com</a>&gt;:<br>
</div><div class=3D"im">&gt;&gt; So what about if the websocket server is n=
ot the same as the web<br>
&gt;&gt; server from which the JS code has been got? Would the WS handshake=
<br>
&gt;&gt; request include a Cookie header (that replied in the HTTP 200 OK f=
rom<br>
&gt;&gt; the server? so, should the separate websocket server do some magic=
<br>
&gt;&gt; with the Cookie value to verify ist validity?<br>
&gt;<br>
&gt; How would you do it if you weren&#39;t using WebSockets but instead XH=
R? I doubt<br>
&gt; you would use HTTP auth...<br>
<br>
</div>Usually XHR is sent to the same web server (so using Cookie is very<b=
r>
suitable), am I wrong?<br>
Note however I&#39;m not an expert in XHR so maybe I miss something.<br>
<div class=3D"im"><br>
<br></div></blockquote><div><br></div><div>XHR can be sent to a different o=
rigin.=C2=A0<a href=3D"http://www.w3.org/TR/cors/">http://www.w3.org/TR/cor=
s/</a></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">
<br>
&gt; I agree that a better solution would be to do whatever authentication =
you<br>
&gt; need when the user goes to the website, and then once the user is<br>
&gt; authenticated open the WS connection and pass some sort of credential.=
 That<br>
&gt; could be via cookies if it&#39;s on the same origin, or it could be pa=
ssed over<br>
&gt; the established WS connection. I don&#39;t know that it should be defi=
ned in the<br>
&gt; WS API though, as different sites might want to use vastly different<b=
r>
&gt; authentication mechanisms (client-side certs, passwords, oauth, ...). =
It&#39;s<br>
&gt; much more flexible to leave it to the application.<br>
<br>
</div>Ok, but take into account that not all the WS connections would be<br=
>
preceded by an access to a web page. Let&#39;s imagine a desktop wigdet<br>
(or an Android app!) that directly open a WS connection (without<br>
opening first a web page, so the client cannot authenticate via an<br>
HTML form in &quot;any custom way&quot;). What to do then? How to prompt th=
e<br>
user for credentials? which authentication mechanism to use? So there<br>
would be needed:<br></blockquote><div><br></div><div>A desktop widget / and=
roid app / ... surely already faces this problem with whatever communicatio=
n mechanism they use, and I would be frankly amazed if they expected to sol=
ve it with http auth...</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
- An API for promting the user for credentials.<br>
- A specified authentication mechanism for &quot;pure websocket&quot; conne=
ction<br>
(without depending on a previous HTTP/HTML access).<br>
<br>
Have the WG considered this case?<br>
<br>
<br>
IMHO authentication should occur at protocol level, rather than at<br>
application level. This is true in all the protocols of Internet but<br>
HTTP, which is a jungle. But HTTP usually means displaying a web page<br>
with some HTML form in which the user can interact by setting his<br>
credentials, press &quot;submit&quot; and that&#39;s all. Such kind of<br>
authentication level is not possible in WebSocket as a WebSocket<br>
renders nothing to the user, a WebSocket server does reply a web page.<br>
<br>
I still see the need to mandate the support of HTTP Digest<br>
authentication in WebSocket (which involves an API and a section in<br>
current specification.<br>
<br>
Regards.<br>
<font color=3D"#888888"><br>
<br>
<br>
<br>
--<br>
</font><div><div></div><div class=3D"h5">I=C3=B1aki Baz Castillo<br>
&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
</div></div></blockquote></div><br>

--0015176f0d28c3b72604a64a5586--

From francis@aspl.es  Wed Jun 22 03:55:58 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D0A11E80BC for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.151
X-Spam-Level: ***
X-Spam-Status: No, score=3.151 tagged_above=-999 required=5 tests=[AWL=0.867,  BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172,  HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ws6vCrlxD5OC for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 03:55:53 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 8C57D11E80EC for <hybi@ietf.org>; Wed, 22 Jun 2011 03:55:53 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 393B01170003; Wed, 22 Jun 2011 12:55:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6RJYI8x8Zi7; Wed, 22 Jun 2011 12:55:50 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 3E3B41170001; Wed, 22 Jun 2011 12:55:50 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: ifette@google.com
In-Reply-To: <BANLkTi=VR5kfDaOm7W7zfpQb-BfNEK-8n+_BGWYXy68N+1yP2w@mail.gmail.com>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com> <BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com> <1308737503.11941.641.camel@vulcan.aspl.local> <BANLkTi=VR5kfDaOm7W7zfpQb-BfNEK-8n+_BGWYXy68N+1yP2w@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 12:55:51 +0200
Message-ID: <1308740151.11941.767.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 10:55:58 -0000

> If a frame is sent that a server is unable to buffer for whatever
> reason, I would expect the server to close the connection with error
> code 1004 

Sorry Ian, but I don't see how this will solve the problem. 

Given the 1004 solution, the websocket server developer will have to
"assume" a default max frame size (for the reasons pointed).

He can even provide a config so every site administrator can tweak this,
however, any value selected will be easily exceeded soon or
later...causing a 1004?

At the same time current websocket javascript API do not provide a way
to send fragmented messages (which is right, this is message oriented).
However, this leads the browser to decide how to fragment content sent
to the server. 

In this context I think the browser needs the right value to avoid the
1004 error by splitting the message into frames accepted by the server.

-- 
Francis Brosnan Blázquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).


From arman@noemax.com  Wed Jun 22 05:24:57 2011
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A19911E8130 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 05:24:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMSvrOIpHKfK for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 05:24:56 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBCC11E80F5 for <hybi@ietf.org>; Wed, 22 Jun 2011 05:24:56 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id FSU12643; Wed, 22 Jun 2011 15:24:43 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: <ifette@google.com>, "'Francis Brosnan Blazquez'" <francis@aspl.es>
References: <1308720860.5393.18.camel@tot.local> <4E01ADE7.7050800@jp.sony.com>	<BANLkTinBH_UAj7kA5uKVJ2Rvg329xxfbCCrxYPTW-MhH_=-HwA@mail.gmail.com>	<1308737503.11941.641.camel@vulcan.aspl.local> <BANLkTi=VR5kfDaOm7W7zfpQb-BfNEK-8n+_BGWYXy68N+1yP2w@mail.gmail.com>
In-Reply-To: <BANLkTi=VR5kfDaOm7W7zfpQb-BfNEK-8n+_BGWYXy68N+1yP2w@mail.gmail.com>
Date: Wed, 22 Jun 2011 15:23:39 +0300
Message-ID: <005c01cc30d7$3b9eda70$b2dc8f50$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJ8i1mdz3mFqsVfocjtntDVp294NQHA3+B8ALid6AkAyELKwwED+iwIk0ZpCCA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 12:24:57 -0000

> If a frame is sent that a server is unable to buffer for whatever =
reason, I would expect the server to close the connection with error =
code 1004.

If a sever cannot buffer an entire frame for any reason then it can =
still preform local frame fragmentation just as an intermediary would =
do.

With best regards,
Arman


On Wed, Jun 22, 2011 at 3:11 AM, Francis Brosnan Blazquez =
<francis@aspl.es> wrote:
Hi Ian,

> We spent almost a year before we got to the point on agreeing on
> framing. We're now in last call. It's not the time to re-open such
> lengthy conversations based on individual preferences
I'm not trying to reconsider framing; that's ok. I'm talking about
providing a way to each party to advice is buffering capabilities which
has nothing to do with the framing format.

> (e.g. you're not saying anything the group hasn't already considered).
Possibly but the problem is yet not addressed. I think this will cause
lot of wrong patterns and a security problem at the server side like
passing to the app level not completed frame (unfragemented or not) but
just octects because the server was unable to buffer.

That is, assuming a 2MB message, with a 64KB buffer limit, the app level
may receive a first indication that a frame was received, only 64kb, and
subsequent indications of pending content without header?

If this is the pattern accepted, this will make easy do stream injection
for those servers that won't buffer 20MB content until pass a complete
frame to the app level..
> As for negotiation, that's a very complex topic, which, while
> interesting, is not necessary for the base protocol to function. I
> would suggest that if you're interested you propose text for an
> extension that would handle negotiation of such parameters as
> optimal/max frame sizes etc.
Ok, I'll wait for your comments since I believe this is not an
individual preference but a risk at the server side. The idea is to
ensure server side delivers complete frames to the app level, not
octects without header..

> -Ian
>
> On Wed, Jun 22, 2011 at 1:55 AM, Norio Kobota
> <norio.kobota@jp.sony.com> wrote:
>         Hi,
>
>         I think that 63 bits-length is too big for single frame, too.
>         But there is no need to provide any header in handshake.
>
>         The websocket frame format has a FIN bit for fragment message.
>         So we can use this bit when we want to send very long message.
>
>         I think that the websocket frame format can be more simple.
>
>         =
+-+-+-+-+-------+-+-------------+-------------------------------+
>         |F|R|R|R| opcode|M| Payload len |    Extended payload length
>            |
>         |I|S|S|S|  (4)  |A|     (7)     |             (16)
>            |
>         |N|V|V|V|       |S|             |   (if payload len=3D=3D126)
>         |
>         | |1|2|3|       |K|             |
>         |
>         =
+-+-+-+-+-------+-+-------------+-------------------------------+
>         | Masking-key, if MASK set to 1 | Masking-key (continued)
>         |
>         =
+-------------------------------+-------------------------------+
>         |          Payload Data...
>            |
>         =
+---------------------------------------------------------------+
>         |          Payload Data (continued)
>         |
>         =
+---------------------------------------------------------------+
>         or
>         =
+-+-+-+-+-------+-+-------------+-------------------------------+
>         |F|R|R|R| opcode|M| reserve     |    Payload length
>         |
>         |I|S|S|S|  (4)  |A| (7)         |    (16)
>         |
>         |N|V|V|V|       |S|             |
>         |
>         | |1|2|3|       |K|             |
>         |
>         =
+-+-+-+-+-------+-+-------------+-------------------------------+
>         | Masking-key, if MASK set to 1 | Masking-key (continued)
>         |
>         =
+-------------------------------+-------------------------------+
>         |          Payload Data
>         |
>         =
+---------------------------------------------------------------+
>         |          Payload Data (continued)
>         |
>         =
+---------------------------------------------------------------+
>
>         Regards, nori
>
>
>
>         (2011/06/22 14:34), Francis Brosnan Bl=C3=A1zquez wrote:
>                 Hi,
>
>                 Current frame design allows to send a very big single
>                 frame size (63
>                 bits). In terms of memory a websocket server will have
>                 problems with
>                 this because he must buffer all content until he can
>                 deliver the entire
>                 message to the app level (assuming message based API).
>
>                 I think we need a way for servers (and possibly
>                 clients) to notify each
>                 other which is the max frame size each part is willing
>                 to accept so each
>                 site administrator can configure this according to its
>                 resources,
>                 application type, number of connections, etc.
>
>                 I think a simple header notified at the websocket
>                 handshake will provide
>                 this valuable control to each party:
>
>                    Max-Frame-Size: 4096
>
>                 This will cause each party to fragment application
>                 level messages if it
>                 is found bigger than Max-Frame-Size.
>
>                 In the same direction, if not provided Max-Frame-Size,
>                 it looks
>                 reasonable to assume a default value for this header.
>                 Again, 4096 bytes
>                 looks like a good value.
>
>                 What do you think?
>
>
>
>
>
>                 _______________________________________________
>                 hybi mailing list
>                 hybi@ietf.org
>                 https://www.ietf.org/mailman/listinfo/hybi
>
>
>
>         _______________________________________________
>         hybi mailing list
>         hybi@ietf.org
>         https://www.ietf.org/mailman/listinfo/hybi
>
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
--
Francis Brosnan Bl=C3=A1zquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se proh=C3=ADbe divulgarlos, en virtud de las leyes =
vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Org=C3=A1nica 15/1999, de 13 de
diciembre, de Protecci=C3=B3n de Datos de Car=C3=A1cter Personal, le =
informamos de
que sus datos de car=C3=A1cter personal, recogidos de fuentes accesibles =
al
p=C3=BAblico o datos que usted nos ha facilitado previamente, proceden =
de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificaci=C3=B3n, cancelaci=C3=B3n y oposici=C3=B3n dispuestos en la =
mencionada Ley
Org=C3=A1nica, notific=C3=A1ndolo por escrito a:
ASPL - Protecci=C3=B3n Datos, C/Antonio Su=C3=A1rez 10 A-102, 28802, =
Alcal=C3=A1 de
Henares (Madrid).



From w@1wt.eu  Wed Jun 22 05:25:47 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8781111E8076 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 05:25:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.74
X-Spam-Level: 
X-Spam-Status: No, score=-4.74 tagged_above=-999 required=5 tests=[AWL=-2.697,  BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HH7iarGg1SDh for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 05:25:46 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 61DC511E8073 for <hybi@ietf.org>; Wed, 22 Jun 2011 05:25:46 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5MCPL4m022227; Wed, 22 Jun 2011 14:25:21 +0200
Date: Wed, 22 Jun 2011 14:25:21 +0200
From: Willy Tarreau <w@1wt.eu>
To: Francis Brosnan Blazquez <francis@aspl.es>
Message-ID: <20110622122521.GA22198@1wt.eu>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1308738811.11941.704.camel@vulcan.aspl.local>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 12:25:48 -0000

On Wed, Jun 22, 2011 at 12:33:31PM +0200, Francis Brosnan Blazquez wrote:
> Hi Willy,
> 
> > There is nothing in the protocol which makes whole frame buffering mandatory
> 
> I know, but I'm not talking about buffering, I'm talking about what to
> do when you receive more content than you can buffer. 
> 
> With the current design, the server have the following options: close
> the connection, or keep buffering or pass octects directly to the app
> level without having a frame header (with previous frame closed)...all 3
> options are really bad idea.

But why would it strip the frame header ? It should simply pass the frame
header and stream the data.

The server should proceed exactly as it would proceed if receiving a large
POST. All file transfer applications which support large POSTs (webmails
etc...) don't buffer everything, they pass it as a stream. Do you imagine
if the server had to buffer a DVD image or something like this before passing
it to the application ?

I don't see the difference with frames. You can call the application saying
"hey, here come 5 GB of data, please read them from this connection handle".

Regards,
Willy


From gezelter@rlgsc.com  Wed Jun 22 06:01:03 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6487511E814B for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 06:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.367
X-Spam-Level: 
X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UG+e1ZTDi7hO for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 06:01:02 -0700 (PDT)
Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 891BB11E8139 for <hybi@ietf.org>; Wed, 22 Jun 2011 06:01:02 -0700 (PDT)
Received: (qmail 29870 invoked from network); 22 Jun 2011 13:01:01 -0000
Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 22 Jun 2011 13:01:01 -0000
Received: (qmail 17351 invoked by uid 99); 22 Jun 2011 13:01:01 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 162.83.149.110
User-Agent: Web-Based Email 5.5.05
Message-Id: <20110622060058.ef1fc80126c74c6c202a919c41c7bb0b.24a5465d55.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Wed, 22 Jun 2011 06:00:58 -0700
Mime-Version: 1.0
Subject: [hybi] deflate-stream vs. frame-by-frame
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 13:01:03 -0000

Arman,

With regards to:

>I don't think we should take the "mux" extension into account when
>discussing the deflate-stream extension. Compressing "mux" channels is a
>special case that should be covered by the "mux" extension specification.
>
>Combining all multiplexed streams into a single deflate channel is a good
>idea because it is actually very cheap memory wise, otherwise compressing
>each sub-channel with a separate DEFLATE stream could end up being very
>expensive memory wise. You can expect over 200KB of memory needed per each
>sub-channel, this basically kills the whole purpose of sub-channels which
>are actually supposed to decrease the load on the server side. Two-three
>thousands of compressed sub-channels would be enough to put the server on
>its knees.
>
>I consider the deflate-stream extension just as basic transport compressio=
n
>which is offered "out of the box" by a WebSocket implementation,
>irrespective of whether it supports multiplexing or not.

There are several issues that are co-mingled in this thread.

First, there is the question of compression and masking. Compressing
masked text is of dubious utility, efficacy, and efficiency. Masking
tends to randomize text, random text is a poor candidate for compression
(in some cases, attempting to compress random text can actually cause
the "compressed" text to be larger than the original text). Taken solely
on this basis, ANY compression should precede masking.

Second, John Tamplin's draft multiplexing proposal well notes that
multiplexing opens up possibilities for various traffic management
devices (e.g., de-aggregators) at the WebSocket protocol level. Thus, a
collection of sub-channels within a WebSocket connection may end up at
different destination nodes. If the entire stream is compressed as a
whole, this will require the entire stream to be de-compressed and then
the individual sub-channels re-compressed before ongoing transmission.
This realizes little benefit over compression at the sub-channel level
(further noting that there may indeed be compression done in any event
at lower levels of the protocol stack).

Lastly, compression on a sub-channel by sub-channel basis (generally
meaning per-frame basis) does not imply a need for 200KB of buffer space
per sub-channel. Rather, the amount of buffer space required per
sub-channel depends upon the frame-size and the compression scheme used.
Some compression schemes can function with minimal context, others may
need more. In any event, compression works best with a high degree of
correlation between successive data elements, thus there is a logical
division between the frames being transmitted within different
sub-channels to (presumably) different applications.

- Bob Gezelter, http://www.rlgsc.com


From ibc@aliax.net  Wed Jun 22 06:54:36 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 441B511E808D for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 06:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level: 
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zaqp201Q+GNb for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 06:54:35 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4A221F0C44 for <hybi@ietf.org>; Wed, 22 Jun 2011 06:54:35 -0700 (PDT)
Received: by qwc23 with SMTP id 23so579927qwc.31 for <hybi@ietf.org>; Wed, 22 Jun 2011 06:54:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.115.21 with SMTP id g21mr506855qcq.230.1308750875019; Wed, 22 Jun 2011 06:54:35 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Wed, 22 Jun 2011 06:54:34 -0700 (PDT)
In-Reply-To: <20110622060058.ef1fc80126c74c6c202a919c41c7bb0b.24a5465d55.wbe@email03.secureserver.net>
References: <20110622060058.ef1fc80126c74c6c202a919c41c7bb0b.24a5465d55.wbe@email03.secureserver.net>
Date: Wed, 22 Jun 2011 15:54:34 +0200
Message-ID: <BANLkTi=9mKTRWd=FnDECohbrFCoQ95LhOA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Bob Gezelter <gezelter@rlgsc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] deflate-stream vs. frame-by-frame
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 13:54:36 -0000

2011/6/22 Bob Gezelter <gezelter@rlgsc.com>:
> First, there is the question of compression and masking. Compressing
> masked text is of dubious utility, efficacy, and efficiency. Masking
> tends to randomize text, random text is a poor candidate for compression
> (in some cases, attempting to compress random text can actually cause
> the "compressed" text to be larger than the original text). Taken solely
> on this basis, ANY compression should precede masking.

I expect this is obvious for everyone (or should be). Will not WS
draft be adapted to fulfill this obvious reality?

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From arman@noemax.com  Wed Jun 22 07:50:56 2011
Return-Path: <arman@noemax.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D9121F853B for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 07:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHfLwbVcIpqW for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 07:50:55 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id AB22021F853A for <hybi@ietf.org>; Wed, 22 Jun 2011 07:50:55 -0700 (PDT)
Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id FUU46953 for <hybi@ietf.org>; Wed, 22 Jun 2011 17:50:53 +0300
From: "Arman Djusupov" <arman@noemax.com>
To: <hybi@ietf.org>
References: <20110622060058.ef1fc80126c74c6c202a919c41c7bb0b.24a5465d55.wbe@email03.secureserver.net>
In-Reply-To: <20110622060058.ef1fc80126c74c6c202a919c41c7bb0b.24a5465d55.wbe@email03.secureserver.net>
Date: Wed, 22 Jun 2011 17:49:50 +0300
Message-ID: <006301cc30eb$a74beb00$f5e3c100$@noemax.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQE7bOykHjR32LJwBM8bXshsQWSgq5Xq/EOg
Content-Language: en-us
Subject: Re: [hybi] deflate-stream vs. frame-by-frame
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 14:50:56 -0000

> First, there is the question of compression and masking. Compressing=20
> masked text is of dubious utility, efficacy, and efficiency. Masking=20
> tends to randomize text, random text is a poor candidate for=20
> compression (in some cases, attempting to compress random text can=20
> actually cause the "compressed" text to be larger than the original=20
> text). Taken solely on this basis, ANY compression should precede =
masking.

Agree, compression should be applied before masking or not applied at =
all.=20
=20
> Lastly, compression on a sub-channel by sub-channel basis (generally=20
> meaning per-frame basis) does not imply a need for 200KB of buffer=20
> space per sub-channel. Rather, the amount of buffer space required per
> sub- channel depends upon the frame-size and the compression scheme =
used.
> Some compression schemes can function with minimal context, others may =

> need more. In any event, compression works best with a high degree of=20
> correlation between successive data elements, thus there is a logical=20
> division between the frames being transmitted within different=20
> sub-channels to
> (presumably) different applications.

Yes, there are solutions on how to efficiently compress mux channels but =
these do not need to be defined in the current spec. IMO a mux extension =
should offer its own, independent compression extension which could be =
more efficient with mux frames.

The "deflate-stream" should either be removed or adapted to be applied =
prior to masking to be good for general purpose transport compression. =
But in any case, since "deflate-stream" is optional it is not required =
to be ideal for mux frames compression.

With best regards,
Arman


From francis@aspl.es  Wed Jun 22 08:35:19 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4818821F84A2 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:35:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.934
X-Spam-Level: **
X-Spam-Status: No, score=2.934 tagged_above=-999 required=5 tests=[AWL=0.650,  BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172,  HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJLK5WAAOo6G for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:35:18 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBAB21F849C for <hybi@ietf.org>; Wed, 22 Jun 2011 08:35:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 746A71170003; Wed, 22 Jun 2011 17:35:13 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cRqp8ShiJ3l; Wed, 22 Jun 2011 17:35:12 +0200 (CEST)
Received: from [192.168.0.132] (barracuda [10.0.0.4]) by mail.aspl.es (Postfix) with ESMTP id 387B41170001; Wed, 22 Jun 2011 17:35:12 +0200 (CEST)
From: Francis Brosnan Blazquez <francis@aspl.es>
To: Willy Tarreau <w@1wt.eu>
In-Reply-To: <20110622122521.GA22198@1wt.eu>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu>
Content-Type: text/plain; charset="ISO-8859-15"
Organization: ASPL
Date: Wed, 22 Jun 2011 17:35:13 +0200
Message-ID: <1308756913.11941.823.camel@vulcan.aspl.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 15:35:19 -0000

Hi Willy,

> But why would it strip the frame header ? It should simply pass the frame
> header and stream the data.

I'm trying to figure how the use case for this would be. 

So, if the frame received is less than 127 or 65535 bytes the server
reads everything, checks header correctness and that the header
represents bits advised, etc, and then pass the data through a handler
to the user level code...but if the data is bigger, you pass a file
descriptor??

> The server should proceed exactly as it would proceed if receiving a large
> POST. All file transfer applications which support large POSTs (webmails
> etc...) don't buffer everything, they pass it as a stream. Do you imagine
> if the server had to buffer a DVD image or something like this before passing
> it to the application ?

I see your example but this is not the same. In the POST case you have a
single app handling its data (HTTP). 

In the websocket case you have a webserver + an application level code
that implements an application protocol that is unknown to the webserver
so it is not a nice pattern to just pass a file descriptor to the app
level...

> I don't see the difference with frames. You can call the application saying
> "hey, here come 5 GB of data, please read them from this connection handle".

Ok, the way it should be done, assuming we have a message/frame oriented
protocol, is that the app level register a handler which is called every
time a single frame is received. 

This way, the handler is called, for example, each 4k, so the handler
can receive those 5GB with minimum memory allocation and with the
security it handles messages not raw access to a file descriptor (with
the security and code complexity implications it has).

> Regards,
> Willy
> 

-- 
Francis Brosnan Blázquez <francis.brosnan@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).


From andy@warmcat.com  Wed Jun 22 08:48:46 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0155411E807A for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:48:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.487
X-Spam-Level: 
X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jrFv4WWZNeQL for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:48:45 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6320111E811B for <hybi@ietf.org>; Wed, 22 Jun 2011 08:48:45 -0700 (PDT)
Message-ID: <4E020EDB.7010606@warmcat.com>
Date: Wed, 22 Jun 2011 16:48:43 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Francis Brosnan Blazquez <francis@aspl.es>
References: <1308720860.5393.18.camel@tot.local>	<20110622060514.GF18843@1wt.eu>	<1308738811.11941.704.camel@vulcan.aspl.local>	<20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local>
In-Reply-To: <1308756913.11941.823.camel@vulcan.aspl.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 15:48:46 -0000

On 06/22/2011 04:35 PM, Somebody in the thread at some point said:

Hi -

> So, if the frame received is less than 127 or 65535 bytes the server
> reads everything, checks header correctness and that the header
> represents bits advised, etc, and then pass the data through a handler
> to the user level code...but if the data is bigger, you pass a file
> descriptor??

There's more than one way to write the code to deal with this, but the 
way that is immune to running out of buffer space or funny boundary 
conditions / packet fragmentation fragility is to pass everything 
through a bytewise state machine, as Willy says treat it strictly as a 
stream of bytes.

Then you really don't care about what size packets it comes in, how big 
a frame can be, you interpret the frame header as each byte of it comes 
in and just buffer payload locally using any size buffer or none at all, 
and spill those up to the guy who takes payload for that kind of frame 
as it fills up or you see it was the last byte.

> This way, the handler is called, for example, each 4k, so the handler
> can receive those 5GB with minimum memory allocation and with the
> security it handles messages not raw access to a file descriptor (with
> the security and code complexity implications it has).

I guess you could write it like that but it has other problems, like 
blocking and timeout management that are handled neatly by having the 
state machine as the one place for everything.

-Andy

From ferg@caucho.com  Wed Jun 22 08:58:40 2011
Return-Path: <ferg@caucho.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6C911E8125 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.185
X-Spam-Level: 
X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RFhyMiVFsjG for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 08:58:40 -0700 (PDT)
Received: from nm5-vm0.bullet.mail.sp2.yahoo.com (nm5-vm0.bullet.mail.sp2.yahoo.com [98.139.91.204]) by ietfa.amsl.com (Postfix) with SMTP id 7E3D311E80C7 for <hybi@ietf.org>; Wed, 22 Jun 2011 08:58:40 -0700 (PDT)
Received: from [98.139.91.68] by nm5.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jun 2011 15:58:40 -0000
Received: from [98.139.91.10] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jun 2011 15:58:40 -0000
Received: from [127.0.0.1] by omp1010.mail.sp2.yahoo.com with NNFMP; 22 Jun 2011 15:58:40 -0000
X-Yahoo-Newman-Id: 422962.8506.bm@omp1010.mail.sp2.yahoo.com
Received: (qmail 13752 invoked from network); 22 Jun 2011 15:58:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308758320; bh=OXkfMCfrliYiPB3xId7pqe764cPara8Jp09KG/UhinE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=gaL+qSPYpdZxbmeG3Ix0MznLH8h+p+evfHaJnDxIaz9RCtAi/5BMry7kj6mDQ3ns2dpdygdN0LSsGuiYmMB3zu5QZEQhiRnuyPjMxA/kMa29g3eVH4imqXvtVwy7akFycUOXIehde5IcPAVEiHNu8Fc3oOd4RrOeWcZtqR2XiCg=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: IYJDEwMVM1k5LkMbn9pW0gUxWevI93P_7Ax9O3gushCtNMt A5fbFmQlq3omSMChgT5DvrQZG_ef__ewAHq6z6rmLoWp6GzzCwogRbzvpZK. 6AyNTf2yr1xosapCmuQuVoRBlR8NKWjLKQF4qGHr8DLXt3tdO_UnK.G.oCd6 lKo8z81m98a2zKIbeySVsgas6F3C.cQc01uE6q0R9OSoM.Tnm5WditexWaxm _7lFyGD7uQ_1S_wFbAESDbqyC8FIz7nZfRYdMjo5wcSdGTR3s8depYaGBgPH SXNGCp2Fo6sOurRqCRltEDSt2egsZ5O8fjMlyuvvaYJnPDJ.umXRZbWhF5kB u2MtEvwrXaLWunwKKe.mgxHUlx740zjZBOwknNUoI5w--
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 22 Jun 2011 08:58:40 -0700 PDT
Message-ID: <4E021121.5050409@caucho.com>
Date: Wed, 22 Jun 2011 08:58:25 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: hybi@ietf.org
References: <1308720860.5393.18.camel@tot.local>	<20110622060514.GF18843@1wt.eu>	<1308738811.11941.704.camel@vulcan.aspl.local>	<20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local>
In-Reply-To: <1308756913.11941.823.camel@vulcan.aspl.local>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 15:58:41 -0000

On 06/22/2011 08:35 AM, Francis Brosnan Blazquez wrote:
>
>> I don't see the difference with frames. You can call the application saying
>> "hey, here come 5 GB of data, please read them from this connection handle".
> Ok, the way it should be done, assuming we have a message/frame oriented
> protocol, is that the app level register a handler which is called every
> time a single frame is received.

No. It's like a HTTP chunked POST, where the application receives a 
stream of data, not the underlying HTTP chunks.

A server (or client) which exposes the frames as its primary API is 
doing it wrong.

> This way, the handler is called, for example, each 4k, so the handler
> can receive those 5GB with minimum memory allocation and with the
> security it handles messages not raw access to a file descriptor (with
> the security and code complexity implications it has).

See stdio.h, specifically the FILE methods like fdopen, fread, fgets, 
etc. That's the level of abstraction the application needs to see.

-- Scott

>> Regards,
>> Willy
>>


From ibc@aliax.net  Wed Jun 22 09:05:50 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1663C1F0C3D for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 09:05:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level: 
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6ye3V3pTTAn for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 09:05:49 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id A7F371F0C57 for <hybi@ietf.org>; Wed, 22 Jun 2011 09:05:41 -0700 (PDT)
Received: by qyk29 with SMTP id 29so692945qyk.10 for <hybi@ietf.org>; Wed, 22 Jun 2011 09:05:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.17.17 with SMTP id q17mr663538qca.154.1308758740595; Wed, 22 Jun 2011 09:05:40 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Wed, 22 Jun 2011 09:05:40 -0700 (PDT)
In-Reply-To: <4E021121.5050409@caucho.com>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local> <4E021121.5050409@caucho.com>
Date: Wed, 22 Jun 2011 18:05:40 +0200
Message-ID: <BANLkTikKr15rBt2oLyO1vTtihyjy5c4fpA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Scott Ferguson <ferg@caucho.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 16:05:50 -0000

2011/6/22 Scott Ferguson <ferg@caucho.com>:
> No. It's like a HTTP chunked POST, where the application receives a strea=
m
> of data, not the underlying HTTP chunks.
>
> A server (or client) which exposes the frames as its primary API is doing=
 it
> wrong.

Completely right. There is something in OSI and Internet model called
"layers" (even if here we are already in application layer).

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From bruce@callenish.com  Wed Jun 22 10:38:09 2011
Return-Path: <bruce@callenish.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC6021F852B for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 10:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P8ABmhHSjWG for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 10:38:09 -0700 (PDT)
Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 3F06421F84C7 for <hybi@ietf.org>; Wed, 22 Jun 2011 10:38:09 -0700 (PDT)
Received: from [24.108.133.142] (helo=[192.168.145.100]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from <bruce@callenish.com>) id 1QZRNQ-0007tq-1v; Wed, 22 Jun 2011 10:38:08 -0700
Message-ID: <4E022872.4060606@callenish.com>
Date: Wed, 22 Jun 2011 10:37:54 -0700
From: Bruce Atherton <bruce@callenish.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version: 1.0
To: ifette@google.com
References: <BANLkTi=UVMAd1nER6mRBe7zoD29CSbCkGA@mail.gmail.com>	<4E010FF9.1000207@callenish.com>	<BANLkTikSQi2j9xRx8itVwvXOvTpzvqR0bw@mail.gmail.com>	<4E01B364.9020608@warmcat.com> <BANLkTikeAGR_2RUk=QBzW43Tsg-7Biu0JwwROVbKrGcv=LErGw@mail.gmail.com>
In-Reply-To: <BANLkTikeAGR_2RUk=QBzW43Tsg-7Biu0JwwROVbKrGcv=LErGw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - callenish.com
Cc: Hybi <hybi@ietf.org>
Subject: Re: [hybi] deflate-stream and masking
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 17:38:10 -0000

If the suggestion is to add deflate-frame as proposed in that document 
to the spec as a known extension, then that is a tune I can hum along 
to. There would be no cost to doing that since there would be no 
requirement to implement it if someone didn't want to. The only question 
is whether deflate-frame been tested enough in implementations that we 
can be confident it is going to be stable.

Removing deflate-stream from the spec as a known extension is a separate 
question. Sure, it is useless and a terrible example of how to create a 
websocket extension, but there are probably a few people that have 
implementations. Do these extensions suddenly become "unknown"? What 
would be the consequence of that?

Personally I would be fine with the removal of deflate-stream, but I 
recognize there are issues.

On 22/06/2011 2:26 AM, Ian Fette (ã‚¤ã‚¢ãƒ³ãƒ•ã‚§ãƒƒãƒ†ã‚£) wrote:
> As an individual:
>
> Yoshino-san sent out a proposal a while ago that did a much better job 
> of respecting the way extensions are supposed to work. Conceptually, I 
> think what we really should have is
>
> WebSocket Frame [ Masked Data [ Compress [ Application Data ] ] ]
>
> That is, the application data is first compressed, /then/ that 
> compressed data is masked and framed as per the rest of the spec.
>
> http://www.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-00.txt
>
> -Ian
>


From gezelter@rlgsc.com  Wed Jun 22 14:58:50 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFCFF11E807B for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 14:58:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level: 
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy83rQKF3sJy for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 14:58:50 -0700 (PDT)
Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 02D6011E8073 for <hybi@ietf.org>; Wed, 22 Jun 2011 14:58:49 -0700 (PDT)
Received: (qmail 27929 invoked from network); 22 Jun 2011 21:58:48 -0000
Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 22 Jun 2011 21:58:48 -0000
Received: (qmail 26488 invoked by uid 99); 22 Jun 2011 21:58:48 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 162.83.149.110
User-Agent: Web-Based Email 5.5.05
Message-Id: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Wed, 22 Jun 2011 14:58:47 -0700
Mime-Version: 1.0
Subject: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 21:58:51 -0000

The FILE methods in stdio.h include a "number of bytes" parameter. In
the context of the WebSocket protocol, the natural unit would appear to
be the frame. Once the frame has been retrieved by a user, then a
character-by-character state machine may (emphasis MAY) be appropriate,
however, the interface is best (most efficient) if entire frames can be
transferred at a time.

If programs must pull one character at a time, the efficiency will be
poor, with a large amount of overhead being consumed moving up and down
the call tree.

For an example of how a past message-based protocol deal with this
issue, Digital's NSP (see citation below) is an example. NSP handled
long messages by segmentation, passing the segments in order to user
program.

- Bob Gezelter, http://www.rlgsc.com

Digital Equipment Corporation (1984, July) =E2=80=9CDECnet DIGITAL Network
Architecture NSP Functional Specification, Phase IV, Version 4.0.1=E2=80=9D=
,
Retrieved from http://linux-decnet.sourceforge.net/docs/nsp401.txt on
March 23, 2011


From w@1wt.eu  Wed Jun 22 15:15:10 2011
Return-Path: <w@1wt.eu>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B17221F0C45 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 15:15:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.37
X-Spam-Level: 
X-Spam-Status: No, score=-4.37 tagged_above=-999 required=5 tests=[AWL=-2.927,  BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_46=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j2zTqizcTkJu for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 15:15:10 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id B0F471F0C41 for <hybi@ietf.org>; Wed, 22 Jun 2011 15:15:09 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p5MMF1mS024529; Thu, 23 Jun 2011 00:15:01 +0200
Date: Thu, 23 Jun 2011 00:15:01 +0200
From: Willy Tarreau <w@1wt.eu>
To: Bob Gezelter <gezelter@rlgsc.com>
Message-ID: <20110622221501.GB24102@1wt.eu>
References: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 22:15:11 -0000

Hi Bob,

On Wed, Jun 22, 2011 at 02:58:47PM -0700, Bob Gezelter wrote:
> The FILE methods in stdio.h include a "number of bytes" parameter. In
> the context of the WebSocket protocol, the natural unit would appear to
> be the frame. Once the frame has been retrieved by a user, then a
> character-by-character state machine may (emphasis MAY) be appropriate,
> however, the interface is best (most efficient) if entire frames can be
> transferred at a time.
> 
> If programs must pull one character at a time, the efficiency will be
> poor, with a large amount of overhead being consumed moving up and down
> the call tree.

Obviously, and noone is recommending to do that! But the most common
read/write streaming loop is the appropriate way to do this in my
opinion, as it's done in any stream-based processor :

process_frame(int socket, int bytesleft)
{
    while (bytesleft > 0) {
        int bytes = read(socket, buffer, buffer_size);
        process(buffer, bytes);
        bytesleft -= bytes;
    }
}

Large frames will mostly be used for video streaming or file transfers.
It totally makes sense to use a loop similar to the above to write bytes
to disk (in case of file upload) or to pass the stream to the video
decoder. Here we're just facing a streaming protocol (which was the
goal of WebSockets since the beginning) so I don't see what's new here.

It is possible that the frames make people think they should process
them at once, but frames are just here to make streaming easier to
handle. It can be easier to think as an uninterrupted stream with
some occasional checkpoints.

Regards,
Willy


From andy@warmcat.com  Wed Jun 22 15:18:12 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6BC1F0C47 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 15:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.466
X-Spam-Level: 
X-Spam-Status: No, score=-2.466 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gxVO0QLhGiwA for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 15:18:12 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id F2A141F0C45 for <hybi@ietf.org>; Wed, 22 Jun 2011 15:18:11 -0700 (PDT)
Message-ID: <4E026A1C.2030603@warmcat.com>
Date: Wed, 22 Jun 2011 23:18:04 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: Bob Gezelter <gezelter@rlgsc.com>
References: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net>
In-Reply-To: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 22:18:12 -0000

On 06/22/2011 10:58 PM, Somebody in the thread at some point said:
> The FILE methods in stdio.h include a "number of bytes" parameter. In
> the context of the WebSocket protocol, the natural unit would appear to
> be the frame. Once the frame has been retrieved by a user, then a
> character-by-character state machine may (emphasis MAY) be appropriate,
> however, the interface is best (most efficient) if entire frames can be
> transferred at a time.

That's true but it's inherently fragile when 63-bit length frames are 
allowed by the protocol but cannot be buffered.  It means there's a 
ceiling where the code must act different or break based on its 
buffering arrangements.

Requiring maximum frame size buffers per connection may also present 
scaling problems.

> If programs must pull one character at a time, the efficiency will be
> poor, with a large amount of overhead being consumed moving up and down
> the call tree.

Well, it depends.  You'll notice that "...and just buffer payload 
locally using any size buffer or none at all...", so buffering at the 
layer that contains the state machine is possible with this technique 
and reduces the calls to the handler dramatically even with a small 
buffer.  And with this technique, there's no dependency on that buffer 
size compared to max frame size so scalability is improved.

-Andy



From gezelter@rlgsc.com  Wed Jun 22 15:26:39 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD8F1F0C42 for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 15:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.444
X-Spam-Level: 
X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M01fKNkCwb1U for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 15:26:38 -0700 (PDT)
Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id C791D1F0C38 for <hybi@ietf.org>; Wed, 22 Jun 2011 15:26:38 -0700 (PDT)
Received: (qmail 12071 invoked from network); 22 Jun 2011 22:26:38 -0000
Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 22 Jun 2011 22:26:38 -0000
Received: (qmail 5677 invoked by uid 99); 22 Jun 2011 22:26:38 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 162.83.149.110
User-Agent: Web-Based Email 5.5.05
Message-Id: <20110622152637.ef1fc80126c74c6c202a919c41c7bb0b.727d09b396.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Wed, 22 Jun 2011 15:26:37 -0700
Mime-Version: 1.0
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 22:26:39 -0000

Andy and Willy,

Agreed. I just wanted to explicitly mention the critical efficiency
issue. Since frames can be extremely large, perhaps it would be
appropriate to designate a term for some sub-frame quantum to be
handled. Such a quantum (e.g., a segment) would be small enough to be
processed with reasonable resources.

- Bob Gezelter, http://www.rlgsc.com


From Martin.Thomson@commscope.com  Wed Jun 22 16:15:41 2011
Return-Path: <Martin.Thomson@commscope.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9298721F853B for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 16:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YTgsIMd1izND for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 16:15:40 -0700 (PDT)
Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 8669A21F8478 for <hybi@ietf.org>; Wed, 22 Jun 2011 16:15:40 -0700 (PDT)
X-AuditID: 0a0404e8-b7baaae0000009ea-5c-4e0277a743ad
Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id 1B.33.02538.7A7720E4; Wed, 22 Jun 2011 18:15:51 -0500 (CDT)
Received: from CDCE10HC1.commscope.com (10.86.20.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 22 Jun 2011 18:15:56 -0500
Received: from SISPE7HC2.commscope.com (10.97.4.13) by CDCE10HC1.commscope.com (10.86.20.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 22 Jun 2011 16:15:36 -0700
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 23 Jun 2011 07:15:34 +0800
From: "Thomson, Martin" <Martin.Thomson@commscope.com>
To: Bob Gezelter <gezelter@rlgsc.com>, "hybi@ietf.org" <hybi@ietf.org>
Date: Thu, 23 Jun 2011 07:15:33 +0800
Thread-Topic: [hybi] Interface for Large Frames
Thread-Index: AcwxK438y/PQpV1OQaGo6VpGS5CCzwABiSqw
Message-ID: <8B0A9FCBB9832F43971E38010638454F040B26C35F@SISPE7MB1.commscope.com>
References: <20110622152637.ef1fc80126c74c6c202a919c41c7bb0b.727d09b396.wbe@email03.secureserver.net>
In-Reply-To: <20110622152637.ef1fc80126c74c6c202a919c41c7bb0b.727d09b396.wbe@email03.secureserver.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 22 Jun 2011 23:15:41 -0000

On 2011-06-23 at 08:26:37, Bob Gezelter wrote:
> Andy and Willy,
>=20
> Agreed. I just wanted to explicitly mention the critical efficiency=20
> issue. Since frames can be extremely large, perhaps it would be=20
> appropriate to designate a term for some sub-frame quantum to be=20
> handled. Such a quantum (e.g., a segment) would be small enough to be=20
> processed with reasonable resources.

Such a concept might be useful within an API, but the protocol can (and sho=
uld) remain ignorant of such details.

To some extent, it depends on how capable you want your API to be.  I can e=
asily imagine a simple API that passes frames whole and rejects frames larg=
er than it wants to handle.  For a lot of applications, I imagine that this=
 would be sufficient.  A generic API doesn't have that luxury, so I'll be i=
nterested to see how it is solved.

--Martin

From ifette@google.com  Wed Jun 22 23:43:30 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6A1321F84AB for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 23:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.515
X-Spam-Level: 
X-Spam-Status: No, score=-105.515 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdYSbUl11HZa for <hybi@ietfa.amsl.com>; Wed, 22 Jun 2011 23:43:30 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CF99421F84A9 for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:29 -0700 (PDT)
Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p5N6hS2W012604 for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:28 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1308811408; bh=+mvKiKkjwcYSw3Zrbyd8UfHttaw=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=SFOJkwYLPWQBvL6hDBwBISfh8LkkyqKDhV8APisolOhv+7HCZtAV4COeYA0HeTKL+ B5ktlbUoqiez7wtLcTvmg==
Received: from qyk32 (qyk32.prod.google.com [10.241.83.160]) by hpaq7.eem.corp.google.com with ESMTP id p5N6gw8N031074 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:27 -0700
Received: by qyk32 with SMTP id 32so2349838qyk.7 for <hybi@ietf.org>; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=qxeQb3e1EJ2yV0sO+ipxDYDYZkBTijx0rjX/h+OSSyo=; b=kAdcWz6f9S9uHbtRwG5P8GYNtqDsB5HsB/oAiGn7n2uikq+YI6EScNdVPEl3P5xVV3 wPbIUtsaWl/PXvwYvDpQ==
DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; b=MZEqAi1uxzw0U2BgpPwL/rhvjhqNZKksrGUR3Y6wmV5weCh6SnHB0hNHNfD8i/lUwP mszuxRWTWuj6dRptpwxA==
MIME-Version: 1.0
Received: by 10.229.8.138 with SMTP id h10mr1200510qch.105.1308811406628; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Wed, 22 Jun 2011 23:43:26 -0700 (PDT)
In-Reply-To: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
References: <BANLkTimduZjX6YG+X23yOvwxk5CwWW6=uRexcPjhHEUkLkwu2w@mail.gmail.com>
Date: Wed, 22 Jun 2011 23:43:26 -0700
Message-ID: <BANLkTinda0p+gsc+qjYUB40gXjHxsoDoNg@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: Dan Adkins <dadkins@google.com>
Content-Type: multipart/alternative; boundary=0015176f0d70f8591204a65b66f4
X-System-Of-Record: true
Cc: hybi@ietf.org
Subject: Re: [hybi] Sec-WebSocket-Protocl
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 06:43:30 -0000

--0015176f0d70f8591204a65b66f4
Content-Type: text/plain; charset=UTF-8

I have tried to address the ambiguity, change checked in to svn -
http://trac.tools.ietf.org/wg/hybi/trac/changeset/118/websocket/draft-ietf-hybi-thewebsocketprotocol.xml

On Fri, Jun 17, 2011 at 1:53 PM, Dan Adkins <dadkins@google.com> wrote:

> If the client does not specify a subprotocol, is the server allowed to
> respond with one?
>
> Section 1.3:
>   The |Sec-WebSocket-Protocol| request-header field can be used to
>   indicate what subprotocols (application-level protocols layered over
>   the WebSocket protocol) are acceptable to the client.  The server
>   selects one of the acceptable protocols and echoes that value in its
>   handshake to indicate that it has selected that protocol.
> ...
>  Option fields can also be included.  In this version of the protocol,
>   the main option field is |Sec-WebSocket-Protocol|, which indicates
>   the subprotocol that the server has selected.  Web browsers verify
>   that the server included one of the values as was specified in the
>   WebSocket client's handshake.  A server that speaks multiple
>   subprotocols has to make sure it selects one based on the client's
>   handshake and specifies it in its handshake.
>
> From this, it appears not.  But there's some ambiguity with the
> mention of multiple subprotocols.
>
> Section 5.2.2:
>       /subprotocol/
>          Either a single value or null, representing the subprotocol
>          the server is ready to use.  If the server supports multiple
>          subprotocols, then the value MUST be derived from the client's
>          handshake, specifically by selecting one of the values from
>          the "Sec-WebSocket-Protocol" field.  The absence of such a
>          field is equivalent to the null value.  The empty string is
>          not the same as the null value for these purposes, and is not
>          a legal value for this field.  The ABNF for the value of this
>          header is (token), where the definitions of constructs and
>          rules are as given in [RFC2616].
>
> So, we know what the server MUST do if the server supports multiple
> subprotocols.  But what if the client didn't include that field?  Is
> the server free to respond with the protocol of its choice?  That
> seems strange that the server would be allowed to say to the client,
> "we're speaking this protocol, like it or not," as the client has no
> opportunity to respond.
>
> Maybe I'm reading too much into this, but it does seem like there's a
> bit of a hole in the spec as I can't find the answer to my original
> question: if the client doesn't specify a subprotocol, can the server
> dictate one?
>
> -Dan
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

--0015176f0d70f8591204a65b66f4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I have tried to address the ambiguity, change checked in to svn -=C2=A0<a h=
ref=3D"http://trac.tools.ietf.org/wg/hybi/trac/changeset/118/websocket/draf=
t-ietf-hybi-thewebsocketprotocol.xml">http://trac.tools.ietf.org/wg/hybi/tr=
ac/changeset/118/websocket/draft-ietf-hybi-thewebsocketprotocol.xml</a><br>
<br><div class=3D"gmail_quote">On Fri, Jun 17, 2011 at 1:53 PM, Dan Adkins =
<span dir=3D"ltr">&lt;<a href=3D"mailto:dadkins@google.com">dadkins@google.=
com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
If the client does not specify a subprotocol, is the server allowed to<br>
respond with one?<br>
<br>
Section 1.3:<br>
 =C2=A0 The |Sec-WebSocket-Protocol| request-header field can be used to<br=
>
 =C2=A0 indicate what subprotocols (application-level protocols layered ove=
r<br>
 =C2=A0 the WebSocket protocol) are acceptable to the client. =C2=A0The ser=
ver<br>
 =C2=A0 selects one of the acceptable protocols and echoes that value in it=
s<br>
 =C2=A0 handshake to indicate that it has selected that protocol.<br>
...<br>
 =C2=A0Option fields can also be included. =C2=A0In this version of the pro=
tocol,<br>
 =C2=A0 the main option field is |Sec-WebSocket-Protocol|, which indicates<=
br>
 =C2=A0 the subprotocol that the server has selected. =C2=A0Web browsers ve=
rify<br>
 =C2=A0 that the server included one of the values as was specified in the<=
br>
 =C2=A0 WebSocket client&#39;s handshake. =C2=A0A server that speaks multip=
le<br>
 =C2=A0 subprotocols has to make sure it selects one based on the client&#3=
9;s<br>
 =C2=A0 handshake and specifies it in its handshake.<br>
<br>
>From this, it appears not. =C2=A0But there&#39;s some ambiguity with the<br=
>
mention of multiple subprotocols.<br>
<br>
Section 5.2.2:<br>
 =C2=A0 =C2=A0 =C2=A0 /subprotocol/<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Either a single value or null, represent=
ing the subprotocol<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the server is ready to use. =C2=A0If the=
 server supports multiple<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0subprotocols, then the value MUST be der=
ived from the client&#39;s<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0handshake, specifically by selecting one=
 of the values from<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the &quot;Sec-WebSocket-Protocol&quot; f=
ield. =C2=A0The absence of such a<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0field is equivalent to the null value. =
=C2=A0The empty string is<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not the same as the null value for these=
 purposes, and is not<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a legal value for this field. =C2=A0The =
ABNF for the value of this<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0header is (token), where the definitions=
 of constructs and<br>
 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0rules are as given in [RFC2616].<br>
<br>
So, we know what the server MUST do if the server supports multiple<br>
subprotocols. =C2=A0But what if the client didn&#39;t include that field? =
=C2=A0Is<br>
the server free to respond with the protocol of its choice? =C2=A0That<br>
seems strange that the server would be allowed to say to the client,<br>
&quot;we&#39;re speaking this protocol, like it or not,&quot; as the client=
 has no<br>
opportunity to respond.<br>
<br>
Maybe I&#39;m reading too much into this, but it does seem like there&#39;s=
 a<br>
bit of a hole in the spec as I can&#39;t find the answer to my original<br>
question: if the client doesn&#39;t specify a subprotocol, can the server<b=
r>
dictate one?<br>
<br>
-Dan<br>
_______________________________________________<br>
hybi mailing list<br>
<a href=3D"mailto:hybi@ietf.org">hybi@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/hybi" target=3D"_blank">ht=
tps://www.ietf.org/mailman/listinfo/hybi</a><br>
</blockquote></div><br>

--0015176f0d70f8591204a65b66f4--

From francis@aspl.es  Thu Jun 23 04:01:06 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A055D11E807F for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:01:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.584
X-Spam-Level: **
X-Spam-Status: No, score=2.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172,  HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k4fk2s29VAmh for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:01:06 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id C120F9E8012 for <hybi@ietf.org>; Thu, 23 Jun 2011 04:01:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id 9D2761170003; Thu, 23 Jun 2011 13:01:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8RWeVjFTOkKT; Thu, 23 Jun 2011 13:01:00 +0200 (CEST)
Received: from [192.168.0.153] (unknown [89.7.176.101]) (Authenticated sender: acinom) by mail.aspl.es (Postfix) with ESMTPA id 1EBF51170001; Thu, 23 Jun 2011 13:01:00 +0200 (CEST)
From: Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?= <francis@aspl.es>
To: Scott Ferguson <ferg@caucho.com>
In-Reply-To: <4E021121.5050409@caucho.com>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local> <4E021121.5050409@caucho.com>
Content-Type: text/plain
Date: Thu, 23 Jun 2011 13:01:01 +0200
Message-Id: <1308826861.11268.47.camel@tot.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 11:01:06 -0000

Hi Scott,

> >> I don't see the difference with frames. You can call the application saying
> >> "hey, here come 5 GB of data, please read them from this connection handle".
> > Ok, the way it should be done, assuming we have a message/frame oriented
> > protocol, is that the app level register a handler which is called every
> > time a single frame is received.
> 
> No. It's like a HTTP chunked POST, where the application receives a 
> stream of data, not the underlying HTTP chunks.
> 
> A server (or client) which exposes the frames as its primary API is 
> doing it wrong.

I think you are getting my wrong maybe because I mentioned "...which is
called every single frame is received", but obviously my point is
focused on the concept of having a handler called when a frame "with
useful app level data (message)", not control frames directed to the
engine.

>From websocket draft we can read:

   The WebSocket protocol uses this framing so that specifications that
   use the WebSocket protocol can expose such connections using an
   event-based mechanism instead of requiring users of those
   specifications to implement buffering and piecing together of
   messages manually.

This definition matches the handler concept I'm exposing and...current
websocket javascript API (on message event).

> > This way, the handler is called, for example, each 4k, so the handler
> > can receive those 5GB with minimum memory allocation and with the
> > security it handles messages not raw access to a file descriptor (with
> > the security and code complexity implications it has).
> 
> See stdio.h, specifically the FILE methods like fdopen, fread, fgets, 
> etc. That's the level of abstraction the application needs to see.

..and you really think this API is suitable for a message oriented
protocol? (I assuming your fread concept will return bytes as it comes
not complete messages)

While I see this API makes the buffering (max frame size) problem for
the websocket developer to be not an issue, is in fact not solving but
moving the problem to the app level where, again, the application will
have to buffer the content until a message is completed.

I still think we need a way to each party to notify its buffering or
message size limit capabilities, *mainly*, because we have a framing
designed to notify messages, defined as *units* by the draft, not
bytes...

> -- Scott
> 
> >> Regards,
> >> Willy
> >>
> 
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi


From andy@warmcat.com  Thu Jun 23 04:12:39 2011
Return-Path: <andy@warmcat.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D9411E80E7 for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XY5MMhsbKTbb for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:12:38 -0700 (PDT)
Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id A388711E807F for <hybi@ietf.org>; Thu, 23 Jun 2011 04:12:38 -0700 (PDT)
Message-ID: <4E031FA4.10008@warmcat.com>
Date: Thu, 23 Jun 2011 12:12:36 +0100
From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= <andy@warmcat.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110531 Fedora/3.1.10-2.fc16 Thunderbird/3.1.10
MIME-Version: 1.0
To: =?UTF-8?B?RnJhbmNpcyBCcm9zbmFuIEJsw6F6cXVleg==?= <francis@aspl.es>
References: <1308720860.5393.18.camel@tot.local>	<20110622060514.GF18843@1wt.eu>	<1308738811.11941.704.camel@vulcan.aspl.local>	<20110622122521.GA22198@1wt.eu>	<1308756913.11941.823.camel@vulcan.aspl.local>	<4E021121.5050409@caucho.com> <1308826861.11268.47.camel@tot.local>
In-Reply-To: <1308826861.11268.47.camel@tot.local>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 11:12:39 -0000

On 06/23/2011 12:01 PM, Somebody in the thread at some point said:

> While I see this API makes the buffering (max frame size) problem for
> the websocket developer to be not an issue, is in fact not solving but
> moving the problem to the app level where, again, the application will
> have to buffer the content until a message is completed.
>
> I still think we need a way to each party to notify its buffering or
> message size limit capabilities, *mainly*, because we have a framing
> designed to notify messages, defined as *units* by the draft, not
> bytes...

The way I think of it is that frames are directly analogous to TCP/IP 
packets, one level up.

Everyone accepts application code has to act defensively and not make 
assumptions about tcp / ip packet lengths and if they got merged or 
fragmented along the way.  How much turns up at any given time when 
poll() or select() tells you something came must be treated like a 
random number you find out when you read from the socket and it says how 
much was ready.  You can't be expecting 32 bytes every time because you 
think that the sender always sends 32 byte packets.

It's the same with frames, reliance on assumptions about when they turn 
up, in how many pieces of what size needs to be defended against in the 
code so it's not vulnerable to problems.  If you take that approach it 
naturally leads you away from this idea you need to buffer whole frames.

-Andy

From francis@aspl.es  Thu Jun 23 04:18:53 2011
Return-Path: <francis@aspl.es>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6A511E80B6 for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:18:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.584
X-Spam-Level: **
X-Spam-Status: No, score=2.584 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_ALMOST_IP=1.889, HOST_EQ_STATIC=1.172,  HOST_EQ_STATICIP=1.511, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FeAsMyNKZcL for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:18:52 -0700 (PDT)
Received: from mail.aspl.es (196.Red-212-170-101.staticIP.rima-tde.net [212.170.101.196]) by ietfa.amsl.com (Postfix) with ESMTP id 9CFF611E807F for <hybi@ietf.org>; Thu, 23 Jun 2011 04:18:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.aspl.es (Postfix) with ESMTP id D58D01170003; Thu, 23 Jun 2011 13:18:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at aspl.es
Received: from mail.aspl.es ([127.0.0.1]) by localhost (dolphin.aspl.es [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh32gAX1nZIc; Thu, 23 Jun 2011 13:18:48 +0200 (CEST)
Received: from [192.168.0.153] (unknown [89.7.176.101]) (Authenticated sender: acinom) by mail.aspl.es (Postfix) with ESMTPA id 2DA351170001; Thu, 23 Jun 2011 13:18:48 +0200 (CEST)
From: Francis Brosnan =?ISO-8859-1?Q?Bl=E1zquez?= <francis@aspl.es>
To: "\"Andy Green" =?UTF-8?Q?=28=E6=9E=97=E5=AE=89=E5=BB=B8=29=22?= <andy@warmcat.com>
In-Reply-To: <4E026A1C.2030603@warmcat.com>
References: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net> <4E026A1C.2030603@warmcat.com>
Content-Type: text/plain; charset=ISO-8859-15
Date: Thu, 23 Jun 2011 13:18:49 +0200
Message-Id: <1308827929.11268.63.camel@tot.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.3.1 
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org, Bob Gezelter <gezelter@rlgsc.com>
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 11:18:53 -0000

Hi Andy,

> That's true but it's inherently fragile when 63-bit length frames are 
> allowed by the protocol but cannot be buffered.  It means there's a 
> ceiling where the code must act different or break based on its 
> buffering arrangements.

We have a framing with fragmentation support so each application could
decide how to handle such situations (63 bit frames), in some cases
better than stream oriented API because the application can choose the
chunk size it likes where stream oriented will return what is available
at the call time...

Whatever method used by a websocket implementation (stream oriented or
message/frame notification) I believe it is a contradiction to state
websocket is protocol designed to exchange *units* as messages but not
giving required elements to handle pointed situations, forcing people to
design stream oriented, and hence, force websocket users to
piece/buffering..

> Requiring maximum frame size buffers per connection may also present 
> scaling problems.

At the end, someone will buffer, or the websocket engine or the
application level. I think a checked websocket implementation will
buffer better than an application on top of it so, the scaling problem,
if present, will affect both methods...
-- 
Francis Brosnan Blázquez <francis@aspl.es>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL
 
En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL).
 
ASPL garantiza que los datos serán tratados con la finalidad de mantener
las oportunas relaciones comerciales o promocionales con usted o la
entidad que usted representa. No obstante, usted puede ejercitar sus
derechos de acceso, rectificación, cancelación y oposición dispuestos en
la mencionada Ley Orgánica, notificándolo por escrito a ASPL -
Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de Henares
(Madrid).





From phil127@gmail.com  Thu Jun 23 04:25:37 2011
Return-Path: <phil127@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65D911E811F for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:25:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level: 
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyc4d8qlJXsg for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:25:36 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E53311E807F for <hybi@ietf.org>; Thu, 23 Jun 2011 04:25:36 -0700 (PDT)
Received: by fxm15 with SMTP id 15so1373420fxm.31 for <hybi@ietf.org>; Thu, 23 Jun 2011 04:25:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=hg5qrGXHF+jAWGC464OWcUMlhUXi/4i74drF21O/zjM=; b=BCprB6jy0WUJ9Dbuq8DvnpT7+Pjd9uuXAelump2jmLUk+AMsFNZlSV2zScrRkKVDeM Vtlswc8KEFD7F4FwKjtHmjvTbQJBhgde7z+R+U1+mB2bao3v2HyiVLpGOBpZQ6DKAECS rgTKZ4Mdk9xcXnicbmF05aB4z7ai1uzUJymfg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=dbkUQUFFx9k/UiHODEyBRmcEt33ZsRrymxUGxvVo3z2WQsPOGL/d5tSmM0quzyM1qE IcKgCiKgozobCKXxMWO6Cb1wvY6iIPkP+EFVaz/yiB9ZO6q0WHQ9qh9+fYhG3tYEAHwv OD9M7KqpwkFOi7xXspOdSMphOu2wwrmVSSQEs=
Received: by 10.223.6.28 with SMTP id 28mr2552402fax.41.1308828335621; Thu, 23 Jun 2011 04:25:35 -0700 (PDT)
Received: from [212.201.74.125] (pptp-212-201-74-125.pptp.stw-bonn.de [212.201.74.125]) by mx.google.com with ESMTPS id h28sm923764faj.5.2011.06.23.04.25.33 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Jun 2011 04:25:34 -0700 (PDT)
Message-ID: <4E03229F.9070409@gmail.com>
Date: Thu, 23 Jun 2011 13:25:19 +0200
From: Philipp Serafin <phil127@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: hybi@ietf.org
References: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net>	<4E026A1C.2030603@warmcat.com> <1308827929.11268.63.camel@tot.local>
In-Reply-To: <1308827929.11268.63.camel@tot.local>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 11:25:37 -0000

>> Requiring maximum frame size buffers per connection may also present 
>> scaling problems.
> At the end, someone will buffer, or the websocket engine or the
> application level. I think a checked websocket implementation will
> buffer better than an application on top of it so, the scaling problem,
> if present, will affect both methods...

Hasn't XMLHTTPRequest basically the same problem?
The current JS API for XHR makes it necessary for a browser to buffer
the complete response before passing it on to the JS layer. There also
don't seem to be any clear restrictions on the maximum size of a
resource fetched via XHR.
Maybe it could be useful to see how current browsers handle the edge
case of very large XHR responses?

Regards

From brofield@gmail.com  Thu Jun 23 04:26:19 2011
Return-Path: <brofield@gmail.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31BE11E8137 for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSIMlbAbeQDU for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:26:19 -0700 (PDT)
Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by ietfa.amsl.com (Postfix) with ESMTP id 23C3F11E807F for <hybi@ietf.org>; Thu, 23 Jun 2011 04:26:19 -0700 (PDT)
Received: by pvh18 with SMTP id 18so1161703pvh.31 for <hybi@ietf.org>; Thu, 23 Jun 2011 04:26:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sECdP+mcSw5J/Tb+8b5ikVdtD0RN6KC4Q7wmJ57HjiA=; b=f2ZzCdTSaQ5vTcc6cPpeDV3SwFumWXX2KQVtREFCsog57KThzcMQsNfGizIqDO7zG0 FHEmHCRnQyeMp6W+o2B+HBqD+jZV5poeiZmztF/ZrC/87x2yJ4lGdS1f2/8QONJ6BAh2 B2hya30Fbk/ENt8QXEBNNNsKagLmIx6Sf9FFs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=jSylmujwVpQzQ0W1HiEC5vG+5eF9ONPFTavY55+k1b928DTdpu014Yk5XSgwzxizB0 L9CNmN/VoKEA/SAk+vfepFzSfnWCIjzWRY4XLMD6qUv9AiuwcE1SZEPFDMEIHdVq+e7r dkAQwbw2jnehbuegf1PR81D0ffP2XPHLFDu20=
MIME-Version: 1.0
Received: by 10.68.48.7 with SMTP id h7mr982116pbn.152.1308828378654; Thu, 23 Jun 2011 04:26:18 -0700 (PDT)
Sender: brofield@gmail.com
Received: by 10.68.51.231 with HTTP; Thu, 23 Jun 2011 04:26:18 -0700 (PDT)
In-Reply-To: <1308826861.11268.47.camel@tot.local>
References: <1308720860.5393.18.camel@tot.local> <20110622060514.GF18843@1wt.eu> <1308738811.11941.704.camel@vulcan.aspl.local> <20110622122521.GA22198@1wt.eu> <1308756913.11941.823.camel@vulcan.aspl.local> <4E021121.5050409@caucho.com> <1308826861.11268.47.camel@tot.local>
Date: Thu, 23 Jun 2011 20:26:18 +0900
X-Google-Sender-Auth: yODbhuHvrpgUkzeR8H36iPA8JSs
Message-ID: <BANLkTinnSkPx7zkBDMUk_hVyK4TrbN9=4g@mail.gmail.com>
From: Brodie Thiesfield <brodie@jellycan.com>
To: =?ISO-8859-1?Q?Francis_Brosnan_Bl=E1zquez?= <francis@aspl.es>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 11:26:19 -0000

On Thu, Jun 23, 2011 at 8:01 PM, Francis Brosnan Bl=E1zquez
<francis@aspl.es> wrote:
> Hi Scott,
>> No. It's like a HTTP chunked POST, where the application receives a
>> stream of data, not the underlying HTTP chunks.
>>
>> A server (or client) which exposes the frames as its primary API is
>> doing it wrong.
>
> I think you are getting my wrong maybe because I mentioned "...which is
> called every single frame is received", but obviously my point is
[snip]
> ..and you really think this API is suitable for a message oriented
> protocol? (I assuming your fread concept will return bytes as it comes
> not complete messages)

Scott understood you and was only talking about the data, however the
file stream API metaphor might be distracting.

Websocket is a message based protocol, but the message contents are
byte streams that might be split into any number of frames. So your
websocket layer notifies your upper layer only of the messages and
bytes. The frames are a websocket layer concept that the next layer
has no need to know of.

The websocket layer will tell the upper layer about the start of a
message, then feed it bytes until the message is complete, then tell
it that the message is complete. The bytes may come from a single
frame, or multiple frames. The upper layer has no need to know.

Think of the processing as something like the following (note that
control frames, compression, etc is ignored):

while have connection:
    receive frame header
    if first frame in message:
        notify application layer of the start of a message
    receive bytes up to max of frame length:
        pass bytes up to the application layer as message data
    if last frame in message:
        notify application layer that the message is complete

The frames are never notified to the application layer. It doesn't need to =
know.

Brodie

From ibc@aliax.net  Thu Jun 23 04:47:26 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9902C11E80C9 for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:47:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.664
X-Spam-Level: 
X-Spam-Status: No, score=-2.664 tagged_above=-999 required=5 tests=[AWL=0.013,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TDmIVDUrtXLa for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 04:47:26 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 055C811E8073 for <hybi@ietf.org>; Thu, 23 Jun 2011 04:47:25 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1219120qwc.31 for <hybi@ietf.org>; Thu, 23 Jun 2011 04:47:25 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.7.212 with SMTP id e20mr1418915qce.192.1308829645252; Thu, 23 Jun 2011 04:47:25 -0700 (PDT)
Received: by 10.229.181.209 with HTTP; Thu, 23 Jun 2011 04:47:25 -0700 (PDT)
In-Reply-To: <4E03229F.9070409@gmail.com>
References: <20110622145847.ef1fc80126c74c6c202a919c41c7bb0b.c4cc844e80.wbe@email03.secureserver.net> <4E026A1C.2030603@warmcat.com> <1308827929.11268.63.camel@tot.local> <4E03229F.9070409@gmail.com>
Date: Thu, 23 Jun 2011 13:47:25 +0200
Message-ID: <BANLkTinmZR4Eyc4TbfHgyfnv=utnRP4Pdg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Philipp Serafin <phil127@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] Interface for Large Frames
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 11:47:26 -0000

2011/6/23 Philipp Serafin <phil127@gmail.com>:
> Hasn't XMLHTTPRequest basically the same problem?
> The current JS API for XHR makes it necessary for a browser to buffer
> the complete response before passing it on to the JS layer. There also
> don't seem to be any clear restrictions on the maximum size of a
> resource fetched via XHR.
> Maybe it could be useful to see how current browsers handle the edge
> case of very large XHR responses?

I expect the problem will be more in server side than in client side.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From salvatore.loreto@ericsson.com  Thu Jun 23 05:34:50 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC42C11E812E for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 05:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.298
X-Spam-Level: 
X-Spam-Status: No, score=-106.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_92=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEo3Y84iYi1L for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 05:34:49 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7ADDC11E8107 for <hybi@ietf.org>; Thu, 23 Jun 2011 05:34:48 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-71-4e0332e716f4
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A0.47.09774.7E2330E4; Thu, 23 Jun 2011 14:34:47 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Thu, 23 Jun 2011 14:34:47 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id E9F972603	for <hybi@ietf.org>; Thu, 23 Jun 2011 15:34:46 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A28E251151	for <hybi@ietf.org>; Thu, 23 Jun 2011 15:34:46 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D195A510CF	for <hybi@ietf.org>; Thu, 23 Jun 2011 15:34:45 +0300 (EEST)
Message-ID: <4E0332E5.1090306@ericsson.com>
Date: Thu, 23 Jun 2011 15:34:45 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: hybi@ietf.org
References: <BANLkTi=ZtT5jrhZNevt8j_O5T+q0A2XD3A@mail.gmail.com>
In-Reply-To: <BANLkTi=ZtT5jrhZNevt8j_O5T+q0A2XD3A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------080602040705050605060505"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [hybi] -09: abstract and introduction
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 12:34:50 -0000

--------------080602040705050605060505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

On 6/21/11 9:10 PM, Alessandro Alinone wrote:
> Hi,
>
> I think that limiting the historical mention to HTTP polling and long 
> polling is a bit restrictive. We have been using HTTP streaming 
> very successfully for 11 years now, in many production scenarios (via 
> various techniques made available in the course of history, including: 
> ILAYER streaming on glorious Netscape 4; FRAME streaming on other very 
> old browsers; IFRAME streaming on old browsers; XHR streaming on some 
> newer browsers). So I propose to rephrase the "Background" section 
> including HTTP streaming.
>
(as individual)

Note that the first paragraph of Background section includes reference 
to RFC6202 that also cover HTTP streaming.
However I think it would be good spell out also HTTP streaming directly 
in the paragraph.

/Sal

-- 
Salvatore Loreto
www.sloreto.com




> Thanks,
>
> Alessandro
>
> -- 
> Alessandro Alinone
> co-CEO and CTO
> www.lightstreamer.com <http://www.lightstreamer.com> :: Weswit Srl
>
>
> On 6/20/11 12:57 AM, Greg Wilkins wrote:
> >  On 16 June 2011 07:10, Peter Saint-Andre<stpeter atstpeter.im  <http://stpeter.im>>  wrote:
> >>  Section 1.1 has always struck me as strange. It sounds as if we're
> >>  developing an IM protocol here! I suggest:
> >>
> >>    Historically, creating Web applications that need bidirectional
> >>    communication between a client and a server (e.g., instant messaging
> >>    and gaming applications) has required an abuse of HTTP to poll the
> >>    server for updates while sending upstream notifications as distinct
> >>    HTTP calls. [RFC6202]
> >
> >
> >  I don't think the usage of "abuse" can be justified.   There is
> >  nothing abusive about long polling and it is entirely legal HTTP.
> >  Besides that is too much of a subjective reason.
> >
> >  How about:
> >
> >    Historically, creating Web applications that need bidirectional
> >    communication between a client and a server (e.g., instant messaging
> >    and gaming applications), has required the use of HTTP to poll or long
> >    poll the server for updates.  Such usage of HTTP is less efficient
> >  and responsive
> >    that what is possible with a TCP/IP connection.
>
> Sure. I tried to leave as much of the current text alone in my suggestion.
>
> Peter
>
> -- 
> Peter Saint-Andre
> https://stpeter.im/
>


--------------080602040705050605060505
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#ffffff" text="#000000">
    On 6/21/11 9:10 PM, Alessandro Alinone wrote:
    <blockquote
      cite="mid:BANLkTi=ZtT5jrhZNevt8j_O5T+q0A2XD3A@mail.gmail.com"
      type="cite">Hi,
      <div><br>
      </div>
      <div>I think that limiting the historical mention to HTTP polling
        and long polling is a bit restrictive. We have been using HTTP
        streaming very&nbsp;successfully&nbsp;for 11 years now, in many production
        scenarios (via various techniques made available in the course
        of history, including: ILAYER streaming on glorious Netscape 4;
        FRAME streaming on other very old browsers; IFRAME streaming on
        old browsers; XHR streaming on some newer browsers). So I
        propose to rephrase the "Background" section including HTTP
        streaming.</div>
      <div><br>
      </div>
    </blockquote>
    (as individual) <br>
    <br>
    Note that the first paragraph of Background section includes
    reference to RFC6202 that also cover HTTP streaming.<br>
    However I think it would be good spell out also HTTP streaming
    directly in the paragraph.<br>
    <br>
    /Sal<br>
    <pre class="moz-signature" cols="72">-- 
Salvatore Loreto
<a class="moz-txt-link-abbreviated" href="http://www.sloreto.com">www.sloreto.com</a></pre>
    <br>
    <br>
    <br>
    <blockquote
      cite="mid:BANLkTi=ZtT5jrhZNevt8j_O5T+q0A2XD3A@mail.gmail.com"
      type="cite">
      <div>Thanks,</div>
      <div><br>
      </div>
      <div>Alessandro</div>
      <div><br>
      </div>
      <div>
        <div>--&nbsp;</div>
        Alessandro Alinone<br>
        co-CEO and CTO<br>
        <div><a moz-do-not-send="true"
            href="http://www.lightstreamer.com" target="_blank">www.lightstreamer.com</a>
          :: Weswit Srl</div>
        <div><br>
        </div>
        <div><span class="Apple-style-span" style="font-family:
            monospace; white-space: pre-wrap; font-size: medium;"><br>
          </span></div>
        <div><span class="Apple-style-span" style="font-family:
            monospace; white-space: pre-wrap; font-size: medium;">On
            6/20/11 12:57 AM, Greg Wilkins wrote:</span></div>
        <div><span class="Apple-style-span" style="font-family: 'Times
            New Roman'; font-size: medium;">
            <pre style="white-space: pre-wrap; word-wrap: break-word; width: 954px;">&gt; On 16 June 2011 07:10, Peter Saint-Andre &lt;stpeter at <a moz-do-not-send="true" href="http://stpeter.im">stpeter.im</a>&gt; wrote:
&gt;&gt; Section 1.1 has always struck me as strange. It sounds as if we're
&gt;&gt; developing an IM protocol here! I suggest:
&gt;&gt;
&gt;&gt;   Historically, creating Web applications that need bidirectional
&gt;&gt;   communication between a client and a server (e.g., instant messaging
&gt;&gt;   and gaming applications) has required an abuse of HTTP to poll the
&gt;&gt;   server for updates while sending upstream notifications as distinct
&gt;&gt;   HTTP calls. [RFC6202]
&gt; 
&gt; 
&gt; I don't think the usage of "abuse" can be justified.   There is
&gt; nothing abusive about long polling and it is entirely legal HTTP.
&gt; Besides that is too much of a subjective reason.
&gt; 
&gt; How about:
&gt; 
&gt;   Historically, creating Web applications that need bidirectional
&gt;   communication between a client and a server (e.g., instant messaging
&gt;   and gaming applications), has required the use of HTTP to poll or long
&gt;   poll the server for updates.  Such usage of HTTP is less efficient
&gt; and responsive
&gt;   that what is possible with a TCP/IP connection.

Sure. I tried to leave as much of the current text alone in my suggestion.

Peter

-- 
Peter Saint-Andre
<a moz-do-not-send="true" rel="nofollow" href="https://stpeter.im/">https://stpeter.im/</a>
</pre>
            <div><br>
            </div>
          </span></div>
      </div>
    </blockquote>
    <br>
  </body>
</html>

--------------080602040705050605060505--

From ferg@caucho.com  Thu Jun 23 09:37:41 2011
Return-Path: <ferg@caucho.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB6611E8179 for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 09:37:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.392
X-Spam-Level: 
X-Spam-Status: No, score=-1.392 tagged_above=-999 required=5 tests=[AWL=1.207,  BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZovCgJV9EVL for <hybi@ietfa.amsl.com>; Thu, 23 Jun 2011 09:37:40 -0700 (PDT)
Received: from nm18.bullet.mail.sp2.yahoo.com (nm18.bullet.mail.sp2.yahoo.com [98.139.91.88]) by ietfa.amsl.com (Postfix) with SMTP id C57D011E813D for <hybi@ietf.org>; Thu, 23 Jun 2011 09:37:40 -0700 (PDT)
Received: from [98.139.91.64] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:37:38 -0000
Received: from [98.139.91.26] by tm4.bullet.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:37:38 -0000
Received: from [127.0.0.1] by omp1026.mail.sp2.yahoo.com with NNFMP; 23 Jun 2011 16:37:38 -0000
X-Yahoo-Newman-Id: 282133.43472.bm@omp1026.mail.sp2.yahoo.com
Received: (qmail 42260 invoked from network); 23 Jun 2011 16:37:37 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1308847057; bh=1ruodZp7BQj0UvxcAaWnfwG9/zDeWDBZXINJ9Yz08u8=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=FWDNRXEXle8DtMPlD7et4Zkwg38vzzHHzcDQ4COOd7WR9uphL2KTngbCYV1GLIbcK81Y6yjUVqrugeGzn6+T1XwD6wJMmL51EjBUuYIpMoq4UPI+5BtZgKBFBBbRz7MTtTAyBUrLrkaoRZPkb3omAfPuQi762VBuLVheWrAYwV4=
X-Yahoo-Newman-Property: ymail-3
X-YMail-OSG: GKT0d08VM1ljJ6M9RC38vux9xonW6lDwzYHpCCe9U2hqKMi 4eXE1YelYUzqvqmLBpOObXZ4zyERiNYLGSJSnu4UjlRGa1Mca7lrY86YuICW vPc2F2wupKvZdXzCTQ2k0THTPtrBt9LQ7TCc9iXmhBQn5WEsZzp0Ve1884Jb zi7kL2masfuak8r.wx3YnF__DJguOpZKwio9v1QnR1HzzilfMCsUxWdEERsJ JGpqIkP02m7immJXcmXbOtUlSBT_32spqgNUBMjci9gXHW0Al8IQmKOoTBLD QnzmyoJDlJ2ltXC70G1KC3q6IzX5_D_At4kK2TY4O.at6uP3G6lOb5jQ.kNH Ol99n6fB8PxgV1XNht7AILwwG9LL.N7o_
X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C
Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 23 Jun 2011 09:37:37 -0700 PDT
Message-ID: <4E036BC1.3090400@caucho.com>
Date: Thu, 23 Jun 2011 09:37:21 -0700
From: Scott Ferguson <ferg@caucho.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: Brodie Thiesfield <brodie@jellycan.com>
References: <1308720860.5393.18.camel@tot.local>	<20110622060514.GF18843@1wt.eu>	<1308738811.11941.704.camel@vulcan.aspl.local>	<20110622122521.GA22198@1wt.eu>	<1308756913.11941.823.camel@vulcan.aspl.local>	<4E021121.5050409@caucho.com>	<1308826861.11268.47.camel@tot.local> <BANLkTinnSkPx7zkBDMUk_hVyK4TrbN9=4g@mail.gmail.com>
In-Reply-To: <BANLkTinnSkPx7zkBDMUk_hVyK4TrbN9=4g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: hybi@ietf.org
Subject: Re: [hybi] Max frame size
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 23 Jun 2011 16:37:41 -0000

On 06/23/2011 04:26 AM, Brodie Thiesfield wrote:
> On Thu, Jun 23, 2011 at 8:01 PM, Francis Brosnan Blázquez
> <francis@aspl.es>  wrote:
>> Hi Scott,
>>> No. It's like a HTTP chunked POST, where the application receives a
>>> stream of data, not the underlying HTTP chunks.
>>>
>>> A server (or client) which exposes the frames as its primary API is
>>> doing it wrong.
>
>> ..and you really think this API is suitable for a message oriented
>> protocol? (I assuming your fread concept will return bytes as it comes
>> not complete messages)
> Scott understood you and was only talking about the data, however the
> file stream API metaphor might be distracting.
>
> Websocket is a message based protocol, but the message contents are
> byte streams that might be split into any number of frames. So your
> websocket layer notifies your upper layer only of the messages and
> bytes. The frames are a websocket layer concept that the next layer
> has no need to know of.

+1

Yes, that's exactly what I'd meant.

If you use the stream model (assuming it's not too distracting), the 
FILE/fread ends when the message ends. Each new message produces a new 
FILE as the new stream which ends when the new message is fully read.

The application sees messages as distinct byte/char-streams but doesn't 
see the frames.

For example, the API could have a callback to the application for each 
message:

class WebSocketHandler {
   void onBinaryMessage(InputStream is);
   void onTextMessage(Reader in);
}

The InputStream/Reader produces bytes/chars until the message is done 
and then returns EOF.

-- Scott

> The websocket layer will tell the upper layer about the start of a
> message, then feed it bytes until the message is complete, then tell
> it that the message is complete. The bytes may come from a single
> frame, or multiple frames. The upper layer has no need to know.
>
> Think of the processing as something like the following (note that
> control frames, compression, etc is ignored):
>
> while have connection:
>      receive frame header
>      if first frame in message:
>          notify application layer of the start of a message
>      receive bytes up to max of frame length:
>          pass bytes up to the application layer as message data
>      if last frame in message:
>          notify application layer that the message is complete
>
> The frames are never notified to the application layer. It doesn't need to know.
>
> Brodie
>
>
>


From salvatore.loreto@ericsson.com  Fri Jun 24 12:28:14 2011
Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD1FE11E81E7 for <hybi@ietfa.amsl.com>; Fri, 24 Jun 2011 12:28:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.579
X-Spam-Level: 
X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arlOMktLACIi for <hybi@ietfa.amsl.com>; Fri, 24 Jun 2011 12:28:14 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 47ECF11E8084 for <hybi@ietf.org>; Fri, 24 Jun 2011 12:28:13 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c17ae00000262e-8e-4e04e54cd7f6
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id B2.72.09774.C45E40E4; Fri, 24 Jun 2011 21:28:12 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 24 Jun 2011 21:28:11 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id E73CC2603	for <hybi@ietf.org>; Fri, 24 Jun 2011 22:28:11 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B2A005114A	for <hybi@ietf.org>; Fri, 24 Jun 2011 22:28:11 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6E634507EE	for <hybi@ietf.org>; Fri, 24 Jun 2011 22:28:11 +0300 (EEST)
Message-ID: <4E04E54B.4020002@ericsson.com>
Date: Fri, 24 Jun 2011 22:28:11 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: "hybi@ietf.org" <hybi@ietf.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Subject: [hybi] Fwd: HYBI - Requested session has been scheduled for IETF 81
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 24 Jun 2011 19:28:15 -0000

Tentative times for HyBi sessions at IETF 81,
please consider that Agenda is still preliminary so time and day can still change


HYBI Session 1 (2 hours)
Thursday, Afternoon Session II 1520-1720
Room Name: 206 B
----------------------------------------------




From jat@google.com  Tue Jun 28 14:58:08 2011
Return-Path: <jat@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360B811E80F2 for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 14:58:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYSNb+7CIzts for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 14:58:07 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9845A11E80C0 for <hybi@ietf.org>; Tue, 28 Jun 2011 14:58:06 -0700 (PDT)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id p5SLw4rv009917 for <hybi@ietf.org>; Tue, 28 Jun 2011 14:58:05 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309298285; bh=AYnCMGqJXyILuqd4P2K+SrgXzYI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=h8wZmkm+F0Ja5jDRqoO2KI9j5rCgC/TWbgovfB16K5ftxiJrEY2lAJOVEPECPP6DU 4G5/ybo7ATI7BPpCHdgvQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=V+Nfv2dSU8Pbr9k0cmKXxSv1+F4rTvrXTJJaczuOOEdfHiDaef+OzGBjqIC2nOvxN WtFKbf62/nwQEFIXjJaPw==
Received: from ywb26 (ywb26.prod.google.com [10.192.2.26]) by kpbe14.cbf.corp.google.com with ESMTP id p5SLvHBo001081 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 28 Jun 2011 14:58:03 -0700
Received: by ywb26 with SMTP id 26so346548ywb.14 for <hybi@ietf.org>; Tue, 28 Jun 2011 14:58:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bBKNrMULYW4ChNl3biiYVcAeuK0sSUb21x8mY0/nFyc=; b=wJx6X5VZNTGeG7xDEARBZtGlgiZEGAn2WBUekrQTOsUXEXCqIlIwFNk58EJftXqfb6 cEhDy6MxXTPG2kyBO77Q==
Received: by 10.150.66.20 with SMTP id o20mr97414yba.344.1309298283120; Tue, 28 Jun 2011 14:58:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.49.7 with HTTP; Tue, 28 Jun 2011 14:57:43 -0700 (PDT)
In-Reply-To: <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Tue, 28 Jun 2011 17:57:43 -0400
Message-ID: <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=000e0cd51b401207a004a6ccc3ee
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jun 2011 21:58:08 -0000

--000e0cd51b401207a004a6ccc3ee
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 22, 2011 at 6:42 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> - Web developers don't like HTTP authentication in web pages and
> prefer authentication at application level. I agree, it's nicer, but
> it relies on the fact that HTTP usualy carries a web page (application
> data) in which the user can fill a form, submit, and get
> authentication and a Cookie for a session.
>

Note that cookies are problematic for supporting multiple tabs logged in
with different accounts, and are vulnerable to XSRF attacks without
additional precautions.


> - This WG does not want to cover authentication mechanism at all for
> WebSocket protocol, and instead leave it again at application level.
> But here there is no a rendered web page in which the user can fill a
> login form. So...
>
> Assuming that any websocket connection would be preceded by a web
> access (in which login and a session Cookie has been got) would be a
> terrible error IMHO. So, does nobody agree that WS needs a built-in
> authentication mechanism? Honestly I cannot understand. Hope I miss
> something very important in this topic.
>

The point is common practice in web apps is not to use HTTP authentication
anyway (aside from not being able to style it the way you want, you can't
easily log out, plus other limitations), but to have the app request the
credentials and send them to the server itself.  If it takes that approach,
then it can easily do the same thing for WS communication.

--=20
John A. Tamplin
Software Engineer (GWT), Google

--000e0cd51b401207a004a6ccc3ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 22, 2011 at 6:42 AM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">- Web developers don&#39;t like HTTP authentication in we=
b pages and</div>
prefer authentication at application level. I agree, it&#39;s nicer, but<br=
>
it relies on the fact that HTTP usualy carries a web page (application<br>
data) in which the user can fill a form, submit, and get<br>
authentication and a Cookie for a session.<br></blockquote><div><br></div><=
div>Note that cookies are problematic for supporting multiple tabs logged i=
n with different accounts, and are vulnerable to XSRF attacks without addit=
ional precautions.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">
- This WG does not want to cover authentication mechanism at all for<br>
WebSocket protocol, and instead leave it again at application level.<br>
But here there is no a rendered web page in which the user can fill a<br>
login form. So...<br>
<br>
Assuming that any websocket connection would be preceded by a web<br>
access (in which login and a session Cookie has been got) would be a<br>
terrible error IMHO. So, does nobody agree that WS needs a built-in<br>
authentication mechanism? Honestly I cannot understand. Hope I miss<br>
something very important in this topic.<br></blockquote><div><br></div><div=
>The point is common practice in web apps is not to use HTTP authentication=
 anyway (aside from not being able to style it the way you want, you can&#3=
9;t easily log out, plus other limitations), but to have the app request th=
e credentials and send them to the server itself. =C2=A0If it takes that ap=
proach, then it can easily do the same thing for WS communication.</div>

</div><br>-- <br>John A. Tamplin<br>Software Engineer (GWT), Google<br>

--000e0cd51b401207a004a6ccc3ee--

From ibc@aliax.net  Tue Jun 28 15:19:56 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3528A21F8671 for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVkNP3RR1Qhh for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:19:55 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A55DA21F8660 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:19:55 -0700 (PDT)
Received: by qwc23 with SMTP id 23so529655qwc.31 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:19:55 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.23.69 with SMTP id q5mr41622qcb.249.1309299595085; Tue, 28 Jun 2011 15:19:55 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Tue, 28 Jun 2011 15:19:55 -0700 (PDT)
In-Reply-To: <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com>
Date: Wed, 29 Jun 2011 00:19:55 +0200
Message-ID: <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jun 2011 22:19:56 -0000

2011/6/28 John Tamplin <jat@google.com>:
> Note that cookies are problematic for supporting multiple tabs logged in
> with different accounts, and are vulnerable to XSRF attacks without
> additional precautions.

But still Cookies are the only authentication mechanism mentioned in
the WS draft.



> The point is common practice in web apps is not to use HTTP authenticatio=
n
> anyway (aside from not being able to style it the way you want, you can't
> easily log out, plus other limitations),

I agree. It's ugly.


> but to have the app request the
> credentials and send them to the server itself. =C2=A0If it takes that ap=
proach,
> then it can easily do the same thing for WS communication.

Humm, in my previous mail I already explained that a web server
returns an HTML page in which the user can fill his credentials and
so. But in WebSocket, how to do that? when you connect to a WebSocket
server you don't receive a custom HTML or a form to login.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ifette@google.com  Tue Jun 28 15:21:37 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6894821F86F3 for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjZG0hwnLfpI for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:21:35 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 94AC621F86CA for <hybi@ietf.org>; Tue, 28 Jun 2011 15:21:35 -0700 (PDT)
Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p5SMLTgf031320 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:21:29 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309299694; bh=xA5qLd1fdXDMGd/KkJ57gVeYua8=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=ORSdagHAW4CMSAPYQZoAA5EODJpDGc8sdxFcAxfVIJrstB+hUoVD19ufL2omt3bGd 3swau0U9qvk+fHb4Kw3QQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=ffOLNmS5m/P3VCgJdFRsD4QLz1vXjii+Dto05fQZYugXxv1Eopn7nB6P3oK+CaVYM EfF53Iu7D1CBtjSuIO3HQ==
Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by kpbe15.cbf.corp.google.com with ESMTP id p5SMLMkt029086 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 28 Jun 2011 15:21:23 -0700
Received: by qyk9 with SMTP id 9so2283768qyk.3 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:21:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=eLkm0g3OkuMILJoVzdfLizeHbzxe7r+K3aofNSePnQ0=; b=v9J4yuDJcKobGBZxRYTtomTOkkVrQrfX+jchzHRGl0oucycBqSRlRSR4cqnWPkPQ+r 7B1OGjI5rXSneijM07ww==
MIME-Version: 1.0
Received: by 10.224.188.212 with SMTP id db20mr69247qab.141.1309299682362; Tue, 28 Jun 2011 15:21:22 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Tue, 28 Jun 2011 15:21:22 -0700 (PDT)
In-Reply-To: <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com>
Date: Tue, 28 Jun 2011 15:21:22 -0700
Message-ID: <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=20cf303346d578c42204a6cd1631
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jun 2011 22:21:37 -0000

--20cf303346d578c42204a6cd1631
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2011 at 3:19 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> 2011/6/28 John Tamplin <jat@google.com>:
> > Note that cookies are problematic for supporting multiple tabs logged i=
n
> > with different accounts, and are vulnerable to XSRF attacks without
> > additional precautions.
>
> But still Cookies are the only authentication mechanism mentioned in
> the WS draft.
>
>
>
> > The point is common practice in web apps is not to use HTTP
> authentication
> > anyway (aside from not being able to style it the way you want, you can=
't
> > easily log out, plus other limitations),
>
> I agree. It's ugly.
>
>
> > but to have the app request the
> > credentials and send them to the server itself.  If it takes that
> approach,
> > then it can easily do the same thing for WS communication.
>
> Humm, in my previous mail I already explained that a web server
> returns an HTML page in which the user can fill his credentials and
> so. But in WebSocket, how to do that? when you connect to a WebSocket
> server you don't receive a custom HTML or a form to login.
>
>
>
A user is not going to type in a ws:// url to a browser or other client.
They are going to open some webpage/application/... that will have ample
opportunity to deal with login before that thing instantiates the ws
connection.


>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>

--20cf303346d578c42204a6cd1631
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jun 28, 2011 at 3:19 PM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/6/28 John Tamplin &lt;<a href=3D"mailto:jat@google.com">jat@google.com=
</a>&gt;:<br>
<div class=3D"im">&gt; Note that cookies are problematic for supporting mul=
tiple tabs logged in<br>
&gt; with different accounts, and are vulnerable to XSRF attacks without<br=
>
&gt; additional precautions.<br>
<br>
</div>But still Cookies are the only authentication mechanism mentioned in<=
br>
the WS draft.<br>
<div class=3D"im"><br>
<br>
<br>
&gt; The point is common practice in web apps is not to use HTTP authentica=
tion<br>
&gt; anyway (aside from not being able to style it the way you want, you ca=
n&#39;t<br>
&gt; easily log out, plus other limitations),<br>
<br>
</div>I agree. It&#39;s ugly.<br>
<div class=3D"im"><br>
<br>
&gt; but to have the app request the<br>
&gt; credentials and send them to the server itself. =C2=A0If it takes that=
 approach,<br>
&gt; then it can easily do the same thing for WS communication.<br>
<br>
</div>Humm, in my previous mail I already explained that a web server<br>
returns an HTML page in which the user can fill his credentials and<br>
so. But in WebSocket, how to do that? when you connect to a WebSocket<br>
server you don&#39;t receive a custom HTML or a form to login.<br>
<font color=3D"#888888"><br>
<br></font></blockquote><div><br></div><div>A user is not going to type in =
a ws:// url to a browser or other client. They are going to open some webpa=
ge/application/... that will have ample opportunity to deal with login befo=
re that thing instantiates the ws connection.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;"><font color=3D"#888888">
<br>
--<br>
</font><div><div></div><div class=3D"h5">I=C3=B1aki Baz Castillo<br>
&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
</div></div></blockquote></div><br>

--20cf303346d578c42204a6cd1631--

From ibc@aliax.net  Tue Jun 28 15:43:07 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9D0211E81BB for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:43:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bGZKswHzn6Zc for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:43:07 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3536D11E81EE for <hybi@ietf.org>; Tue, 28 Jun 2011 15:43:06 -0700 (PDT)
Received: by qyk9 with SMTP id 9so2917575qyk.10 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:43:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.224.75 with SMTP id in11mr62970qcb.211.1309300985682; Tue, 28 Jun 2011 15:43:05 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Tue, 28 Jun 2011 15:43:05 -0700 (PDT)
In-Reply-To: <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com>
Date: Wed, 29 Jun 2011 00:43:05 +0200
Message-ID: <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jun 2011 22:43:07 -0000

2011/6/29 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
> A user is not going to type in a ws:// url to a browser or other client.
> They are going to open some webpage/application/... that will have ample
> opportunity to deal with login before that thing instantiates the ws
> connection.

Ian, I think I already exposed the issue with your suggestion:

- Web Server:  1.1.1.1:80
- WebSocket Server:  2.2.2.2:80

The webbrowser gets a page and a JS code from 1.1.1.1:80.
The JS opens a WebSocket connection with 2.2.2.2:80.

Could you explain me how the WebSocket server, ***running in a
separate server***, can authenticate the user based on previous user's
authentication with the Web Server?



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ifette@google.com  Tue Jun 28 15:44:52 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DF011E81C2 for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.675
X-Spam-Level: 
X-Spam-Status: No, score=-105.675 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLPUmRIdUnch for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 15:44:52 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C67EB11E81BB for <hybi@ietf.org>; Tue, 28 Jun 2011 15:44:51 -0700 (PDT)
Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5SMioR5030826 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:44:50 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309301090; bh=W8fFDX7WZFZdmIJ+gZnLg/lyzfU=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=qjTHmKekVOrzsC8m6IXu04kvua55zjnwA9vmKyrFmwMCJ1Xtf/Bq21ympfS9YK32g QzVOkGTVQ4NERXVMbWUoQ==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=F40dHmQZr98vkW5Z6zwv9reNXXdr5qpLGjxDgSjT9pm9Nt6qhF17gPwczV/2/g887 iErCG4saaoAbbsx8dAA/A==
Received: from qyl38 (qyl38.prod.google.com [10.241.83.230]) by hpaq11.eem.corp.google.com with ESMTP id p5SMhmR5006442 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Tue, 28 Jun 2011 15:44:49 -0700
Received: by qyl38 with SMTP id 38so2203200qyl.9 for <hybi@ietf.org>; Tue, 28 Jun 2011 15:44:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lUrvbq3rsxehBOLcrO2l0QGrpek4cNymi7sXHIyoDBc=; b=MwJTO6hWHBqAcoAyAW2W2VofHEQweIZ3ll4WmXfj0w2hmcf5pUSEQ5Z8/kEUrg4zqy MBF3xTBtdZFOEEtenbXg==
MIME-Version: 1.0
Received: by 10.229.118.78 with SMTP id u14mr87004qcq.29.1309301089218; Tue, 28 Jun 2011 15:44:49 -0700 (PDT)
Received: by 10.229.137.137 with HTTP; Tue, 28 Jun 2011 15:44:49 -0700 (PDT)
In-Reply-To: <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com>
Date: Tue, 28 Jun 2011 15:44:49 -0700
Message-ID: <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=000e0cd5f4aa53afa204a6cd6a6f
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jun 2011 22:44:52 -0000

--000e0cd5f4aa53afa204a6cd6a6f
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 28, 2011 at 3:43 PM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> 2011/6/29 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> > A user is not going to type in a ws:// url to a browser or other client=
.
> > They are going to open some webpage/application/... that will have ampl=
e
> > opportunity to deal with login before that thing instantiates the ws
> > connection.
>
> Ian, I think I already exposed the issue with your suggestion:
>
> - Web Server:  1.1.1.1:80
> - WebSocket Server:  2.2.2.2:80
>
> The webbrowser gets a page and a JS code from 1.1.1.1:80.
> The JS opens a WebSocket connection with 2.2.2.2:80.
>
> Could you explain me how the WebSocket server, ***running in a
> separate server***, can authenticate the user based on previous user's
> authentication with the Web Server?
>
>
>
Pass an oauth token, or have the WS server issue some challenge that the JS
answers (or presents to the user on behalf of the server if it's really
necessary), many ways. This is not a new problem.


>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>

--000e0cd5f4aa53afa204a6cd6a6f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Tue, Jun 28, 2011 at 3:43 PM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
2011/6/29 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) &lt;<a href=3D"mailto:ifette@google.com">ifette@google.=
com</a>&gt;:<br>
<div class=3D"im">&gt; A user is not going to type in a ws:// url to a brow=
ser or other client.<br>
&gt; They are going to open some webpage/application/... that will have amp=
le<br>
&gt; opportunity to deal with login before that thing instantiates the ws<b=
r>
&gt; connection.<br>
<br>
</div>Ian, I think I already exposed the issue with your suggestion:<br>
<br>
- Web Server: =C2=A0<a href=3D"http://1.1.1.1:80" target=3D"_blank">1.1.1.1=
:80</a><br>
- WebSocket Server: =C2=A0<a href=3D"http://2.2.2.2:80" target=3D"_blank">2=
.2.2.2:80</a><br>
<br>
The webbrowser gets a page and a JS code from <a href=3D"http://1.1.1.1:80"=
 target=3D"_blank">1.1.1.1:80</a>.<br>
The JS opens a WebSocket connection with <a href=3D"http://2.2.2.2:80" targ=
et=3D"_blank">2.2.2.2:80</a>.<br>
<br>
Could you explain me how the WebSocket server, ***running in a<br>
separate server***, can authenticate the user based on previous user&#39;s<=
br>
authentication with the Web Server?<br>
<font color=3D"#888888"><br>
<br></font></blockquote><div><br></div><div>Pass an oauth token, or have th=
e WS server issue some challenge that the JS answers (or presents to the us=
er on behalf of the server if it&#39;s really necessary), many ways. This i=
s not a new problem.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;"><font color=3D"#888888">
<br>
--<br>
</font><div><div></div><div class=3D"h5">I=C3=B1aki Baz Castillo<br>
&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
</div></div></blockquote></div><br>

--000e0cd5f4aa53afa204a6cd6a6f--

From gregw@intalio.com  Tue Jun 28 16:03:42 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9493811E815B for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 16:03:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bdRp4TsRQo0N for <hybi@ietfa.amsl.com>; Tue, 28 Jun 2011 16:03:42 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8C811E810A for <hybi@ietf.org>; Tue, 28 Jun 2011 16:03:41 -0700 (PDT)
Received: by vws12 with SMTP id 12so606947vws.31 for <hybi@ietf.org>; Tue, 28 Jun 2011 16:03:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.173.111 with SMTP id bj15mr170758vdc.122.1309302219236; Tue, 28 Jun 2011 16:03:39 -0700 (PDT)
Received: by 10.52.187.66 with HTTP; Tue, 28 Jun 2011 16:03:39 -0700 (PDT)
In-Reply-To: <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
Date: Wed, 29 Jun 2011 09:03:39 +1000
Message-ID: <BANLkTi=E6+pfqUCSv8g078itHv5UNer+2g@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: ifette@google.com
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 28 Jun 2011 23:03:42 -0000

2011/6/29 Ian Fette ($B%$%"%s%U%'%C%F%#(B) <ifette@google.com>:
> Pass an oauth token, or have the WS server issue some challenge that the JS
> answers (or presents to the user on behalf of the server if it's really
> necessary), many ways. This is not a new problem.

It would be great if the oauth token could be in the handshake, so
that authentication (and thus authorisation) could be done before a WS
connection is established.
I would not be surprised if we see the subprotocol field used for this
purpose, as the only user settable header in the handshake.

cheers

From ibc@aliax.net  Wed Jun 29 01:05:33 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752D822800F for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vB5PhokfCEY for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id BCCE0228006 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
Received: by qyk29 with SMTP id 29so721953qyk.10 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.44.132 with SMTP id a4mr323590qcf.287.1309334732082; Wed, 29 Jun 2011 01:05:32 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Wed, 29 Jun 2011 01:05:31 -0700 (PDT)
In-Reply-To: <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com>
Date: Wed, 29 Jun 2011 10:05:31 +0200
Message-ID: <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 08:05:33 -0000

2011/6/29 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
> Pass an oauth token,

How? within the subprotocol itself?


> or have the WS server issue some challenge that the JS
> answers

Reinventing the wheel (HTTP Digest auth) but at WS subprotocol level?
So should the JavaScript client *code* perform the challenge in pure
and custom JavaScript code? I expect *lots* of future vulnerabilities
in WS.

Unfortunately it's common in this WG not to reuse existing
technologies (neither reusing DNS SRV for good
load-balancing/failover, neither reusing any existing authentication
mechanism). This is not good IMHO.


> (or presents to the user on behalf of the server if it's really
> necessary), many ways. This is not a new problem.

Even worse, it's not a new problem but it seems that WebSocket draft
authors don't want to deal with it. WebSocket world will become a
jungle.

So, is it really possible that WebSocket will be the first
client->server protocol without, at least, one solid authentication
mechanism specified? I just can't believe it. Please, WS is not like a
DNS query. WS is supposed to carry personal and private data.

Please don't take me wrong, but IMHO some other people with experience
in Internet protocols other than HTTP should also take a look to this
draft. I don't like the WWW-style of doing things this protocol is
acquiring. The fact that WWW world is a jungle doesn't mean that any
other new protocol (even when related to HTTP) should also be jungle.


I strongly disagree with the direction this draft is taking when
coming to authentication area in WebSocket protocol.

Regards.

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From jat@google.com  Wed Jun 29 01:28:50 2011
Return-Path: <jat@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 527079E8028 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0hx-84VrovB for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:28:49 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7B29E8025 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:28:49 -0700 (PDT)
Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p5T8Smri017772 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:28:48 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309336128; bh=ark6vZoGNeKCVURYXRjAdSnu6p0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Z+r+9nUNcoiOXxpFaiZVJZltUf9hdwnm9l40Ja3Acnr5NaWGWC18ThaVG6CrY/G+D 1f+uexQmkGWAoShTm8E/A==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=WE+xDdcKtQQOmOnrppBCs136jTHm/coS7t50ho9zfO7xUlzVB31nCALSNc6ubd/bL JZKsapNwc1YsxgI4mKNfg==
Received: from yxe1 (yxe1.prod.google.com [10.190.2.1]) by hpaq11.eem.corp.google.com with ESMTP id p5T8SSL6022768 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 29 Jun 2011 01:28:46 -0700
Received: by yxe1 with SMTP id 1so450401yxe.20 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:28:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eIIF5xMjgqQiRZlqKpjd5r7hfFygLCwnHejkbK7otb4=; b=Dgvsjenpz720cVyQ4LHC6Ge3vlHoe4qWNU7WqLzWAokomuyXdVten54khDJbezoTrs dZEUr81AsmR7QVsZZF2A==
Received: by 10.150.141.13 with SMTP id o13mr451224ybd.287.1309336126376; Wed, 29 Jun 2011 01:28:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.49.7 with HTTP; Wed, 29 Jun 2011 01:28:26 -0700 (PDT)
In-Reply-To: <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Wed, 29 Jun 2011 04:28:26 -0400
Message-ID: <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=000e0cdf1a96b44c6804a6d5924e
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 08:28:50 -0000

--000e0cdf1a96b44c6804a6d5924e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2011 at 4:05 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> > or have the WS server issue some challenge that the JS
> > answers
>
> Reinventing the wheel (HTTP Digest auth) but at WS subprotocol level?
> So should the JavaScript client *code* perform the challenge in pure
> and custom JavaScript code? I expect *lots* of future vulnerabilities
> in WS.
>
> Unfortunately it's common in this WG not to reuse existing
> technologies (neither reusing DNS SRV for good
> load-balancing/failover, neither reusing any existing authentication
> mechanism). This is not good IMHO.


How many sites use HTTP auth instead of rolling their own?  I can't think o=
f
a single one that I use regularly that does.

Therefore, standardizing on something that nobody uses seems hardly a good
idea.  It also seems unlikely that everyone would agree on a the One True
Auth mechanism to be included in WS.  Personally, I would expect one or mor=
e
extensions to be created that specifies how credentials are sent in the
handshake, assuming there is sufficient interest and that a common standard
emerges, such as perhaps OAuth.

> (or presents to the user on behalf of the server if it's really
> > necessary), many ways. This is not a new problem.
>
> Even worse, it's not a new problem but it seems that WebSocket draft
> authors don't want to deal with it. WebSocket world will become a
> jungle.
>

Make a proposal and see if you can get sufficient support behind it.  I am
pretty sure HTTP Auth is not going to achieve such support, and given how
long WS has taken to achieve consensus, I suspect any such mechanism will b=
e
done via an extension.

--=20
John A. Tamplin
Software Engineer (GWT), Google

--000e0cdf1a96b44c6804a6d5924e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 29, 2011 at 4:05 AM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">&gt; or have the WS server issue some challenge that the =
JS</div><div class=3D"im">
&gt; answers<br>
<br>
</div>Reinventing the wheel (HTTP Digest auth) but at WS subprotocol level?=
<br>
So should the JavaScript client *code* perform the challenge in pure<br>
and custom JavaScript code? I expect *lots* of future vulnerabilities<br>
in WS.<br>
<br>
Unfortunately it&#39;s common in this WG not to reuse existing<br>
technologies (neither reusing DNS SRV for good<br>
load-balancing/failover, neither reusing any existing authentication<br>
mechanism). This is not good IMHO.</blockquote><div><br></div><div>How many=
 sites use HTTP auth instead of rolling their own? =C2=A0I can&#39;t think =
of a single one that I use regularly that does.</div><div><br></div><div>Th=
erefore, standardizing on something that nobody uses seems hardly a good id=
ea. =C2=A0It also seems unlikely that everyone would agree on a the One Tru=
e Auth mechanism to be included in WS. =C2=A0Personally, I would expect one=
 or more extensions to be created that specifies how credentials are sent i=
n the handshake, assuming there is sufficient interest and that a common st=
andard emerges, such as perhaps OAuth.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
&gt; (or presents to the user on behalf of the server if it&#39;s really<br=
>
&gt; necessary), many ways. This is not a new problem.<br>
<br>
</div>Even worse, it&#39;s not a new problem but it seems that WebSocket dr=
aft<br>
authors don&#39;t want to deal with it. WebSocket world will become a<br>
jungle.<br></blockquote><div><br></div><div>Make a proposal and see if you =
can get sufficient support behind it. =C2=A0I am pretty sure HTTP Auth is n=
ot going to achieve such support, and given how long WS has taken to achiev=
e consensus, I suspect any such mechanism will be done via an extension.</d=
iv>

</div><br>-- <br>John A. Tamplin<br>Software Engineer (GWT), Google<br>

--000e0cdf1a96b44c6804a6d5924e--

From ibc@aliax.net  Wed Jun 29 01:41:45 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44010228018 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:41:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgtTSyDwSjLf for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:41:44 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 937F6228016 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:41:44 -0700 (PDT)
Received: by qwc23 with SMTP id 23so825529qwc.31 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:41:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.137.19 with SMTP id u19mr348401qct.173.1309336903931; Wed, 29 Jun 2011 01:41:43 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Wed, 29 Jun 2011 01:41:43 -0700 (PDT)
In-Reply-To: <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com> <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com>
Date: Wed, 29 Jun 2011 10:41:43 +0200
Message-ID: <CALiegfkcnUHbYB6MeQw3Vp+OadA-drUjWHqfjzrtd2Tp1VQCJA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 08:41:45 -0000

2011/6/29 John Tamplin <jat@google.com>:
> How many sites use HTTP auth instead of rolling their own? =C2=A0I can't =
think of
> a single one that I use regularly that does.


Hi John. Thanks for your response. Anyhow it seems I must repeat many
times the same in this same thread:

A web server returns an HTML page in which the user can fill his credential=
s and
so (a form). But in WebSocket, how to do that? when you connect to a WebSoc=
ket
server you don't receive a custom HTML or a form to login, instead you
recibe from the server some WS message containing a subprotocol
request (which is supposed to be custom in each subprotocol). How to
render that to the user?


> Therefore, standardizing on something that nobody uses seems hardly a goo=
d
> idea.

And since WWW is a jungle you are making a new jungle. There are many
protocols in which authentication is not a jungle, why not copy from
them instead of copying from WWW?



> =C2=A0It also seems unlikely that everyone would agree on a the One True
> Auth mechanism to be included in WS.

IMHO the draft should specify at least one. Others could come into new
extensions to the draft (as in many other protocols as SIP or XMPP).


>=C2=A0Personally, I would expect one or more
> extensions to be created that specifies how credentials are sent in the
> handshake,

But again, IMHO the core draft should already specify one.


> assuming there is sufficient interest

Interest in secure authentication? such interesnt should be mandatory.


> and that a common standard
> emerges, such as perhaps OAuth.

There are already enough authentication mechanism not to need waiting
for a new one (IMHO).




> Make a proposal and see if you can get sufficient support behind it. =C2=
=A0I am
> pretty sure HTTP Auth is not going to achieve such support, and given how
> long WS has taken to achieve consensus, I suspect any such mechanism will=
 be
> done via an extension.

I don't say that HTTP Auth is the best, it's just an option. WWW
people don't like it because, indeed, it's ugly implemented (the popup
alert, difficult to logout, etc). It does not mean that it could be
properly implemented in WebSocket if its done well from the beginning.



Regards.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From jat@google.com  Wed Jun 29 01:47:48 2011
Return-Path: <jat@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3911121F8698 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DnqOLb6XQ16B for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 01:47:47 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8D221F8696 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:47:47 -0700 (PDT)
Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p5T8ljIM002304 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:47:46 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309337266; bh=aX8A8lCY2zDzCYqN3pkLM23Sy0k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pnWU6TkhKmH/HdDzF2+o6PgowB6y8jZvjeqeycc786+6nJzCYAScgPIcw8+8TWSqC sa+rzD17hBGJD1L2ic0tA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=E6Za/Pu/stn4p+Ps3iM+ihAA4V1wCPEG1x9IMbpODGCPk9GgAAkcag69yTJQweZcX +keYppAtXZUBzSl+fSVNA==
Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by kpbe18.cbf.corp.google.com with ESMTP id p5T8lYNB025651 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 29 Jun 2011 01:47:44 -0700
Received: by gxk7 with SMTP id 7so474639gxk.7 for <hybi@ietf.org>; Wed, 29 Jun 2011 01:47:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=IdLiTDJ8CJNlGUGvdxMRkKJ93dAZpHSXZr11zcSkePE=; b=MWiF7z5S1yuL07DMjp3rE1TiQDWBbpF3wtVsvvNA5S33YMDiDWwMPeMOAd3Ipt5o0I sBYHQiCZjCmD/IKoXFZg==
Received: by 10.150.73.26 with SMTP id v26mr474519yba.59.1309337264138; Wed, 29 Jun 2011 01:47:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.49.7 with HTTP; Wed, 29 Jun 2011 01:47:23 -0700 (PDT)
In-Reply-To: <CALiegfkcnUHbYB6MeQw3Vp+OadA-drUjWHqfjzrtd2Tp1VQCJA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com> <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com> <CALiegfkcnUHbYB6MeQw3Vp+OadA-drUjWHqfjzrtd2Tp1VQCJA@mail.gmail.com>
From: John Tamplin <jat@google.com>
Date: Wed, 29 Jun 2011 04:47:23 -0400
Message-ID: <CABLsOLCDq_Hs6eLuouPQrjzZ9NwBKt=jGDyVmAhq9ttWSngv5w@mail.gmail.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=000e0cd598ca852afe04a6d5d6f2
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 08:47:48 -0000

--000e0cd598ca852afe04a6d5d6f2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2011 at 4:41 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> Hi John. Thanks for your response. Anyhow it seems I must repeat many
> times the same in this same thread:


I feel the same way, and this is my last response.


>  A web server returns an HTML page in which the user can fill his
> credentials and
> so (a form). But in WebSocket, how to do that? when you connect to a
> WebSocket
> server you don't receive a custom HTML or a form to login, instead you
> recibe from the server some WS message containing a subprotocol
> request (which is supposed to be custom in each subprotocol). How to
> render that to the user?


Some JS code is making a WS request.  It can use whatever mechanism it want=
s
for obtaining the credentials from the user, and send them over the WS
connection.


> And since WWW is a jungle you are making a new jungle. There are many
> protocols in which authentication is not a jungle, why not copy from
> them instead of copying from WWW?


Feel free to suggest something that has broad consensus.  I haven't heard
any such suggestion, nor have I heard anyone else beside you clamoring for
it.

--=20
John A. Tamplin
Software Engineer (GWT), Google

--000e0cd598ca852afe04a6d5d6f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 29, 2011 at 4:41 AM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

Hi John. Thanks for your response. Anyhow it seems I must repeat many<br>
times the same in this same thread:</blockquote><div><br></div><div>I feel =
the same way, and this is my last response.</div><div>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex;">

<div class=3D"im">
A web server returns an HTML page in which the user can fill his credential=
s and<br>
</div>so (a form). But in WebSocket, how to do that? when you connect to a =
WebSocket<br>
server you don&#39;t receive a custom HTML or a form to login, instead you<=
br>
recibe from the server some WS message containing a subprotocol<br>
request (which is supposed to be custom in each subprotocol). How to<br>
render that to the user?</blockquote><div><br></div><div>Some JS code is ma=
king a WS request. =C2=A0It can use whatever mechanism it wants for obtaini=
ng the credentials from the user, and send them over the WS connection.</di=
v>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;">And since WWW is a jungle =
you are making a new jungle. There are many<br>
protocols in which authentication is not a jungle, why not copy from<br>
them instead of copying from WWW?</blockquote><div><br></div><div>Feel free=
 to suggest something that has broad consensus. =C2=A0I haven&#39;t heard a=
ny such suggestion, nor have I heard anyone else beside you clamoring for i=
t.</div>

</div><br>-- <br>John A. Tamplin<br>Software Engineer (GWT), Google<br>

--000e0cd598ca852afe04a6d5d6f2--

From gregw@intalio.com  Wed Jun 29 02:14:36 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A83721F8627 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 02:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level: 
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPEc6AsqJeXi for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 02:14:36 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFA5621F8623 for <hybi@ietf.org>; Wed, 29 Jun 2011 02:14:35 -0700 (PDT)
Received: by vws12 with SMTP id 12so892912vws.31 for <hybi@ietf.org>; Wed, 29 Jun 2011 02:14:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.75.129 with SMTP id c1mr761684vdw.202.1309338875007; Wed, 29 Jun 2011 02:14:35 -0700 (PDT)
Received: by 10.52.187.66 with HTTP; Wed, 29 Jun 2011 02:14:33 -0700 (PDT)
In-Reply-To: <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com> <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com>
Date: Wed, 29 Jun 2011 19:14:33 +1000
Message-ID: <BANLkTimLonO3NoKfqQdgX3hs_fz7ztakDQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 09:14:36 -0000

On 29 June 2011 18:28, John Tamplin <jat@google.com> wrote:
> How many sites use HTTP auth instead of rolling their own? =A0I can't thi=
nk of
> a single one that I use regularly that does.

It is true that not many (if any) large when known sites use the HTTP
auth mechanisms. However there are many many smaller sites that do use
them and they remain well supported by J2EE environments. I also
frequently see them used with webservices.

I really don't think that WS should be forcing a choice in
authentication mechanism.   It should be able to support:
  + standard HTTP authentication mechanisms
  + simple cookie based authentication
  + token passing (eg oath) authentication

I actually think the protocol already is pretty good at doing all
this, however the API does not support any of them.

From ibc@aliax.net  Wed Jun 29 02:14:58 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33E2F21F862B for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 02:14:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFeqZ33in9wf for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 02:14:57 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id A5D0E21F8623 for <hybi@ietf.org>; Wed, 29 Jun 2011 02:14:57 -0700 (PDT)
Received: by qwc23 with SMTP id 23so845340qwc.31 for <hybi@ietf.org>; Wed, 29 Jun 2011 02:14:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.23.69 with SMTP id q5mr359429qcb.249.1309338897082; Wed, 29 Jun 2011 02:14:57 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Wed, 29 Jun 2011 02:14:57 -0700 (PDT)
In-Reply-To: <CABLsOLCDq_Hs6eLuouPQrjzZ9NwBKt=jGDyVmAhq9ttWSngv5w@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com> <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com> <CALiegfkcnUHbYB6MeQw3Vp+OadA-drUjWHqfjzrtd2Tp1VQCJA@mail.gmail.com> <CABLsOLCDq_Hs6eLuouPQrjzZ9NwBKt=jGDyVmAhq9ttWSngv5w@mail.gmail.com>
Date: Wed, 29 Jun 2011 11:14:57 +0200
Message-ID: <CALiegf=NVNgcfZEbxu+DzpCjwFFjK9dmOKYQOfX3KVQz92nRYQ@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: John Tamplin <jat@google.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 09:14:58 -0000

2011/6/29 John Tamplin <jat@google.com>:
> I feel the same way, and this is my last response.

Mine also, I think this thread is long enough and opinions are already give=
n.


> Some JS code is making a WS request. =C2=A0It can use whatever mechanism =
it wants
> for obtaining the credentials from the user, and send them over the WS
> connection.

Which means authentication at pure JavaScript level. Dangerous IMHO.



> Feel free to suggest something that has broad consensus. =C2=A0I haven't =
heard
> any such suggestion, nor have I heard anyone else beside you clamoring fo=
r
> it.

This is expected as, IMHO, most of this WG comes from WWW world in
which no one authentication standard has succedeed (HTTP auth is ugly
indeed) so custom authentication mechanism are mainly used.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From ibc@aliax.net  Wed Jun 29 02:16:06 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C24321F862C for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 02:16:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HauUOzeEWrAf for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 02:16:05 -0700 (PDT)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2003021F862A for <hybi@ietf.org>; Wed, 29 Jun 2011 02:16:04 -0700 (PDT)
Received: by qyk9 with SMTP id 9so3185204qyk.10 for <hybi@ietf.org>; Wed, 29 Jun 2011 02:16:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.23.69 with SMTP id q5mr360052qcb.249.1309338963574; Wed, 29 Jun 2011 02:16:03 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Wed, 29 Jun 2011 02:16:03 -0700 (PDT)
In-Reply-To: <BANLkTimLonO3NoKfqQdgX3hs_fz7ztakDQ@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com> <CABLsOLB17_BVH+mGG4PCvMo8hWSfc=BvuNgq8Rcbo5Mxm6k7Zg@mail.gmail.com> <BANLkTimLonO3NoKfqQdgX3hs_fz7ztakDQ@mail.gmail.com>
Date: Wed, 29 Jun 2011 11:16:03 +0200
Message-ID: <CALiegf=MzVv5P1WbxA1tq3=Z8H7osz2G0ecxYSEKNhfC+9NEcA@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Greg Wilkins <gregw@intalio.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 09:16:06 -0000

2011/6/29 Greg Wilkins <gregw@intalio.com>:
> I really don't think that WS should be forcing a choice in
> authentication mechanism. =C2=A0 It should be able to support:
> =C2=A0+ standard HTTP authentication mechanisms
> =C2=A0+ simple cookie based authentication
> =C2=A0+ token passing (eg oath) authentication
>
> I actually think the protocol already is pretty good at doing all
> this, however the API does not support any of them.

So there is nothing then...

--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From gezelter@rlgsc.com  Wed Jun 29 05:41:43 2011
Return-Path: <gezelter@rlgsc.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA87511E8071 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 05:41:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZZ9CfJTNVvU for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 05:41:41 -0700 (PDT)
Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id DEE9F21F862A for <hybi@ietf.org>; Wed, 29 Jun 2011 05:41:41 -0700 (PDT)
Received: (qmail 4179 invoked from network); 29 Jun 2011 12:41:41 -0000
Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 29 Jun 2011 12:41:41 -0000
Received: (qmail 21918 invoked by uid 99); 29 Jun 2011 12:41:41 -0000
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"
X-Originating-IP: 141.157.214.30
User-Agent: Web-Based Email 5.5.06
Message-Id: <20110629054140.ef1fc80126c74c6c202a919c41c7bb0b.9ab03fb9ba.wbe@email03.secureserver.net>
From: "Bob Gezelter" <gezelter@rlgsc.com>
To: hybi@ietf.org
Date: Wed, 29 Jun 2011 05:41:40 -0700
Mime-Version: 1.0
Cc: gregw@intalio.com
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 12:41:44 -0000

Indeed, session control and authentication have been an ongoing weakness
in the Internet protocol suite. With all due respect to those who wrote
the original RFCs, this weakness has been at the root of far too many
security breaches. However, to be fair, the authors of the original RFCs
saw them as a demonstration, not as a foundation for a global,
mission-critical information infrastructure.

An authentication scheme is NOT (emphatically NOT) what is needed within
the WebSocket protocol. What is needed is a framework for the inclusion
of authentication at the start of a connection, with the actual details
of the authentication specified not in terms of specific algorithms, but
in terms of a framework within which a authentication scheme must fit.
In programming, this goes under a number of different names, the oldest
of which is "exit routine".

The WebSocket protocol is not an applications-level protocol, but more
of an intermediate between a transport protocol and an applications
protocol upon which other protocols (generally distributed and custom)
will be operated over. It is in this context that I noted that IMHO,
multiplexing (e.g., John Tamplin's proposal) should be part of the base
RFC, not a later add-on.

This has implications at several levels. Some servers will require
authentication merely to open a base connection. Other servers will
allow anonymous base connections, but may require various degrees of
authentication for different multiplexed subchannels. A
WebSocket-connected service for TimeofDay may be anonymous, one for
pricing data may be lightly authenticated, and yet a third for actually
performing transactions may require a strong authentication scheme. The
acceptable technology for a particular authentication must be negotiated
by both sides of the connection.

However, since the WebSocket protocol is for program-to-program use, a
pop-up type query would not be appropriate for any number of reasons.
Rather (and this is something for the WebSocket API activity in the
WHATWG group), the appropriate callbacks/events should be defined to
facilitate whatever processing is needed to facilitate authentication
(e.g., a user pop-up dialogue, computations based upon an X.509
certificate, interrogation or retrieval of data from an external device
such as a USB memory device).

In summary, the WebSocket protocol does need a framework for
authentication, and to enable interoperaability, a registry of published
authentication schemes within that framework, with provisions for local
extensions. It does not need a specific authentication scheme as part of
the specification. Any such scheme should include provisions for
unauthenticated/anonymous connections.

- Bob Gezelter, http://www.rlgsc.com


From ibc@aliax.net  Wed Jun 29 06:01:30 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8DD11E8075 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 06:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0GMNwwnyh+gD for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 06:01:29 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id E975A11E8070 for <hybi@ietf.org>; Wed, 29 Jun 2011 06:01:28 -0700 (PDT)
Received: by qyk29 with SMTP id 29so882886qyk.10 for <hybi@ietf.org>; Wed, 29 Jun 2011 06:01:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.44.132 with SMTP id a4mr513319qcf.287.1309352488432; Wed, 29 Jun 2011 06:01:28 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Wed, 29 Jun 2011 06:01:28 -0700 (PDT)
In-Reply-To: <20110629054140.ef1fc80126c74c6c202a919c41c7bb0b.9ab03fb9ba.wbe@email03.secureserver.net>
References: <20110629054140.ef1fc80126c74c6c202a919c41c7bb0b.9ab03fb9ba.wbe@email03.secureserver.net>
Date: Wed, 29 Jun 2011 15:01:28 +0200
Message-ID: <CALiegfkziM9kMZP9m7ETMPF9==hxF2+P-ohP34_kbH9fmB2q+w@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Bob Gezelter <gezelter@rlgsc.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, gregw@intalio.com
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 29 Jun 2011 13:01:30 -0000

(now correctly replying to the list address):


2011/6/29 Bob Gezelter <gezelter@rlgsc.com>:
> In summary, the WebSocket protocol does need a framework for
> authentication, and to enable interoperaability, a registry of published
> authentication schemes within that framework, with provisions for local
> extensions. It does not need a specific authentication scheme as part of
> the specification. Any such scheme should include provisions for
> unauthenticated/anonymous connections.

It makes lot of sense. I agree that an authentication framework should
be needed (better than a single authentication mechanism) and, of
course, an API for managing it from the client side.

The problem is that the WG seems not to want to cover this area at
all, and instead let the authentication process at WS subprotocol
level, leaving all the possible challenge computation at pure
JavaScript level (danger danger).

The fact that there is no broad consensus in the need of this
mechanism, neither interest, does not justify publishing the protocol
as it is. Come on WG, if nobody in the WG would care about which
encoding to use in WebSocket protocol, would the protocol born without
specifying it??? This is a protocol specification, not a FAQ, there
cannot be black holes.


--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>

From gregw@intalio.com  Wed Jun 29 18:43:27 2011
Return-Path: <gregw@intalio.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8E11F0C3B for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 18:43:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.582
X-Spam-Level: 
X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.027,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, URI_HEX=0.368]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhciYwi+vh71 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 18:43:26 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 94DFF1F0C36 for <hybi@ietf.org>; Wed, 29 Jun 2011 18:43:26 -0700 (PDT)
Received: by vxi40 with SMTP id 40so1580032vxi.31 for <hybi@ietf.org>; Wed, 29 Jun 2011 18:43:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.109.228 with SMTP id hv4mr2097621vdb.42.1309398205712; Wed, 29 Jun 2011 18:43:25 -0700 (PDT)
Received: by 10.52.112.231 with HTTP; Wed, 29 Jun 2011 18:43:25 -0700 (PDT)
In-Reply-To: <BANLkTikz=J_xYPBgdaTvdcNpfXoD6OpxqA@mail.gmail.com>
References: <20110629053802.ef1fc80126c74c6c202a919c41c7bb0b.579b437e87.wbe@email03.secureserver.net> <CALiegfkCzDURkBKTNOCR9Tgc_Aa9JHRAQb_7SUYDq=EUkrSC8w@mail.gmail.com> <BANLkTikz=J_xYPBgdaTvdcNpfXoD6OpxqA@mail.gmail.com>
Date: Thu, 30 Jun 2011 11:43:25 +1000
Message-ID: <BANLkTim0cDxCQzsezE76cC+KhvH9QpaPEQ@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Hybi <hybi@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Jun 2011 01:43:27 -0000

Sorry if this is a duplicate - there was an error in sending and I
also notice I left out a .net from my example:


I do not think that this WG should be in the business of mandating
Authentication mechanisms. There is no one-size-fits all
authentication mechanism and best practises change. I believe that we
need WS to support a variety of authentication mechanisms and thus
avoid the "you don't want to use that mechanism" debate.

For cookie based authentication mechanisms, the protocol already
supports sending and setting cookies in handshakes and handshake
responses.  However I cannot see any requirements on the browsers to
actually send any cookies - so perhaps we need to strengthen the spec
here with some recommendations (ie SHOULD send appropriate cookies
rather than MAY send).

For the HTTP authentication mechanisms of BASIC and DIGEST, the spec
does allow a 401 challenge to be sent, however I do not think that we
currently don't explicitly allow the WWW-Authenticate or Authorisation
headers in the handshake.   So I think we should add a point in 5.1
saying that a handshake request MAY include other HTTP headers such as
Authorisation.  Currently we only say MAY include
Sec-WebSocket-Protocol, Sec-WebSocket-Extensions and cookie headers -
which by omission implies we can't have arbitrary headers (which I do
not think was the intent).       Note I do recognise that there are
issues with collecting credentials for these mechanisms and thus I
think we should defer to the browsers if and how they will be
supported, but we should definitely allow them in the protocol.

For token passing authentication mechanisms, there is currently no way
for users to set HTTP headers in the handshake.  This is probably a
good thing!    The only user settable field in the handshake is the
subprotocol fields, and as I have said before, I would not be
surprised if this was used (or abused?) to send OAUTH tokens. Perhaps
usage of OAUTH is a subprotocol and we should allow multiple
subprotocols and  parameters to subprotocols for passing data, eg.


       GET /chat HTTP/1.1
       Host: server.example.com
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
       Sec-WebSocket-Origin: http://example.com
       Sec-WebSocket-Protocol:oauth.net;token=9AF4023B3CDFAA021C3456BFAA,chat,superchat
       Sec-WebSocket-Version: 8

       HTTP/1.1 101 Switching Protocols
       Upgrade: websocket
       Connection: Upgrade
       Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
       Sec-WebSocket-Protocol: oauth.net,chat



So in summary, I think to better support flexible authentication we should
1. say that clients SHOULD send appropriate cookies (rather than MAY)
2. expand 5.1 to so that clients MAY send arbitrary HTTP headers,
including Authorisation (which can be listed as an example).
3. Allow multiple parameterised subprotocols, so that they may be used
for token based authentication.


cheers

From ifette@google.com  Wed Jun 29 19:28:40 2011
Return-Path: <ifette@google.com>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7373421F85C1 for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 19:28:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level: 
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvoHz-z+aL0X for <hybi@ietfa.amsl.com>; Wed, 29 Jun 2011 19:28:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6B6C821F8583 for <hybi@ietf.org>; Wed, 29 Jun 2011 19:28:39 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p5U2Sbqa028464 for <hybi@ietf.org>; Wed, 29 Jun 2011 19:28:38 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1309400918; bh=vNp1qkTXUWtgLksPOay/812s8YM=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=qu0jwImsLwgExXHg5BjPH7syKuXQ75bd6jvz5U71WXO00Ad6wUTLzeUwbZ1rPf8MC 3J/SxaBrFJbpkgFV+RBFw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=k0L7hXDggBCLB7yCmfG+OQL4Q/ls4skd9IQ7mqzA6gGUi8q9NC3mx17mGP0Y9zYJY a2hvVT9JpHnwk0LfbXyxQ==
Received: from iwn39 (iwn39.prod.google.com [10.241.68.103]) by wpaz33.hot.corp.google.com with ESMTP id p5U2RuJL027941 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <hybi@ietf.org>; Wed, 29 Jun 2011 19:28:36 -0700
Received: by iwn39 with SMTP id 39so2005125iwn.31 for <hybi@ietf.org>; Wed, 29 Jun 2011 19:28:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=3BybCQkqBkfugiTc6GznDJi8MiqkeyHIIHekDr9eTD8=; b=eCze0kI8CmQRdWtOmtDi0APOGKqtkY3nodM5Xl3xQVJLODsTHwBa8U23UKPYAQYd2D ZbPZqn2Gk/lQSTIq05xw==
MIME-Version: 1.0
Received: by 10.231.41.69 with SMTP id n5mr1319494ibe.83.1309400916575; Wed, 29 Jun 2011 19:28:36 -0700 (PDT)
Received: by 10.231.30.140 with HTTP; Wed, 29 Jun 2011 19:28:36 -0700 (PDT)
In-Reply-To: <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com>
Date: Wed, 29 Jun 2011 19:28:36 -0700
Message-ID: <CAF4kx8fsyrkdJ7TX2+hkMcb=M-TPtbPiLup1OWoxpvKf=FZDOA@mail.gmail.com>
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= <ifette@google.com>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=0015177407d48047f704a6e4a86b
X-System-Of-Record: true
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ifette@google.com
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Jun 2011 02:28:40 -0000

--0015177407d48047f704a6e4a86b
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 29, 2011 at 1:05 AM, I=C3=B1aki Baz Castillo <ibc@aliax.net> wr=
ote:

> 2011/6/29 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=
=83=E3=83=86=E3=82=A3) <ifette@google.com>:
> > Pass an oauth token,
>
> How? within the subprotocol itself?
>
>
> > or have the WS server issue some challenge that the JS
> > answers
>
> Reinventing the wheel (HTTP Digest auth) but at WS subprotocol level?
> So should the JavaScript client *code* perform the challenge in pure
> and custom JavaScript code? I expect *lots* of future vulnerabilities
> in WS.
>
> Unfortunately it's common in this WG not to reuse existing
> technologies (neither reusing DNS SRV for good
> load-balancing/failover, neither reusing any existing authentication
> mechanism). This is not good IMHO.
>
>
I think the base protocol defines enough for the vast majority of people to
easily work this into their workflow. For those that it's nontrivial for,
it's certainly possible and by no means a hard CS problem. If enough people
face it, they can build a library, or propose an extension.

As for loadbalancing / failover beyond what basic DNS provides, again, this
isn't required for a base protocol but could easily be specified as an
extension should the need arise / people wish to do so. HTTP and TCP weren'=
t
built in a day either.


>
> > (or presents to the user on behalf of the server if it's really
> > necessary), many ways. This is not a new problem.
>
> Even worse, it's not a new problem but it seems that WebSocket draft
> authors don't want to deal with it. WebSocket world will become a
> jungle.
>
> So, is it really possible that WebSocket will be the first
> client->server protocol without, at least, one solid authentication
> mechanism specified? I just can't believe it. Please, WS is not like a
> DNS query. WS is supposed to carry personal and private data.
>
> Please don't take me wrong, but IMHO some other people with experience
> in Internet protocols other than HTTP should also take a look to this
> draft. I don't like the WWW-style of doing things this protocol is
> acquiring. The fact that WWW world is a jungle doesn't mean that any
> other new protocol (even when related to HTTP) should also be jungle.
>
>
> I strongly disagree with the direction this draft is taking when
> coming to authentication area in WebSocket protocol.
>
> Regards.
>
> --
> I=C3=B1aki Baz Castillo
> <ibc@aliax.net>
>

--0015177407d48047f704a6e4a86b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Wed, Jun 29, 2011 at 1:05 AM, I=C3=B1aki Baz =
Castillo <span dir=3D"ltr">&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.n=
et</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class=3D"im">2011/6/29 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=
=E3=82=A7=E3=83=83=E3=83=86=E3=82=A3) &lt;<a href=3D"mailto:ifette@google.c=
om">ifette@google.com</a>&gt;:<br>
</div>&gt; Pass an oauth token,<br>
<br>
How? within the subprotocol itself?<br>
<div class=3D"im"><br>
<br>
&gt; or have the WS server issue some challenge that the JS<br>
&gt; answers<br>
<br>
</div>Reinventing the wheel (HTTP Digest auth) but at WS subprotocol level?=
<br>
So should the JavaScript client *code* perform the challenge in pure<br>
and custom JavaScript code? I expect *lots* of future vulnerabilities<br>
in WS.<br>
<br>
Unfortunately it&#39;s common in this WG not to reuse existing<br>
technologies (neither reusing DNS SRV for good<br>
load-balancing/failover, neither reusing any existing authentication<br>
mechanism). This is not good IMHO.<br>
<div class=3D"im"><br></div></blockquote><div><br></div><div>I think the ba=
se protocol defines enough for the vast majority of people to easily work t=
his into their workflow. For those that it&#39;s nontrivial for, it&#39;s c=
ertainly possible and by no means a hard CS problem. If enough people face =
it, they can build a library, or propose an extension.</div>
<div><br></div><div>As for loadbalancing / failover beyond what basic DNS p=
rovides, again, this isn&#39;t required for a base protocol but could easil=
y be specified as an extension should the need arise / people wish to do so=
. HTTP and TCP weren&#39;t built in a day either.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex;"><div class=3D"im">
<br>
&gt; (or presents to the user on behalf of the server if it&#39;s really<br=
>
&gt; necessary), many ways. This is not a new problem.<br>
<br>
</div>Even worse, it&#39;s not a new problem but it seems that WebSocket dr=
aft<br>
authors don&#39;t want to deal with it. WebSocket world will become a<br>
jungle.<br>
<br>
So, is it really possible that WebSocket will be the first<br>
client-&gt;server protocol without, at least, one solid authentication<br>
mechanism specified? I just can&#39;t believe it. Please, WS is not like a<=
br>
DNS query. WS is supposed to carry personal and private data.<br>
<br>
Please don&#39;t take me wrong, but IMHO some other people with experience<=
br>
in Internet protocols other than HTTP should also take a look to this<br>
draft. I don&#39;t like the WWW-style of doing things this protocol is<br>
acquiring. The fact that WWW world is a jungle doesn&#39;t mean that any<br=
>
other new protocol (even when related to HTTP) should also be jungle.<br>
<br>
<br>
I strongly disagree with the direction this draft is taking when<br>
coming to authentication area in WebSocket protocol.<br>
<br>
Regards.<br>
<font color=3D"#888888"><br>
--<br>
</font><div><div></div><div class=3D"h5">I=C3=B1aki Baz Castillo<br>
&lt;<a href=3D"mailto:ibc@aliax.net">ibc@aliax.net</a>&gt;<br>
</div></div></blockquote></div><br>

--0015177407d48047f704a6e4a86b--

From ibc@aliax.net  Thu Jun 30 04:50:11 2011
Return-Path: <ibc@aliax.net>
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13D6221F8762 for <hybi@ietfa.amsl.com>; Thu, 30 Jun 2011 04:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.677
X-Spam-Level: 
X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z+8sOa4rTKIm for <hybi@ietfa.amsl.com>; Thu, 30 Jun 2011 04:50:10 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 867D721F875C for <hybi@ietf.org>; Thu, 30 Jun 2011 04:50:10 -0700 (PDT)
Received: by qyk29 with SMTP id 29so1584041qyk.10 for <hybi@ietf.org>; Thu, 30 Jun 2011 04:50:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.224.75 with SMTP id in11mr1427979qcb.211.1309434608422; Thu, 30 Jun 2011 04:50:08 -0700 (PDT)
Received: by 10.229.240.15 with HTTP; Thu, 30 Jun 2011 04:50:08 -0700 (PDT)
In-Reply-To: <CAF4kx8fsyrkdJ7TX2+hkMcb=M-TPtbPiLup1OWoxpvKf=FZDOA@mail.gmail.com>
References: <BANLkTinerv=Ua4d-ma+uPVJjF95U1U5iXg@mail.gmail.com> <BANLkTin4mWJgQm+pfyYRs_RhRkdMBfY_Og@mail.gmail.com> <BANLkTiksptqmTWftg7Ur98QQnp22QV7OLA@mail.gmail.com> <BANLkTimw8T4pZieBeCjaPQJ8oYWfbTjkmg@mail.gmail.com> <BANLkTikOzzHF1dGz-2-UwTC0kb2ZQd_0Jw@mail.gmail.com> <BANLkTimCTTCU4UFA7JFuBvDZSFv++UyGCA@mail.gmail.com> <BANLkTinWnTxkCh9BM_utX0=pxzE02DypuA@mail.gmail.com> <BANLkTi=LEOyhagpGZF9gTyLxGuqv5U64wmO_afwaw=eR=pVcPw@mail.gmail.com> <BANLkTinGb38bLyH20Q-QaP2jeDCfgYvENw@mail.gmail.com> <CABLsOLD-EWb=pQ33c9FSU3cu0JTGS5mc2-e5-oq-skfp7rzQhA@mail.gmail.com> <CALiegfnfWwqtWqHZ5GUCWMNdWODnV+fHNhn+fxpL49KQ=Fs8Fw@mail.gmail.com> <BANLkTi=CHoqCaTpBUyjokotR6F6tcfajcNedwQg0_ge0JRUYNQ@mail.gmail.com> <CALiegf=Y-kWG7piRnbDtKeh7Edj11OtQqHVCUq4N2_D1pXG8Qw@mail.gmail.com> <BANLkTim++ywp3fCM8YXuRkH41pUOLqbJZt1JhVdpdUcbJkaVmQ@mail.gmail.com> <CALiegfm8aCsnav51DC=h4DmH+F0DAJUk69D4bbv_0GtvDjw3tw@mail.gmail.com> <CAF4kx8fsyrkdJ7TX2+hkMcb=M-TPtbPiLup1OWoxpvKf=FZDOA@mail.gmail.com>
Date: Thu, 30 Jun 2011 13:50:08 +0200
Message-ID: <CALiegfnDTgq2B1G+qDmsG+Vv1=bcKedhcn-UJbcNHv__JRHSjg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: ifette@google.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Greg Wilkins <gregw@intalio.com>
Subject: Re: [hybi] About authentication mechanism
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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, 30 Jun 2011 11:50:11 -0000

2011/6/30 Ian Fette (=E3=82=A4=E3=82=A2=E3=83=B3=E3=83=95=E3=82=A7=E3=83=83=
=E3=83=86=E3=82=A3) <ifette@google.com>:
> As for loadbalancing / failover beyond what basic DNS provides, again, th=
is
> isn't required for a base protocol but could easily be specified as an
> extension should the need arise / people wish to do so. HTTP and TCP were=
n't
> built in a day either.

Hi Ian. DNS SRV does exist but however HTTP makes no usage of it, why?
because HTTP was previous to SRV and because at this time, it's
impossible to expect that all HTTP clients would implement SRV.

If WebSocket protocol is published without mandating DNS SRV
resolution in client side, then adding it into a late extension will
never succeed (as there will be clients not supporting it, so a server
could never rely on SRV resolution from clients).

In other protocols much more complex than WebSocket (as SIP or XMPP),
DNS SRV is defined/mandated in the core protocol, it's not an
extension, so things work.

BTW: http://tools.ietf.org/html/draft-ibc-websocket-dns-srv-02

Cheers.



--=20
I=C3=B1aki Baz Castillo
<ibc@aliax.net>
