From tyoshino@google.com Thu Jul 7 05:36:06 2011 Return-Path: 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 D12E121F86B9 for ; Thu, 7 Jul 2011 05:36:06 -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 DOgFjpRh4wj8 for ; Thu, 7 Jul 2011 05:36:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id D77A821F8754 for ; Thu, 7 Jul 2011 05:36:05 -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 p67Ca5lA023958 for ; Thu, 7 Jul 2011 05:36:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310042165; bh=CJiaUGFTHSL8f1t9K+mG6t9l16E=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=EYd6sEOvymAnqKTtrw3g5JYL58pziU1BtaACDGwDWdHykrhsbp+4sNyQRC95aC7+H N05AM3jK6alCpCsaje1LA== 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:content-type:x-system-of-record; b=WwPAEtpbvAMQFJGWLwJV7R67xv5vEGRo+dA4D0PCVVUchokoYNMXmhkngiVcbXwPh twA/nHkdB4jOXT9b7gJOA== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by kpbe19.cbf.corp.google.com with ESMTP id p67Ca3as000438 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2011 05:36:03 -0700 Received: by yib2 with SMTP id 2so379103yib.38 for ; Thu, 07 Jul 2011 05:36: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 :content-type; bh=iRJAQayt3EiSozkRrxtmCypLTrzXJwBXTOXcSVzrqCw=; b=cXvxgveGqXCHlqTnyw6L0JhoFMPIvdy6qH6/H5bdgNM1E8UmXzrm5sACf7abm6I83Y 3vNUUwlRHgcFEmiCFSjw== Received: by 10.151.92.3 with SMTP id u3mr879600ybl.114.1310042163117; Thu, 07 Jul 2011 05:36:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.13.7 with HTTP; Thu, 7 Jul 2011 05:35:43 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: Takeshi Yoshino Date: Thu, 7 Jul 2011 21:35:43 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd25774c5fd4404a779f53d X-System-Of-Record: true Subject: Re: [hybi] Payload only compression extension, again X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:36:06 -0000 --000e0cd25774c5fd4404a779f53d Content-Type: text/plain; charset=ISO-8859-1 Here's new draft. http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-01 http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=http://tools.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-00.txt&url2=http://tools.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-01.txt I've applied the change below, added some examples and changed requirement on negotiation. Extension parameters (e.g. LZ77 window size negotiation) can be added in future versions. Old server implementation just ignores received extension parameters and reply with only extension token to ask the client to fall back to old version. Thanks, Takeshi On Tue, May 10, 2011 at 16:30, Takeshi Yoshino wrote: > I can change my proposal to accept last blocks (blocks with BFINAL=1) to > allow use of java.util.zip. In my proposal, receiver expects 3 header bits > 0b000 (and padding to byte boundary) on the tail of the application data > portion. Not to complicate receiver logic much, I'd make change like this > - sender: send( + "\x00") > - receiver: inflate(received_data + "\x00\x00\xff\xff"). every time > inflater encounters end of stream (the last octet of a last block), renew > inflater and keep decompressing the remainder. > or > - sender: send() > - receiver: inflate(received_data). every time inflater encounters end of > stream, renew inflater and keep decompressing the remainder. if the end of > received_data is not end of stream, inflate("\x00\x00\xff\xff"). > > Either algorithm works for Z_SYNC_FLUSH-ed and "\x00\x00\xff\xff" stripped > frame, too. > > Takeshi > > > > On Tue, May 3, 2011 at 07:52, Greg Wilkins wrote: > >> On 3 May 2011 08:02, John Tamplin wrote: >> > My point was I see little value in having a compression extension which >> > starts the compression state afresh with every frame, as on real-world >> > applications this gives poor performance. >> >> +1 >> >> My extension is more about prototyping plugable extension that work >> well in a chain of extension, plus handling the negotiation and per >> frame issues. I'll follow the lead of the others/experience on the >> exact algorithms to use (even though I think that is going to cause me >> endless headaches with mismatched licenses and getting IP audits done >> at eclipse :( >> >> cheers >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > > --000e0cd25774c5fd4404a779f53d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Here's new draft.

I've applied the change below, added some= examples and changed requirement on negotiation. Extension parameters (e.g= . LZ77 window size negotiation) can be added in future versions. Old server= implementation just ignores received extension parameters and reply with o= nly extension token to ask the client to fall back to old version.

Thanks,
Takeshi


On Tue, May 10, 2011 at 16:30, Takeshi Y= oshino <tyoshin= o@google.com> wrote:
I can change my proposal to accept last blocks (blocks with=A0BFINAL=3D1) t= o allow use of java.util.zip. In my proposal, receiver expects 3 header bit= s 0b000 (and padding to byte boundary) on the tail of the application data = portion.=A0Not to complicate receiver logic much, I'd make change like = this
- sender: send(<compressed data flushed with Z_FINISH> + "\x00&q= uot;)
- receiver: inflate(received_data + "\x00\x00\xff\xff&= quot;). every time inflater encounters end of stream (the last octet of a l= ast block), renew inflater and keep decompressing the remainder.
or
- sender: send(<compressed data flushed with= Z_FINISH>)
- receiver: inflate(received_data).=A0every time i= nflater encounters end of stream, renew inflater and keep decompressing the= remainder. if the end of received_data is not end of stream, inflate("= ;\x00\x00\xff\xff").

Either algorithm works for Z_SYNC_FLUSH-ed and "\x= 00\x00\xff\xff" stripped frame, too.

Takeshi



On Tue, May 3, 2011 at 07:52, Greg Wilki= ns <gregw@intalio.com> wrote:
On 3 May 2011 08:02, John Tamplin <jat@google.com> wrote:
> My point was I see little value in having a compression extension whic= h
> starts the compression state afresh with every frame, as on real-world=
> applications this gives poor performance.

+1

My extension is more about prototyping plugable extension that work
well in a chain of extension, plus handling the negotiation and per
frame issues. =A0 =A0I'll follow the lead of the others/experience on t= he
exact algorithms to use (even though I think that is going to cause me
endless headaches with mismatched licenses and getting IP audits done
at eclipse :(

cheers
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--000e0cd25774c5fd4404a779f53d-- From ibc@aliax.net Thu Jul 7 05:41:39 2011 Return-Path: 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 3DCC621F87C8 for ; Thu, 7 Jul 2011 05:41:39 -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 CHTd-Zhs7wyD for ; Thu, 7 Jul 2011 05:41:38 -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 A772221F87C7 for ; Thu, 7 Jul 2011 05:41:38 -0700 (PDT) Received: by gwb20 with SMTP id 20so423910gwb.31 for ; Thu, 07 Jul 2011 05:41:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.184.33 with SMTP id r21mr863205yhm.11.1310042498082; Thu, 07 Jul 2011 05:41:38 -0700 (PDT) Received: by 10.146.121.7 with HTTP; Thu, 7 Jul 2011 05:41:38 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> Date: Thu, 7 Jul 2011 14:41:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Payload only compression extension, again X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 12:41:39 -0000 2011/7/7 Takeshi Yoshino : > Old server implementation just ignores received extension parameters and > reply with only extension token to ask the client to fall back to old > version. Hi, WS is still a draft, IMHO the specs should not include backawards compatibility mechanisms with other revisions of the spec (while still a draft). Maybe I miss something? Regards. --=20 I=C3=B1aki Baz Castillo From jat@google.com Thu Jul 7 07:17:47 2011 Return-Path: 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 620F121F8776 for ; Thu, 7 Jul 2011 07:17:47 -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 eR5QclR636Qf for ; Thu, 7 Jul 2011 07:17:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 93C3421F8758 for ; Thu, 7 Jul 2011 07:17:46 -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 p67EHixa019759 for ; Thu, 7 Jul 2011 07:17:45 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1310048265; bh=IAlY3X09seBtRI+4uMXitKlHXWc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mmYogSEd4GwAheAHnahsjkOwechmX0lnhfSo1hXQtLxSRYe4JD3igxg8zude/MzOy Rmu7TrIkN9azqB7EkKjOA== 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=gLXke00DtwMbOVkdJLCqEeENFOif56dkxcE50hc7VedkRHfPl6oQeAgizud1uwSRu j+nQkJuAexJcNqkfU6z3Q== Received: from gxk1 (gxk1.prod.google.com [10.202.11.1]) by kpbe11.cbf.corp.google.com with ESMTP id p67EHhJd023628 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 7 Jul 2011 07:17:43 -0700 Received: by gxk1 with SMTP id 1so506846gxk.10 for ; Thu, 07 Jul 2011 07:17:43 -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=btqLqrJNuBD7C9nxwt7jPp2NvI+SeU6obtcRVthELzk=; b=DLCcKOFv648TfJiswwYOiWphJbJnvFv4me8qU+xrSVTZg/M+QlZ0BEQDNc4RRf5U1M nT5tix2kp8D7x1j/F4zw== Received: by 10.150.66.20 with SMTP id o20mr925204yba.344.1310048263106; Thu, 07 Jul 2011 07:17:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Thu, 7 Jul 2011 07:17:23 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: John Tamplin Date: Thu, 7 Jul 2011 10:17:23 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd51b405c730c04a77b61b5 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Payload only compression extension, again X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 14:17:47 -0000 --000e0cd51b405c730c04a77b61b5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jul 7, 2011 at 8:41 AM, I=C3=B1aki Baz Castillo wro= te: > Hi, WS is still a draft, IMHO the specs should not include backawards > compatibility mechanisms with other revisions of the spec (while still > a draft). Maybe I miss something? > The problem is that there are deployed implementations, and breaking them would be bad for adoption of the spec. I agree, you don't want to clutter up the spec with too much support for old versions, but in this case there is very little cost. In an ideal world, the spec would be finished before it was deployed, but that also means not getting implementation experience back into the spec, s= o there are tradeoffs both ways. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd51b405c730c04a77b61b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 7, 2011 at 8:41 AM, I=C3=B1aki Baz C= astillo <ibc@aliax.ne= t> wrote:
Hi, WS is still a draft, IMHO the specs should not include backawards
compatibility mechanisms with other revisions of the spec (while still
a draft). Maybe I miss something?

The = problem is that there are deployed implementations, and breaking them would= be bad for adoption of the spec. =C2=A0I agree, you don't want to clut= ter up the spec with too much support for old versions, but in this case th= ere is very little cost.

In an ideal world, the spec would be finished before it was = deployed, but that also means not getting implementation experience back in= to the spec, so there are tradeoffs both ways.

--
John A. T= amplin
Software Engineer (GWT), Google
--000e0cd51b405c730c04a77b61b5-- From alexey.melnikov@isode.com Thu Jul 7 11:42:00 2011 Return-Path: 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 D2D4821F867A for ; Thu, 7 Jul 2011 11:42:00 -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 3T+lYzNUFiSO for ; Thu, 7 Jul 2011 11:42:00 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D0CBB21F8678 for ; Thu, 7 Jul 2011 11:41:58 -0700 (PDT) Received: from [188.28.132.132] (188.28.132.132.threembb.co.uk [188.28.132.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jul 2011 19:41:56 +0100 Message-ID: <4E15FDCF.7020803@isode.com> Date: Thu, 07 Jul 2011 19:41:19 +0100 From: Alexey Melnikov 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 References: <4DFB8E07.60908@stpeter.im> In-Reply-To: <4DFB8E07.60908@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:42:00 -0000 Peter Saint-Andre wrote: [...] >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. > > I've replaced "None" with "Use of WebSocket requires use of HTTP version 1.1 or higher.". I hope this is sufficient. >Section 11.6 mentions private use tokens beginning with "x-". Ick. :) > > I think this is still a debate to have in the Apps Area meeting in Quebec ;-). >Typo in Section 11.10: "Paragraph 10 of Paragraph 4 of Section 5.1 " > > I've removed "of Paragraph 4", as I think the Paragraph 10 of Section 5.1 is the correct reference. >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. > I am not entirely sure that RFC Required prevents what the document does, but in order to clarify I've added: In order to improve interoperability with intermediate versions published in Internet Drafts, version numbers associated with such drafts might be registered in this registry. From alexey.melnikov@isode.com Thu Jul 7 11:56:24 2011 Return-Path: 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 2B69721F8656 for ; Thu, 7 Jul 2011 11:56:24 -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 cAMpN1h7QWwy for ; Thu, 7 Jul 2011 11:56:23 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 56FCB21F8655 for ; Thu, 7 Jul 2011 11:56:23 -0700 (PDT) Received: from [188.28.132.132] (188.28.132.132.threembb.co.uk [188.28.132.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jul 2011 19:56:20 +0100 Message-ID: <4E160135.4070405@isode.com> Date: Thu, 07 Jul 2011 19:55:49 +0100 From: Alexey Melnikov 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 References: <4DF93ACB.9070100@stpeter.im> In-Reply-To: <4DF93ACB.9070100@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] -09: data framing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:56:24 -0000 Peter Saint-Andre wrote: >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 = %x0 ; 1 bit, MUST be 0 > > frame-rsv2 = %x0 ; 1 bit, MUST be 0 > > frame-rsv3 = %x0 ; 1 bit, MUST be 0 > >I think we mean "MUST be 0 unless negotiated otherwise". > > Yes, changed. >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)? > > I think this would require a bit of discussion and some text (not necessarily from you). >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. > > I think this is already clear, e.g. A Pong frame sent in response to a Ping frame must have identical Application Data as found in the message body of the Ping frame being replied to. >In 4.8, I think we mean "prescriptive" instead of "proscriptive" (from >"proscribe" = "forbid"). > Fixed. >o Extension data may be placed in the payload data before the > application data. > >Do we mean "MAY"? > I don't feel particularly strongly about this, but this sentence is included in the list of examples, so use of MAY seems inapropriate. From alexey.melnikov@isode.com Thu Jul 7 11:59:54 2011 Return-Path: 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 BA2EA1F0C7F for ; Thu, 7 Jul 2011 11:59:54 -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 xTMoY+2fX7LG for ; Thu, 7 Jul 2011 11:59:54 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2741F0C72 for ; Thu, 7 Jul 2011 11:59:54 -0700 (PDT) Received: from [188.28.132.132] (188.28.132.132.threembb.co.uk [188.28.132.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jul 2011 19:59:51 +0100 Message-ID: <4E160204.4080807@isode.com> Date: Thu, 07 Jul 2011 19:59:16 +0100 From: Alexey Melnikov 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 References: <4DFB906D.2000905@stpeter.im> In-Reply-To: <4DFB906D.2000905@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] -09: SHA-1 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 18:59:54 -0000 Peter Saint-Andre wrote: >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. > There is no requirement for collision resistence, as far as I understand. IMHO, we can even use MD5. SHA-1 is used to protect against replays (different requests will have different client key and thus different hashes) and intermediaries that would try to mess with websocket traffic without understanding it. Do you think that needs to be said in the Security Considerations? From alexey.melnikov@isode.com Thu Jul 7 12:05:39 2011 Return-Path: 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 35B8C1F0CC4 for ; Thu, 7 Jul 2011 12:05:39 -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 G9pClO5nsOSZ for ; Thu, 7 Jul 2011 12:05:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCD81F0C7F for ; Thu, 7 Jul 2011 12:05:38 -0700 (PDT) Received: from [188.28.132.132] (188.28.132.132.threembb.co.uk [188.28.132.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jul 2011 20:05:37 +0100 Message-ID: <4E15EF9F.7080001@isode.com> Date: Thu, 07 Jul 2011 18:40:47 +0100 From: Alexey Melnikov 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: Willy Tarreau References: <20110615211401.GG21551@1wt.eu> In-Reply-To: <20110615211401.GG21551@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:05:39 -0000 Hi, Willy Tarreau wrote: >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. > I've used a slightly modified version of this text: In compliance with RFC 2616, header fields in the handshake may be sent by the client in any order, so the order in which different header fields are received is not significant. >The same point is valid for the response format BTW. > > Right. > > From alexey.melnikov@isode.com Thu Jul 7 12:12:58 2011 Return-Path: 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 6F6F61F0CCA for ; Thu, 7 Jul 2011 12:12:58 -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 I8sB0rV4AkLb for ; Thu, 7 Jul 2011 12:12:57 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 391361F0CC9 for ; Thu, 7 Jul 2011 12:12:57 -0700 (PDT) Received: from [188.28.132.132] (188.28.132.132.threembb.co.uk [188.28.132.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jul 2011 20:12:44 +0100 Message-ID: <4E16050C.1070002@isode.com> Date: Thu, 07 Jul 2011 20:12:12 +0100 From: Alexey Melnikov 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 References: <4DF91FCA.8060403@stpeter.im> In-Reply-To: <4DF91FCA.8060403@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:12:58 -0000 Peter Saint-Andre wrote: >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 > I've done that in my copy ... >and putting them in a slightly-longer first paragraph in the intro >(before Section 1.1). > ... but I haven't done that part yet. >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've used your text, thanks! >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 impossible. > > I am afraid I will need some help with such text. >BTW [I-D.ietf-httpstate-cookie] is now [RFC6265] (thanks, Adam!). > Updated. >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? > > The section is informative. Do you really want the specific error code(s) listed? >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? > I think you got an answer to this on the mailing list. >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. > I think you got an answer to this on the mailing list: the section is informative, so it would be better to avoid using RFC 2119 language here. >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. > I've changed that to "intercepting proxies", I think that is the correct 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). > Changed, thanks. >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. > Changed. I will review later on if the text is actually correctly describe the protocol. >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 think that was also extensively discussed on the mailing list. >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 = 1* > >And in RFC 5234 we find: > > CHAR = %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. > I think just saying "ASCII domain name" in Section 1.9 should be sufficient. If you think the document should have a reference to the most recent IDNA specs, such reference can be added. From w@1wt.eu Thu Jul 7 12:15:53 2011 Return-Path: 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 785181F0CD9 for ; Thu, 7 Jul 2011 12:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.321 X-Spam-Level: X-Spam-Status: No, score=-6.321 tagged_above=-999 required=5 tests=[AWL=-4.278, 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 5usAHMEdUSpv for ; Thu, 7 Jul 2011 12:15:53 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id AEF131F0CD6 for ; Thu, 7 Jul 2011 12:15:52 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p67JFkRN028199; Thu, 7 Jul 2011 21:15:46 +0200 Date: Thu, 7 Jul 2011 21:15:46 +0200 From: Willy Tarreau To: Alexey Melnikov Message-ID: <20110707191546.GA27254@1wt.eu> References: <20110615211401.GG21551@1wt.eu> <4E15EF9F.7080001@isode.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E15EF9F.7080001@isode.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 19:15:53 -0000 Hi Alexey, On Thu, Jul 07, 2011 at 06:40:47PM +0100, Alexey Melnikov wrote: > I've used a slightly modified version of this text: > > In compliance with RFC 2616, header fields in the handshake may be > sent by > the client in any order, so the order in which different header fields > are received is not significant. This looks perfect to me. Thanks, Willy From alexey.melnikov@isode.com Thu Jul 7 13:54:49 2011 Return-Path: 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 5F9339E8022 for ; Thu, 7 Jul 2011 13:54:49 -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 i51sLj9ao-44 for ; Thu, 7 Jul 2011 13:54:48 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 909419E8019 for ; Thu, 7 Jul 2011 13:54:48 -0700 (PDT) Received: from [188.28.132.132] (188.28.132.132.threembb.co.uk [188.28.132.132]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 7 Jul 2011 21:54:47 +0100 Message-ID: <4E161CEB.2080104@isode.com> Date: Thu, 07 Jul 2011 21:54:03 +0100 From: Alexey Melnikov 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 References: <4DFA967D.5050308@stpeter.im> In-Reply-To: <4DFA967D.5050308@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] -09: sending, closing, errors, extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jul 2011 20:54:49 -0000 Peter Saint-Andre wrote: >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". > Changed. I've read "unmask" as "remove masking", but I see why this can be confusing. >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? > I think I've complained about this privately as well :-) >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. > Fixed. >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 > From salvatore.loreto@ericsson.com Fri Jul 8 01:33:45 2011 Return-Path: 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 595D221F86CA for ; Fri, 8 Jul 2011 01:33:45 -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 tx5mWzbmdGpY for ; Fri, 8 Jul 2011 01:33:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 0878521F859A for ; Fri, 8 Jul 2011 01:33:43 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-bd-4e16c0e67452 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 93.7F.20773.6E0C61E4; Fri, 8 Jul 2011 10:33:42 +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, 8 Jul 2011 10:33:42 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 48510245F for ; Fri, 8 Jul 2011 11:33:42 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0EDD0511A2 for ; Fri, 8 Jul 2011 11:33:42 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BBE8550B46 for ; Fri, 8 Jul 2011 11:33:41 +0300 (EEST) Message-ID: <4E16C0E5.40106@ericsson.com> Date: Fri, 8 Jul 2011 11:33:41 +0300 From: Salvatore Loreto 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" Content-Type: multipart/alternative; boundary="------------010901090009000107070500" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] WebSocket: current status and next steps X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:33:45 -0000 --------------010901090009000107070500 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit (as chairs) status: ------ Gabriel and I started the WG last call process for version -07 on April 25th, 2011 (until May 9th), since then two new version -08 and -09 have been produced to address all the comments/discussion received during the WG LC time and after the IESG process requires that once the WG LC is over and the document is ready it has to be submitted to IESG for publication... so we have asked the IESG to publish it, I will be the Document Shepherd for it. (if you are not familiar with the IETF process see: http://tools.ietf.org/html/rfc4858#section-3 ) Now we are on the AD evaluation phase: Peter Saint-Andre is the Application AD responsible for HyBi wg; (you can check all the information from the tracker: https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/ ) In order to address the last, mostly editorials comments/fix we have asked the editors to produce a new version -10 for July 11th as soon the version -10 is produced we will ask to start the two weeks broader IESG/IETF last call that involve all the IETF community (not only the HyBi wg): the discussion will happen on the IETF discussion list (ietf@ietf.org): http://www.ietf.org/list/discussion.html The idea is to take advantage of the IETF81 meeting in Quebec to discuss all the comments received on version -10 what next: --------- now that the WebSocket Protocol is stable, it is time to discuss the extension that we have put on hold for a while and decide on what we want to work. among the others I have in my notes: - Multiplexing - per Frame deflate extension (draft-tyoshino-hybi-websocket-perframe-deflate) - Timeout (draft-thomson-hybi-http-timeout) - DNS SRV for WebSocket (draft-ibc-websocket-dns-srv) forgive me and let me know if I forgot something... or there is other stuff you think is important to discuss cheers /Sal -- Salvatore Loreto www.sloreto.com --------------010901090009000107070500 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit (as chairs)

status:
------
Gabriel and I started the WG last call process for version -07 on April 25th, 2011 (until May 9th),
since then two new version -08 and -09 have been produced
to address all the comments/discussion received during the WG LC time and after

the IESG process requires that once the WG LC is over and the document is ready
it has to be submitted to IESG for publication...
so we have asked the IESG to publish it,
I will be the Document Shepherd for it.


(if you are not familiar with the IETF process see: http://tools.ietf.org/html/rfc4858#section-3 )

Now we are on the AD evaluation phase:
Peter Saint-Andre is the Application AD responsible for HyBi wg;
(you can check all the information from the tracker:
https://datatracker.ietf.org/doc/draft-ietf-hybi-thewebsocketprotocol/ )

In order to address the last, mostly editorials comments/fix we have asked the editors to produce
a new version -10 for July 11th

as soon the version -10 is produced we will ask
to start the two weeks broader IESG/IETF last call that involve all the IETF community (not only the HyBi wg):
the discussion will happen on the IETF discussion list (ietf@ietf.org):
http://www.ietf.org/list/discussion.html


The idea is to take advantage of the IETF81 meeting in Quebec to discuss all the comments received
on version -10



what next:
---------
now that the WebSocket Protocol is stable, it is time to discuss the extension that we have put on hold for a while
and decide on what we want to work.
among the others I have in my notes:
    - Multiplexing
    - per Frame deflate extension (draft-tyoshino-hybi-websocket-perframe-deflate)
    - Timeout (draft-thomson-hybi-http-timeout)
    - DNS SRV for WebSocket (draft-ibc-websocket-dns-srv)


forgive me and let me know if I forgot something... or there is other stuff you think is important to discuss


cheers
/Sal
-- 
Salvatore Loreto
www.sloreto.com
--------------010901090009000107070500-- From djc.ochtman@gmail.com Fri Jul 8 01:48:59 2011 Return-Path: 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 B012421F86F3 for ; Fri, 8 Jul 2011 01:48:59 -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 hxyX2+RiaFnT for ; Fri, 8 Jul 2011 01:48:59 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3054321F86FC for ; Fri, 8 Jul 2011 01:48:59 -0700 (PDT) Received: by yxp4 with SMTP id 4so867127yxp.31 for ; Fri, 08 Jul 2011 01:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=u/5N06TEFYi3odmbK2u31kjoSt8aaf4s8M2gfxNpRGc=; b=LN+IXApTLGqaHguu3xjwaYNHSjj33yoRdMS982Khaxe4Bzkklm6vO+5zf2yQvWZtqT hYCpwwk+JkXCTUyP0IUhAO0jTy8hXXWCKaypZOo8A9FkA4WxJK0d7yUc9cVvwvkkRHSm I40GJYNbScp8q7M8xQjJEzXRmZtxVkePO+M7I= Received: by 10.150.169.18 with SMTP id r18mr1819802ybe.331.1310114938076; Fri, 08 Jul 2011 01:48:58 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.150.144.2 with HTTP; Fri, 8 Jul 2011 01:48:38 -0700 (PDT) In-Reply-To: <4E16C0E5.40106@ericsson.com> References: <4E16C0E5.40106@ericsson.com> From: Dirkjan Ochtman Date: Fri, 8 Jul 2011 10:48:38 +0200 X-Google-Sender-Auth: GT5f3kVLRXYtm3Sgzpt8-bh9Nu0 Message-ID: To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket: current status and next steps X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 08:48:59 -0000 On Fri, Jul 8, 2011 at 10:33, Salvatore Loreto wrote: > what next: > --------- > now that the WebSocket Protocol is stable, it is time to discuss the > extension that we have put on hold for a while > and decide on what we want to work. > among the others I have in my notes: > =C2=A0=C2=A0=C2=A0 - Multiplexing > =C2=A0=C2=A0=C2=A0 - per Frame deflate extension > (draft-tyoshino-hybi-websocket-perframe-deflate) > =C2=A0=C2=A0=C2=A0 - Timeout (draft-thomson-hybi-http-timeout) > =C2=A0=C2=A0=C2=A0 - DNS SRV for WebSocket (draft-ibc-websocket-dns-srv) For the deflate extension, it seems to me that there's a fair amount of consensus on this list (in "deflate-stream and masking") that the deflate-stream extension as specified in draft-09 is suboptimal. Given that, it seems prudent to exclude it from the WebSocket Protocol spec for now and await the outcome of the perframe-deflate efforts. As for DNS SRV, I briefly looked it over and think it would certainly be nice to specify. I just wonder if it wouldn't make more sense to put it inside the WebSocket Protocol spec, given the mandatory machinations required from WebSocket client applications. Cheers, Dirkjan From salvatore.loreto@ericsson.com Fri Jul 8 02:12:54 2011 Return-Path: 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 6CEA321F88C0 for ; Fri, 8 Jul 2011 02:12:54 -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 ICkn8AUW+mh8 for ; Fri, 8 Jul 2011 02:12:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8BA2821F86FC for ; Fri, 8 Jul 2011 02:12:53 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-1d-4e16ca14b456 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EB.06.20773.41AC61E4; Fri, 8 Jul 2011 11:12:52 +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, 8 Jul 2011 11:12:52 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 37BBC245F for ; Fri, 8 Jul 2011 12:12:52 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E8609511A1 for ; Fri, 8 Jul 2011 12:12:51 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A266E508DF for ; Fri, 8 Jul 2011 12:12:51 +0300 (EEST) Message-ID: <4E16CA13.1010206@ericsson.com> Date: Fri, 8 Jul 2011 12:12:51 +0300 From: Salvatore Loreto 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" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 09:12:54 -0000 time for HyBi session in the final version of the agenda: HYBI Session 1 (2 hours) Thursday, Afternoon Session III 1740-1940 Room Name: 202 cheers /Sal -- Salvatore Loreto www.sloreto.com From ibc@aliax.net Fri Jul 8 03:52:35 2011 Return-Path: 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 86C7121F864E for ; Fri, 8 Jul 2011 03:52:35 -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 DaQkRiK2dh8r for ; Fri, 8 Jul 2011 03:52:35 -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 0A36621F8612 for ; Fri, 8 Jul 2011 03:52:34 -0700 (PDT) Received: by qyk9 with SMTP id 9so254471qyk.10 for ; Fri, 08 Jul 2011 03:52:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.19 with SMTP id u19mr1373253qct.173.1310122354061; Fri, 08 Jul 2011 03:52:34 -0700 (PDT) Received: by 10.229.240.15 with HTTP; Fri, 8 Jul 2011 03:52:33 -0700 (PDT) In-Reply-To: References: <4E16C0E5.40106@ericsson.com> Date: Fri, 8 Jul 2011 12:52:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Dirkjan Ochtman Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket: current status and next steps X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 10:52:35 -0000 2011/7/8 Dirkjan Ochtman : > As for DNS SRV, I briefly looked it over and think it would certainly > be nice to specify. I just wonder if it wouldn't make more sense to > put it inside the WebSocket Protocol spec, given the mandatory > machinations required from WebSocket client applications. Hi, the problem with the extensions is that we are speaking mostly about webbrowsers. So if just a widely used webbrowser in the world decides not to implement an extension (ie: DNS SRV if approbed) then WebSocket service providers could not rely on such mechanism. I suppose the same is true for other extensions (but I'm not sure about their backwards-compatibility and so). In the case of DNS SRV, all the clients must implement it. If not, it's like if it does not exist because no one service provider will want to use DNS SRV knowing that some known clients cannot use them. Just wondering. Regards. --=20 I=C3=B1aki Baz Castillo From djc.ochtman@gmail.com Fri Jul 8 04:05:22 2011 Return-Path: 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 51EB021F8870 for ; Fri, 8 Jul 2011 04:05:22 -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, 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 uIiUEqUaa6Bs for ; Fri, 8 Jul 2011 04:05:21 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id C55F421F87E2 for ; Fri, 8 Jul 2011 04:05:21 -0700 (PDT) Received: by ywp31 with SMTP id 31so109990ywp.31 for ; Fri, 08 Jul 2011 04:05:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=yZw9DQp6tPvwZoewBFkiGT1ppE+AoQJZutQh7NKZUls=; b=a14iEXryypIY4Rvcm19e5CYtMgkNQ9woAN/FLm3TrzfaYZkyxcpYH4ZylFh/97kWKO L3uY/SlOD3P1XXxOyBwyhaYL9Uz01cKMDWeoXg/62allsCDt93CLf/5TSMF2x4F2lnMv 4cD5Q/DXwUD8aklCqYOuLF+oKHDWwYLjKeGjE= Received: by 10.150.74.17 with SMTP id w17mr1815043yba.274.1310123121249; Fri, 08 Jul 2011 04:05:21 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.150.144.2 with HTTP; Fri, 8 Jul 2011 04:05:01 -0700 (PDT) In-Reply-To: References: <4E16C0E5.40106@ericsson.com> From: Dirkjan Ochtman Date: Fri, 8 Jul 2011 13:05:01 +0200 X-Google-Sender-Auth: z35MlCU7sRqUNYXzsq-QpDs6D_Y Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket: current status and next steps X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 11:05:22 -0000 On Fri, Jul 8, 2011 at 12:52, I=C3=B1aki Baz Castillo wrote= : > Hi, the problem with the extensions is that we are speaking mostly > about webbrowsers. So if just a widely used webbrowser in the world > decides not to implement an extension (ie: DNS SRV if approbed) then > WebSocket service providers could not rely on such mechanism. That was kind of my point (but admittedly poorly expressed): we should put it in the spec (i.e. not as an extension) instead of specifying it separately as an extension. Cheers, Dirkjan From alexey.melnikov@isode.com Fri Jul 8 09:02:44 2011 Return-Path: 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 0C67421F8B09 for ; Fri, 8 Jul 2011 09:02:44 -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 vi+IUUM10zyQ for ; Fri, 8 Jul 2011 09:02:42 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7A87721F8B06 for ; Fri, 8 Jul 2011 09:02:41 -0700 (PDT) Received: from [188.28.19.130] (188.28.19.130.threembb.co.uk [188.28.19.130]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Fri, 8 Jul 2011 17:02:38 +0100 Message-ID: <4E172A00.3060600@isode.com> Date: Fri, 08 Jul 2011 17:02:08 +0100 From: Alexey Melnikov 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 References: <4DFA7ABF.3030308@stpeter.im> In-Reply-To: <4DFA7ABF.3030308@stpeter.im> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] -09: handshake X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jul 2011 16:02:44 -0000 Peter Saint-Andre wrote: >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". > I will try to clarify. >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... > Changed. > 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? > > All of the above. I am not convinced that that needs clarifying, I think the text is clear as is. >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've used the following variation of your text, which I think is more correct: 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 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 if thirty simultaneous connections to a single host are requested, that may not be allowed). 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. > > While your suggestion might be a good idea, I would like to hear more feedback from the WG. >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"? > > I've changed "hosts" to "host/IP addresses" (I assume the former comes from some reverse DNS lookup). I don't think "client" is going to be useful, because in a general case the server can't tell if it is talking to the same client or not. (Hmm, unless the client is using the same TLS certificate or something like this.) But anyway, this text is informative and I think leaving it as is or adding "IP addresses" is good enough. > 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. :) > > Changed. >s/SOCKS/SOCKS5 [RFC1928]/ > >s/[RFC3548]/[RFC4648]/ > Updated. >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. > Agreed. >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). > I don't think mandating that is a good idea. The client might pipeline its data in anticipation of successful outcome of the handshake. That was discussed on the mailing list. >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? > Yes, but in general case the client doesn't know that until it reads the response to the handshake. So I suggest no change is needed. From gregw@intalio.com Sun Jul 10 18:26:53 2011 Return-Path: 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 6975A21F8661 for ; Sun, 10 Jul 2011 18:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.773 X-Spam-Level: X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[AWL=0.204, 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 qQgfvgjtys-Y for ; Sun, 10 Jul 2011 18:26:53 -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 D413221F8655 for ; Sun, 10 Jul 2011 18:26:52 -0700 (PDT) Received: by vws12 with SMTP id 12so3575255vws.31 for ; Sun, 10 Jul 2011 18:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.174.113 with SMTP id br17mr5151658vdc.107.1310347583550; Sun, 10 Jul 2011 18:26:23 -0700 (PDT) Received: by 10.52.115.103 with HTTP; Sun, 10 Jul 2011 18:26:23 -0700 (PDT) In-Reply-To: References: <4E16C0E5.40106@ericsson.com> Date: Mon, 11 Jul 2011 11:26:23 +1000 Message-ID: From: Greg Wilkins To: Dirkjan Ochtman Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket: current status and next steps X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 01:26:53 -0000 On 8 July 2011 18:48, Dirkjan Ochtman wrote: > On Fri, Jul 8, 2011 at 10:33, Salvatore Loreto > For the deflate extension, it seems to me that there's a fair amount > of consensus on this list (in "deflate-stream and masking") that the > deflate-stream extension as specified in draft-09 is suboptimal. Given > that, it seems prudent to exclude it from the WebSocket Protocol spec > for now and await the outcome of the perframe-deflate efforts. +1 From internet-drafts@ietf.org Mon Jul 11 05:33:18 2011 Return-Path: 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 6E9E321F8B05; Mon, 11 Jul 2011 05:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 p4Y00ChzWwyB; Mon, 11 Jul 2011 05:33:18 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007C721F85C5; Mon, 11 Jul 2011 05:33:18 -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: <20110711123317.17092.18690.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 05:33:17 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-10.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 12:33:18 -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 Alexey Melnikov Filename : draft-ietf-hybi-thewebsocketprotocol-10.txt Pages : 68 Date : 2011-07-11 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. 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-10= .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-10.= txt From djc.ochtman@gmail.com Mon Jul 11 06:01:17 2011 Return-Path: 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 739CA21F8B59; Mon, 11 Jul 2011 06:01:17 -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 NAAZvvszuw+d; Mon, 11 Jul 2011 06:01:17 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id BEFA121F8B56; Mon, 11 Jul 2011 06:01:16 -0700 (PDT) Received: by yie30 with SMTP id 30so1796234yie.31 for ; Mon, 11 Jul 2011 06:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=XLX8myk/ayG3I94dYasHNWtlraOOtc2jSy546tV9viw=; b=rg3aZCSnHGe2Yg4VZ0pDBg8MahoXAGOD/QbO1OmtTf5rEUuEDGs/vZwem/kFREb/oj i0uVqE9zbGQkjHT0oLjEgqJCNmVKBqQ5TGkIELvxfrqYdTueIe6sSjujHZgHtheA9kh7 fpdhG1gESzNZhgEOxB7V1KXExxpx4eACFMYi4= Received: by 10.150.132.15 with SMTP id f15mr3985990ybd.388.1310389276090; Mon, 11 Jul 2011 06:01:16 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.150.144.2 with HTTP; Mon, 11 Jul 2011 06:00:56 -0700 (PDT) In-Reply-To: <20110711123317.17092.18690.idtracker@ietfa.amsl.com> References: <20110711123317.17092.18690.idtracker@ietfa.amsl.com> From: Dirkjan Ochtman Date: Mon, 11 Jul 2011 15:00:56 +0200 X-Google-Sender-Auth: VAE1Qc5u5tih2rqqdGY4z4xK9z0 Message-ID: To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org, i-d-announce@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-10.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:01:17 -0000 On Mon, Jul 11, 2011 at 14:33, wrote: > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-10.txt Tools version: http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 Editorial nit, page 15, line 22: "(and it said that "the secure flag is set")" -> "it is said that"? Technical differences (quick overview): - Clarified that ASCII-encoded domain names should be sent - Connection should be failed on unknown opcode (instead of ignoring frame) - reserved bits maybe non-0 when negotiated - Sec-WebSocket-Accept value leading/trailing whitespace should be ignored - client must fail the connection when server-sent frame is non-conformant - new status code 1007 - UTF-8 encoding failure -> must fail the connection Cheers, Dirkjan From julian.reschke@gmx.de Mon Jul 11 06:28:48 2011 Return-Path: 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 97C2E21F8BAA for ; Mon, 11 Jul 2011 06:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.821 X-Spam-Level: X-Spam-Status: No, score=-104.821 tagged_above=-999 required=5 tests=[AWL=-2.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 EtjcBOymXAxZ for ; Mon, 11 Jul 2011 06:28:47 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 2DE5221F8BA9 for ; Mon, 11 Jul 2011 06:28:47 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 13:28:45 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp071) with SMTP; 11 Jul 2011 15:28:45 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vfht+kNnvhpxjTMZfuqr4wedYCCGsIvIAxXXIUF cr0sb2v0zaM3un Message-ID: <4E1AFA8B.7000500@gmx.de> Date: Mon, 11 Jul 2011 15:28:43 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4DFC7A25.3060403@gmx.de> In-Reply-To: <4DFC7A25.3060403@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [hybi] hybi-09 refs X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:28:48 -0000 On 2011-06-18 12:12, Julian Reschke wrote: > ... > 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, > . > > and needs to be updated as well. To enable automated checking with > , > I'd make it: > > target='http://www.w3.org/TR/2011/WD-websockets-20110419/'> > > The WebSocket API > > > > > > Latest version available at > . > > Apparently this wasn't fixed (the spec still references a draft dated August 2010). Also, new: [I-D.ietf-websec-origin] Barth, A., "The Web Origin Concept", draft-ietf-websec-origin-00 (work in progress), December 2010. I believe this has been replaced by (Adam, you should tell the IETF secretariat about replacements like these so that the pub database is correct). Best regards, Julian From julian.reschke@gmx.de Mon Jul 11 06:31:21 2011 Return-Path: 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 E0CD121F8BB1 for ; Mon, 11 Jul 2011 06:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.704 X-Spam-Level: X-Spam-Status: No, score=-104.704 tagged_above=-999 required=5 tests=[AWL=-2.105, 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 OCQNg+7O+cuS for ; Mon, 11 Jul 2011 06:31:21 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id EAAD221F8BB0 for ; Mon, 11 Jul 2011 06:31:20 -0700 (PDT) Received: (qmail invoked by alias); 11 Jul 2011 13:31:19 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 11 Jul 2011 15:31:19 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+TwtIScl6T0nMKhu2cTJcbbFTYegRAs7fiLM78nn cwlyckuaETN4sb Message-ID: <4E1AFB25.8070004@gmx.de> Date: Mon, 11 Jul 2011 15:31:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4DFC7A25.3060403@gmx.de> <4E1AFA8B.7000500@gmx.de> In-Reply-To: <4E1AFA8B.7000500@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [hybi] hybi-09 refs X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:31:22 -0000 On 2011-07-11 15:28, Julian Reschke wrote: > ... > (Adam, you should tell the IETF secretariat about replacements like > these so that the pub database is correct). > ... Sorry, my confusion. ID base name is indeed is the same. From stpeter@stpeter.im Mon Jul 11 06:43:45 2011 Return-Path: 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 2F5A221F8BCD for ; Mon, 11 Jul 2011 06:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.991 X-Spam-Level: X-Spam-Status: No, score=-102.991 tagged_above=-999 required=5 tests=[AWL=-0.392, 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 5S5oFebrNslV for ; Mon, 11 Jul 2011 06:43:44 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 51A4221F8BCC for ; Mon, 11 Jul 2011 06:43:44 -0700 (PDT) Received: from squire.local (unknown [216.17.179.111]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 687D640FFF for ; Mon, 11 Jul 2011 07:44:01 -0600 (MDT) Message-ID: <4E1AFE0E.7090900@stpeter.im> Date: Mon, 11 Jul 2011 07:43:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "hybi@ietf.org" X-Enigmail-Version: 1.1.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [hybi] IETF Last Call X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 13:43:45 -0000 I've requested IETF Last Call for draft-ietf-hybi-thewebsocketprotocol, which means the document will begin to experience wider review. Some of the upcoming feedback will be provided on the ietf@ietf.org discussion list, so you might want to temporarily subscribe to that list: https://www.ietf.org/mailman/listinfo/ietf Also, please note that we have a normative reference to this document: http://tools.ietf.org/html/draft-ietf-websec-origin-02 It would be very helpful for HyBi folks to review that document and post any comments to the WEBSEC WG: https://www.ietf.org/mailman/listinfo/websec Thanks! Peter -- Peter Saint-Andre https://stpeter.im/ From iesg-secretary@ietf.org Mon Jul 11 07:02:29 2011 Return-Path: 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 D978E21F8B92; Mon, 11 Jul 2011 07:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.492 X-Spam-Level: X-Spam-Status: No, score=-102.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 rxr3psy4AA3S; Mon, 11 Jul 2011 07:02:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6609F21F8B40; Mon, 11 Jul 2011 07:02:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> Date: Mon, 11 Jul 2011 07:02:29 -0700 Cc: hybi@ietf.org Subject: [hybi] Last Call: (The WebSocket protocol) to Proposed Standard X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jul 2011 14:02:30 -0000 The IESG has received a request from the BiDirectional or Server-Initiated HTTP WG (hybi) to consider the following document: - 'The WebSocket protocol' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-07-25. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. 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