From tyoshino@google.com Thu Mar 1 11:59:59 2012 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 3481B21E8088 for ; Thu, 1 Mar 2012 11:59:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.953 X-Spam-Level: X-Spam-Status: No, score=-102.953 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6L3BUb+EUitw for ; Thu, 1 Mar 2012 11:59:58 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E42E121E8013 for ; Thu, 1 Mar 2012 11:59:57 -0800 (PST) Received: by yenm5 with SMTP id m5so527325yen.31 for ; Thu, 01 Mar 2012 11:59:57 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.100.225.18 as permitted sender) client-ip=10.100.225.18; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.100.225.18 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.100.225.18]) by 10.100.225.18 with SMTP id x18mr2898346ang.48.1330631997526 (num_hops = 1); Thu, 01 Mar 2012 11:59:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=6YLCmGhtbiSxbqmHXI78ewCwH6gEY7g4O1RwyDgD82s=; b=ZtMCME1M7P5BibXuyr4ZwzVl0+ti7FNyFCJIn/6n0fIYcndsGzKklVVHtWFwmhcl+T MyqLLptUHBzvXEAk5PH2UdpOVCsgkvxNrMdpp3wGMAwGYmKYfjXdZHoC1etVC1Z5l3Pu zdcLR3wU67bpzfbMW4wzGtXdmNAd+rQpet9o/uiTJid9vIRKhP6RN85Lo1NoLpUwL+St AxBIbuq++BnAZpDxB8RVLm2P7Jh+4Wodm3G43R8t5UVYrolF77DmYOKtDXmn9wShJv7o pyIsoDPoyWuI0YG/BNuYATGYh5bMDDQb13Herlrc8Ig7xc1WLMi4YS9fntmSGIklRtmD B9Vw== Received: by 10.100.225.18 with SMTP id x18mr2287886ang.48.1330631997406; Thu, 01 Mar 2012 11:59:57 -0800 (PST) Received: by 10.100.225.18 with SMTP id x18mr2287877ang.48.1330631997272; Thu, 01 Mar 2012 11:59:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Thu, 1 Mar 2012 11:59:37 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> From: Takeshi Yoshino Date: Thu, 1 Mar 2012 14:59:37 -0500 Message-ID: To: John Tamplin Content-Type: multipart/alternative; boundary=001636b432568631db04ba33e7e3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQj/vXfyi7NEUg+JzsfC/we5L8XjXh8M6Ri43ad3Mb0pVyq2QN2aGPsG4O9eW6CavW42L5+ikUrIKMYkO4CeEzLxXzWhTJ8TP2SzylTxgFjgFCqGTQnUk+9HKjyybcI0ChwPGZ Cc: "hybi@ietf.org" , SM , Gabriel Montenegro Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 01 Mar 2012 19:59:59 -0000 --001636b432568631db04ba33e7e3 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 28, 2012 at 09:05, John Tamplin wrote: > > I think it needs some significant changes (in particular, if it is going > to allocate a reserved frame bit it needs to be extensible to other > compression algorithms, which also implies renaming it to compress-frame or > similar), but I think it is a fine starting point. > Do you think drastic abstraction is better? I.e. should we put texts describing generic per-frame compression spec and texts describing how to use it with DEFLATE into separate sections, or even into separate specs? If it's sufficient to make it clear that the bit allocated in this spec is also available for any other per-frame compression method, I'd replace "COMP" bit in the spec with, say, "Per-frame compressed" bit, and change the registration section to: 7.2. Registration of the "Per-frame compressed" WebSocket Framing Header Bit This section describes a WebSocket framing header bit registration in the WebSocket Framing Header Bits Registry. [RFC6455] Header Bit RSV1 Common Name Per-frame compressed Meaning Per-frame compression is applied to the frame or not. Reference Section 4 of this document. The "Per-frame compressed" framing header bit is used to indicate whether any negotiated per-frame compression extension is applied to the frame or not. When this bit is used by this per-frame DEFLATE extension, it means whether "Application data" part of the frame contains octets generated using DEFLATE or not. Any other compression extension MAY define its own use of this bit. Note that this per-frame DEFLATE extension and that extension will be incompatible in such case. --001636b432568631db04ba33e7e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2012 at 09:05, John Tamplin <jat@google.com><= /span> wrote:
I think it needs some significant changes (= in particular, if it is going to allocate a reserved frame bit it needs to = be extensible to other compression algorithms, which also implies renaming = it to compress-frame or similar), but I think it is a fine starting point.= =A0

Do you think drastic abstraction is = better? I.e. should we put texts describing generic per-frame compression s= pec and texts describing how to use it with DEFLATE into separate sections,= or even into separate specs?

If it's sufficient to make it clear that the bit al= located in this spec is also available for any other per-frame compression = method, I'd replace "COMP" bit in the spec with, say, "P= er-frame compressed" bit, and change the registration section to:

7.2. =A0Registration of the "Per-frame compre= ssed" WebSocket Framing Header Bit

=A0 =A0Thi= s section describes a WebSocket framing header bit registration in
=A0 =A0the WebSocket Framing Header Bits Registry. =A0[RFC6455]
<= br>
=A0 =A0Header Bit
=A0 =A0 =A0 RSV1

=A0 =A0Common Name
=A0 =A0 =A0 Per-frame compressed

=A0 =A0Meaning
=A0 =A0 =A0 Per-frame compression is applied to the frame or not.

=A0 =A0Reference
=A0 =A0 =A0 Section 4 of th= is document.

=A0 =A0The "Per-frame compressed= " framing header bit is used to indicate whether
=A0 =A0any negotiated per-frame compression extension is applied to th= e frame or not.

=A0 =A0When this bit=A0is used by = this per-frame DEFLATE extension, it means whether
=A0 =A0"A= pplication data" part of the frame contains octets generated using
=A0 =A0DEFLATE or not.

=A0 =A0Any other compr= ession extension MAY define
=A0 =A0its own use of this bit. =A0No= te that this=A0per-frame DEFLATE
=A0 =A0extension and that extens= ion will be incompatible=A0in such case.

--001636b432568631db04ba33e7e3-- From tyoshino@google.com Thu Mar 1 12:04:46 2012 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 0FCDB21F8A9F for ; Thu, 1 Mar 2012 12:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.955 X-Spam-Level: X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K74Hm57E8sDT for ; Thu, 1 Mar 2012 12:04:45 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F41321F8A93 for ; Thu, 1 Mar 2012 12:04:44 -0800 (PST) Received: by yenm5 with SMTP id m5so530869yen.31 for ; Thu, 01 Mar 2012 12:04:43 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.100.225.18 as permitted sender) client-ip=10.100.225.18; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.100.225.18 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.100.225.18]) by 10.100.225.18 with SMTP id x18mr2907280ang.48.1330632283497 (num_hops = 1); Thu, 01 Mar 2012 12:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=MfWv702BAlbHm9LccdBl1Jmm3pefvsRQpBPf/WqROpI=; b=ZGl57bni3ucjGx4ARuaIJFpeYzH+gAYK5OH7ghZvoQsPCJ3MHZ0AKWm/hJE/Xa8NgM e2vEIT/uX9Ny9yt/tlbrjv234/WzNyrmdgsp8uiAtyNEyAkuCQH3UynMJqxsXtHsPVNf mATmtqM+dTw6IZUr2G8lGx47H8KBjMJYNL0pYFh8PQuSP3X1ZCO1jcxoIt+5kfzOsOtp gB/xkV1VCepxk7VGM4G8q74czPXwjTN/usOv87pxy5XG+Jby4jnPj8g3AyYRDOZxD5jO DHxuigruhUuH2xU+lY39K0UOKgOtrqPic7pBJlECNKjH04qZLDMBxsIVr/cpBvplBVlY 8ZTg== Received: by 10.100.225.18 with SMTP id x18mr2295466ang.48.1330632283436; Thu, 01 Mar 2012 12:04:43 -0800 (PST) Received: by 10.100.225.18 with SMTP id x18mr2295457ang.48.1330632283281; Thu, 01 Mar 2012 12:04:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Thu, 1 Mar 2012 12:04:23 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> From: Takeshi Yoshino Date: Thu, 1 Mar 2012 15:04:23 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=001636b4325692593004ba33f884 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkm6o3Gg/vDZfMVjy2wX5Lmr77U3rsmqQBKGfMNgFJhOoImua3hVGDKCjkZwgKvF8wuWzHG4SN9scLIoWId/Tg4Pb7GmhXNrvbnFATfuRVSYQWJvdsdVID+sVU1tT3KdDi7jeU1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 01 Mar 2012 20:04:46 -0000 --001636b4325692593004ba33f884 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 28, 2012 at 18:10, Greg Wilkins wrote: > > > +1 to have it adopted as a base line for further discussion and refinement. > > I share Johns concern about the allocation of a reserved bit to the > extension and think that we should go through a process of exhaustively > considering all the alternatives before allocation of such a scarce > resource. > Yes. I also wonder if it's useful to make it able to negotiate whether to use compression bit or not on opening handshake. --001636b4325692593004ba33f884 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2012 at 18:10, Greg Wilkins <gregw@intalio.com> wrote:


+1 to have it adopted as a base line for further discussion and ref= inement.

I share Johns concern about the allocation of a reserved bi= t to the extension and think that we should go through a process of exhaust= ively considering all the alternatives before allocation of such a scarce r= esource.=A0=A0

Yes.

I also wonde= r if it's useful to make it able to negotiate whether to use compressio= n bit or not on opening handshake.

--001636b4325692593004ba33f884-- From jat@google.com Thu Mar 1 14:26:10 2012 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 CB7EE21E8391 for ; Thu, 1 Mar 2012 14:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YFVeKpeT6Jbs for ; Thu, 1 Mar 2012 14:26:10 -0800 (PST) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id E6B5D21E8390 for ; Thu, 1 Mar 2012 14:26:09 -0800 (PST) Received: by qcsg15 with SMTP id g15so681692qcs.27 for ; Thu, 01 Mar 2012 14:26:09 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.224.182.79 as permitted sender) client-ip=10.224.182.79; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.224.182.79 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.224.182.79]) by 10.224.182.79 with SMTP id cb15mr6130304qab.3.1330640769532 (num_hops = 1); Thu, 01 Mar 2012 14:26:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Yk+lcjWyL15HJPSFABoe0aCB+bFkS9ZMSi2N8tUAyWw=; b=jjtC6MXsi9Ehg1wAn0wj2v5wNhfFy36XuntnbGO9slMYa4oskVC+syxHSWA6zE5IX+ 0H0rwQ3YmD4zpGMkpiBvWMF9c2e3JB5ONOKKIgGaAkVCxkneGqklUUQuhZeGc9axDet3 T5F2SrrkOUWdkWeHjsorFbs+/WrLpNq5ng6Zdgww9ey5jjplYIwnvAnXT1KapFn7QON/ XLDT0tv+ILsFvf+njuxIoNsj1Zg8QuWT1oSJQP2bKNwughuJK5izaB5SPazm0kT669jN uFntt7CTfdVS8r1esCAf8AtfumdXjfWsTU+87fhuMsEvqLbQMzaO28jYmIKEHZ46HTo+ 1ntg== Received: by 10.224.182.79 with SMTP id cb15mr5148889qab.3.1330640769444; Thu, 01 Mar 2012 14:26:09 -0800 (PST) Received: by 10.224.182.79 with SMTP id cb15mr5148881qab.3.1330640769308; Thu, 01 Mar 2012 14:26:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.103.149 with HTTP; Thu, 1 Mar 2012 14:25:49 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> From: John Tamplin Date: Thu, 1 Mar 2012 17:25:49 -0500 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf303b429160d72704ba35f254 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmy8qcGUF9B9uofBtZCv+JCtH4uPyiZCib+W4kLjnstHFzYhFGOku8aIP/8yJqx4CeE2UFvwTDw1aSSkcmvoZSGGeNdj4Va8s2cLtdYGYOu+pAV0HhG2k4qhZFDSos9DCtMHWeT Cc: "hybi@ietf.org" , SM , Gabriel Montenegro Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 01 Mar 2012 22:26:10 -0000 --20cf303b429160d72704ba35f254 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 1, 2012 at 2:59 PM, Takeshi Yoshino wrote: > On Tue, Feb 28, 2012 at 09:05, John Tamplin wrote: >> >> I think it needs some significant changes (in particular, if it is going >> to allocate a reserved frame bit it needs to be extensible to other >> compression algorithms, which also implies renaming it to compress-frame or >> similar), but I think it is a fine starting point. >> > > Do you think drastic abstraction is better? I.e. should we put texts > describing generic per-frame compression spec and texts describing how to > use it with DEFLATE into separate sections, or even into separate specs? > I think it is fine to have it in the same spec. It can describe the general use of per-frame compression, and then supply the specific case of using deflate as the algorithm. I don't think any more is required than reordering pieces of the doc and some name changes, as well as adding some way of selecting the compression algorithm (and supplying parameters to it if necessary). > If it's sufficient to make it clear that the bit allocated in this spec is > also available for any other per-frame compression method, I'd replace > "COMP" bit in the spec with, say, "Per-frame compressed" bit, and change > the registration section to: > > 7.2. Registration of the "Per-frame compressed" WebSocket Framing Header > Bit > > This section describes a WebSocket framing header bit registration in > the WebSocket Framing Header Bits Registry. [RFC6455] > > Header Bit > RSV1 > > Common Name > Per-frame compressed > > Meaning > Per-frame compression is applied to the frame or not. > > Reference > Section 4 of this document. > > The "Per-frame compressed" framing header bit is used to indicate > whether > any negotiated per-frame compression extension is applied to the frame > or not. > > When this bit is used by this per-frame DEFLATE extension, it means > whether > "Application data" part of the frame contains octets generated using > DEFLATE or not. > > Any other compression extension MAY define > its own use of this bit. Note that this per-frame DEFLATE > extension and that extension will be incompatible in such case. > I would prefer a bit more generic definition of the bit, and rather than saying that this is the per-frame deflate extension it is a general-purpose per-frame compression extension, and deflate is merely a required option among potentially many different compression algorithms. -- John A. Tamplin Software Engineer (GWT), Google --20cf303b429160d72704ba35f254 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 1, 2012 at 2:59 PM, Takeshi Yoshino = <tyoshino@googl= e.com> wrote:
On Tue, Feb 28, 2012 at 09:05,= John Tamplin <jat@google.com> wrote:
I think it needs some significant changes (= in particular, if it is going to allocate a reserved frame bit it needs to = be extensible to other compression algorithms, which also implies renaming = it to compress-frame or similar), but I think it is a fine starting point.= =C2=A0

Do you think drastic abstracti= on is better? I.e. should we put texts describing generic per-frame compres= sion spec and texts describing how to use it with DEFLATE into separate sec= tions, or even into separate specs?

I think it is fine to have it in the= same spec. =C2=A0It can describe the general use of per-frame compression,= and then supply the specific case of using deflate as the algorithm. =C2= =A0I don't think any more is required than reordering pieces of the doc= and some name changes, as well as adding some way of selecting the compres= sion algorithm (and supplying parameters to it if necessary).
=C2=A0
=
If it's sufficient to make it clear that the bit alloca= ted in this spec is also available for any other per-frame compression meth= od, I'd replace "COMP" bit in the spec with, say, "Per-f= rame compressed" bit, and change the registration section to:

7.2. =C2=A0Registration of the "Per-frame com= pressed" WebSocket Framing Header Bit

=C2=A0 = =C2=A0This section describes a WebSocket framing header bit registration in=
=C2=A0 =C2=A0the WebSocket Framing Header Bits Registry. =C2=A0[RFC6455]

=C2=A0 =C2=A0Header Bit
=C2=A0 =C2=A0 =C2= =A0 RSV1

=C2=A0 =C2=A0Common Name
=C2=A0= =C2=A0 =C2=A0 Per-frame compressed

=C2=A0 =C2=A0Meaning
=C2=A0 =C2=A0 =C2=A0 Per-frame compression is applied to the frame or = not.

=C2=A0 =C2=A0Reference
=C2=A0 =C2= =A0 =C2=A0 Section 4 of this document.

=C2=A0 =C2= =A0The "Per-frame compressed" framing header bit is used to indic= ate whether
=C2=A0 =C2=A0any negotiated per-frame compression extension is applied= to the frame or not.

=C2=A0 =C2=A0When this bit= =C2=A0is used by this per-frame DEFLATE extension, it means whether
=C2=A0 =C2=A0"Application data" part of the frame contains oct= ets generated using
=C2=A0 =C2=A0DEFLATE or not.

=C2=A0 =C2=A0Any= other compression extension MAY define
=C2=A0 =C2=A0its own use = of this bit. =C2=A0Note that this=C2=A0per-frame DEFLATE
=C2=A0 = =C2=A0extension and that extension will be incompatible=C2=A0in such case.<= /div>

I would prefer a bit more generic definition of the = bit, and rather than saying that this is the per-frame deflate extension it= is a general-purpose per-frame compression extension, and deflate is merel= y a required option among potentially many different compression algorithms= .

--
John A. Tamplin
Software Engineer (GWT), Google --20cf303b429160d72704ba35f254-- From jat@google.com Thu Mar 1 14:26:54 2012 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 7362021E836D for ; Thu, 1 Mar 2012 14:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohMw-O5qyWhz for ; Thu, 1 Mar 2012 14:26:54 -0800 (PST) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id D675C21E809C for ; Thu, 1 Mar 2012 14:26:53 -0800 (PST) Received: by qcsg15 with SMTP id g15so682003qcs.27 for ; Thu, 01 Mar 2012 14:26:53 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.224.181.66 as permitted sender) client-ip=10.224.181.66; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.224.181.66 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.224.181.66]) by 10.224.181.66 with SMTP id bx2mr5903361qab.68.1330640813495 (num_hops = 1); Thu, 01 Mar 2012 14:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/+LNjV+r5WnHL2zBo1nxOCd7GyxXDA66DWjBqh3WXIw=; b=XfNN8yMyMtuj6uTy1hIxTeDXo96BPljBTZtIv69cqzq4M2539GFGBwOr4CGoRJD3DC Lz+4upclVUsnRonaVCevn2lyPlzCv5C0bnYmjxopiMGNz7uKpAaUQ+GFlVkPNuuKY6ly VjxcMhyIFlfl8++6AMdmvX+6+ZvzkTmwy8bdaIYlq+H0rmr40oLPN0Lp+46mYiG3NfKN 8BZjPqnvrGRBXlX1CGNYkMORNPRudxikw9x7GQnaqDFScMJraAa2HTjxDZBupUFSIfvj QaHK6/05kHZzfBKf04VbZZfhgmBqyDFdzebx2xRZw7cKlu3ey2XXiVHIN8aX/Nt0s8iI 8iTw== Received: by 10.224.181.66 with SMTP id bx2mr4931543qab.68.1330640813441; Thu, 01 Mar 2012 14:26:53 -0800 (PST) Received: by 10.224.181.66 with SMTP id bx2mr4931538qab.68.1330640813335; Thu, 01 Mar 2012 14:26:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.103.149 with HTTP; Thu, 1 Mar 2012 14:26:33 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> From: John Tamplin Date: Thu, 1 Mar 2012 17:26:33 -0500 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf30334f9100a5ce04ba35f5d3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmPU581vSIpMuglEUCk3LxOuR+bLDr+FN4kOrQGm66Jf38aLcopDwXZWPzjCzs00bPlz5UfV7801MiOjSWtQ9koiZEQv8e8Mw0FtVBAhD0e4Xgan7V81tsjrDdwmfKTeptGSHPW Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 01 Mar 2012 22:26:54 -0000 --20cf30334f9100a5ce04ba35f5d3 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yoshino wrote: > I also wonder if it's useful to make it able to negotiate whether to use > compression bit or not on opening handshake. > Personally, I think that complicates things too much. When we reserved the bit, one of the things we were reserving it for was per-frame compression. -- John A. Tamplin Software Engineer (GWT), Google --20cf30334f9100a5ce04ba35f5d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yoshino = <tyoshino@googl= e.com> wrote:
I also wonder if it's usef= ul to make it able to negotiate whether to use compression bit or not on op= ening handshake.

Personally, I= think that complicates things too much. =C2=A0When we reserved the bit, on= e of the things we were reserving it for was per-frame compression.

--
John A. Tamplin
Software Engineer (GWT), Google --20cf30334f9100a5ce04ba35f5d3-- From gregw@intalio.com Thu Mar 1 16:11:24 2012 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 ABD0521E8011 for ; Thu, 1 Mar 2012 16:11:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCzfSvb-AIhe for ; Thu, 1 Mar 2012 16:11:24 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id D08E621E800E for ; Thu, 1 Mar 2012 16:11:23 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1622774obb.31 for ; Thu, 01 Mar 2012 16:11:23 -0800 (PST) Received-SPF: pass (google.com: domain of gregw@intalio.com designates 10.60.3.9 as permitted sender) client-ip=10.60.3.9; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gregw@intalio.com designates 10.60.3.9 as permitted sender) smtp.mail=gregw@intalio.com Received: from mr.google.com ([10.60.3.9]) by 10.60.3.9 with SMTP id 9mr2606570oey.49.1330647083550 (num_hops = 1); Thu, 01 Mar 2012 16:11:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.3.9 with SMTP id 9mr2272374oey.49.1330647083494; Thu, 01 Mar 2012 16:11:23 -0800 (PST) Received: by 10.60.55.166 with HTTP; Thu, 1 Mar 2012 16:11:23 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> Date: Fri, 2 Mar 2012 11:11:23 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=e89a8f83ae2bbbaeb404ba376a93 X-Gm-Message-State: ALoCoQms3nqnDmTmu2aMJfbOUh2BHzM6OuN8RziZAmaIG3pMGAK4gCFDGX0aZ9KAOr+DkPMnYJ7l Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 02 Mar 2012 00:11:24 -0000 --e89a8f83ae2bbbaeb404ba376a93 Content-Type: text/plain; charset=ISO-8859-1 On 2 March 2012 09:26, John Tamplin wrote: > On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yoshino wrote: > >> I also wonder if it's useful to make it able to negotiate whether to use >> compression bit or not on opening handshake. >> > > Personally, I think that complicates things too much. When we reserved > the bit, one of the things we were reserving it for was per-frame > compression. I agree - we should either use a reserve bit or not - optional use is probably the worst of both worlds. The options I see we have are: a) Just use the bit in this extension. Any other extension that uses the same bit will be incompatible and we leave it undefined how we work that out. b) Nominate the bit as some kind of general purpose per frame compression bit, available to multiple compression extensions. c) Come up with a system of dynamically allocated reserved bits. The extension requests to use a bit and the server allocates one and indicates which in the handshake response. This would allow multiple reserve bit using extensions to co-exist... up until our limit of reserved bits. d) Don't use a reserved bit. Use the first byte of the payload to indicate if the frame is compressed or not. e) Don't use a reserved bit. Compress all frames. I see c) as probably too complex and too limited to be worth the effort. So failing dynamic reserve bit allocation, I think if we don't allocate a reserved bit for frame compression, then we will never allocate them for anything. If we don't allocate a reserved bit, I think there is enough previous discussions to show that e) compress everything is not optimal. d) is not too bad, specially if meanings could be assigned to other bits in that byte (eg a reset dictionary bit, a use dictionary but don't update it bit etc.) So I think b) or d) are viable options cheers --e89a8f83ae2bbbaeb404ba376a93 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 2 March 2012 09:26, John Tamplin <jat@google.com><= /span> wrote:
On Thu, Mar 1, 2012 at 3:04 PM= , Takeshi Yoshino <tyoshino@google.com> wrote:
I also wonder if it's useful to make it= able to negotiate whether to use compression bit or not on opening handsha= ke.

Personally, I think = that complicates things too much. =A0When we reserved the bit, one of the t= hings we were reserving it for was per-frame compression.

I agree - we should either use a reserve bit or not - optional use= is probably the worst of both worlds.


The options I see we have= are:

a) Just use the bit in this extension.=A0 Any other extension = that uses the same bit will be incompatible and we leave it undefined how w= e work that out.
b) Nominate the bit as some kind of general purpose per frame compression b= it, available to multiple compression extensions.
c) Come up with a syst= em of dynamically allocated reserved bits. The extension requests to use a = bit and the server allocates one and indicates which in the handshake respo= nse.=A0 This would allow multiple reserve bit using extensions to co-exist.= .. up until our limit of reserved bits.
d) Don't use a reserved bit.=A0 Use the first byte of the payload to in= dicate if the frame is compressed or not.
e) Don't use a reserved bi= t. Compress all frames.

I see c) as probably too complex and too lim= ited to be worth the effort.
So failing dynamic reserve bit allocation, I think if we don't allocate= a reserved bit for frame compression, then we will never allocate them for= anything.
If we don't allocate a reserved bit, I think there is en= ough previous discussions to show that e) compress everything is not optima= l.=A0=A0 d) is not too bad, specially if meanings could be assigned to othe= r bits in that byte (eg a reset dictionary bit, a use dictionary but don= 9;t update it bit etc.)

So I think b) or d) are viable options

cheers



--e89a8f83ae2bbbaeb404ba376a93-- From theturtle32@gmail.com Thu Mar 1 16:58:50 2012 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 6C30B21F8ABD for ; Thu, 1 Mar 2012 16:58:50 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x76uQIPmxF94 for ; Thu, 1 Mar 2012 16:58:49 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6C52721F8ABB for ; Thu, 1 Mar 2012 16:58:49 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1668321obb.31 for ; Thu, 01 Mar 2012 16:58:49 -0800 (PST) Received-SPF: pass (google.com: domain of theturtle32@gmail.com designates 10.60.4.71 as permitted sender) client-ip=10.60.4.71; Authentication-Results: mr.google.com; spf=pass (google.com: domain of theturtle32@gmail.com designates 10.60.4.71 as permitted sender) smtp.mail=theturtle32@gmail.com; dkim=pass header.i=theturtle32@gmail.com Received: from mr.google.com ([10.60.4.71]) by 10.60.4.71 with SMTP id i7mr2768159oei.39.1330649929135 (num_hops = 1); Thu, 01 Mar 2012 16:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xoU2H1Fw4gqLuG9oWjFvzKbLvOZsoVRaZvntBBnGM2U=; b=v8A5wQPZ3fA5xSEgPY54uPeXb1LpV3N/VeQCt56occBvWHg+QDy3B9i+c9Oo7DNrSi iu9mBd9mmA6MxOHaJuaGO/p6Lsr3UjK/Lp5/QsSFF6wOAZngspiynbEO9v+YGOzRHMd7 uVPF+t2/EVvnWg8KEx3igfqbhE+/+xmdzCJ3kT+fhn9lhSnKImHmdVm04pOGxS/4KBLo 6/9P0RbGQ/7/f1jcHAneM4nE7/0hNVOwbQ3mYafRhGgiTCCuJw+f6yIRT0HISrL8u9es jBlxfgGOiBOJRKJoqI4PBVSsOaf2wXQiI3olRad4dCcyQkF3DtjatoRgcDL8Nv5kBmUC 8Dlw== MIME-Version: 1.0 Received: by 10.60.4.71 with SMTP id i7mr2405603oei.39.1330649929011; Thu, 01 Mar 2012 16:58:49 -0800 (PST) Received: by 10.182.89.74 with HTTP; Thu, 1 Mar 2012 16:58:48 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> Date: Thu, 1 Mar 2012 16:58:48 -0800 Message-ID: From: Brian To: Greg Wilkins Content-Type: multipart/alternative; boundary=e89a8fb1ee1256d31704ba381451 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 02 Mar 2012 00:58:50 -0000 --e89a8fb1ee1256d31704ba381451 Content-Type: text/plain; charset=ISO-8859-1 I like option "d." One framing byte of overhead is practically nothing and enables lots of opportunities for tuning and control. If the byte of overhead is too much for some people, perhaps there could be a configuration parameter during the handshake to allow the user to opt into across-the-board compression settings that would eliminate the byte and just apply to every frame. That would allow users with consistently compressible data to eliminate the one byte overhead. Alternatively, we could define a control frame to configure the compression extension that could turn the per-frame control byte on or off. Brian On Thu, Mar 1, 2012 at 4:11 PM, Greg Wilkins wrote: > > > On 2 March 2012 09:26, John Tamplin wrote: > >> On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yoshino wrote: >> >>> I also wonder if it's useful to make it able to negotiate whether to use >>> compression bit or not on opening handshake. >>> >> >> Personally, I think that complicates things too much. When we reserved >> the bit, one of the things we were reserving it for was per-frame >> compression. > > > I agree - we should either use a reserve bit or not - optional use is > probably the worst of both worlds. > > > The options I see we have are: > > a) Just use the bit in this extension. Any other extension that uses the > same bit will be incompatible and we leave it undefined how we work that > out. > b) Nominate the bit as some kind of general purpose per frame compression > bit, available to multiple compression extensions. > c) Come up with a system of dynamically allocated reserved bits. The > extension requests to use a bit and the server allocates one and indicates > which in the handshake response. This would allow multiple reserve bit > using extensions to co-exist... up until our limit of reserved bits. > d) Don't use a reserved bit. Use the first byte of the payload to > indicate if the frame is compressed or not. > e) Don't use a reserved bit. Compress all frames. > > I see c) as probably too complex and too limited to be worth the effort. > So failing dynamic reserve bit allocation, I think if we don't allocate a > reserved bit for frame compression, then we will never allocate them for > anything. > If we don't allocate a reserved bit, I think there is enough previous > discussions to show that e) compress everything is not optimal. d) is not > too bad, specially if meanings could be assigned to other bits in that byte > (eg a reset dictionary bit, a use dictionary but don't update it bit etc.) > > So I think b) or d) are viable options > > cheers > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --e89a8fb1ee1256d31704ba381451 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I like option "d." =A0One framing byte of overhead is practically= nothing and enables lots of opportunities for tuning and control. =A0If th= e byte of overhead is too much for some people, perhaps there could be a co= nfiguration parameter during the handshake to allow the user to opt into ac= ross-the-board compression settings that would eliminate the byte and just = apply to every frame. =A0That would allow users with consistently=A0compres= sible=A0data to eliminate the one byte overhead.

Alternatively, we could define a control frame to configure = the compression extension that could turn the per-frame control byte on or = off.

Brian

On Th= u, Mar 1, 2012 at 4:11 PM, Greg Wilkins <gregw@intalio.com> wrote:


On 2 March 2012 09:26, John Tamplin <jat@google.com> = wrote:
On Thu, Mar 1, 2012 at 3:04 PM, Takeshi Yos= hino <tyoshino@google.com> wrote:
I also wonder if it's useful to make it= able to negotiate whether to use compression bit or not on opening handsha= ke.

Personally, I think = that complicates things too much. =A0When we reserved the bit, one of the t= hings we were reserving it for was per-frame compression.

I agree - we should either use a reserve bit or not - option= al use is probably the worst of both worlds.


The options I see w= e have are:

a) Just use the bit in this extension.=A0 Any other exte= nsion that uses the same bit will be incompatible and we leave it undefined= how we work that out.
b) Nominate the bit as some kind of general purpose per frame compression b= it, available to multiple compression extensions.
c) Come up with a syst= em of dynamically allocated reserved bits. The extension requests to use a = bit and the server allocates one and indicates which in the handshake respo= nse.=A0 This would allow multiple reserve bit using extensions to co-exist.= .. up until our limit of reserved bits.
d) Don't use a reserved bit.=A0 Use the first byte of the payload to in= dicate if the frame is compressed or not.
e) Don't use a reserved bi= t. Compress all frames.

I see c) as probably too complex and too lim= ited to be worth the effort.
So failing dynamic reserve bit allocation, I think if we don't allocate= a reserved bit for frame compression, then we will never allocate them for= anything.
If we don't allocate a reserved bit, I think there is en= ough previous discussions to show that e) compress everything is not optima= l.=A0=A0 d) is not too bad, specially if meanings could be assigned to othe= r bits in that byte (eg a reset dictionary bit, a use dictionary but don= 9;t update it bit etc.)

So I think b) or d) are viable options

cheers




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


--e89a8fb1ee1256d31704ba381451-- From jat@google.com Thu Mar 1 17:11:00 2012 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 0FBB521E8187 for ; Thu, 1 Mar 2012 17:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKv-pGzm1qyN for ; Thu, 1 Mar 2012 17:10:59 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id E969F21E8062 for ; Thu, 1 Mar 2012 17:10:58 -0800 (PST) Received: by qadc14 with SMTP id c14so23398qad.10 for ; Thu, 01 Mar 2012 17:10:58 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.224.218.10 as permitted sender) client-ip=10.224.218.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.224.218.10 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.224.218.10]) by 10.224.218.10 with SMTP id ho10mr6176681qab.16.1330650658534 (num_hops = 1); Thu, 01 Mar 2012 17:10:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=uPkTSr48RJSTgz4inPO2DPKZFNrukwWUiugVZV8mirE=; b=Im6ugk8BhlPmXn+9K67HEdPm2Q2EZciIPhuP4eRnhK2W7g2Irrl2QUL/5QDTlm4g+A nFKwfNyNmACkL9ZAiSnZywd2aNq7iv8Qt3oorATtNoFq2lOj4ll/kJcoyL6dV/soYDRT tCeu8mD0ok7qxnFDhsLtxnDFm8bB1Y6X+8HJ3LvvL2IMFmZ8GPoRhcTpkreYcQKC2gfm aBQFAZZIp9OUyGa3RrQn1ScfJ0yfIr7gD3qrsSqI4rmgpEuIGGfrnkdpEfLxrZHddt2E XESZSdm3QJknJl0Bmlf6oMZ2jljI3yNTqyl731nHLr3UHQESzXgvKUqqCmzv7oRkeEX9 NzuA== Received: by 10.224.218.10 with SMTP id ho10mr5186463qab.16.1330650658431; Thu, 01 Mar 2012 17:10:58 -0800 (PST) Received: by 10.224.218.10 with SMTP id ho10mr5186454qab.16.1330650658268; Thu, 01 Mar 2012 17:10:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.103.149 with HTTP; Thu, 1 Mar 2012 17:10:38 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> From: John Tamplin Date: Thu, 1 Mar 2012 20:10:38 -0500 Message-ID: To: Brian Content-Type: multipart/alternative; boundary=20cf300fad4fce668904ba383f93 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlm1t5UV3nds3UXqJuXfrKM6belmhpeWeuPvvr8Qn6SP24qKqskaWwA9l+DvbAzLe0OE9YVewgK8kJ75LzF3Tir7jrtAwzYDwaIrVSBS5WQGW7ZYT5/krZi/ZT3iLpEQ5cYS1P5 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 02 Mar 2012 01:11:00 -0000 --20cf300fad4fce668904ba383f93 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 1, 2012 at 7:58 PM, Brian wrote: > I like option "d." One framing byte of overhead is practically nothing > and enables lots of opportunities for tuning and control. If the byte of > overhead is too much for some people, perhaps there could be a > configuration parameter during the handshake to allow the user to opt into > across-the-board compression settings that would eliminate the byte and > just apply to every frame. That would allow users with > consistently compressible data to eliminate the one byte overhead. > > Alternatively, we could define a control frame to configure the > compression extension that could turn the per-frame control byte on or off. > The options of knowing what to compress are: 1) compress everything on a connection, configured at handshake time. We know compressing incompressible data is a loss, so we would need to expose a way in the JS API to indicate whether to use compression or not. Applications that mix compressible and incompressible data would use multiple connections (made less costly via multiplexing). 2) compress only compressible data in a frame, leaving incompressible data in uncompressed frames. The choice of how to determine compressibility: 2a) the API says whether it is compressible 2b) the API gives a type of data being supplied, and an implementation chooses whether to compress it based on the type 2c) heuristic choices, such as "compress all text frames, leave binary frames uncompressed" (though earlier experiments with GwtQuake over WebSockets showed that even its binary data substantially benefited from compression) 2d) try and compress the data, and send it compressed only if it reduces the size Another question is about sharing compression state -- if we compress each frame individually, we lose the benefit of redundancy with other frames. For example, the WS binary frames in GwtQuake saw little improvement at all if each frame was compressed individually, but there was a lot of redundancy across frames. To take advantage of this, we need a compression scheme that maintains a compression dictionary for the stream (which might complicated 2d above depending on the compression library available). As Greg said, if we aren't going to use a reserved bit for per-frame compression, where we hope to reduce the payload to a small number of bytes already so an extra byte to indicate compression may be expensive, what exactly will we use it for? My opinion is we should allocate a reserved bit for per-frame compression, create an extension to indicate that is to be used for compression and a way to select the compression algorithm, and define deflate with no state shared across frames as a required compression algorithm to be supported if no other algorithm is negotiated. We can then define more effective compression algorithms that provide ways of sharing compression state across frames, for example, though we still have to work out the above questions though. -- John A. Tamplin Software Engineer (GWT), Google --20cf300fad4fce668904ba383f93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 1, 2012 at 7:58 PM, Brian <theturtle32@gmail.com= > wrote:
I like option "d." =C2=A0One framing byte of overhead is practica= lly nothing and enables lots of opportunities for tuning and control. =C2= =A0If the byte of overhead is too much for some people, perhaps there could= be a configuration parameter during the handshake to allow the user to opt= into across-the-board compression settings that would eliminate the byte a= nd just apply to every frame. =C2=A0That would allow users with consistentl= y=C2=A0compressible=C2=A0data to eliminate the one byte overhead.

Alternatively, we could define a control frame to configure = the compression extension that could turn the per-frame control byte on or = off.

The options of knowing what to c= ompress are:
1) compress everything on a connection, configured at handshake time. = =C2=A0We know compressing incompressible data is
a loss, so we wo= uld need to expose a way in the JS API to indicate whether to use compressi= on or not. =C2=A0Applications that mix compressible and incompressible data= would use multiple connections (made less costly via multiplexing).

2) compress only compressible data in a frame, leaving = incompressible data in uncompressed frames. =C2=A0The choice of how to dete= rmine compressibility:
=C2=A0 2a) the API says whether it is comp= ressible
=C2=A0 2b) the API gives a type of data being supplied, and an impleme= ntation chooses whether to compress it based on the type
=C2=A0 2= c) heuristic choices, such as "compress all text frames, leave binary = frames uncompressed" (though earlier experiments with GwtQuake over We= bSockets showed that even its binary data substantially benefited from comp= ression)
=C2=A0 2d) try and compress the data, and send it compressed only if i= t reduces the size

Another question is about shari= ng compression state -- if we compress each frame individually, we lose the= benefit of redundancy with other frames. =C2=A0For example, the WS binary = frames in GwtQuake saw little improvement at all if each frame was compress= ed individually, but there was a lot of redundancy across frames. =C2=A0To = take advantage of this, we need a compression scheme that maintains a compr= ession dictionary for the stream (which might complicated 2d above dependin= g on the compression library available).

As Greg said, if we aren't going to use a reserved = bit for per-frame compression, where we hope to reduce the payload to a sma= ll number of bytes already so an extra byte to indicate compression may be = expensive, what exactly will we use it for?

My opinion is we should allocate a reserved bit for per= -frame compression, create an extension to indicate that is to be used for = compression and a way to select the compression algorithm, and define defla= te with no state shared across frames as a required compression algorithm t= o be supported if no other algorithm is negotiated. =C2=A0We can then defin= e more effective compression algorithms that provide ways of sharing compre= ssion state across frames, for example, though we still have to work out th= e above questions though.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--20cf300fad4fce668904ba383f93-- From theturtle32@gmail.com Thu Mar 1 17:19:49 2012 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 3F23021E8108 for ; Thu, 1 Mar 2012 17:19:49 -0800 (PST) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJq4qvBp+inn for ; Thu, 1 Mar 2012 17:19:48 -0800 (PST) Received: from mail-tul01m020-f172.google.com (mail-tul01m020-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6694D21E805E for ; Thu, 1 Mar 2012 17:19:44 -0800 (PST) Received: by obbeh20 with SMTP id eh20so1689981obb.31 for ; Thu, 01 Mar 2012 17:19:44 -0800 (PST) Received-SPF: pass (google.com: domain of theturtle32@gmail.com designates 10.182.1.104 as permitted sender) client-ip=10.182.1.104; Authentication-Results: mr.google.com; spf=pass (google.com: domain of theturtle32@gmail.com designates 10.182.1.104 as permitted sender) smtp.mail=theturtle32@gmail.com; dkim=pass header.i=theturtle32@gmail.com Received: from mr.google.com ([10.182.1.104]) by 10.182.1.104 with SMTP id 8mr3016948obl.19.1330651184132 (num_hops = 1); Thu, 01 Mar 2012 17:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NE0WXjUP0X6PoggUcZiskzF8bPKsXBg8Zw2HjIFSriE=; b=LXJRSpgDAKPO1ASkQ2DYawdTwmMEOL4Mh0jvmjXOKN1Vn/p8K3cs6FHTeAO7jrqORI vj5TD6YsC7LtJtVvE6lkGQLz9zPJ9xJUim6QbqHcJBZJgsmc2DwkahopV5XK94hyQDTe +J4QzSz4fkdtuOFHkRvzsPYj1dS/OnmJetDTlmClq9C6qudb0IlpPC7nriTUeFgfPdQB hApWQHuoHmNi28gYvTh+QLgm1CX9aK4EWp8zJhqmqOTsUZ7FRhzasVWwaBdTPzuxYTqt T5ZS9Ij4Kws8EfHcKlbMCtnyqZtJjdepRlpbyWuEZhxDFqpHks4cbFaYX3g3fycXLAC9 CQkg== MIME-Version: 1.0 Received: by 10.182.1.104 with SMTP id 8mr2612569obl.19.1330651184048; Thu, 01 Mar 2012 17:19:44 -0800 (PST) Received: by 10.182.89.74 with HTTP; Thu, 1 Mar 2012 17:19:43 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> Date: Thu, 1 Mar 2012 17:19:43 -0800 Message-ID: From: Brian To: John Tamplin Content-Type: multipart/alternative; boundary=f46d0446316625293404ba385f15 Cc: "hybi@ietf.org" Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 02 Mar 2012 01:19:49 -0000 --f46d0446316625293404ba385f15 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 1, 2012 at 5:10 PM, John Tamplin wrote: > As Greg said, if we aren't going to use a reserved bit for per-frame > compression, where we hope to reduce the payload to a small number of bytes > already so an extra byte to indicate compression may be expensive, what > exactly will we use it for? > > My opinion is we should allocate a reserved bit for per-frame compression, > create an extension to indicate that is to be used for compression and a > way to select the compression algorithm, and define deflate with no state > shared across frames as a required compression algorithm to be supported if > no other algorithm is negotiated. We can then define more effective > compression algorithms that provide ways of sharing compression state > across frames, for example, though we still have to work out the above > questions though. > That's true enough. If ever there were a perfect use for the reserved bits it would be this. It's just such a rare resource and it's still early days for WebSockets in general that the gut reaction is to keep them reserved at all costs until some mythical extension suddenly jumps out as worthy enough to have one of the sacred bits ceremonially bestowed upon it from on high. I'm good with a reserved bit being allocated for per frame compression. Brian --f46d0446316625293404ba385f15 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Mar 1, 2012 at 5:10 PM, John Tamplin <jat@google.com>= wrote:
As Greg said, if we aren't= going to use a reserved bit for per-frame compression, where we hope to re= duce the payload to a small number of bytes already so an extra byte to ind= icate compression may be expensive, what exactly will we use it for?

My opinion is we should allocate a reserved bit for per= -frame compression, create an extension to indicate that is to be used for = compression and a way to select the compression algorithm, and define defla= te with no state shared across frames as a required compression algorithm t= o be supported if no other algorithm is negotiated. =A0We can then define m= ore effective compression algorithms that provide ways of sharing compressi= on state across frames, for example, though we still have to work out the a= bove questions though.

That's true enough. =A0If ever t= here were a perfect use for the reserved bits it would be this. =A0It's= just such a rare resource and it's still early days for WebSockets in = general that the gut reaction is to keep them reserved at all costs until s= ome mythical extension suddenly jumps out as worthy enough to have one of t= he sacred bits ceremonially bestowed upon it from on high.

I'm good with a reserved bit being allocated for pe= r frame compression.

Brian

--f46d0446316625293404ba385f15-- From alexey.melnikov@isode.com Fri Mar 2 09:25:35 2012 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 C47A621F865A for ; Fri, 2 Mar 2012 09:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.247 X-Spam-Level: X-Spam-Status: No, score=-102.247 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0UdzyEEr2Ip for ; Fri, 2 Mar 2012 09:25:30 -0800 (PST) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1530B21F853B for ; Fri, 2 Mar 2012 09:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1330709121; d=isode.com; s=selector; i=@isode.com; bh=lP7d7q7AEZ1NuKxlYzRwxQSqaUEewpVftE6ecGSk8Sk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZOfTnVvn3Yd9Aw9e4HntOkZ8FcYsSRPyk7/dQC+2slYxVY2IP7TKD1uX/Ke9/TekkYxXMH co0JwijZSdZjyUzeZ7BLrXkQQfNEsz+8swC1FWuBamwUwOW+KTKaklAtBiwyMOA7OtI2Ui aAt6OKirfgocw/Lq2VAxP+AT2VCLucY=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 2 Mar 2012 17:25:21 +0000 Message-ID: <4F510299.2030409@isode.com> Date: Fri, 02 Mar 2012 17:25:45 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 To: John Tamplin , Salvatore Loreto References: <4F4C8568.7070403@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------050305020403040904060403" Cc: "hybi@ietf.org" , SM , Gabriel Montenegro Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 02 Mar 2012 17:25:52 -0000 This is a multi-part message in MIME format. --------------050305020403040904060403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 28/02/2012 14:05, John Tamplin wrote: > On Tue, Feb 28, 2012 at 2:42 AM, Salvatore Loreto > > > wrote: > > the first optimization/extension (or milestone if you prefer) > in the new approved HyBi charter (see > http://tools.ietf.org/wg/hybi/charters ) > is about: > > A per-frame compression extension to improve bandwidth > usage > > > Takeshi Yoshino has been working on a draft proposal since April 2011. > The draft has been discussed extensively in the mailing list, > it has already received comments, suggestions and feedback; > and Takeshi has produced several new versions to address the > raised issues. > > The current version is: > http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05 > > > Gabriel and I, as chairs, want to check the consensus to adopt the > draft as > baseline for the working group item that will fulfill the first > Goal in the current charter: > > Feb 2012 - Adopt a WG item for the per-frame compression extension > > I think it needs some significant changes (in particular, if it is > going to allocate a reserved frame bit it needs to be extensible to > other compression algorithms, which also implies renaming it to > compress-frame or similar), but I think it is a fine starting point. +1. --------------050305020403040904060403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 28/02/2012 14:05, John Tamplin wrote:
On Tue, Feb 28, 2012 at 2:42 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
the first optimization/extension (or milestone if you prefer)
in the new approved HyBi charter (see http://tools.ietf.org/wg/hybi/charters )
is about:
A per-frame compression extension to improve bandwidth
usage

Takeshi Yoshino has been working on a draft proposal since April 2011.
The draft has been discussed extensively in the mailing list,
it  has already received comments, suggestions and feedback;
and  Takeshi has produced several new versions to address the raised issues.

The current version is:
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05


Gabriel and I, as chairs, want to check the consensus to adopt the draft as
baseline for the working group item that will fulfill the first Goal in the current charter:
  Feb 2012 - Adopt a WG item for the per-frame compression extension
I think it needs some significant changes (in particular, if it is going to allocate a reserved frame bit it needs to be extensible to other compression algorithms, which also implies renaming it to compress-frame or similar), but I think it is a fine starting point.
+1.


--------------050305020403040904060403-- From bruce@callenish.com Fri Mar 2 10:34:50 2012 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 ECB8F21F856C for ; Fri, 2 Mar 2012 10:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuqeHxQer3UW for ; Fri, 2 Mar 2012 10:34:50 -0800 (PST) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 1872D21F855F for ; Fri, 2 Mar 2012 10:34:50 -0800 (PST) Received: from [24.108.137.46] (port=54834 helo=[192.168.145.106]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1S3XJX-0006Cf-4G; Fri, 02 Mar 2012 10:34:47 -0800 Message-ID: <4F5112C3.60907@callenish.com> Date: Fri, 02 Mar 2012 10:34:43 -0800 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Salvatore Loreto References: <4F4C8568.7070403@ericsson.com> In-Reply-To: <4F4C8568.7070403@ericsson.com> Content-Type: multipart/alternative; boundary="------------010208030805080605090806" 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 X-Source: X-Source-Args: X-Source-Dir: Cc: "hybi@ietf.org" , SM , Gabriel Montenegro Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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, 02 Mar 2012 18:34:51 -0000 This is a multi-part message in MIME format. --------------010208030805080605090806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit +1 On 2/27/2012 11:42 PM, Salvatore Loreto wrote: > > The current version is: > http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05 > > > Gabriel and I, as chairs, want to check the consensus to adopt the > draft as > baseline for the working group item that will fulfill the first Goal > in the current charter: > Feb 2012 - Adopt a WG item for the per-frame compression extension > > --------------010208030805080605090806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit +1

On 2/27/2012 11:42 PM, Salvatore Loreto wrote:

The current version is:
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05


Gabriel and I, as chairs, want to check the consensus to adopt the draft as
baseline for the working group item that will fulfill the first Goal in the current charter:
  Feb 2012 - Adopt a WG item for the per-frame compression extension


--------------010208030805080605090806-- From arman@noemax.com Mon Mar 5 23:49:23 2012 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 277EE21F8647 for ; Mon, 5 Mar 2012 23:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.436 X-Spam-Level: X-Spam-Status: No, score=-1.436 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUOLH0A-AJ6n for ; Mon, 5 Mar 2012 23:49:22 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6331821F860F for ; Mon, 5 Mar 2012 23:49:22 -0800 (PST) Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id QKD50015; Tue, 06 Mar 2012 09:49:15 +0200 From: "Arman Djusupov" To: "'John Tamplin'" , "'Brian'" References: <4F4C8568.7070403@ericsson.com> In-Reply-To: Date: Tue, 6 Mar 2012 09:49:16 +0200 Message-ID: <001a01ccfb6d$a5bdfb00$f139f100$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01CCFB7E.6947B560" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI5JnD12ZeDMrPxta9c4d0WdlgBkwLx4IPdAX4iXf8CFfZF3QD4exAdAiHC/eIBkEd3epUrCaKA Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Call for Consensus: draft-tyoshino-hybi-websocket-perframe-deflate as WG Item 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: Tue, 06 Mar 2012 07:49:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001B_01CCFB7E.6947B560 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I also agree on this. Creating an extension that would allow the use of = various compression algorithms and reserving this bit for per-frame = compression would be wise. In general, frame compression is a useful = feature of the transport that deserves reserving one bit for it. =20 With best regards, Arman =20 =20 From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = John Tamplin Sent: Friday, March 02, 2012 3:11 AM To: Brian Cc: hybi@ietf.org Subject: Re: [hybi] Call for Consensus: = draft-tyoshino-hybi-websocket-perframe-deflate as WG Item =20 =E2=80=A6 =20 My opinion is we should allocate a reserved bit for per-frame = compression, create an extension to indicate that is to be used for = compression and a way to select the compression algorithm, and define = deflate with no state shared across frames as a required compression = algorithm to be supported if no other algorithm is negotiated. We can = then define more effective compression algorithms that provide ways of = sharing compression state across frames, for example, though we still = have to work out the above questions though. =20 --=20 John A. Tamplin Software Engineer (GWT), Google ------=_NextPart_000_001B_01CCFB7E.6947B560 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I also = agree on this. Creating an extension that would allow the use of various = compression algorithms and reserving this bit for per-frame compression = would be wise. In general, frame compression is a useful feature of the = transport that deserves reserving one bit for it.

 

With = best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = John Tamplin
Sent: Friday, March 02, 2012 3:11 = AM
To: Brian
Cc: hybi@ietf.org
Subject: = Re: [hybi] Call for Consensus: = draft-tyoshino-hybi-websocket-perframe-deflate as WG = Item

 

=E2=80=A6

 

My opinion is we should allocate a reserved bit for = per-frame compression, create an extension to indicate that is to be = used for compression and a way to select the compression algorithm, and = define deflate with no state shared across frames as a required = compression algorithm to be supported if no other algorithm is = negotiated.  We can then define more effective compression = algorithms that provide ways of sharing compression state across frames, = for example, though we still have to work out the above questions = though.

 

--
John A. Tamplin
Software Engineer (GWT), = Google

------=_NextPart_000_001B_01CCFB7E.6947B560-- From bashi@google.com Tue Mar 6 00:21:00 2012 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 487FC21E80B8 for ; Tue, 6 Mar 2012 00:21:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgZwkYDmGWP5 for ; Tue, 6 Mar 2012 00:20:59 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 99D1D21E80BB for ; Tue, 6 Mar 2012 00:20:58 -0800 (PST) Received: by iazz13 with SMTP id z13so7860937iaz.31 for ; Tue, 06 Mar 2012 00:20:58 -0800 (PST) Received-SPF: pass (google.com: domain of bashi@google.com designates 10.42.72.130 as permitted sender) client-ip=10.42.72.130; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bashi@google.com designates 10.42.72.130 as permitted sender) smtp.mail=bashi@google.com; dkim=pass header.i=bashi@google.com Received: from mr.google.com ([10.42.72.130]) by 10.42.72.130 with SMTP id o2mr18619159icj.8.1331022058384 (num_hops = 1); Tue, 06 Mar 2012 00:20:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type:x-system-of-record; bh=1U0F/s/bpZ3QeYm1ZveU//eivSWGT5WsTZPbviHt44M=; b=JeXtMBjxzSk/h/NipqNdm4GMe7buOqMMZxMckaxZsELutmZoROmfxjtCX4sgQzeRKG ufdiQ9kXKDZ94QLVSo3zyDxlzCw/mV2uTkF/6uRZ5lNOpxW0dtMb3BbgMLHxN9sC+al0 uGJbrPGrOi06WzZ1N9siLafzfVtiIE9FFBIm03JARFeTkjpGc/BZ2ydsHb9Uu7QeBrwb NgvYuITXSl5dLpQ2xaDPjH5g8Ts9AElZNQuW1fGRTAvC2NLHYLhJqX7zn7Ky+MIejs6r yfA7xQgVjqT0yV4WzW17vxEcc3IwnxFC17MM/V0MBe4+fKjqRHgpWvHMNpjdQqh2khch XhQw== Received: by 10.42.72.130 with SMTP id o2mr15382476icj.8.1331022058340; Tue, 06 Mar 2012 00:20:58 -0800 (PST) Received: by 10.42.72.130 with SMTP id o2mr15382467icj.8.1331022058238; Tue, 06 Mar 2012 00:20:58 -0800 (PST) MIME-Version: 1.0 Sender: bashi@google.com Received: by 10.231.20.226 with HTTP; Tue, 6 Mar 2012 00:20:37 -0800 (PST) From: Kenichi Ishibashi Date: Tue, 6 Mar 2012 17:20:37 +0900 X-Google-Sender-Auth: h2tr_6Hic-XfLLaHnxxUPfzjQWc Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=90e6ba6e84f6f833bd04ba8eb82e X-System-Of-Record: true X-Gm-Message-State: ALoCoQkSg6XksRMONiF6BdSAtTi/YL1FXj0I+h2i9flK0TLhXyo2ZXtLyQEOk44BnRXc1GsmuYFUgZads2ELkQfELVBDH6yDS6ISBCj2AxXZ5LuR1t2hvhm2isIkyrb/lceNfGxVaSEc Subject: [hybi] deflate-frame extension in WebKit 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: Tue, 06 Mar 2012 08:28:27 -0000 --90e6ba6e84f6f833bd04ba8eb82e Content-Type: text/plain; charset=ISO-8859-1 Hi, I just want to let you know that we added deflate-frame extension to WebKit[1]. The current implementation is based on the current draft[2] and the extension name is "x-webkit-deflate-frame." Pywebsocket[3] can handle the extension. Chrome canary will use the extension when it communicates with pywebsocket server. [1] http://trac.webkit.org/changeset/109538 [2] http://tools.ietf.org/id/draft-tyoshino-hybi-websocket-perframe-deflate-05.txt [3] http://code.google.com/p/pywebsocket/ I hope this contributes the discussion of per-frame compression extension. Regards, --90e6ba6e84f6f833bd04ba8eb82e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

I just want to let you know that we added deflate-fr= ame extension to WebKit[1].=A0The current implementation is based on the cu= rrent draft[2] and the extension name is "x-webkit-deflate-frame."= ; Pywebsocket[3] can handle the extension. Chrome canary will use the exten= sion when it communicates with pywebsocket server.


I ho= pe this contributes the discussion of per-frame compression extension.

Regards,

--90e6ba6e84f6f833bd04ba8eb82e-- From wwwrun@rfc-editor.org Wed Mar 7 11:17:23 2012 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 D6F5B11E807F for ; Wed, 7 Mar 2012 11:17:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.409 X-Spam-Level: X-Spam-Status: No, score=-103.409 tagged_above=-999 required=5 tests=[AWL=1.191, BAYES_00=-2.599, GB_I_LETTER=-2, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V8krzCxibKp for ; Wed, 7 Mar 2012 11:17:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 727D411E8072 for ; Wed, 7 Mar 2012 11:17:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B5D1262179; Wed, 7 Mar 2012 11:17:13 -0800 (PST) To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, presnick@qualcomm.com, stpeter@stpeter.im, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com From: RFC Errata System Message-Id: <20120307191713.B5D1262179@rfc-editor.org> Date: Wed, 7 Mar 2012 11:17:13 -0800 (PST) Cc: hybi@ietf.org, robertm-cooppith@stackframe.com, rfc-editor@rfc-editor.org Subject: [hybi] [Technical Errata Reported] RFC6455 (3150) 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: Wed, 07 Mar 2012 19:17:24 -0000 The following errata report has been submitted for RFC6455, "The WebSocket Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3150 -------------------------------------- Type: Technical Reported by: Robert Munyer Section: 4.1 Original Text ------------- AQIDBAUGBwgJCgsMDQ4PEC== Corrected Text -------------- AQIDBAUGBwgJCgsMDQ4PEA== Notes ----- The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 section 4.1, is wrong. It was processed by a base 64 encoder that was "improperly implemented" as mentioned in RFC 4648 section 3.5. Pad bits were not set to zero, which is a "MUST" requirement in RFC 4648, and was also required by many other RFCs, going back to RFC 989 in the 1980s. In the string "AQIDBAUGBwgJCgsMDQ4PEC==", the final C should be changed to A. In a Sec-WebSocket-Key header sent by a properly implemented client, the last letter will always be A, Q, g or w. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) -------------------------------------- Title : The WebSocket Protocol Publication Date : December 2011 Author(s) : I. Fette, A. Melnikov Category : PROPOSED STANDARD Source : BiDirectional or Server-Initiated HTTP Area : Applications Stream : IETF Verifying Party : IESG From derhoermi@gmx.net Wed Mar 7 16:24:06 2012 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 C5F4221F85A4 for ; Wed, 7 Mar 2012 16:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.633 X-Spam-Level: X-Spam-Status: No, score=-3.633 tagged_above=-999 required=5 tests=[AWL=-1.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9U1Q0SXIa2xD for ; Wed, 7 Mar 2012 16:24:06 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 8917D21F84B8 for ; Wed, 7 Mar 2012 16:24:05 -0800 (PST) Received: (qmail invoked by alias); 08 Mar 2012 00:24:04 -0000 Received: from dslb-094-223-208-043.pools.arcor-ip.net (EHLO HIVE) [94.223.208.43] by mail.gmx.net (mp032) with SMTP; 08 Mar 2012 01:24:04 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/3oh1yU933enl/zkmaQVPfzYOjvRiKbvjZPBLBoi tOz76mW0MOcMQH From: Bjoern Hoehrmann To: hybi@ietf.org Date: Thu, 08 Mar 2012 01:24:11 +0100 Message-ID: References: <20120307191713.B5D1262179@rfc-editor.org> In-Reply-To: <20120307191713.B5D1262179@rfc-editor.org> 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 Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150) 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, 08 Mar 2012 00:24:06 -0000 * RFC Errata System wrote: >Section: 4.1 > >Original Text >------------- >AQIDBAUGBwgJCgsMDQ4PEC== > >Corrected Text >-------------- >AQIDBAUGBwgJCgsMDQ4PEA== > >Notes >----- >The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 >section 4.1, is wrong. It was processed by a base 64 encoder that was >"improperly implemented" as mentioned in RFC 4648 section 3.5. If this is true, why did we fail to catch this in time? Was it added late, for instance? (I would like an analysis to support discussions whether to create a review team specifically for this kind of formal syntax error.) -- 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 stpeter@stpeter.im Wed Mar 7 16:28:08 2012 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 14C1921F85AA for ; Wed, 7 Mar 2012 16:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.673 X-Spam-Level: X-Spam-Status: No, score=-102.673 tagged_above=-999 required=5 tests=[AWL=-0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vARcGMiVciuV for ; Wed, 7 Mar 2012 16:28:07 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 74DDC21F85A7 for ; Wed, 7 Mar 2012 16:28:07 -0800 (PST) Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D007F4005B; Wed, 7 Mar 2012 17:40:07 -0700 (MST) Message-ID: <4F57FD15.2030703@stpeter.im> Date: Wed, 07 Mar 2012 17:28:05 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <20120307191713.B5D1262179@rfc-editor.org> In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150) 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, 08 Mar 2012 00:28:08 -0000 On 3/7/12 5:24 PM, Bjoern Hoehrmann wrote: > * RFC Errata System wrote: >> Section: 4.1 >> >> Original Text >> ------------- >> AQIDBAUGBwgJCgsMDQ4PEC== >> >> Corrected Text >> -------------- >> AQIDBAUGBwgJCgsMDQ4PEA== >> >> Notes >> ----- >> The "test vector" for Sec-WebSocket-Key encoding, provided in RFC 6455 >> section 4.1, is wrong. It was processed by a base 64 encoder that was >> "improperly implemented" as mentioned in RFC 4648 section 3.5. > > If this is true, why did we fail to catch this in time? Was it added > late, for instance? (I would like an analysis to support discussions > whether to create a review team specifically for this kind of formal > syntax error.) As far as I can tell from the erratum, this was a problem with generation of an example, not a syntax error. Peter -- Peter Saint-Andre https://stpeter.im/ From derhoermi@gmx.net Wed Mar 7 16:37:23 2012 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 55ECF11E8089 for ; Wed, 7 Mar 2012 16:37:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.607 X-Spam-Level: X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[AWL=-1.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XqhAOq5EDG9 for ; Wed, 7 Mar 2012 16:37:22 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id F06C511E8085 for ; Wed, 7 Mar 2012 16:37:21 -0800 (PST) Received: (qmail invoked by alias); 08 Mar 2012 00:37:20 -0000 Received: from dslb-094-223-208-043.pools.arcor-ip.net (EHLO HIVE) [94.223.208.43] by mail.gmx.net (mp033) with SMTP; 08 Mar 2012 01:37:20 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/uAdQ7H6DuAbjEq7pMxiXqm3cm6G+KCMEapGZ7wT Ai0eD3OQ/wT5gH From: Bjoern Hoehrmann To: Peter Saint-Andre Date: Thu, 08 Mar 2012 01:37:27 +0100 Message-ID: <9fvfl7dc444d23n3539v6ep5a0kighhfjd@hive.bjoern.hoehrmann.de> References: <20120307191713.B5D1262179@rfc-editor.org> <4F57FD15.2030703@stpeter.im> In-Reply-To: <4F57FD15.2030703@stpeter.im> 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 Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150) 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, 08 Mar 2012 00:37:23 -0000 * Peter Saint-Andre wrote: >On 3/7/12 5:24 PM, Bjoern Hoehrmann wrote: >> If this is true, why did we fail to catch this in time? Was it added >> late, for instance? (I would like an analysis to support discussions >> whether to create a review team specifically for this kind of formal >> syntax error.) > >As far as I can tell from the erratum, this was a problem with >generation of an example, not a syntax error. Base64 is a formal language. Unlike interpreting english prose, people are not good at spotting problems with formal languages, in the case here they would most probably have to use software to verify the code. That it occurs in an example does not really matter, people would like- ly use the examples in the specification for their first tests, and if they come up with different results there is costly confusion, to the point that people might change their correct implementation so it re- produces the example, which would lead to interoperability problems. I think we should try to avoid this kind of costly bug, and understanding how we ended up with it, if the report is correct, is the first step. -- 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 stpeter@stpeter.im Thu Mar 8 07:31:44 2012 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 38E7621F866E for ; Thu, 8 Mar 2012 07:31:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.776 X-Spam-Level: X-Spam-Status: No, score=-102.776 tagged_above=-999 required=5 tests=[AWL=-0.177, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFQguUQ0hdlq for ; Thu, 8 Mar 2012 07:31:43 -0800 (PST) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id BBC8A21F8648 for ; Thu, 8 Mar 2012 07:31:43 -0800 (PST) Received: from squire.local (unknown [64.101.72.114]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9FDF34005B for ; Thu, 8 Mar 2012 08:43:39 -0700 (MST) Message-ID: <4F58CB17.8040100@stpeter.im> Date: Thu, 08 Mar 2012 08:07:03 -0700 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "hybi@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [hybi] Fwd: [spdy-dev] WebSocket Layering over SPDY draft specification 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, 08 Mar 2012 15:31:44 -0000 Perhaps of interest here. -------- Original Message -------- Subject: [spdy-dev] WebSocket Layering over SPDY draft specification Date: Wed, 7 Mar 2012 20:58:46 -0800 From: Takashi Toyoshima Reply-To: spdy-dev@googlegroups.com To: spdy-dev@googlegroups.com Hi, I propose a draft specification on WebSocket Layering over SPDY. https://docs.google.com/document/d/1zUEFzz7NCls3Yms8hXxY4wGXJ3EEvoZc3GihrqPQcM0/edit?pli=1 For now, this specification contains some open questions. I think framing and masking must be major topics to be discussed. Your comments are welcomed. Cheers, -- Takashi Toyoshima Software Engineer, Google From tyoshino@google.com Fri Mar 9 16:16:18 2012 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 52C1621F8537 for ; Fri, 9 Mar 2012 16:16:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.956 X-Spam-Level: X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9wHVQYfA87P for ; Fri, 9 Mar 2012 16:16:17 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id BBEE821F84D3 for ; Fri, 9 Mar 2012 16:16:17 -0800 (PST) Received: by ghbg16 with SMTP id g16so1462813ghb.31 for ; Fri, 09 Mar 2012 16:16:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=mjGkfC+ObjFphDpbYbcKhrAT/9V/MYwEG8t6zMY0eIU=; b=NGOPT/M5ownlXEbXhABXi4iE5/EYYJMnXz0C4GGlqKhtZ3Vu8kAk4kXsJ/qZI8Oo4w lOiidqgdPkilPYAKm+YsipqQGMJlN+8cRCzmFnke3kSA15K26EzfyIUIrBpANa/xCSdt MOvNhAzKSsEUoCq2tepOu5ygNDaHiza4Baz7rxGiv5oob++UJI04SofbXGgZ9rnOzSPY cgj1Jt54Y0yNNPe5LWsT3a0ftmSrhgSQjThVf4myuvYMKTA6Q0N+Hx/2Dx6Woci1DUFz h75TePhrLMVmvhASrv9xlVeHHJVsgDHZdZaL3E5d9CFjJ8A7GNr1sP9dmKSgTZJFk3rw qsWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=mjGkfC+ObjFphDpbYbcKhrAT/9V/MYwEG8t6zMY0eIU=; b=UqSyHhlNE8ZZpmUsKBISV8zqo2D9O5H17hKTlYQc+w3ZOB9vU8WZZ942pWjH0ftT2G IDnQq4eBtjljVrAZDuv+73q2PXDTm4CgUDqIRjdPCxa73r3udNi5eN8L6XTn291uS2QL 4talOkvTOUqqqHot0kIS7491LTVx6PqES5dfZGkRX7S1c7NAYtU0KFxwCW5hqfX9re0O X0W0BZsW9PLQ0VXKzF1f5LrwyBJbM4+WQmHjDGbnuOdwHWRrmKqrYBGO2GWrkB99raq7 2iv/MwMlZb1KIOSk2SBFx0oJOEvldcS4ITP4fNI/JRtVUH9qieFI//CHwjpVy0iZQw9H M6oQ== Received: by 10.236.195.38 with SMTP id o26mr4975537yhn.100.1331338577349; Fri, 09 Mar 2012 16:16:17 -0800 (PST) Received: by 10.236.195.38 with SMTP id o26mr4975531yhn.100.1331338577270; Fri, 09 Mar 2012 16:16:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Fri, 9 Mar 2012 16:15:57 -0800 (PST) From: Takeshi Yoshino Date: Fri, 9 Mar 2012 16:15:57 -0800 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf305e2763f958fd04bad86a12 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmME1yn0oNXHlzdmQaNa7ewluPFF14DSVqvtO7E3G4QXG17WbfehBrKgqo7wCoOjBQ3FddIy9QoXLaltjVanZIvC0FVB6QU7B0dzPwbUeYFU3/RWr8tzCu5X6vVmZIzpaNxFsas Subject: [hybi] Per-frame compression spec draft 06 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: Sat, 10 Mar 2012 00:16:18 -0000 --20cf305e2763f958fd04bad86a12 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here's a revised version of the per-frame compression spec. I'm planning to rename it to draft-ietf-hybi-websocket-perframe-compression-00 after the meeting. http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06 http://tools.ietf.org/rfcdiff?url2=draft-tyoshino-hybi-websocket-perframe-deflate-06.txt Based on the feedback comments for the CfC, I've done - reordering of sections - abstracting the framing method (COMP bit and how to build compressed frames) as general per-frame compression scheme - renaming COMP bit to "per-frame compressed" and giving more general description for it in both the main texts and IANA consideration section Thanks Takeshi --20cf305e2763f958fd04bad86a12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Here's a revised version of the p= er-frame compression spec.=A0I'm planning to rename it to draft-ietf-hy= bi-websocket-perframe-compression-00 after the meeting.
= http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-0= 6

Based on the feedback comments for the CfC, I've done
<= div>- reordering of sections
- abstracting the framing method (CO= MP bit and how to build compressed frames) as general per-frame compression= scheme
- renaming COMP bit to "per-frame compressed" and giving mor= e general description for it in both the main texts and IANA consideration = section

Thanks
Takeshi
--20cf305e2763f958fd04bad86a12-- From jat@google.com Fri Mar 9 16:56:51 2012 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 8803421E8019 for ; Fri, 9 Mar 2012 16:56:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEM22SL37bzn for ; Fri, 9 Mar 2012 16:56:50 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EC8B121E8018 for ; Fri, 9 Mar 2012 16:56:49 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so2322283vcb.31 for ; Fri, 09 Mar 2012 16:56:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=iCTj75gSH01D/Y/FIP/zxVUXeV41TB1FdDhOwS32ufc=; b=L4caudZjXq3ywAdedEB/FwqJqk+RRfR1Y6NKQK7eBZuH3Klv/tl7zibZKVEK/wuRqn nEorGZWbKFD4pedx4VsWoq5U4nY4FNDYyVDo9WkElQUFVzUkiaN0wWk4yCSJ84UpMGhT 1PhseFML0AG6RAueh+RM4T/V+JZ33iOQ7UrcDh05Cuq/bsm6PForyJHZOI8jlSpaTrmX Dq1+QS7csf9AeSlJBLPKCSIEfGvYuTzS9YrKVtCBpuvFq9qvBjhQxLSQ1aFzoRotELUO qtji68eHCD5oaDMnnQYMMmzoY8XvBBMn5mgOXl6tO+jPV3AKWGc0FApXv6tZlNGcFgMV 0tYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=iCTj75gSH01D/Y/FIP/zxVUXeV41TB1FdDhOwS32ufc=; b=gaLKf8fvDzXt7caHsiNF9efFD9RG2BCUFpRTdgu/f9cT18U/CbNQhialArTND/jsQR mRmjka4notwJA2XPCOtk+upIm8UO/ZR/fFohnfUoxz3nMXzCRD2e1vxV/UWvOJUOYu9+ sJ44ZqbA/BzW82/IzQudHQhXb1xHxPZURZr7SdLrGn+dA/BIVBjfdL50gAU90j2RXq5T CKnhoTn22TKSmMEVridbuI3rH1XGcANXaXo7G91JU+AVjMYIyuC5VRXx1BY++U3JX79L m2QnlmVZTvkeba7WpPLHqILXJfZgugT+ymDQLIwO4JmxIK8UpybPLBl1mj/3cxd092o/ Df9Q== Received: by 10.52.28.178 with SMTP id c18mr7084762vdh.45.1331341009333; Fri, 09 Mar 2012 16:56:49 -0800 (PST) Received: by 10.52.28.178 with SMTP id c18mr7084753vdh.45.1331341009228; Fri, 09 Mar 2012 16:56:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Fri, 9 Mar 2012 16:56:29 -0800 (PST) In-Reply-To: References: From: John Tamplin Date: Fri, 9 Mar 2012 19:56:29 -0500 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf307ac3f3ee119704bad8fbc9 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm76J1QFdUa5oZI195UMkIjqYR6U5B/a0h+3MwsaqT2QqVyqtJoJTSjQVexeHfKwL8rfHK4rKMhr0Vd0eA5hGtrWh0F701CZWLad+mKNRZjLeULGOq2eTksiSEVZGntZ+TFESZz Cc: hybi@ietf.org Subject: Re: [hybi] Per-frame compression spec draft 06 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: Sat, 10 Mar 2012 00:56:51 -0000 --20cf307ac3f3ee119704bad8fbc9 Content-Type: text/plain; charset=UTF-8 On Fri, Mar 9, 2012 at 7:15 PM, Takeshi Yoshino wrote: > Here's a revised version of the per-frame compression spec. I'm planning > to rename it to draft-ietf-hybi-websocket-perframe-compression-00 after the > meeting. > > http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06 > > > http://tools.ietf.org/rfcdiff?url2=draft-tyoshino-hybi-websocket-perframe-deflate-06.txt > Based on the feedback comments for the CfC, I've done > - reordering of sections > - abstracting the framing method (COMP bit and how to build compressed > frames) as general per-frame compression scheme > - renaming COMP bit to "per-frame compressed" and giving more general > description for it in both the main texts and IANA consideration section > >From the summary here, I expected it to be described as two separate pieces: 1) a generic per-frame compression extension, including a way to negotiate the algorithm to be used 2) a particular compression algorithm available by default (and required to be supported) - deflate Instead, it still looks like an extension just for deflate, using slightly more general language. -- John A. Tamplin Software Engineer (GWT), Google --20cf307ac3f3ee119704bad8fbc9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 9, 2012 at 7:15 PM, Takeshi Yoshino = <tyoshino@googl= e.com> wrote:
Here's a revised version of the per-frame compression spec.=C2=A0I= 'm planning to rename it to draft-ietf-hybi-websocket-perframe-compress= ion-00 after the meeting.
http://tools= .ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06

Based on the feedback comments for the CfC, I've done
<= div>- reordering of sections
- abstracting the framing method (CO= MP bit and how to build compressed frames) as general per-frame compression= scheme
- renaming COMP bit to "per-frame compressed" and giving mor= e general description for it in both the main texts and IANA consideration = section

From the summary here, I expe= cted it to be described as two separate pieces:
=C2=A01) a generic per-frame compression extension, including a way to= negotiate the algorithm to be used
=C2=A02) a particular compres= sion algorithm available by default (and required to be supported) - deflat= e

Instead, it still looks like an extension just for defl= ate, using slightly more general language.

-- John A. Tamplin
Software Engineer (GWT), Google
--20cf307ac3f3ee119704bad8fbc9-- From Gabriel.Montenegro@microsoft.com Fri Mar 9 17:57:43 2012 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 0120E21E8018 for ; Fri, 9 Mar 2012 17:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewl7Kx1O6MPd for ; Fri, 9 Mar 2012 17:57:42 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id B9ACB21E8042 for ; Fri, 9 Mar 2012 17:57:41 -0800 (PST) Received: from mail55-db3-R.bigfish.com (10.3.81.245) by DB3EHSOBE005.bigfish.com (10.3.84.25) with Microsoft SMTP Server id 14.1.225.23; Sat, 10 Mar 2012 01:57:40 +0000 Received: from mail55-db3 (localhost [127.0.0.1]) by mail55-db3-R.bigfish.com (Postfix) with ESMTP id 3A5D440632; Sat, 10 Mar 2012 01:57:40 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic857h98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail55-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail55-db3 (localhost.localdomain [127.0.0.1]) by mail55-db3 (MessageSwitch) id 1331344656718488_2953; Sat, 10 Mar 2012 01:57:36 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.239]) by mail55-db3.bigfish.com (Postfix) with ESMTP id 9F5774E0045; Sat, 10 Mar 2012 01:57:36 +0000 (UTC) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 10 Mar 2012 01:57:36 +0000 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.2.283.4; Sat, 10 Mar 2012 01:57:35 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.219]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Fri, 9 Mar 2012 17:57:34 -0800 From: Gabriel Montenegro To: John Tamplin , Takeshi Yoshino Thread-Topic: [hybi] Per-frame compression spec draft 06 Thread-Index: AQHM/lMHL6t3sv5zoESdnIgB1T4R/ZZjOreA//+KhrA= Date: Sat, 10 Mar 2012 01:57:34 +0000 Message-ID: References: In-Reply-To: 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_CA566BAEAD6B3F4E8B5C5C4F61710C1147F18BAATK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "hybi@ietf.org" Subject: Re: [hybi] Per-frame compression spec draft 06 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: Sat, 10 Mar 2012 01:57:43 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F18BAATK5EX14MBXW604w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIFRha2VzaGksDQoNCkp1c3QgYSBjbGFyaWZpY2F0aW9uIHRoYXQgcmVuYW1pbmcgdGhl IGRyYWZ0IHRvIGRyYWZ0LWlldGYtaHliaS13ZWJzb2NrZXQtcGVyZnJhbWUtY29tcHJlc3Npb24t MDAsIG9mIGNvdXJzZSwgZGVwZW5kcyBvbiB0aGUgcmVzdWx0IG9mIHRoZSBjdXJyZW50IGNvbnNl bnN1cyBjYWxsIG9uIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgYSBXRyBkb2N1bWVudC4gVGhh dCBjYWxsIHJ1bnMgdW50aWwgbmV4dCBNb24gTWFyY2ggMTIuDQoNCkdhYnJpZWwNCg0KRnJvbTog aHliaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgSm9obiBUYW1wbGluDQpTZW50OiBGcmlkYXksIDA5IE1hcmNoLCAyMDEyIDE2OjU2 DQpUbzogVGFrZXNoaSBZb3NoaW5vDQpDYzogaHliaUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFto eWJpXSBQZXItZnJhbWUgY29tcHJlc3Npb24gc3BlYyBkcmFmdCAwNg0KDQpPbiBGcmksIE1hciA5 LCAyMDEyIGF0IDc6MTUgUE0sIFRha2VzaGkgWW9zaGlubyA8dHlvc2hpbm9AZ29vZ2xlLmNvbTxt YWlsdG86dHlvc2hpbm9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0KSGVyZSdzIGEgcmV2aXNlZCB2ZXJz aW9uIG9mIHRoZSBwZXItZnJhbWUgY29tcHJlc3Npb24gc3BlYy4gSSdtIHBsYW5uaW5nIHRvIHJl bmFtZSBpdCB0byBkcmFmdC1pZXRmLWh5Ymktd2Vic29ja2V0LXBlcmZyYW1lLWNvbXByZXNzaW9u LTAwIGFmdGVyIHRoZSBtZWV0aW5nLg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt dHlvc2hpbm8taHliaS13ZWJzb2NrZXQtcGVyZnJhbWUtZGVmbGF0ZS0wNg0KDQpodHRwOi8vdG9v bHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXR5b3NoaW5vLWh5Ymktd2Vic29ja2V0LXBl cmZyYW1lLWRlZmxhdGUtMDYudHh0DQpCYXNlZCBvbiB0aGUgZmVlZGJhY2sgY29tbWVudHMgZm9y IHRoZSBDZkMsIEkndmUgZG9uZQ0KLSByZW9yZGVyaW5nIG9mIHNlY3Rpb25zDQotIGFic3RyYWN0 aW5nIHRoZSBmcmFtaW5nIG1ldGhvZCAoQ09NUCBiaXQgYW5kIGhvdyB0byBidWlsZCBjb21wcmVz c2VkIGZyYW1lcykgYXMgZ2VuZXJhbCBwZXItZnJhbWUgY29tcHJlc3Npb24gc2NoZW1lDQotIHJl bmFtaW5nIENPTVAgYml0IHRvICJwZXItZnJhbWUgY29tcHJlc3NlZCIgYW5kIGdpdmluZyBtb3Jl IGdlbmVyYWwgZGVzY3JpcHRpb24gZm9yIGl0IGluIGJvdGggdGhlIG1haW4gdGV4dHMgYW5kIElB TkEgY29uc2lkZXJhdGlvbiBzZWN0aW9uDQoNCkZyb20gdGhlIHN1bW1hcnkgaGVyZSwgSSBleHBl Y3RlZCBpdCB0byBiZSBkZXNjcmliZWQgYXMgdHdvIHNlcGFyYXRlIHBpZWNlczoNCiAxKSBhIGdl bmVyaWMgcGVyLWZyYW1lIGNvbXByZXNzaW9uIGV4dGVuc2lvbiwgaW5jbHVkaW5nIGEgd2F5IHRv IG5lZ290aWF0ZSB0aGUgYWxnb3JpdGhtIHRvIGJlIHVzZWQNCiAyKSBhIHBhcnRpY3VsYXIgY29t cHJlc3Npb24gYWxnb3JpdGhtIGF2YWlsYWJsZSBieSBkZWZhdWx0IChhbmQgcmVxdWlyZWQgdG8g YmUgc3VwcG9ydGVkKSAtIGRlZmxhdGUNCg0KSW5zdGVhZCwgaXQgc3RpbGwgbG9va3MgbGlrZSBh biBleHRlbnNpb24ganVzdCBmb3IgZGVmbGF0ZSwgdXNpbmcgc2xpZ2h0bHkgbW9yZSBnZW5lcmFs IGxhbmd1YWdlLg0KDQotLQ0KSm9obiBBLiBUYW1wbGluDQpTb2Z0d2FyZSBFbmdpbmVlciAoR1dU KSwgR29vZ2xlDQo= --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F18BAATK5EX14MBXW604w_ 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 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgVGFrZXNoaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkp1c3QgYSBjbGFyaWZpY2F0aW9uIHRoYXQgcmVuYW1pbmcgdGhlIGRyYWZ0IHRvIGRyYWZ0 LWlldGYtaHliaS13ZWJzb2NrZXQtcGVyZnJhbWUtY29tcHJlc3Npb24tMDAsIG9mIGNvdXJzZSwg ZGVwZW5kcyBvbiB0aGUgcmVzdWx0IG9mIHRoZSBjdXJyZW50IGNvbnNlbnN1cw0KIGNhbGwgb24g YWRvcHRpb24gb2YgdGhpcyBkcmFmdCBhcyBhIFdHIGRvY3VtZW50LiBUaGF0IGNhbGwgcnVucyB1 bnRpbCBuZXh0IE1vbiBNYXJjaCAxMi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdhYnJpZWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaHliaS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86aHliaS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIFRhbXBs aW48YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCAwOSBNYXJjaCwgMjAxMiAxNjo1Njxicj4NCjxi PlRvOjwvYj4gVGFrZXNoaSBZb3NoaW5vPGJyPg0KPGI+Q2M6PC9iPiBoeWJpQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gUGVyLWZyYW1lIGNvbXByZXNzaW9uIHNwZWMg ZHJhZnQgMDY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRnJpLCBNYXIgOSwgMjAxMiBhdCA3OjE1IFBNLCBUYWtlc2hpIFlvc2hpbm8gJmx0 OzxhIGhyZWY9Im1haWx0bzp0eW9zaGlub0Bnb29nbGUuY29tIj50eW9zaGlub0Bnb29nbGUuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGVyZSdzIGEgcmV2aXNlZCB2ZXJzaW9uIG9mIHRoZSBwZXItZnJhbWUgY29tcHJlc3Npb24g c3BlYy4mbmJzcDtJJ20gcGxhbm5pbmcgdG8gcmVuYW1lIGl0IHRvIGRyYWZ0LWlldGYtaHliaS13 ZWJzb2NrZXQtcGVyZnJhbWUtY29tcHJlc3Npb24tMDAgYWZ0ZXIgdGhlIG1lZXRpbmcuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXR5b3NoaW5vLWh5Ymktd2Vic29ja2V0LXBlcmZyYW1l LWRlZmxhdGUtMDYiIHRhcmdldD0iX2JsYW5rIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC10eW9zaGluby1oeWJpLXdlYnNvY2tldC1wZXJmcmFtZS1kZWZsYXRlLTA2PC9hPg0KPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXR5b3NoaW5vLWh5Ymktd2Vic29j a2V0LXBlcmZyYW1lLWRlZmxhdGUtMDYudHh0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL3Rvb2xz LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC10eW9zaGluby1oeWJpLXdlYnNvY2tldC1wZXJm cmFtZS1kZWZsYXRlLTA2LnR4dDwvYT4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmFzZWQgb24gdGhlIGZlZWRiYWNrIGNvbW1lbnRzIGZvciB0 aGUgQ2ZDLCBJJ3ZlIGRvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi0gcmVvcmRlcmluZyBvZiBzZWN0aW9uczxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBhYnN0cmFjdGluZyB0aGUgZnJhbWlu ZyBtZXRob2QgKENPTVAgYml0IGFuZCBob3cgdG8gYnVpbGQgY29tcHJlc3NlZCBmcmFtZXMpIGFz IGdlbmVyYWwgcGVyLWZyYW1lIGNvbXByZXNzaW9uIHNjaGVtZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSByZW5hbWluZyBDT01QIGJpdCB0byAm cXVvdDtwZXItZnJhbWUgY29tcHJlc3NlZCZxdW90OyBhbmQgZ2l2aW5nIG1vcmUgZ2VuZXJhbCBk ZXNjcmlwdGlvbiBmb3IgaXQgaW4gYm90aCB0aGUgbWFpbiB0ZXh0cyBhbmQgSUFOQSBjb25zaWRl cmF0aW9uIHNlY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+RnJvbSB0aGUgc3VtbWFyeSBoZXJlLCBJIGV4cGVjdGVkIGl0IHRvIGJlIGRl c2NyaWJlZCBhcyB0d28gc2VwYXJhdGUgcGllY2VzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7MSkgYSBnZW5lcmljIHBlci1mcmFtZSBj b21wcmVzc2lvbiBleHRlbnNpb24sIGluY2x1ZGluZyBhIHdheSB0byBuZWdvdGlhdGUgdGhlIGFs Z29yaXRobSB0byBiZSB1c2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsyKSBhIHBhcnRpY3VsYXIgY29tcHJlc3Npb24gYWxnb3JpdGht IGF2YWlsYWJsZSBieSBkZWZhdWx0IChhbmQgcmVxdWlyZWQgdG8gYmUgc3VwcG9ydGVkKSAtIGRl ZmxhdGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW5zdGVhZCwgaXQgc3RpbGwgbG9va3MgbGlrZSBhbiBleHRlbnNpb24ganVzdCBmb3IgZGVm bGF0ZSwgdXNpbmcgc2xpZ2h0bHkgbW9yZSBnZW5lcmFsIGxhbmd1YWdlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0KSm9obiBB LiBUYW1wbGluPGJyPg0KU29mdHdhcmUgRW5naW5lZXIgKEdXVCksIEdvb2dsZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F18BAATK5EX14MBXW604w_-- From tyoshino@google.com Sat Mar 10 12:50:26 2012 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 5CCD421F85C2 for ; Sat, 10 Mar 2012 12:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sc0EYcNK3Fno for ; Sat, 10 Mar 2012 12:50:25 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id F3D9721F85B5 for ; Sat, 10 Mar 2012 12:50:24 -0800 (PST) Received: by yenm5 with SMTP id m5so1863270yen.31 for ; Sat, 10 Mar 2012 12:50:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=YcRT914f3Dh6e1XV5yGWLwYljaceESwe/J2MgFdyvMk=; b=ojizGbXjx1+Wz0Uiuuqe7swIhcFm7Mq1L2USxuZmiPtWDgNSt9OrqWFk2Qb/adZzuo n5VugANYYq8BqzoNt8V/uPxOjUq3CeuUEYJFK9ujpx8wnMWspZlwwC4of0YBtW4C7twL KkeH++SoEMG0qv/ocK46DwI3AQ51HuOm7l9nms6Hi+MSTAVOdB7o7uJWF4XIaF6e4YMJ LIPaYzbShN9gpo1qrn4gDjSLfm3+MQSMI7dYvXO7qHGHAm+hlfkYEajcJK5QIzYQIMq7 H8LRbGW1YE/tRRB/Qo5+gKvOPjPxN+jY/AnUjcZWXp3+QP5GtJZfz35rJWk7k795FgdV RPMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=YcRT914f3Dh6e1XV5yGWLwYljaceESwe/J2MgFdyvMk=; b=cNlO/PZsnS/fPn3AbmZBTahJRGkoYPKiCdvEivdEvX6gf+hXMV6pzx3kBSYJBlGVPD cvO/iiBlzHUYvroI86E6Faq4inMl6ajf5wlrgq+lieTOAWGdGBYnpchCQMrvk0OiPByY 5rGSDmDXZU1ScGTLCaB5ZESqE32aCaNkYE7aeLAMrkvuwVRXtnYo/vQgdmwjpY5Lb7ff pzlWHx1oaO3qIcelGlXa/Tvw+Vq+2yX6rhl294QlfVIbT2h78T9OwfoRuDTl+xHtvAoF YBQOAkUAdPVb4ct89K5u0seo6J/jq9tiy5AUzRW8V1eLAfdIZ+U7KUpiopB8IPwT/55j 00Ow== Received: by 10.236.174.106 with SMTP id w70mr7903824yhl.68.1331412624374; Sat, 10 Mar 2012 12:50:24 -0800 (PST) Received: by 10.236.174.106 with SMTP id w70mr7903814yhl.68.1331412624224; Sat, 10 Mar 2012 12:50:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Sat, 10 Mar 2012 12:50:04 -0800 (PST) In-Reply-To: References: From: Takeshi Yoshino Date: Sat, 10 Mar 2012 12:50:04 -0800 Message-ID: To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=20cf3040e3bc84321404bae9a8b5 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmKwOw34k7iEcaLN9vTQL0g/E32+mHqllQcH6UDIravAz1Uh0eB/WIInaXrM1SheA1TH9DHsqWwg6ltND5W4oeNvOj5Djhp3js0aydE4DWUeBYzrTgtDYmz0jKj3A/ZlnvOh3LC Cc: "hybi@ietf.org" Subject: Re: [hybi] Per-frame compression spec draft 06 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: Sat, 10 Mar 2012 20:50:26 -0000 --20cf3040e3bc84321404bae9a8b5 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Mar 9, 2012 at 16:56, John Tamplin wrote: ... > From the summary here, I expected it to be described as two separate > pieces: > 1) a generic per-frame compression extension, including a way to > negotiate the algorithm to be used > 2) a particular compression algorithm available by default (and required > to be supported) - deflate > Sorry to be unclear. > Instead, it still looks like an extension just for deflate, using slightly > more general language. > Yes. I just factored out texts around comp bit handling so that other extension specs can refer it. ---- Thanks for the clarification, Gabriel. --20cf3040e3bc84321404bae9a8b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Mar 9, 2012 at 16:56, John Tamplin=A0<jat@= google.com>=A0wrote:
...
From the summary here, I expected it to be described as two separate p= ieces:
=A01) a generic per-frame compression extension, including= a way to negotiate the algorithm to be used
=A02) a particular c= ompression algorithm available by default (and required to be supported) - = deflate

Sorry to be unclear.
=A0
Instead, it still looks like an = extension just for deflate, using slightly more general language.

Yes.=A0I just factored out texts around = comp bit handling so that other extension specs can refer it.

----<= /div>

Thanks for the clarification, Gabr= iel.
--20cf3040e3bc84321404bae9a8b5-- From stpeter@stpeter.im Mon Mar 12 10:49:24 2012 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 1590B21F89D0 for ; Mon, 12 Mar 2012 10:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.716 X-Spam-Level: X-Spam-Status: No, score=-102.716 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZGNUnye15HB for ; Mon, 12 Mar 2012 10:49:23 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E86621F89CD for ; Mon, 12 Mar 2012 10:49:23 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 72FF740058 for ; Mon, 12 Mar 2012 12:01:39 -0600 (MDT) Message-ID: <4F5E3722.2030707@stpeter.im> Date: Mon, 12 Mar 2012 11:49:22 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "hybi@ietf.org" References: <20120312162130.19825.97549.idtracker@ietfa.amsl.com> In-Reply-To: <20120312162130.19825.97549.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.5 OpenPGP: url=https://stpeter.im/stpeter.asc X-Forwarded-Message-Id: <20120312162130.19825.97549.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [hybi] Fwd: I-D Action: draft-thomson-hybi-http-timeout-01.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, 12 Mar 2012 17:49:24 -0000 As seen on the i-d-announce list... -------- Original Message -------- Subject: I-D Action: draft-thomson-hybi-http-timeout-01.txt Date: Mon, 12 Mar 2012 09:21:30 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Hypertext Transfer Protocol (HTTP) Keep-Alive Header Author(s) : Martin Thomson Salvatore Loreto Greg Wilkins Filename : draft-thomson-hybi-http-timeout-01.txt Pages : 10 Date : 2012-03-12 A Keep-Alive header is defined for HTTP. This hop-by-hop header informs hosts about connection management policies. Parameters are defined for idle connection timeout and maximum request count. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-thomson-hybi-http-timeout-01.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-thomson-hybi-http-timeout-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From martin.thomson@gmail.com Mon Mar 12 11:22:25 2012 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 9C69521F8897 for ; Mon, 12 Mar 2012 11:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=-1.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OfA5AnKCmX2 for ; Mon, 12 Mar 2012 11:22:24 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 534DB21F8888 for ; Mon, 12 Mar 2012 11:22:24 -0700 (PDT) Received: by bkuw5 with SMTP id w5so3387243bku.31 for ; Mon, 12 Mar 2012 11:22:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=2I4pohiuSKLmmt4gtz4GTgMmP1aryvPGA4rffqUR3K4=; b=WPEGBO+sKDTgjHWnIZdIbt5CFq5slhjrDbwOiHH1CN+Pnhjl+R2WLw8lPuon4JTiOv UfPx7RC1XzJAuATYk5N3RIUkG0QTx/H9brOwwMTXRz1mzLbQIwPMaXaotaL/2+CByJMT lwZhGh5vXn7BkJ0JM3HekBDZoVPD5iw2LBpS6rpeFc7UhTx+4mWNUvoOEFMZxoNrpUs0 Nak21CmElCVajQ1Fv6i8HxcSzHxAxR2cA/14scPC0BV+Rv6379+d3xwVG4KIcYz67Qeh Fg70QRGTxaUJCD5TgFJM2CYwzpOfEL96AUgBegyVzyB6raJg4tIEeA9hafjCSkvlOr52 FQ8w== MIME-Version: 1.0 Received: by 10.204.154.144 with SMTP id o16mr5038177bkw.122.1331576543395; Mon, 12 Mar 2012 11:22:23 -0700 (PDT) Received: by 10.204.121.208 with HTTP; Mon, 12 Mar 2012 11:22:23 -0700 (PDT) In-Reply-To: <4F5E3722.2030707@stpeter.im> References: <20120312162130.19825.97549.idtracker@ietfa.amsl.com> <4F5E3722.2030707@stpeter.im> Date: Mon, 12 Mar 2012 11:22:23 -0700 Message-ID: From: Martin Thomson To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: I-D Action: draft-thomson-hybi-http-timeout-01.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, 12 Mar 2012 18:22:26 -0000 Thanks Peter, I was going to save the announcement until tomorrow, but some people... http://tools.ietf.org/html/draft-thomson-hybi-http-timeout-01 This version removes the Request-Timeout concept in favour of the Prefer header "wait" parameter [1]. It also attempts to revive Keep-Alive to fill the role of Connection-Timeout. Based on feedback from HTTP folks, this seems to be what fits best with their views. The guidance suggests that the baggage associated with Keep-Alive is far enough in the past to risk its reuse. One goal of this is to seek out instances where this assumption doesn't hold true. There's a newly added section that deals with the upgrade to thewebsocketprotocol, noting that the onederfool hop-by-hop nature of the header is undermined by the end-to-end nature of a thewebsocketprotocol connection. Examples included. This version was made without the input from Greg. He is on vacation, so don't be surprised if this doesn't reflect his opinion. --Martin On 12 March 2012 10:49, Peter Saint-Andre wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Hyp= ertext Transfer Protocol (HTTP) Keep-Alive Header > =C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Martin Thomso= n > =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=A0Salvatore Loreto > =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=A0Greg Wilkins > =C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-th= omson-hybi-http-timeout-01.txt > =C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 10 > =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 2012-03-12 > > =C2=A0 A Keep-Alive header is defined for HTTP. =C2=A0This hop-by-hop hea= der > =C2=A0 informs hosts about connection management policies. =C2=A0Paramete= rs are > =C2=A0 defined for idle connection timeout and maximum request count. From salvatore.loreto@ericsson.com Mon Mar 12 21:53:05 2012 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 2E55421F8900 for ; Mon, 12 Mar 2012 21:53:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.94 X-Spam-Level: X-Spam-Status: No, score=-109.94 tagged_above=-999 required=5 tests=[AWL=0.658, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-A7lqYw5tVi for ; Mon, 12 Mar 2012 21:53:04 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id A700021F88FF for ; Mon, 12 Mar 2012 21:53:03 -0700 (PDT) X-AuditID: c1b4fb39-b7bf2ae0000069a1-c2-4f5ed2ad590c Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4F.8F.27041.DA2DE5F4; Tue, 13 Mar 2012 05:53:01 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Mar 2012 05:53:01 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2E3DD2188; Tue, 13 Mar 2012 06:53:01 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 19D4B5240B; Tue, 13 Mar 2012 06:53:01 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B2BAA51E11; Tue, 13 Mar 2012 06:53:00 +0200 (EET) Message-ID: <4F5ED2AC.40807@ericsson.com> Date: Tue, 13 Mar 2012 06:53:00 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Salvatore Loreto References: <4F4C8568.7070403@ericsson.com> In-Reply-To: <4F4C8568.7070403@ericsson.com> Content-Type: multipart/alternative; boundary="------------090909050905040604090208" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" , SM , Gabriel Montenegro Subject: [hybi] Consensus on draft-tyoshino-hybi-websocket-perframe-deflate as wg item. 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: Tue, 13 Mar 2012 04:53:05 -0000 --------------090909050905040604090208 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi there, this call is now over. Thanks to all of you for the feedback and the good discussion on the topic. Based on the fact that nobody objected, Gabriel and I, as chairs, declare consensus on the adoption of the draft-tyoshino-hybi-websocket-perframe-deflate as wg item. cheers Salvatore -- Salvatore Loreto, PhD www.sloreto.com On 2/28/12 9:42 AM, Salvatore Loreto wrote: > Hi there, > > the first optimization/extension (or milestone if you prefer) > in the new approved HyBi charter (see > http://tools.ietf.org/wg/hybi/charters ) > is about: > > A per-frame compression extension to improve bandwidth > usage > > > Takeshi Yoshino has been working on a draft proposal since April 2011. > The draft has been discussed extensively in the mailing list, > it has already received comments, suggestions and feedback; > and Takeshi has produced several new versions to address the raised > issues. > > The current version is: > http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05 > > > Gabriel and I, as chairs, want to check the consensus to adopt the > draft as > baseline for the working group item that will fulfill the first Goal > in the current charter: > Feb 2012 - Adopt a WG item for the per-frame compression extension > > This consensus call will run until Monday March 12th, 2012. > > > Ciao > Salvatore and Gabriel > -- > Salvatore Loreto > www.sloreto.com > --------------090909050905040604090208 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi there,

this call is now over.
Thanks to all of you for the feedback and the good discussion on the topic.

Based on the fact that nobody objected,
Gabriel and I, as chairs, declare consensus on the adoption of the
draft-tyoshino-hybi-websocket-perframe-deflate as wg item.


cheers
Salvatore
-- 
Salvatore Loreto, PhD
www.sloreto.com

On 2/28/12 9:42 AM, Salvatore Loreto wrote:
Hi there,

the first optimization/extension (or milestone if you prefer)
in the new approved HyBi charter (see http://tools.ietf.org/wg/hybi/charters )
is about:
A per-frame compression extension to improve bandwidth
usage

Takeshi Yoshino has been working on a draft proposal since April 2011.
The draft has been discussed extensively in the mailing list,
it  has already received comments, suggestions and feedback;
and  Takeshi has produced several new versions to address the raised issues.

The current version is:
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-05


Gabriel and I, as chairs, want to check the consensus to adopt the draft as
baseline for the working group item that will fulfill the first Goal in the current charter:
  Feb 2012 - Adopt a WG item for the per-frame compression extension

This consensus call will run until Monday March 12th, 2012.


Ciao
Salvatore and Gabriel
-- 
Salvatore Loreto
www.sloreto.com




  


--------------090909050905040604090208--

From salvatore.loreto@ericsson.com  Mon Mar 12 22:07:52 2012
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 EB6FA21F88A8 for ; Mon, 12 Mar 2012 22:07:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.954
X-Spam-Level: 
X-Spam-Status: No, score=-109.954 tagged_above=-999 required=5 tests=[AWL=0.644, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rem59+Nq1cn6 for ; Mon, 12 Mar 2012 22:07:52 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 44EEA21F88A5 for ; Mon, 12 Mar 2012 22:07:39 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-55-4f5ed61a46b6
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0F.41.27041.A16DE5F4; Tue, 13 Mar 2012 06:07:38 +0100 (CET)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Tue, 13 Mar 2012 06:07:38 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 0B3462188; Tue, 13 Mar 2012 07:07:38 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EC0105240B; Tue, 13 Mar 2012 07:07:37 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 97E4A51E11; Tue, 13 Mar 2012 07:07:37 +0200 (EET)
Message-ID: <4F5ED619.4040503@ericsson.com>
Date: Tue, 13 Mar 2012 07:07:37 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "hybi@ietf.org" 
Content-Type: multipart/alternative; boundary="------------000705060503080509030505"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: Gabriel Montenegro , SM 
Subject: [hybi] Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
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: Tue, 13 Mar 2012 05:07:53 -0000

--------------000705060503080509030505
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,

the second optimization/extension (or milestone if you prefer)
in the new approved HyBi charter (see 
http://tools.ietf.org/wg/hybi/charters )
is about:

    A multiplexing extension to improve the scalability of the
    WebSocket protocol


John Tamplin has been working on a draft proposal since 2011 or even before.
The MUX issue has been largely discussed in the mailing list,
and the so far result have been included in the draft
John Tamplin and Takeshi Yoshino are now co-authoring.

The current version is:
http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03


Gabriel and I, as chairs, want to check the consensus to adopt the draft as
baseline for the working group item that will fulfill the following Goal 
in the current charter:

   Adopt a WG for the multiplexing extension


This consensus call will run until Friday March 23, 2012
(so to not overlap with the IETF83 meeting)


Ciao
Salvatore and Gabriel

-- 
Salvatore Loreto
www.sloreto.com


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


  

    
  
  
    Hi there,

    

    the second optimization/extension (or milestone if you prefer)

    in the new approved HyBi charter (see http://tools.ietf.org/wg/hybi/charters
    )

    is about:

    

      
A multiplexing extension to improve the scalability of the
WebSocket protocol

    

    

    John Tamplin has been working on a draft proposal since 2011 or even
    before.

    The MUX issue has been largely discussed in the mailing list,

    and the so far result have been included in the draft

    John Tamplin and Takeshi Yoshino are now co-authoring.

    

    The current version is:

    http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03

    

    

    Gabriel and I, as chairs, want to check the consensus to adopt the
    draft as 

    baseline for the working group item that will fulfill the following
    Goal in the current charter:

    
  Adopt a WG for the multiplexing extension

    

    This consensus call will run until Friday March 23, 2012

    (so to not overlap with the IETF83 meeting)

    

    

    Ciao 

    Salvatore and Gabriel
    
-- 
Salvatore Loreto
www.sloreto.com

  


--------------000705060503080509030505--

From salvatore.loreto@ericsson.com  Tue Mar 13 00:33:48 2012
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 D321C21F8793 for ; Tue, 13 Mar 2012 00:33:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.968
X-Spam-Level: 
X-Spam-Status: No, score=-109.968 tagged_above=-999 required=5 tests=[AWL=0.630, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I72H8igjtAja for ; Tue, 13 Mar 2012 00:33:47 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 018A521F87DC for ; Tue, 13 Mar 2012 00:33:46 -0700 (PDT)
X-AuditID: c1b4fb39-b7bf2ae0000069a1-a9-4f5ef8590486
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BC.66.27041.958FE5F4; Tue, 13 Mar 2012 08:33:45 +0100 (CET)
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.213.0; Tue, 13 Mar 2012 08:33:45 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id 24F652188; Tue, 13 Mar 2012 09:33:45 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0C69A523A8; Tue, 13 Mar 2012 09:33:45 +0200 (EET)
Received: from n106.nomadiclab.com (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B065B514D3; Tue, 13 Mar 2012 09:33:44 +0200 (EET)
Message-ID: <4F5EF858.3030603@ericsson.com>
Date: Tue, 13 Mar 2012 09:33:44 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "hybi@ietf.org" 
Content-Type: multipart/alternative; boundary="------------070505010408060303090001"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: AAAAAA==
Cc: Gabriel Montenegro , SM 
Subject: [hybi] Agenda for IETF83 meeting
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: Tue, 13 Mar 2012 07:33:48 -0000

--------------070505010408060303090001
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

Hi there,

I have uploaded the first draft of the Agenda to the IETF website
(see http://www.ietf.org/proceedings/83/agenda/agenda-83-hybi.txt )

   WEDNESDAY, March 28, 2012
   1300-1500 Afternoon Session I
   room 252B


   -  Administrative / Agenda bash                                (Chairs, 10')

   -  New Charter overview					 (Chairs, 10')

   -  PerFrame Deflate draft					 (Takeshi, 30')
      draft-tyoshino-hybi-websocket-perframe-deflate-06.txt

   -  Multiplex draft                                             (Takeshi, 45')
      draft-tamplin-hybi-google-mux-03.txt

   -  Timeout proposal						 (Martin, 15')
      draft-thomson-hybi-http-timeout-01.txt

   -  Open discussion (e.g. subprotocols)                         (all, as time allows)



If you think I have missed something, or you want some Agenda time to 
discuss some specific item
please send an email directly to Gabriel and myself

best regards
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


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


  

    
  
  
    Hi there,

    

    I have uploaded the first draft of the Agenda to the IETF website

    (see http://www.ietf.org/proceedings/83/agenda/agenda-83-hybi.txt )

    

    
    
  WEDNESDAY, March 28, 2012
  1300-1500 Afternoon Session I
  room 252B


  -  Administrative / Agenda bash                                (Chairs, 10')

  -  New Charter overview					 (Chairs, 10')

  -  PerFrame Deflate draft					 (Takeshi, 30')
     draft-tyoshino-hybi-websocket-perframe-deflate-06.txt

  -  Multiplex draft                                             (Takeshi, 45')
     draft-tamplin-hybi-google-mux-03.txt

  -  Timeout proposal						 (Martin, 15')
     draft-thomson-hybi-http-timeout-01.txt

  -  Open discussion (e.g. subprotocols)                         (all, as time allows)



    

    If you think I have missed something, or you want some Agenda time
    to discuss some specific item

    please send an email directly to Gabriel and myself 

    

    best regards

    Salvatore

    
-- 
Salvatore Loreto, PhD
www.sloreto.com

  


--------------070505010408060303090001--

From jat@google.com  Tue Mar 13 07:23:41 2012
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 65D1121F8707 for ; Tue, 13 Mar 2012 07:23:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WgKsaHrhz1d for ; Tue, 13 Mar 2012 07:23:41 -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 D1DA721F86F9 for ; Tue, 13 Mar 2012 07:23:40 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so838287vcb.31 for ; Tue, 13 Mar 2012 07:23:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vRJ5CdaKvnTpIv1psVo5XRVEtIA2dNS7iBFn7eUQQss=; b=HewwbBoLo6t5TGSCLaFmixoVvS5cnSu/ZB7RJ607ITyqV+rq0Lu7qcQNaBB7ZBOFvM E4sJ3JwkRzM3L7JvvpVX7Tr1yAVj0Dy6OOSZvZmsR5iHy+DNtYPBwEmq1yhwi8r76R8h L+BHDlBiXLyfNhqpvNvJKmSSWcIMRTQQYq2G+9ZV6K6bhUH72AQUmplTnwyFhmyd+Djp jfpeoU6NUl8wby9mL5sW2uMoz5jEl2n6Rqv5JkEkPDtk4IE+BaR7nFrO+peILGITfZTm lW8Hn2nwtV3pl9C3YkjjsK8pE/yFpJ9RhpJrrXjJsHh3DPzQIorvFhScLdLNs8dyBtJR ySSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=vRJ5CdaKvnTpIv1psVo5XRVEtIA2dNS7iBFn7eUQQss=; b=mSa8dBbPJvs8mtr3rbCefhjHwq1ayRZaBf/+WrSYOlPaWkeVlfxveM7iXF9Wr6gD6V y140xdass1U0TgTEmzZIBGFsat0bCxtuns3M7t/nVjDKnJ5C9UAbRCSuytpioWZcCejW 8ZeIy0K3jDeCbVeEu/cfNxrhd9K0ZkxaS5NJnf540Nf1S/wU7axwG2gq/WPoIsDIKAFq +Q+UhUBiadvvP/ZxFhVTAFezeScfpOFWAIJSU0neW6DlRDXJ649ohHRvtt96RGVNsYhm +8UVr2mjSQ18APlE2JiBSJ5ZIP1a12iP9LotlbdF3kY9kz2wzrsjhyH0goVX7XeZ0WFd 8cbg==
Received: by 10.52.38.102 with SMTP id f6mr17375191vdk.70.1331648620367; Tue, 13 Mar 2012 07:23:40 -0700 (PDT)
Received: by 10.52.38.102 with SMTP id f6mr17375184vdk.70.1331648620291; Tue, 13 Mar 2012 07:23:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.134.207 with HTTP; Tue, 13 Mar 2012 07:23:20 -0700 (PDT)
In-Reply-To: <4F5ED619.4040503@ericsson.com>
References: <4F5ED619.4040503@ericsson.com>
From: John Tamplin 
Date: Tue, 13 Mar 2012 10:23:20 -0400
Message-ID: 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=bcaec51d20d8fa682504bb209a9c
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmYqLqIqshmHhJWxjw+qEjVO+9cFlBpw2K1goqg3qQHP5JH52BA9ElyaFCyMdXB0IKP3IIac8vEWf013mIwD2K68xEpkC4yBfdODuaGpd+2a9+EkV34QdP7x4SRhtWux2LvmKYb
Cc: "hybi@ietf.org" , SM , Gabriel Montenegro 
Subject: Re: [hybi] Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
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: Tue, 13 Mar 2012 14:23:41 -0000

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

On Tue, Mar 13, 2012 at 1:07 AM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

> Gabriel and I, as chairs, want to check the consensus to adopt the draft
> as
> baseline for the working group item that will fulfill the following Goal
> in the current charter:
>
>   Adopt a WG for the multiplexing extension
>
>
> This consensus call will run until Friday March 23, 2012
> (so to not overlap with the IETF83 meeting)
>

In case there was any doubt, +1 :).

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Tue, Mar 13, 2012 at 1:07 AM, Salvatore Loret=
o <sa=
lvatore.loreto@ericsson.com> wrote:



 =20

   =20
 =20
  
Gabriel and I, as chairs, want =
to check the consensus to adopt the
    draft as 

    baseline for the working group item that will fulfill the following
    Goal in the current charter:

    
  Adopt a WG for the multiplexing extension

    

    This consensus call will run until Friday March 23, 2012

    (so to not overlap with the IETF83 meeting)
=

In case there was any doubt, +1 :).=C2=A0
-- 
John A. Tamplin
Software Engineer (GWT), Google


--bcaec51d20d8fa682504bb209a9c--

From jat@google.com  Tue Mar 13 07:29:32 2012
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 9722721F87B3 for ; Tue, 13 Mar 2012 07:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EnEXr+8Q3Kk for ; Tue, 13 Mar 2012 07:29:32 -0700 (PDT)
Received: from mail-fa0-f44.google.com (mail-fa0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id A486421F87AF for ; Tue, 13 Mar 2012 07:29:31 -0700 (PDT)
Received: by faaa25 with SMTP id a25so81959faa.31 for ; Tue, 13 Mar 2012 07:29:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=B6kLfO6Mj1gXoWJ2/sHGg0ZtGwcGGYAJ/S7ekYchOpk=; b=YkD/iDMIcfjDRI1tQ4tDMN0Pnocx2I4IArulwNoxsjRNmV9VQpH9vHANAMaVnvqP1H xwPtbWGiFfsU8tsu10/qiwEztK95/HJ8yty7t+yDSNsj5+pfUts+X5ybuQl+/DK5Lp44 pPffgvf2FD5dPTl3whI9ldSxNm/xXqG5JUUHWh38XEfuh5qih70zhQ4rWxuIoEpV3fLV awYxW18EQu1W1tGDd/3+D0AfhmcThm8pklUaS0JH/fF9dp3W8loKtmx6gFg5uryDPcpj KCgNe2+VBmWxBILzSEIkm2OON+koxQkIiN4Q0RuvDeZ2D9ScDttxOsBrMgqh4Nn3c+v0 Y7HQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=B6kLfO6Mj1gXoWJ2/sHGg0ZtGwcGGYAJ/S7ekYchOpk=; b=NBUyu1YvQQ2GbibxDxoeTbm+jUeZDcGVB/o/aFqVrtmOsbXiz6s7Hg/biSrGdtrGdr 1bI7nkphrfFmZhafSkKXtL4zIb+K0POq0np7SMUjJ32IAiT5jj3jFeVKG22BVjGgKJAg 6jfK7ExbKNc7oMXMckpIKQEpX6RxFuuXiiBT52Opze/hRFidgh1fNh/kSwPRZ+S4d77N UShm8ZMSRn7UTtQdzoWR7BLint1Rj+ExIhSiOeZCcom47UWRyIcAiHKuL+moemL9HtI8 rrreT4cq0+osjvFdf2NEThiGHDtspvVxi8mh3GCLALmcTZA2zekqWmf/6aFVyGLDHEGu 0Phg==
Received: by 10.52.28.178 with SMTP id c18mr17428852vdh.45.1331648968445; Tue, 13 Mar 2012 07:29:28 -0700 (PDT)
Received: by 10.52.28.178 with SMTP id c18mr17428840vdh.45.1331648968251; Tue, 13 Mar 2012 07:29:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.134.207 with HTTP; Tue, 13 Mar 2012 07:29:07 -0700 (PDT)
In-Reply-To: 
References:    
From: John Tamplin 
Date: Tue, 13 Mar 2012 10:29:07 -0400
Message-ID: 
To: Takeshi Yoshino 
Content-Type: multipart/alternative; boundary=20cf307ac3f3b7d7e204bb20affc
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlNeTYLF7SUnJ8BmKN4NPhpKuifqMdiB0EdFsmPd0DMaaT4gcb2AUyVTrpd0ARw6+XvrxV+PiRZqqAH+kjXjOZsdumaHy9BCHASThBiAF8HgE5QMKKvaaSlegZ/tg06PBpaDZrg
Cc: "hybi@ietf.org" , Gabriel Montenegro 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Tue, 13 Mar 2012 14:29:32 -0000

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

On Sat, Mar 10, 2012 at 3:50 PM, Takeshi Yoshino wrote:

> Yes. I just factored out texts around comp bit handling so that other
> extension specs can refer it.
>

Ok, could we get input from others on this?  Do we want something like this
document which defines only the per-frame deflate compression extension,
and any new per-frame compression algorithms would require their own
extension?  Or would we prefer to have a generic per-frame compression
extension, which allows negotiation of the compression algorithm and
parameters while mandating required support for the deflate algorithm as
proposed?

To me, the proposed deflate algorithm falls into the "better than nothing"
category, and really requires some way of detecting incompressible content
since otherwise it could increase the size.  Maintaining compression state
across frames for the most part mitigates that concern, as pretty much
anything except already compressed content will show improvement.  Also, I
expect state of the art for compression to improve over time (both new
algorithms and faster hardware making existing algorithms feasible) so I
expect we will want to support multiple compression algorithms.  For this
reason, I would prefer a more generic and extensible per-frame compression
extension.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Sat, Mar 10, 2012 at 3:50 PM, Takeshi Yoshino=
 <tyoshino@goog=
le.com> wrote:



Yes.=C2=A0I just factored out texts around comp =
bit handling so that other extension specs can refer it.
=


Ok, could we get input from others on this? =C2=A0Do w=
e want something like this document which defines only the per-frame deflat=
e compression extension, and any new per-frame compression algorithms would=
 require their own extension? =C2=A0Or would we prefer to have a generic pe=
r-frame compression extension, which allows negotiation of the compression =
algorithm and parameters while mandating required support for the deflate a=
lgorithm as proposed?



To me, the proposed deflate algorithm falls into the "b=
etter than nothing" category, and really requires some way of detectin=
g incompressible content since otherwise it could increase the size. =C2=A0=
Maintaining compression state across frames for the most part mitigates tha=
t concern, as pretty much anything except already compressed content will s=
how improvement. =C2=A0Also, I expect state of the art for compression to i=
mprove over time (both new algorithms and faster hardware making existing a=
lgorithms feasible) so I expect we will want to support multiple compressio=
n algorithms. =C2=A0For this reason, I would prefer a more generic and exte=
nsible per-frame compression extension.




-- 
John A. Tamplin
Software Engineer (GWT), Google



--20cf307ac3f3b7d7e204bb20affc--

From arman@noemax.com  Tue Mar 13 09:08:37 2012
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 E0BB821F88F0 for ; Tue, 13 Mar 2012 09:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level: 
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.372,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPfnwaTa2pVq for ; Tue, 13 Mar 2012 09:08:37 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 85F9721F88E9 for ; Tue, 13 Mar 2012 09:08:36 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id XTV83035; Tue, 13 Mar 2012 18:08:35 +0200
From: "Arman Djusupov" 
To: "'John Tamplin'" , "'Takeshi Yoshino'" 
References: 			 
In-Reply-To: 
Date: Tue, 13 Mar 2012 18:08:28 +0200
Message-ID: <007701cd0133$8cf4dd70$a6de9850$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0078_01CD0144.50801E70"
X-Mailer: Microsoft Outlook 14.0
thread-index: AQEFf2crWbrct+xTc1bODTMkU5A6FAGBA42bAdhteGgAc2U4agHWpgNgl8pLqYA=
Content-Language: en-us
Cc: hybi@ietf.org, 'Gabriel Montenegro' 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Tue, 13 Mar 2012 16:08:38 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0078_01CD0144.50801E70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

The spec in the current state does not cover any methods other than the =
specific deflate-frame extension. Yes there are other compression =
methods available and there are alternative ways to apply the same =
DEFLATE compression method, for example flush sync can be used at the =
boundaries of the message rather than at frame boundary. But I=E2=80=99m =
not sure if the specification can define how to detect incompressible =
content, such functionality can/should be implementation specific. =
Sometimes even if the data appears to be incompressible it makes sense =
to include it into the sliding window and there is a chance it will =
produce matches with subsequent data. In general DEFLATE does not =
usually inflate frames by much, unless they are totally incompressible =
and extremely small.

=20

I was thinking more about a specification that would define the way =
compression extensions are to be applied and reserves the RSV1 bit as =
compression flag for all extensions. In terms of negotiation, we already =
have a way to negotiate the compression method when the extension is =
being negotiated. As long as each compression method has its own =
extension name the WebSocket handshake will negotiate it anyway. =
Extensions can be named deflate-frame, bzip2-message, =
deflate-message-stateful and so on. What spec has to offer is some =
standard way of using those extensions. e.g. define that =
=E2=80=9Ccompression is applied on payload prior masking=E2=80=9D, =
=E2=80=9Cframe header is not compressed=E2=80=9D and so on. Then all new =
compression extension specs would be able to reference the common =
specification defining the general principles on how it=E2=80=99s =
applied and negotiated, but each of them could have a different name and =
use a different compression method.

=20

With best regards,

Arman

=20

=20

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of =
John Tamplin
Sent: Tuesday, March 13, 2012 4:29 PM
To: Takeshi Yoshino
Cc: hybi@ietf.org; Gabriel Montenegro
Subject: Re: [hybi] Per-frame compression spec draft 06

=20

On Sat, Mar 10, 2012 at 3:50 PM, Takeshi Yoshino  =
wrote:

Yes. I just factored out texts around comp bit handling so that other =
extension specs can refer it.

=20

Ok, could we get input from others on this?  Do we want something like =
this document which defines only the per-frame deflate compression =
extension, and any new per-frame compression algorithms would require =
their own extension?  Or would we prefer to have a generic per-frame =
compression extension, which allows negotiation of the compression =
algorithm and parameters while mandating required support for the =
deflate algorithm as proposed?

=20

To me, the proposed deflate algorithm falls into the "better than =
nothing" category, and really requires some way of detecting =
incompressible content since otherwise it could increase the size.  =
Maintaining compression state across frames for the most part mitigates =
that concern, as pretty much anything except already compressed content =
will show improvement.  Also, I expect state of the art for compression =
to improve over time (both new algorithms and faster hardware making =
existing algorithms feasible) so I expect we will want to support =
multiple compression algorithms.  For this reason, I would prefer a more =
generic and extensible per-frame compression extension.


=20

--=20
John A. Tamplin
Software Engineer (GWT), Google


------=_NextPart_000_0078_01CD0144.50801E70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


The =
spec in the current state does not cover any methods other than the =
specific deflate-frame extension. Yes there are other compression =
methods available and there are alternative ways to apply the same =
DEFLATE compression method, for example flush sync can be used at the =
boundaries of the message rather than at frame boundary. But I=E2=80=99m =
not sure if the specification can define how to detect incompressible =
content, such functionality can/should be implementation specific. =
Sometimes even if the data appears to be incompressible it makes sense =
to include it into the sliding window and there is a chance it will =
produce matches with subsequent data. In general DEFLATE does not =
usually inflate frames by much, unless they are totally incompressible =
and extremely small.
 
I was =
thinking more about a specification that would define the way =
compression extensions are to be applied and reserves the RSV1 bit as =
compression flag for all extensions. In terms of negotiation, we already =
have a way to negotiate the compression method when the extension is =
being negotiated. As long as each compression method has its own =
extension name the WebSocket handshake will negotiate it anyway. =
Extensions can be named deflate-frame, bzip2-message, =
deflate-message-stateful and so on. What spec has to offer is some =
standard way of using those extensions. e.g. define that =
=E2=80=9Ccompression is applied on payload prior masking=E2=80=9D, =
=E2=80=9Cframe header is not compressed=E2=80=9D and so on. Then all new =
compression extension specs would be able to reference the common =
specification defining the general principles on how it=E2=80=99s =
applied and negotiated, but each of them could have a different name and =
use a different compression method.
 
With =
best regards,
Arman
 
 
From:=
 =
hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of =
John Tamplin
Sent: Tuesday, March 13, 2012 4:29 =
PM
To: Takeshi Yoshino
Cc: hybi@ietf.org; Gabriel =
Montenegro
Subject: Re: [hybi] Per-frame compression spec =
draft 06
 
On Sat, =
Mar 10, 2012 at 3:50 PM, Takeshi Yoshino <tyoshino@google.com> =
wrote:
Yes. I just factored =
out texts around comp bit handling so that other extension specs can =
refer it.
 
Ok, =
could we get input from others on this?  Do we want something like =
this document which defines only the per-frame deflate compression =
extension, and any new per-frame compression algorithms would require =
their own extension?  Or would we prefer to have a generic =
per-frame compression extension, which allows negotiation of the =
compression algorithm and parameters while mandating required support =
for the deflate algorithm as proposed?
 
To me, the proposed deflate algorithm falls into the =
"better than nothing" category, and really requires some way =
of detecting incompressible content since otherwise it could increase =
the size.  Maintaining compression state across frames for the most =
part mitigates that concern, as pretty much anything except already =
compressed content will show improvement.  Also, I expect state of =
the art for compression to improve over time (both new algorithms and =
faster hardware making existing algorithms feasible) so I expect we will =
want to support multiple compression algorithms.  For this reason, =
I would prefer a more generic and extensible per-frame compression =
extension.
 
-- =

John A. Tamplin
Software Engineer (GWT), =
Google

------=_NextPart_000_0078_01CD0144.50801E70--


From jat@google.com  Tue Mar 13 09:19:59 2012
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 795F421F86EA for ; Tue, 13 Mar 2012 09:19:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vGwGytoZNtc for ; Tue, 13 Mar 2012 09:19:53 -0700 (PDT)
Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5C21F86A6 for ; Tue, 13 Mar 2012 09:19:53 -0700 (PDT)
Received: by eeke51 with SMTP id e51so418760eek.31 for ; Tue, 13 Mar 2012 09:19:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=wS2emMfGskY2fWD7cExXRQY6fIdIUKN70dK8KM9HXe4=; b=mrfxTbxhlaN7n4RN3/di11KiHnZ9+0ggVv+1j7/q+Hv4a9Ed8f9pGtx1tjB33p4p2x 0IHydFLRpugSYY8Ia0+xpxdwxHCGNX1cgoJ90nGgcX3XILS0WEdL5TcGG/MJO+Bj5BOC fbU7ICb35/3A0zuXr4pnj3zSGC8FCM45OFG/gz8wz7pIG7ia+lOiuzU+2FoGo8QziJd/ Syho4iQvNtdMpe6Y8lALxyzuFYg8DZeXxVJk7ecGZKczp87mgSgIfgZpFXQmopzHp2Ec nqOFyynu3+iYMhONCh3LiaeXRUn/OJVNoYRxf/KepHv51lcweWlxFpyzNJEh91oCEeBe BB/A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=wS2emMfGskY2fWD7cExXRQY6fIdIUKN70dK8KM9HXe4=; b=eKaWF8oFt7a+190ccT0XW55eOF/sEU9GfIzGM9bFjMbZ9n9h/NmYNYifsOhFV+Jsoq FH/IugVET45JW5AT8YntTXgq/151cjfmdd55pNAMnnBFSZTp7a0Kb/vMPE2o8hgoENVf 7YnhORqtPcVbqlBnoQWVRsHQtq6QG45cer3Dfo45lnKf0bgArBAJSjufgMvE1l3PeGLy VbNaKVCA6RQkUu31vklFOE5BMk3DPzfgVlhYw92DSU/oC0nS7dquvQhIQ7c41ZKggeJk U1YJxPbg8RIwjioThci+cycuXoStzSX/SPnh7RaYTLVM+r3OyzWv81bBZFKE/H/3tmZu ljsQ==
Received: by 10.52.29.244 with SMTP id n20mr18205676vdh.22.1331655591758; Tue, 13 Mar 2012 09:19:51 -0700 (PDT)
Received: by 10.52.29.244 with SMTP id n20mr18205666vdh.22.1331655591672; Tue, 13 Mar 2012 09:19:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.134.207 with HTTP; Tue, 13 Mar 2012 09:19:31 -0700 (PDT)
In-Reply-To: <007701cd0133$8cf4dd70$a6de9850$@noemax.com>
References:      <007701cd0133$8cf4dd70$a6de9850$@noemax.com>
From: John Tamplin 
Date: Tue, 13 Mar 2012 12:19:31 -0400
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf307f348c813bda04bb223a90
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlDHPA45nsAtPXmGhFMmfNDoVtBr6J+I7cCpFR3SXgfk1BK52Ig/rQVbxJX+A44zLToMNGVSsWuMtL0aw9PoWYQJjBxp+333LOZ/B9duEezbBMZv8wLVomyWbah6avgVjH4lqKS
Cc: hybi@ietf.org, Gabriel Montenegro 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Tue, 13 Mar 2012 16:19:59 -0000

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

On Tue, Mar 13, 2012 at 12:08 PM, Arman Djusupov  wrote:

> I was thinking more about a specification that would define the way
> compression extensions are to be applied and reserves the RSV1 bit as
> compression flag for all extensions. In terms of negotiation, we already
> have a way to negotiate the compression method when the extension is bein=
g
> negotiated. As long as each compression method has its own extension name
> the WebSocket handshake will negotiate it anyway. Extensions can be named
> deflate-frame, bzip2-message, deflate-message-stateful and so on. What sp=
ec
> has to offer is some standard way of using those extensions. e.g. define
> that =E2=80=9Ccompression is applied on payload prior masking=E2=80=9D, =
=E2=80=9Cframe header is
> not compressed=E2=80=9D and so on. Then all new compression extension spe=
cs would
> be able to reference the common specification defining the general
> principles on how it=E2=80=99s applied and negotiated, but each of them c=
ould have
> a different name and use a different compression method.
>
**
>
One complication of using treating each compression algorithm as a separate
WS extension is how do you negotiate exactly one of them?  Sure, you can
define the extensions as mutually incompatible, but that could complicate
server implementations to have to keep track of which ones use the same bit=
.

I also think it makes clearer specs to separate the mechanism of per-frame
compression from which algorithm to use.

--=20
John A. Tamplin
Software Engineer (GWT), Google

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


On Tue, Mar 13, 2012 at 12:08 PM, Arman Djusupov=
 <arman@noemax.com=
> wrote:



I was thinking m=
ore about a specification that would define the way compression extensions =
are to be applied and reserves the RSV1 bit as compression flag for all ext=
ensions. In terms of negotiation, we already have a way to negotiate the co=
mpression method when the extension is being negotiated. As long as each co=
mpression method has its own extension name the WebSocket handshake will ne=
gotiate it anyway. Extensions can be named deflate-frame, bzip2-message, de=
flate-message-stateful and so on. What spec has to offer is some standard w=
ay of using those extensions. e.g. define that =E2=80=9Ccompression is appl=
ied on payload prior masking=E2=80=9D, =E2=80=9Cframe header is not compres=
sed=E2=80=9D and so on. Then all new compression extension specs would be a=
ble to reference the common specification defining the general principles o=
n how it=E2=80=99s applied and negotiated, but each of them could have a di=
fferent name and use a different compression method.



One complication of using treating each compression algorithm as a separat=
e WS extension is how do you negotiate exactly one of them? =C2=A0Sure, you=
 can define the extensions as mutually incompatible, but that could complic=
ate server implementations to have to keep track of which ones use the same=
 bit.




I also think it makes clearer specs to separate the mec=
hanism of per-frame compression from which algorithm to use.

=

-- 
John A. Tamplin
Software Engineer (GWT), Google


--20cf307f348c813bda04bb223a90--

From fenix@google.com  Tue Mar 13 10:38:02 2012
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 DFFD721F8707 for ; Tue, 13 Mar 2012 10:38:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.476
X-Spam-Level: 
X-Spam-Status: No, score=-106.476 tagged_above=-999 required=5 tests=[AWL=-3.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8-lASKxdK+N for ; Tue, 13 Mar 2012 10:38:01 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8707021F8705 for ; Tue, 13 Mar 2012 10:38:00 -0700 (PDT)
Received: by lagj5 with SMTP id j5so833445lag.31 for ; Tue, 13 Mar 2012 10:37:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=p//L7veoNkgB85G1vxFw1o7Sot/lwnjEaA/gpSGKKrg=; b=jYBzJttxK7ql9XfsWmH6IMu4j5V0KK9KcbmKyF7EFLkX4QcnufgBMyvrHOVOgWuaRw YHHz5qSPwYUEhOw+ZaQA9lxSynefSNldbRM/1MW6MVkwUnD0YzM6kiSHzHMWbxU7Ut6B IG6bKXHKytJd+lfVqlHz7jpKztn9jwh7Pu1AdYI5QyXCSFnD6eaej2a+l076MNtJY2Ts 3S53Cq3WyhyrYRlvdiH3pzGpk5BW+5Jj+7AxCrNSilpi1nloD/h5Mkvwn6qNARkJlrZg ec/8b/ivIIj5JQjDPoJySCoNuV5wBY7KjBIBodmWmuY+NUeNxKVnX9SnOHqfy2nA3ZzT cpwA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=p//L7veoNkgB85G1vxFw1o7Sot/lwnjEaA/gpSGKKrg=; b=dKwRGqofhAlizOsYkmW5XYCzyOb2WjBY+0Nbfx6yMDMXojmgOd2XBK/7+lpqYuT1Bx 2DTlUdUgp8O1eEUyHSLUB63X+/wJBMwNl5CeThvcWajMvXbOZ36A1w8Aa73/k81pTtFN h0RrnwBubEtnOtG2iwB5zNBw1A0A+EUeOsmnIardlmQwqWbwOAmejeYLOpX/nnucpONn DX1Weyx9VqtuizBa7vMyhVH87/xlYi36Y6cFN/dfS/hK0b7R1zSq/aKQrsjwLmLbAUaO JLI3nzjsRoRv3k4/qwRwxorRx7YC+DKlnznRCGJ5tIutKQ2/gewAcfWu5cI3vHxo2R0V /9NA==
Received: by 10.152.146.163 with SMTP id td3mr12879044lab.31.1331660279403; Tue, 13 Mar 2012 10:37:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.146.163 with SMTP id td3mr12879029lab.31.1331660279257; Tue, 13 Mar 2012 10:37:59 -0700 (PDT)
Received: by 10.112.20.137 with HTTP; Tue, 13 Mar 2012 10:37:59 -0700 (PDT)
Received: by 10.112.20.137 with HTTP; Tue, 13 Mar 2012 10:37:59 -0700 (PDT)
In-Reply-To: 
References: <4F5ED619.4040503@ericsson.com> 
Date: Tue, 13 Mar 2012 10:37:59 -0700
Message-ID: 
From: Roberto Peon 
To: John Tamplin 
Content-Type: multipart/alternative; boundary=e89a8f234567e81c3704bb23514e
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmygT+dqthdMV++s26WASbkiPEKvrh3Mamw5k4OLCeUFwZx3C2ODdp1wGY9yjhM/2yVA/CmH28afi+JAXVBz2rtfXWW+8n3x5lZWEGIe0lxLuXyM5bqNyT6blttA3zd2tsLgoLz
Cc: hybi@ietf.org, SM , Gabriel Montenegro 
Subject: Re: [hybi] Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
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: Tue, 13 Mar 2012 17:38:02 -0000

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

+1
On Mar 13, 2012 7:23 AM, "John Tamplin"  wrote:

> On Tue, Mar 13, 2012 at 1:07 AM, Salvatore Loreto <
> salvatore.loreto@ericsson.com> wrote:
>
>> Gabriel and I, as chairs, want to check the consensus to adopt the draft
>> as
>> baseline for the working group item that will fulfill the following Goal
>> in the current charter:
>>
>>   Adopt a WG for the multiplexing extension
>>
>>
>> This consensus call will run until Friday March 23, 2012
>> (so to not overlap with the IETF83 meeting)
>>
>
> In case there was any doubt, +1 :).
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

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


+1


On Mar 13, 2012 7:23 AM, "John Tamplin"=
; <jat@google.com> wrote:


On Tue, Mar 13, 2012 at 1:07 AM, Salvatore Loret=
o <salvatore.loreto@ericsson.com> wrote:




 =20

   =20
 =20
  
Gabriel and I, as chairs, want =
to check the consensus to adopt the
    draft as 

    baseline for the working group item that will fulfill the following
    Goal in the current charter:

    
  Adopt a WG for the multiplexing extension

    

    This consensus call will run until Friday March 23, 2012

    (so to not overlap with the IETF83 meeting)
=

In case there was any doubt, +1 :).=A0

<=
/div>-- 
John A. Tamplin
Software Engineer (GWT), Google


_______________________________________________

hybi mailing list

hybi@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/hybi




--e89a8f234567e81c3704bb23514e--

From jesse.mcconnell@gmail.com  Tue Mar 13 13:30:28 2012
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 7670221F8690 for ; Tue, 13 Mar 2012 13:30:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iRh+9ZavfKzR for ; Tue, 13 Mar 2012 13:30:26 -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 4C7A021F8688 for ; Tue, 13 Mar 2012 13:30:26 -0700 (PDT)
Received: by eaaq11 with SMTP id q11so678330eaa.31 for ; Tue, 13 Mar 2012 13:30:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yFMz+ktSKjpsETBXCfxgZSOg4qadhSC8FWv/Pc5e8sY=; b=ci62muDimgNDTCNEEG4w03vkXx2UBtD/fYhfUuUIB2+HVMRGqiuYiCX4N2C6hzGbNB MJ/drZIbIBQMYMabcWBj2yNmjqboJKeEUB9uZzey0+uwmQSbfDBoESU3sdR3Ijc2kdaa TUJPzxZXMjMUITryJr9gs2UGVZORpAuv9mWZYtUZvQJXsiAaiPzBBxBDSYgm6k0jP0at jJ2tidB2qYiq/THTT24O2/fRp+dSweb/fUQxtSxy73WvEx/7vnjDiBXJqEnQTAMeglg0 ekGkKDhEOJYfaeiK+w1Ya3n/uK5feIEv4cuIIWylPUBibc882eMjBpvEshY9aHjxeHs3 wJdw==
MIME-Version: 1.0
Received: by 10.229.136.10 with SMTP id p10mr4450238qct.46.1331670624244; Tue, 13 Mar 2012 13:30:24 -0700 (PDT)
Received: by 10.229.50.73 with HTTP; Tue, 13 Mar 2012 13:30:24 -0700 (PDT)
In-Reply-To: <4F5ED619.4040503@ericsson.com>
References: <4F5ED619.4040503@ericsson.com>
Date: Tue, 13 Mar 2012 15:30:24 -0500
Message-ID: 
From: Jesse McConnell 
To: Salvatore Loreto 
Content-Type: text/plain; charset=UTF-8
Cc: "hybi@ietf.org" , SM , Gabriel Montenegro 
Subject: Re: [hybi] Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
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: Tue, 13 Mar 2012 20:30:28 -0000

+1, looking forward to seeing it discussed and finalized

--
jesse mcconnell
jesse.mcconnell@gmail.com



On Tue, Mar 13, 2012 at 00:07, Salvatore Loreto
 wrote:
> Hi there,
>
> the second optimization/extension (or milestone if you prefer)
> in the new approved HyBi charter (see http://tools.ietf.org/wg/hybi/charters
> )
> is about:
>
> A multiplexing extension to improve the scalability of the
> WebSocket protocol
>
>
> John Tamplin has been working on a draft proposal since 2011 or even before.
> The MUX issue has been largely discussed in the mailing list,
> and the so far result have been included in the draft
> John Tamplin and Takeshi Yoshino are now co-authoring.
>
> The current version is:
> http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03
>
>
> Gabriel and I, as chairs, want to check the consensus to adopt the draft as
> baseline for the working group item that will fulfill the following Goal in
> the current charter:
>
>   Adopt a WG for the multiplexing extension
>
>
> This consensus call will run until Friday March 23, 2012
> (so to not overlap with the IETF83 meeting)
>
>
> Ciao
> Salvatore and Gabriel
>
> --
> Salvatore Loreto
> www.sloreto.com
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

From gregw@intalio.com  Tue Mar 13 18:19:58 2012
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 8A89C21F859B for ; Tue, 13 Mar 2012 18:19:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.791
X-Spam-Level: 
X-Spam-Status: No, score=-2.791 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+LgZ4XeahBK for ; Tue, 13 Mar 2012 18:19:58 -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 078F421F8598 for ; Tue, 13 Mar 2012 18:19:57 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so1431500yhp.31 for ; Tue, 13 Mar 2012 18:19:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=lPUsbQGp3otfmbt4c0J+U7NUjmUgLLrHRdJqvQ10tHQ=; b=j2zNy1IN0b3iGxKije71uMkbwS5RJVLiaIbYfPAgIUquQVyRauiRSTlkQrqcmUUSwm m773hRcsOGNN4bUjxipTxZiIHaA2UZZvrcDyvg/e/vbOeOiNx49wambtYkcNFJPt5owE CCBxFV61c+qeC9UOqIh6cbKkiytYctAkJYNL1DYgK3IixTt8Up4SfQ1uzO449pf4FU5N PCMjrT+2M51U+VXjBBmUYSbCUlU5tmd1mROod5CuZMBLUkzVXIpu1wS2DtRPKjwDlxzq AiwaI2HiDTxjgt0DDkJ2SEpOygfP2bFjgEluAhmQiC678oNG9slEZKdInfwYlkuNv/3S F+3A==
MIME-Version: 1.0
Received: by 10.224.116.18 with SMTP id k18mr1156306qaq.14.1331687997517; Tue, 13 Mar 2012 18:19:57 -0700 (PDT)
Received: by 10.229.54.12 with HTTP; Tue, 13 Mar 2012 18:19:57 -0700 (PDT)
In-Reply-To: 
References: <4F5ED619.4040503@ericsson.com> 
Date: Wed, 14 Mar 2012 12:19:57 +1100
Message-ID: 
From: Greg Wilkins 
To: Jesse McConnell 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQmZof/ceTCW6lmoSRXua/VjrUCCP9MCZSQToEa6jKY7ufUtOxGB2Q7P+Ykxf57ItppRvzAa
Cc: "hybi@ietf.org" , SM , Gabriel Montenegro 
Subject: Re: [hybi] Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
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: Wed, 14 Mar 2012 01:19:58 -0000

+1

hoping to have implementation in jetty soon.

From tyoshino@google.com  Tue Mar 13 22:36:06 2012
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 CD7C821F85EA for ; Tue, 13 Mar 2012 22:36:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.958
X-Spam-Level: 
X-Spam-Status: No, score=-102.958 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B79UHY2Lb1eg for ; Tue, 13 Mar 2012 22:36:06 -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 0ED2921F85EC for ; Tue, 13 Mar 2012 22:36:05 -0700 (PDT)
Received: by yhpp34 with SMTP id p34so1604026yhp.31 for ; Tue, 13 Mar 2012 22:36:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=55ePfvq2ogrGpO2ltoYovHrYSXRMiaVEnr4keVXOtAE=; b=B30RNOMfwvmlY0njE98dR+I8u0B+fU/dtLn+/oSW+/kIXfHi0CVjfuZFswHbBv/yl/ UQchTVrB3z9JR808R3fed7BgmcpqjccW88APd1LY6h7kzIyjIjLOWzxPj35OajPUWMri D1m67/ctvgFMEh7owLVXjdMeWPOUVuUshZx2OQ5KCS9q4G+jkGQovqtyNa/ZVGFhrpM0 7EecHoCGN0Md0fGMQaRyZuh/pns4sPx9I52J+pkCwaNlfopm2/l6WT4J1jrVMFiAhuNR iiwW9v5K+ew4TzIMKllMXPVVvQ+ArfPizoPONmPnrByFE0bddJ/ZHVqGn5u3WgsHdY1J 0lGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=55ePfvq2ogrGpO2ltoYovHrYSXRMiaVEnr4keVXOtAE=; b=GzxgvaX2PDv4W7yTIx/moPbQLciEd4b8FAFo2iLDe7f/aKxwv5yGmyKdO5zQZ8fWO8 SUe88xXt20NJOMSmTxQVRKIvc2V/y/E0fllODlhw/3WkZdp9OHP/3LG55F7HSNyUpwQB Zh1RqCG5tRojvnvzZh2BmgTc0vR1QRCW1syaR9FtBH9hzkD2V4CBOG+SSZaOe6CX+4ji CMmehiuljbqng9Xeaz3Ah/XyoJN+UF7MSPLdrHjKswownig/WsM4mCk0WtJnmTdgODmi lJHW2vnHzK00sqFVgl2TKX5W38dsI8NAn/uFyNcattikbLkNGjUZxrRPLFgUY/twavew dz6w==
Received: by 10.236.76.41 with SMTP id a29mr1304671yhe.117.1331703365349; Tue, 13 Mar 2012 22:36:05 -0700 (PDT)
Received: by 10.236.76.41 with SMTP id a29mr1304656yhe.117.1331703365266; Tue, 13 Mar 2012 22:36:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Tue, 13 Mar 2012 22:35:45 -0700 (PDT)
In-Reply-To: 
References:      <007701cd0133$8cf4dd70$a6de9850$@noemax.com> 
From: Takeshi Yoshino 
Date: Wed, 14 Mar 2012 14:35:45 +0900
Message-ID: 
To: John Tamplin 
Content-Type: multipart/alternative; boundary=20cf303b40e3086bd304bb2d5ad9
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmeyWT54ktLqfPQEqlRHWCKzRTZQjmpf4FGiufz+ou61LXDCuH/i5j7Y2afaci/AeEtjzR8fG7kw+WAeHYUyhiYvymiHtlwPvW9BZndX3eKEFp2LFGiMtgCEhrem4X22YWmN41a
Cc: hybi@ietf.org, Gabriel Montenegro 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Wed, 14 Mar 2012 05:36:06 -0000

--20cf303b40e3086bd304bb2d5ad9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 14, 2012 at 01:19, John Tamplin  wrote:

> On Tue, Mar 13, 2012 at 12:08 PM, Arman Djusupov  wrote=
:
>
>> I was thinking more about a specification that would define the way
>> compression extensions are to be applied and reserves the RSV1 bit as
>> compression flag for all extensions. In terms of negotiation, we already
>> have a way to negotiate the compression method when the extension is bei=
ng
>> negotiated. As long as each compression method has its own extension nam=
e
>> the WebSocket handshake will negotiate it anyway. Extensions can be name=
d
>> deflate-frame, bzip2-message, deflate-message-stateful and so on. What s=
pec
>> has to offer is some standard way of using those extensions. e.g. define
>> that =93compression is applied on payload prior masking=94, =93frame hea=
der is
>> not compressed=94 and so on. Then all new compression extension specs wo=
uld
>> be able to reference the common specification defining the general
>> principles on how it=92s applied and negotiated, but each of them could =
have
>> a different name and use a different compression method.
>>
> **
>>
> One complication of using treating each compression algorithm as a
> separate WS extension is how do you negotiate exactly one of them?  Sure,
> you can define the extensions as mutually incompatible, but that could
> complicate server implementations to have to keep track of which ones use
> the same bit.
>
> I also think it makes clearer specs to separate the mechanism of per-fram=
e
> compression from which algorithm to use.
>

So, what do we do with multiple choices? Nesting?

Sec-WebSocket-Extensions: perframe-compress;
method=3D"framewise-stateless-deflate; foo=3Dbar; baz=3D123,
messagewise-stateful-deflate; e=3Dmc2"

--20cf303b40e3086bd304bb2d5ad9
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Wed, Mar 14, 2012 at 01:19, John Tamplin <jat@google.com><=
/span> wrote:



On Tue, Mar 13, 2012 at 12:08 =
PM, Arman Djusupov <arman@noemax.com> wrote:





I was thinking m=
ore about a specification that would define the way compression extensions =
are to be applied and reserves the RSV1 bit as compression flag for all ext=
ensions. In terms of negotiation, we already have a way to negotiate the co=
mpression method when the extension is being negotiated. As long as each co=
mpression method has its own extension name the WebSocket handshake will ne=
gotiate it anyway. Extensions can be named deflate-frame, bzip2-message, de=
flate-message-stateful and so on. What spec has to offer is some standard w=
ay of using those extensions. e.g. define that =93compression is applied on=
 payload prior masking=94, =93frame header is not compressed=94 and so on. =
Then all new compression extension specs would be able to reference the com=
mon specification defining the general principles on how it=92s applied and=
 negotiated, but each of them could have a different name and use a differe=
nt compression method.







One complication of using treating each compression algorithm as a separate=
 WS extension is how do you negotiate exactly one of them? =A0Sure, you can=
 define the extensions as mutually incompatible, but that could complicate =
server implementations to have to keep track of which ones use the same bit=
.






I also think it makes clearer specs to separate the mec=
hanism of per-frame compression from which algorithm to use.

So, what do we do with multiple choices? Nesting?



Sec-WebSocket-Extensions: perframe-compress; meth=
od=3D"framewise-stateless-deflate; foo=3Dbar; baz=3D123, messagewise-s=
tateful-deflate; e=3Dmc2"



--20cf303b40e3086bd304bb2d5ad9--

From arman@noemax.com  Wed Mar 14 01:37:26 2012
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 87A5221F86F6 for ; Wed, 14 Mar 2012 01:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.288
X-Spam-Level: 
X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsKxbFtdoVSD for ; Wed, 14 Mar 2012 01:37:25 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9615B21F86EE for ; Wed, 14 Mar 2012 01:37:25 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id YLZ34429; Wed, 14 Mar 2012 10:37:29 +0200
From: "Arman Djusupov" 
To: "'John Tamplin'" 
References:      <007701cd0133$8cf4dd70$a6de9850$@noemax.com> 
In-Reply-To: 
Date: Wed, 14 Mar 2012 10:37:23 +0200
Message-ID: <002001cd01bd$b1bf6690$153e33b0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CD01CE.75494800"
X-Mailer: Microsoft Outlook 14.0
thread-index: AQEFf2crWbrct+xTc1bODTMkU5A6FAGBA42bAdhteGgAc2U4agHWpgNgAWpZfk0CknPZb5ereZwQ
Content-Language: en-us
Cc: hybi@ietf.org, 'Gabriel Montenegro' 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Wed, 14 Mar 2012 08:37:26 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0021_01CD01CE.75494800
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

IMO a server should be ready to handle situations where the use of the =
one extension prohibits the use of another. Just like with HTTP =
Accept-Encoding header =E2=80=9Cgzip, deflate=E2=80=9D or with mux =
channel compression =E2=80=9Cdeflate-frame, mux, deflate-frame=E2=80=9D =
where deflate-frame can be applied either before or after mux. Grouping =
up supported extensions into mutuality exclusive groups would probably =
be simpler than parsing complex extension headers and creating =
specifications for negotiating the extensions of each type.=20

=20

The server can check the extension header for the presence of supported =
extensions from the same group. Once a supported extension found, other =
extensions of the same group are excluded. Such grouping of extensions =
can even be defined as comma separated list of extension names sorted by =
the order of preference.

=20

With best regards,

Arman

=20

=20

From: John Tamplin [mailto:jat@google.com]=20
Sent: Tuesday, March 13, 2012 6:20 PM
To: Arman Djusupov
Cc: Takeshi Yoshino; hybi@ietf.org; Gabriel Montenegro
Subject: Re: [hybi] Per-frame compression spec draft 06

=20

On Tue, Mar 13, 2012 at 12:08 PM, Arman Djusupov  =
wrote:

I was thinking more about a specification that would define the way =
compression extensions are to be applied and reserves the RSV1 bit as =
compression flag for all extensions. In terms of negotiation, we already =
have a way to negotiate the compression method when the extension is =
being negotiated. As long as each compression method has its own =
extension name the WebSocket handshake will negotiate it anyway. =
Extensions can be named deflate-frame, bzip2-message, =
deflate-message-stateful and so on. What spec has to offer is some =
standard way of using those extensions. e.g. define that =
=E2=80=9Ccompression is applied on payload prior masking=E2=80=9D, =
=E2=80=9Cframe header is not compressed=E2=80=9D and so on. Then all new =
compression extension specs would be able to reference the common =
specification defining the general principles on how it=E2=80=99s =
applied and negotiated, but each of them could have a different name and =
use a different compression method.

One complication of using treating each compression algorithm as a =
separate WS extension is how do you negotiate exactly one of them?  =
Sure, you can define the extensions as mutually incompatible, but that =
could complicate server implementations to have to keep track of which =
ones use the same bit.

=20

I also think it makes clearer specs to separate the mechanism of =
per-frame compression from which algorithm to use.

=20

--=20
John A. Tamplin
Software Engineer (GWT), Google


------=_NextPart_000_0021_01CD01CE.75494800
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


IMO a =
server should be ready to handle situations where the use of the one =
extension prohibits the use of another. Just like with HTTP =
Accept-Encoding header =E2=80=9Cgzip, deflate=E2=80=9D or with mux =
channel compression =E2=80=9Cdeflate-frame, mux, deflate-frame=E2=80=9D =
where deflate-frame can be applied either before or after mux. Grouping =
up supported extensions into mutuality exclusive groups would probably =
be simpler than parsing complex extension headers and creating =
specifications for negotiating the extensions of each type. =

 
The server can check the extension header for the =
presence of supported extensions from the same group. Once a supported =
extension found, other extensions of the same group are excluded. Such =
grouping of extensions can even be defined as comma separated list of =
extension names sorted by the order of preference.
 
With =
best regards,
Arman
 
 
From:=
 =
John Tamplin [mailto:jat@google.com] 
Sent: Tuesday, March 13, =
2012 6:20 PM
To: Arman Djusupov
Cc: Takeshi Yoshino; =
hybi@ietf.org; Gabriel Montenegro
Subject: Re: [hybi] =
Per-frame compression spec draft 06
 
On Tue, =
Mar 13, 2012 at 12:08 PM, Arman Djusupov <arman@noemax.com> =
wrote:
I was thinking more about a =
specification that would define the way compression extensions are to be =
applied and reserves the RSV1 bit as compression flag for all =
extensions. In terms of negotiation, we already have a way to negotiate =
the compression method when the extension is being negotiated. As long =
as each compression method has its own extension name the WebSocket =
handshake will negotiate it anyway. Extensions can be named =
deflate-frame, bzip2-message, deflate-message-stateful and so on. What =
spec has to offer is some standard way of using those extensions. e.g. =
define that =E2=80=9Ccompression is applied on payload prior =
masking=E2=80=9D, =E2=80=9Cframe header is not compressed=E2=80=9D and =
so on. Then all new compression extension specs would be able to =
reference the common specification defining the general principles on =
how it=E2=80=99s applied and negotiated, but each of them could have a =
different name and use a different compression =
method.
One =
complication of using treating each compression algorithm as a separate =
WS extension is how do you negotiate exactly one of them?  Sure, =
you can define the extensions as mutually incompatible, but that could =
complicate server implementations to have to keep track of which ones =
use the same bit.
 
I =
also think it makes clearer specs to separate the mechanism of per-frame =
compression from which algorithm to use.
 
-- =

John A. Tamplin
Software Engineer (GWT), =
Google

------=_NextPart_000_0021_01CD01CE.75494800--


From jat@google.com  Wed Mar 14 08:09:42 2012
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 B4C7B21F87C4 for ; Wed, 14 Mar 2012 08:09:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tu8PhLVHCF7G for ; Wed, 14 Mar 2012 08:09:42 -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 14FF821F87A5 for ; Wed, 14 Mar 2012 08:09:41 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so2483044vcb.31 for ; Wed, 14 Mar 2012 08:09:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=9r0XBAgO3VS5jqjdbOu/s9ps6ARuxpGs21hW/7e7aTU=; b=hF1S37Axs4NY2t+y8+hnehjg6Px9NJxJz8knAXbZdW9dEKeRu+WzvGjFQerXQHwVBa lxkQQWhA8UlpK378/lRI/MbiEhHwfoundgGXvqXGgbZN7Jp8o/8mum2XPDT3Oe2ee0VP 00nwEzwp6ckjTEWFk7ZtT01zajos9Affy3YrfyTp4XDvZjC10rLFw5OCq2WIdICDIp04 Rc7XsuBtjqvm9g4ki9zMMYXP6NqKp3WUvguwwWOD53V2CLIhUc8MKvyYDKHrfogCmucW AnoNrUbbhtXiuNAqkA+FBGZINhJeLVVf0OO3hGGK9cv7546ESqvLQiWqPToxNNRUFM6T M4yg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=9r0XBAgO3VS5jqjdbOu/s9ps6ARuxpGs21hW/7e7aTU=; b=Aurdodk77w/qfnXFgy17OgB4NxB+wEzw3zLS3Aj8MwsA0rK4brUAk/zHrHYRI32Jmm LcDyiOqeGk01RNPJkuH+9aJwg8kKrGSKFWL5plxDS9TshEbb1MdClGx7cR3AkA3XFJG9 d4LMXtmf3pVZp4thco+MTaJVnPIvx631mrac26D8dvfNt4pyL5UDiuERcaX8ErsaFMs7 1NqmMSXfMM8HvhxxQOWnl00XHEF+MJ+bjBJm1s1EVBrU7N4CGUKtJw+YiA2y6kj/mHNH r1eitCPRCP+ES9i2FOoOTK35lk+zoiw3hFwDI87KIXK2sd8rprvdDtG9uWkPzuSVP6Tm CNYg==
Received: by 10.52.31.69 with SMTP id y5mr2166641vdh.37.1331737781452; Wed, 14 Mar 2012 08:09:41 -0700 (PDT)
Received: by 10.52.31.69 with SMTP id y5mr2166616vdh.37.1331737781213; Wed, 14 Mar 2012 08:09:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.134.207 with HTTP; Wed, 14 Mar 2012 08:09:21 -0700 (PDT)
In-Reply-To: 
References:      <007701cd0133$8cf4dd70$a6de9850$@noemax.com>  
From: John Tamplin 
Date: Wed, 14 Mar 2012 11:09:21 -0400
Message-ID: 
To: Takeshi Yoshino 
Content-Type: multipart/alternative; boundary=bcaec51d2ed2621ac204bb355d59
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQk5Qh7AIvrPz2jUOvLJ6iRLZY+TpbrIe3umqTjjA3KMvxuy5wjn2uYxwv+GB3FjXM2CQLqP9hRFMBz7Kn65nPGii9KPE8be/FAw1Ig3/CXnD0jJdcqQxFtyvwY9NjOWbKXOa56i
Cc: hybi@ietf.org, Gabriel Montenegro 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Wed, 14 Mar 2012 15:09:42 -0000

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

On Wed, Mar 14, 2012 at 1:35 AM, Takeshi Yoshino wrote:

> So, what do we do with multiple choices? Nesting?
>
> Sec-WebSocket-Extensions: perframe-compress;
> method="framewise-stateless-deflate; foo=bar; baz=123,
> messagewise-stateful-deflate; e=mc2"
>

I was thinking a separate header for compression negotiation, but that
could work also.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Wed, Mar 14, 2012 at 1:35 AM, Takeshi Yoshino=
 <tyoshino@goog=
le.com> wrote:



So, what do we do with mu=
ltiple choices? Nesting?

Sec-WebSocket-Exten=
sions: perframe-compress; method=3D"framewise-stateless-deflate; foo=
=3Dbar; baz=3D123, messagewise-stateful-deflate; e=3Dmc2"






I was thinking a separate header for comp=
ression negotiation, but that could work also.

-- 
John A. Tamplin
Software Engineer (GWT), Google


--bcaec51d2ed2621ac204bb355d59--

From jat@google.com  Wed Mar 14 08:11:37 2012
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 8928321F87C5 for ; Wed, 14 Mar 2012 08:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 535RPgf6y1LB for ; Wed, 14 Mar 2012 08:11:37 -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 9AA4D21F87C4 for ; Wed, 14 Mar 2012 08:11:36 -0700 (PDT)
Received: by eaaq11 with SMTP id q11so1056562eaa.31 for ; Wed, 14 Mar 2012 08:11:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=c3Nj9EiqpSSzxLXu8rsCbVcZ4vvjlAxjxueipIrcmpI=; b=IUDWcui+YaD7KdsNYLJpPkYY3tAKyAco/889Iuhspq0sEXVVZ4mEgNZ+0RJ2CJGM/0 SHQZuMhYd8lvNBpA8O3DTkLtukG4gebmlH4QcxxNVyQmpQLmonl2bshMV1BzX+7Eo4Jy 3/KESl6kxHHbhNGrlwWShVzeX2hNESipmJ79BB/zqbs87dxmnjpoNAuvb0jUGQvf9Z9c /ofq9sb6jK18SAK6bW1NDvOzQ6fKbfJEAwekqxxHk5qFlYDPLl0s88RbF6GfnNtxZpMU j+Nj8rJH4Cv+N8AoortwQ6yp2OaFWxW5qYeH4KG9YP7VFcMBlzDTCyz97rW0RZC+MIK8 qSIQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=c3Nj9EiqpSSzxLXu8rsCbVcZ4vvjlAxjxueipIrcmpI=; b=hsYLF7Z8X5qXJdRf7PR4jcPwfzpmywIHkUB11FvUkpD11Q7Sr8jRkA82qzOUuL1Rig S4NWec+N2jO/Umw2R/BFBlmugXn9U44/0o290Xnzm7hj2WIvwar8dexNLhBurGKifeM4 nTKkCeyXqN4/6KxL2tGS6i4daCs5LqYvYhJwI7/lW0RspfjhzslkqBifExXIAFXKu4Xm /43eMVrocGj1c3KhbtfxftK+pkLUdq0PE4zv6B2D2zvXN0YY1Lt2p/FHg/+LfoDxO07G Kp54nC6tnmBHfQ2aWpx3EPfScqbEn2/ot2n0SZ5SetpMwuZWLEjbqKDsJ89bB3Zw5/sz z9dA==
Received: by 10.52.94.20 with SMTP id cy20mr2072068vdb.117.1331737895291; Wed, 14 Mar 2012 08:11:35 -0700 (PDT)
Received: by 10.52.94.20 with SMTP id cy20mr2072058vdb.117.1331737895218; Wed, 14 Mar 2012 08:11:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.134.207 with HTTP; Wed, 14 Mar 2012 08:11:15 -0700 (PDT)
In-Reply-To: <002001cd01bd$b1bf6690$153e33b0$@noemax.com>
References:      <007701cd0133$8cf4dd70$a6de9850$@noemax.com>  <002001cd01bd$b1bf6690$153e33b0$@noemax.com>
From: John Tamplin 
Date: Wed, 14 Mar 2012 11:11:15 -0400
Message-ID: 
To: Arman Djusupov , Greg Wilkins 
Content-Type: multipart/alternative; boundary=20cf307d051c2dae3104bb356468
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkv1rxxU1uJXNxfhJvpR+QRCUj+mYOiRHMIpyhp6qtfaBrRngq08WZUaPdwXQCLhLUZUI3YopO08q7d7SzYjTU9h2S52Dy42G2bX/U1kDlcsIHoUOBW8Oc9M9Bg464v3AAlRWCg
Cc: hybi@ietf.org, Gabriel Montenegro 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Wed, 14 Mar 2012 15:11:37 -0000

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

On Wed, Mar 14, 2012 at 4:37 AM, Arman Djusupov  wrote:

> IMO a server should be ready to handle situations where the use of the on=
e
> extension prohibits the use of another. Just like with HTTP Accept-Encodi=
ng
> header =E2=80=9Cgzip, deflate=E2=80=9D or with mux channel compression =
=E2=80=9Cdeflate-frame, mux,
> deflate-frame=E2=80=9D where deflate-frame can be applied either before o=
r after
> mux. Grouping up supported extensions into mutuality exclusive groups wou=
ld
> probably be simpler than parsing complex extension headers and creating
> specifications for negotiating the extensions of each type.
>
> **
>
> The server can check the extension header for the presence of supported
> extensions from the same group. Once a supported extension found, other
> extensions of the same group are excluded. Such grouping of extensions ca=
n
> even be defined as comma separated list of extension names sorted by the
> order of preference.
>
@Greg - IIRC, you were one of the ones who objected to requiring low-level
code to know such details due to server architectures you had in mind -- is
that accurate and if so still the case?

--=20
John A. Tamplin
Software Engineer (GWT), Google

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


On Wed, Mar 14, 2012 at 4:37 AM, Arman Djusupov =
<arman@noemax.com<=
/a>> wrote:



IMO a server should b=
e ready to handle situations where the use of the one extension prohibits t=
he use of another. Just like with HTTP Accept-Encoding header =E2=80=9Cgzip=
, deflate=E2=80=9D or with mux channel compression =E2=80=9Cdeflate-frame, =
mux, deflate-frame=E2=80=9D where deflate-frame can be applied either befor=
e or after mux. Grouping up supported extensions into mutuality exclusive g=
roups would probably be simpler than parsing complex extension headers and =
creating specifications for negotiating the extensions of each type.=C2=A0<=
/p>


The server can check the extension header for the presence=
 of supported extensions from the same group. Once a supported extension fo=
und, other extensions of the same group are excluded. Such grouping of exte=
nsions can even be defined as comma separated list of extension names sorte=
d by the order of preference.



@Greg - IIRC, you were one of the ones who ob=
jected to requiring low-level code to know such details due to server archi=
tectures you had in mind -- is that accurate and if so still the case?



-- 
John A. Tamplin
Software Engineer (GWT), Google

--20cf307d051c2dae3104bb356468--

From arman@noemax.com  Wed Mar 14 09:05:06 2012
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 15B2521F873A for ; Wed, 14 Mar 2012 09:05:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.333
X-Spam-Level: 
X-Spam-Status: No, score=-2.333 tagged_above=-999 required=5 tests=[AWL=0.266,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTcdadflnAQ0 for ; Wed, 14 Mar 2012 09:05:05 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 4C40221F86DC for ; Wed, 14 Mar 2012 09:05:04 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id YTT83008; Wed, 14 Mar 2012 18:05:08 +0200
From: "Arman Djusupov" 
To: "'John Tamplin'" , "'Greg Wilkins'" 
References:      <007701cd0133$8cf4dd70$a6de9850$@noemax.com>  <002001cd01bd$b1bf6690$153e33b0$@noemax.com> 
In-Reply-To: 
Date: Wed, 14 Mar 2012 18:05:00 +0200
Message-ID: <005201cd01fc$3ae53a60$b0afaf20$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CD020C.FE6E0A60"
X-Mailer: Microsoft Outlook 14.0
thread-index: AQEFf2crWbrct+xTc1bODTMkU5A6FAGBA42bAdhteGgAc2U4agHWpgNgAWpZfk0CknPZbwKwyMg+AZv8QIGXiZACIA==
Content-Language: en-us
Cc: hybi@ietf.org, 'Gabriel Montenegro' 
Subject: Re: [hybi] Per-frame compression spec draft 06
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: Wed, 14 Mar 2012 16:05:06 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0053_01CD020C.FE6E0A60
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

The server will anyway have to go into such details. It can=E2=80=99t =
simply trust the Sec-WebSocket-Extensions header sent by the client and =
apply all extensions in the order specified by the client. If the server =
blindly trusts the order specified by the client, malicious or =
misbehaving clients will be able to trick the server in combining =
extensions in the worst possible order or in applying incompatible =
extensions together.

=20

With best regards,

Arman

=20

From: John Tamplin [mailto:jat@google.com]=20
Sent: Wednesday, March 14, 2012 5:11 PM
To: Arman Djusupov; Greg Wilkins
Cc: Takeshi Yoshino; hybi@ietf.org; Gabriel Montenegro
Subject: Re: [hybi] Per-frame compression spec draft 06

=20

On Wed, Mar 14, 2012 at 4:37 AM, Arman Djusupov  =
wrote:

IMO a server should be ready to handle situations where the use of the =
one extension prohibits the use of another. Just like with HTTP =
Accept-Encoding header =E2=80=9Cgzip, deflate=E2=80=9D or with mux =
channel compression =E2=80=9Cdeflate-frame, mux, deflate-frame=E2=80=9D =
where deflate-frame can be applied either before or after mux. Grouping =
up supported extensions into mutuality exclusive groups would probably =
be simpler than parsing complex extension headers and creating =
specifications for negotiating the extensions of each type.=20

The server can check the extension header for the presence of supported =
extensions from the same group. Once a supported extension found, other =
extensions of the same group are excluded. Such grouping of extensions =
can even be defined as comma separated list of extension names sorted by =
the order of preference.

@Greg - IIRC, you were one of the ones who objected to requiring =
low-level code to know such details due to server architectures you had =
in mind -- is that accurate and if so still the case?

=20

--=20
John A. Tamplin
Software Engineer (GWT), Google


------=_NextPart_000_0053_01CD020C.FE6E0A60
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


The =
server will anyway have to go into such details. It can=E2=80=99t simply =
trust the Sec-WebSocket-Extensions header sent by the client and apply =
all extensions in the order specified by the client. If the server =
blindly trusts the order specified by the client, malicious or =
misbehaving clients will be able to trick the server in combining =
extensions in the worst possible order or in applying incompatible =
extensions together.
 
With =
best regards,
Arman
 
From:=
 =
John Tamplin [mailto:jat@google.com] 
Sent: Wednesday, March =
14, 2012 5:11 PM
To: Arman Djusupov; Greg =
Wilkins
Cc: Takeshi Yoshino; hybi@ietf.org; Gabriel =
Montenegro
Subject: Re: [hybi] Per-frame compression spec =
draft 06
 
On Wed, =
Mar 14, 2012 at 4:37 AM, Arman Djusupov <arman@noemax.com> =
wrote:
IMO a server should be ready to handle =
situations where the use of the one extension prohibits the use of =
another. Just like with HTTP Accept-Encoding header =E2=80=9Cgzip, =
deflate=E2=80=9D or with mux channel compression =E2=80=9Cdeflate-frame, =
mux, deflate-frame=E2=80=9D where deflate-frame can be applied either =
before or after mux. Grouping up supported extensions into mutuality =
exclusive groups would probably be simpler than parsing complex =
extension headers and creating specifications for negotiating the =
extensions of each type. 
The server can check the =
extension header for the presence of supported extensions from the same =
group. Once a supported extension found, other extensions of the same =
group are excluded. Such grouping of extensions can even be defined as =
comma separated list of extension names sorted by the order of =
preference.
@Greg - =
IIRC, you were one of the ones who objected to requiring low-level code =
to know such details due to server architectures you had in mind -- is =
that accurate and if so still the case?
 
-- =

John A. Tamplin
Software Engineer (GWT), =
Google

------=_NextPart_000_0053_01CD020C.FE6E0A60--


From w@1wt.eu  Fri Mar 16 03:18:56 2012
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 EE16221F85C2 for ; Fri, 16 Mar 2012 03:18:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.198
X-Spam-Level: 
X-Spam-Status: No, score=-5.198 tagged_above=-999 required=5 tests=[AWL=-3.155, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+5eGqG1HJa6 for ; Fri, 16 Mar 2012 03:18:56 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0600421F85AC for ; Fri, 16 Mar 2012 03:18:54 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2GAIoqu010354; Fri, 16 Mar 2012 11:18:50 +0100
Date: Fri, 16 Mar 2012 11:18:50 +0100
From: Willy Tarreau 
To: hybi@ietf.org
Message-ID: <20120316101850.GA10202@1wt.eu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.3i
Cc: Jason Strimpel 
Subject: [hybi] Report of a dirty WS blocking issue with OfficeScan
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, 16 Mar 2012 10:18:57 -0000

Hi,

I'm posting this here as Jason is not subscribed to the list, please
keep him CCed for any response or for more details.

A few months ago I was contacted by Jason Strimpel (CCed) about an issue
with WS and haproxy. From the server side, the handshake correctly worked,
the server sent some data but the client never replied. To make the long
story short, after many tests, network captures, etc... it became obvious
that the data were not leaving the client for connections going to port
80. What made it look like it was haproxy was the fact that connecting
directly to the server on port 8000 used to work.

After inspecting all components deployed on the desktop, Jason found
that Trend Micro's OfficeScan was installed on the machine, and that
disabling it fixed the issue. It seems like this product inspects
outgoing traffic to port 80, doesn't understand HTTP 101+Upgrade and
blocks any further outgoing traffic without closing the connection
(probably that it considers 101 as 200 and the lack of content-length
as a close mode).

It would be nice to know if minor adaptations to the handshake could
make such connections fail cleanly and quickly. I wonder if just sending
"Content-length: 0" in responses would workaround such components. If
the product considers that 101 is a final response, at least with cl:0
it should wait for a new request and reject further client data as an
invalid request. Possibly that if this works, adding "Connection: close"
in the response would also handle the situation when the client expects
the server to speak first.

These are some of the tests we could possibly do with Jason as he has
access to the faulty device.

I wanted to report this here so that nobody needlessly wastes as much time
on a similar issue. We'll report here if we find an simple workaround for
the issue so that the connection fails cleanly.

Regards,
Willy


From tobias.oberstein@tavendo.de  Fri Mar 16 04:01:56 2012
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 E521021F864E for ; Fri, 16 Mar 2012 04:01:55 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goazUqQopNs6 for ; Fri, 16 Mar 2012 04:01:55 -0700 (PDT)
Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id DAA4821F8649 for ; Fri, 16 Mar 2012 04:01:54 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.215]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Fri, 16 Mar 2012 04:01:54 -0700
From: Tobias Oberstein 
To: Willy Tarreau , "hybi@ietf.org" 
Date: Fri, 16 Mar 2012 04:01:52 -0700
Thread-Topic: [hybi] Report of a dirty WS blocking issue with OfficeScan
Thread-Index: Ac0DXjYtP8vjb9REQy68DW9nC+xk6QABO7TA
Message-ID: <634914A010D0B943A035D226786325D42D5BE6DBBF@EXVMBX020-12.exch020.serverdata.net>
References: <20120316101850.GA10202@1wt.eu>
In-Reply-To: <20120316101850.GA10202@1wt.eu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Jason Strimpel 
Subject: Re: [hybi] Report of a dirty WS blocking issue with OfficeScan
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, 16 Mar 2012 11:01:56 -0000

Willy, thanks for reporting. Good to know to watch out for such things.

> After inspecting all components deployed on the desktop, Jason found that
> Trend Micro's OfficeScan was installed on the machine, and that disabling=
 it
> fixed the issue. It seems like this product inspects outgoing traffic to =
port 80,
> doesn't understand HTTP 101+Upgrade and blocks any further outgoing traff=
ic
> without closing the connection (probably that it considers 101 as 200 and=
 the
> lack of content-length as a close mode).

Instead of putting the burden onto the whole WebSocket community, why not
make that single vendor fix their broken product?

Or - quick fix: uninstall it, safe money. Such products often do more harm
than good.

From w@1wt.eu  Fri Mar 16 04:06:59 2012
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 9B54621F8685 for ; Fri, 16 Mar 2012 04:06:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.173
X-Spam-Level: 
X-Spam-Status: No, score=-5.173 tagged_above=-999 required=5 tests=[AWL=-3.130, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUalT3x1upkH for ; Fri, 16 Mar 2012 04:06:59 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CBC2A21F867C for ; Fri, 16 Mar 2012 04:06:58 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2GB6voZ010624; Fri, 16 Mar 2012 12:06:57 +0100
Date: Fri, 16 Mar 2012 12:06:57 +0100
From: Willy Tarreau 
To: Tobias Oberstein 
Message-ID: <20120316110657.GG9940@1wt.eu>
References: <20120316101850.GA10202@1wt.eu> <634914A010D0B943A035D226786325D42D5BE6DBBF@EXVMBX020-12.exch020.serverdata.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <634914A010D0B943A035D226786325D42D5BE6DBBF@EXVMBX020-12.exch020.serverdata.net>
User-Agent: Mutt/1.4.2.3i
Cc: Jason Strimpel , "hybi@ietf.org" 
Subject: Re: [hybi] Report of a dirty WS blocking issue with OfficeScan
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, 16 Mar 2012 11:06:59 -0000

On Fri, Mar 16, 2012 at 04:01:52AM -0700, Tobias Oberstein wrote:
> Willy, thanks for reporting. Good to know to watch out for such things.
> 
> > After inspecting all components deployed on the desktop, Jason found that
> > Trend Micro's OfficeScan was installed on the machine, and that disabling it
> > fixed the issue. It seems like this product inspects outgoing traffic to port 80,
> > doesn't understand HTTP 101+Upgrade and blocks any further outgoing traffic
> > without closing the connection (probably that it considers 101 as 200 and the
> > lack of content-length as a close mode).
> 
> Instead of putting the burden onto the whole WebSocket community, why not
> make that single vendor fix their broken product?

Jason is contacting the vendor in parallel. But we wanted to make WS fail
as cleanly as possible on broken products so that they are easily spotted.
It took us 3 months to spot the faulty product. With a clean failure, it
would just have taken hours.

> Or - quick fix: uninstall it, safe money. Such products often do more harm
> than good.

That's not the subject here. People don't chose what they use at their work,
and our engineering work consists in helping them complain to the right
person to get the product fixed or removed.

Regards,
Willy


From rbarnes@bbn.com  Fri Mar 16 12:14:22 2012
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 25C8621F8639 for ; Fri, 16 Mar 2012 12:14:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.368
X-Spam-Level: 
X-Spam-Status: No, score=-106.368 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUia5GNG8k9P for ; Fri, 16 Mar 2012 12:14:21 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 86EA621F8637 for ; Fri, 16 Mar 2012 12:14:21 -0700 (PDT)
Received: from ros-dhcp192-1-51-17.bbn.com ([192.1.51.17]:50038) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.77 (FreeBSD)) (envelope-from ) id 1S8cbG-0006yN-CJ; Fri, 16 Mar 2012 15:14:06 -0400
Mime-Version: 1.0 (Apple Message framework v1257)
Content-Type: text/plain; charset=us-ascii
From: "Richard L. Barnes" 
In-Reply-To: <20120316110657.GG9940@1wt.eu>
Date: Fri, 16 Mar 2012 15:14:32 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <90B18B4B-4CD4-4454-9C77-2DF3F6D5F7DB@bbn.com>
References: <20120316101850.GA10202@1wt.eu> <634914A010D0B943A035D226786325D42D5BE6DBBF@EXVMBX020-12.exch020.serverdata.net> <20120316110657.GG9940@1wt.eu>
To: Willy Tarreau 
X-Mailer: Apple Mail (2.1257)
Cc: Jason Strimpel , "hybi@ietf.org" 
Subject: Re: [hybi] Report of a dirty WS blocking issue with OfficeScan
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, 16 Mar 2012 19:14:22 -0000

On Mar 16, 2012, at 7:06 AM, Willy Tarreau wrote:

> On Fri, Mar 16, 2012 at 04:01:52AM -0700, Tobias Oberstein wrote:
>> Willy, thanks for reporting. Good to know to watch out for such =
things.
>>=20
>>> After inspecting all components deployed on the desktop, Jason found =
that
>>> Trend Micro's OfficeScan was installed on the machine, and that =
disabling it
>>> fixed the issue. It seems like this product inspects outgoing =
traffic to port 80,
>>> doesn't understand HTTP 101+Upgrade and blocks any further outgoing =
traffic
>>> without closing the connection (probably that it considers 101 as =
200 and the
>>> lack of content-length as a close mode).
>>=20
>> Instead of putting the burden onto the whole WebSocket community, why =
not
>> make that single vendor fix their broken product?
>=20
> Jason is contacting the vendor in parallel. But we wanted to make WS =
fail
> as cleanly as possible on broken products so that they are easily =
spotted.
> It took us 3 months to spot the faulty product. With a clean failure, =
it
> would just have taken hours.

What would clean failure have looked like in this case?  A timeout?  And =
how would that have helped identify the guilty product?=

From w@1wt.eu  Fri Mar 16 12:21:29 2012
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 5605A21E806A for ; Fri, 16 Mar 2012 12:21:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.148
X-Spam-Level: 
X-Spam-Status: No, score=-5.148 tagged_above=-999 required=5 tests=[AWL=-3.105, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id byySKpF9nggQ for ; Fri, 16 Mar 2012 12:21:27 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD0D21E8069 for ; Fri, 16 Mar 2012 12:21:23 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2GJLDf2013634; Fri, 16 Mar 2012 20:21:13 +0100
Date: Fri, 16 Mar 2012 20:21:13 +0100
From: Willy Tarreau 
To: "Richard L. Barnes" 
Message-ID: <20120316192113.GC13250@1wt.eu>
References: <20120316101850.GA10202@1wt.eu> <634914A010D0B943A035D226786325D42D5BE6DBBF@EXVMBX020-12.exch020.serverdata.net> <20120316110657.GG9940@1wt.eu> <90B18B4B-4CD4-4454-9C77-2DF3F6D5F7DB@bbn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <90B18B4B-4CD4-4454-9C77-2DF3F6D5F7DB@bbn.com>
User-Agent: Mutt/1.4.2.3i
Cc: Jason Strimpel , "hybi@ietf.org" 
Subject: Re: [hybi] Report of a dirty WS blocking issue with OfficeScan
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, 16 Mar 2012 19:21:29 -0000

Hi Richard,

On Fri, Mar 16, 2012 at 03:14:32PM -0400, Richard L. Barnes wrote:
> 
> On Mar 16, 2012, at 7:06 AM, Willy Tarreau wrote:
> 
> > On Fri, Mar 16, 2012 at 04:01:52AM -0700, Tobias Oberstein wrote:
> >> Willy, thanks for reporting. Good to know to watch out for such things.
> >> 
> >>> After inspecting all components deployed on the desktop, Jason found that
> >>> Trend Micro's OfficeScan was installed on the machine, and that disabling it
> >>> fixed the issue. It seems like this product inspects outgoing traffic to port 80,
> >>> doesn't understand HTTP 101+Upgrade and blocks any further outgoing traffic
> >>> without closing the connection (probably that it considers 101 as 200 and the
> >>> lack of content-length as a close mode).
> >> 
> >> Instead of putting the burden onto the whole WebSocket community, why not
> >> make that single vendor fix their broken product?
> > 
> > Jason is contacting the vendor in parallel. But we wanted to make WS fail
> > as cleanly as possible on broken products so that they are easily spotted.
> > It took us 3 months to spot the faulty product. With a clean failure, it
> > would just have taken hours.
> 
> What would clean failure have looked like in this case?  A timeout?  And how
> would that have helped identify the guilty product?

No, it should have been a connection close by the scanner, that would have
been detected by the client. When an error happens with an active close, it
is much easier to spot the culprit because both ends would observe the close,
so it's easy to find the middle point. But when everything gets stuck with
everyone thinking the data was properly transmitted, it's very hard to find
where the problem is.

Regards,
Willy


From arman@noemax.com  Mon Mar 19 07:37:21 2012
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 7B77121F883E for ; Mon, 19 Mar 2012 07:37:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.366
X-Spam-Level: 
X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Boq6FZqGx0Ev for ; Mon, 19 Mar 2012 07:37:19 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9E521F8829 for ; Mon, 19 Mar 2012 07:37:19 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id DRE07820; Mon, 19 Mar 2012 16:37:20 +0200
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" , 
References: 
In-Reply-To: 
Date: Mon, 19 Mar 2012 16:37:10 +0200
Message-ID: <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01CD05EE.8C853D70"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdngu5UmlX2Q
Content-Language: en-us
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 19 Mar 2012 14:37:21 -0000

This is a multipart message in MIME format.

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

The procedure of closing the logical channel is not detailed enough. Closing
the logical channel should be performed in a way similar to closing the
websocket connection when no mux extension is used. We need a close control
frame to roundtrip in order to ensure the mutual agreement between the two
sides when a logical channel is closed. Currently the specification does not
require the side that receives a DropChannel control frame to reply to it
(unless I missed something), which does not ensure the graceful closure of
logical channels.

 

"When an endpoint received DropChannel, the endpoint MUST remove the logical
channel and the application instance that used the logical channel MUST
treat this as closure of underlying transport."
 
One side could be in the process of sending a message when it receives a
DropChannel frame, so it is important to ensure that the logical channel is
closed gracefully without dead channel frames left on the wire. The best way
to do it is to let the DropChannel frame roundtrip back to its sender. When
both sides have received the DropChannel frame they are in mutual agreement
to release the channel ID, being sure that no more frames with the same
channel ID are expected to arrive from the remote side.
 
With best regards,
Arman

 

 

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
Takeshi Yoshino
Sent: Tuesday, February 28, 2012 6:47 PM
To: hybi@ietf.org
Subject: [hybi] Multiplexing extension spec draft 03

 

http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03 

Diff http://tools.ietf.org/rfcdiff?url2=draft-tamplin-hybi-google-mux-03.txt


 

- Added a section to describe terms "physical channel" and "logical channel"

- Now the order of extensions in Sec-WebSocket-Extensions determines where
those extensions are applied to frames (before or after (de)multiplexing)

-- Also added explanation of the reason why such a mechanism is needed

-- based on http://www.ietf.org/mail-archive/web/hybi/current/msg09410.html

- Added note discussing how implementors should design quota assignment to
avoid starvation, etc.

-- based on http://www.ietf.org/mail-archive/web/hybi/current/msg09402.html

- Defined operation identifiers such as _Fail the Physical Channel_

- Clarified how events, operations on logical/physical channels must be
handled

- Revised layout of section 7 for readability

- Added DropChannel command to handle logical channel level errors

- Added "Timeout" section

 


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


The procedure of closing the logical channel is not detailed enough. =
Closing the logical channel should be performed in a way similar to =
closing the websocket connection when no mux extension is used. We need =
a close control frame to roundtrip in order to ensure the mutual =
agreement between the two sides when a logical channel is closed. =
Currently the specification does not require the side that receives a =
DropChannel control frame to reply to it (unless I missed something), =
which does not ensure the graceful closure of logical =
channels.
 
“When an =
endpoint received DropChannel, the endpoint MUST remove the logical channel and the application instance =
that used the logical channel MUST treat this as closure of underlying =
transport.“
 
One side could be in the process of sending a message when it =
receives a DropChannel frame, so it is important to ensure that the =
logical channel is closed gracefully without dead channel frames left on =
the wire. The best way to do it is to let the DropChannel frame =
roundtrip back to its sender. When both sides have received the =
DropChannel frame they are in mutual agreement to release the channel =
ID, being sure that no more frames with the same channel ID are expected =
to arrive from the remote side.
 
With best regards,
Arman
 
 
From:=
 =
hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of =
Takeshi Yoshino
Sent: Tuesday, February 28, 2012 6:47 =
PM
To: hybi@ietf.org
Subject: [hybi] Multiplexing =
extension spec draft 03
 
http=
://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03 =

 
- =
Added a section to describe terms "physical channel" and =
"logical channel"
- Now the order of extensions in =
Sec-WebSocket-Extensions determines where those extensions are applied =
to frames (before or after (de)multiplexing)
-- Also added explanation of the reason why such a =
mechanism is needed
- Added note discussing how =
implementors should design quota assignment to avoid starvation, =
etc.
- Defined operation identifiers =
such as _Fail the Physical Channel_
- Clarified how events, operations on logical/physical =
channels must be handled
- =
Revised layout of section 7 for readability
- Added DropChannel command to handle logical channel =
level errors
- Added =
"Timeout" section
 

------=_NextPart_000_0004_01CD05EE.8C853D70--


From tobias.oberstein@tavendo.de  Wed Mar 21 14:27:22 2012
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 E5FF321E80F5 for ; Wed, 21 Mar 2012 14:27:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T55Rh8pSjm-V for ; Wed, 21 Mar 2012 14:27:20 -0700 (PDT)
Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 7018221E80D6 for ; Wed, 21 Mar 2012 14:27:20 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.215]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Wed, 21 Mar 2012 14:27:19 -0700
From: Tobias Oberstein 
To: "hybi@ietf.org" 
Date: Wed, 21 Mar 2012 14:27:15 -0700
Thread-Topic: WS Test Suite - Update
Thread-Index: Ac0HmFXqa9voPvRDQg+t+K4nTf5f6A==
Message-ID: <634914A010D0B943A035D226786325D42D5C0CA441@EXVMBX020-12.exch020.serverdata.net>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [hybi] WS Test Suite - Update
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: Wed, 21 Mar 2012 21:27:23 -0000

There is a new version of the Autobahn WS Testsuite and test reports avail:

 * test reports updated for new browser versions + IE10 and WebKit Nightly =
(Safari)

 * test suite now comes completely packaged, easy install/use, no fuss

 * test suite now includes 12 modes

The modes: 2 are the known "fuzzing" modes to produce WS impl. reports (cli=
ent+server)

New modes: echo, broadcast, testee, .. additional handy tools for WS implem=
entors/devs.

And in particular:

We have started collaborating with the WebSocket++ project (Peter Thorson) =
to build a
distributed WS load generator / performance testing tool.

In one mode it will allow: running multiple instances of the "wsperf" load =
generator/probe
distributed both in LAN and WAN.

The probe will produce load / tests onto a testee target WS server. "wstest=
": will act as a
controller for the probes, aggregate results, produce web UI, ..

This thing is preliminary / still in the cooking .. but I think it has the =
potential to take
"WS testing" to the next level.

http://autobahn.ws/testsuite
http://www.zaphoyd.com/wsperf

\Tobias

From theturtle32@gmail.com  Wed Mar 21 15:05:04 2012
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 5C44E21F8718 for ; Wed, 21 Mar 2012 15:05:04 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id svOza9Nv758j for ; Wed, 21 Mar 2012 15:05:03 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8459C21F8713 for ; Wed, 21 Mar 2012 15:05:03 -0700 (PDT)
Received: by obbtb4 with SMTP id tb4so1135588obb.31 for ; Wed, 21 Mar 2012 15:05:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5c0Fh63739wpFkQgt6QKKnOuIYFwrMasupZVUpV4TnY=; b=d2Bk9qNj8DhTu6LXE2A6UCjryrCqhtmms8wNNxS4k2voIPBRYUUqRREcD53NEGV+v6 MjuSxRIjW9iJdbiBDwZ8YtQaoQW4jpHfXlKYDsd+ZRuccvLMRY6VJHrh5UxZmOF2K1QW QnUIgsGDxyR6RNbSNjfYLNR4aU9vgnudpOB3p5btp0NB+0nxou4HJ2lJO1y3yADJQ/0P xdvcsRTplgjC8AGg+RzhU5NNd55DVktyagHTD+V80zyuqvKyoO3ag4MjGfQAXgLWEtag hexZjL89OM6dbZsfy211+Mx5Qe15D5D95n9SHsP82tOLFeZMFJrgeVNHO6yIF2HhuvmZ 3sqg==
MIME-Version: 1.0
Received: by 10.182.1.104 with SMTP id 8mr6821961obl.19.1332367503058; Wed, 21 Mar 2012 15:05:03 -0700 (PDT)
Received: by 10.182.15.166 with HTTP; Wed, 21 Mar 2012 15:05:02 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D42D5C0CA441@EXVMBX020-12.exch020.serverdata.net>
References: <634914A010D0B943A035D226786325D42D5C0CA441@EXVMBX020-12.exch020.serverdata.net>
Date: Wed, 21 Mar 2012 15:05:02 -0700
Message-ID: 
From: Brian 
To: Tobias Oberstein 
Content-Type: multipart/alternative; boundary=f46d04463166bae57304bbc7fb7d
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] WS Test Suite - Update
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: Wed, 21 Mar 2012 22:05:04 -0000

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

This is awesome!  I can't wait to try wsperf out!

Brian

On Wed, Mar 21, 2012 at 2:27 PM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> There is a new version of the Autobahn WS Testsuite and test reports avail:
>
>  * test reports updated for new browser versions + IE10 and WebKit Nightly
> (Safari)
>
>  * test suite now comes completely packaged, easy install/use, no fuss
>
>  * test suite now includes 12 modes
>
> The modes: 2 are the known "fuzzing" modes to produce WS impl. reports
> (client+server)
>
> New modes: echo, broadcast, testee, .. additional handy tools for WS
> implementors/devs.
>
> And in particular:
>
> We have started collaborating with the WebSocket++ project (Peter Thorson)
> to build a
> distributed WS load generator / performance testing tool.
>
> In one mode it will allow: running multiple instances of the "wsperf" load
> generator/probe
> distributed both in LAN and WAN.
>
> The probe will produce load / tests onto a testee target WS server.
> "wstest": will act as a
> controller for the probes, aggregate results, produce web UI, ..
>
> This thing is preliminary / still in the cooking .. but I think it has the
> potential to take
> "WS testing" to the next level.
>
> http://autobahn.ws/testsuite
> http://www.zaphoyd.com/wsperf
>
> \Tobias
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

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

This is awesome! =A0I can't wait to try wsperf out!

=
Brian

On Wed, Mar 21, 2012 at 2:27 PM, To=
bias Oberstein <tobias.oberstein@tavendo.de> wrote:


There is a new version of the Autobahn WS Te=
stsuite and test reports avail:



=A0* test reports updated for new browser versions + IE10 and WebKit Nightl=
y (Safari)



=A0* test suite now comes completely packaged, easy install/use, no fuss


=A0* test suite now includes 12 modes



The modes: 2 are the known "fuzzing" modes to produce WS impl. re=
ports (client+server)



New modes: echo, broadcast, testee, .. additional handy tools for WS implem=
entors/devs.



And in particular:



We have started collaborating with the WebSocket++ project (Peter Thorson) =
to build a

distributed WS load generator / performance testing tool.



In one mode it will allow: running multiple instances of the "wsperf&q=
uot; load generator/probe

distributed both in LAN and WAN.



The probe will produce load / tests onto a testee target WS server. "w=
stest": will act as a

controller for the probes, aggregate results, produce web UI, ..



This thing is preliminary / still in the cooking .. but I think it has the =
potential to take

"WS testing" to the next level.



http://autobahn.=
ws/testsuite

http://www.zaph=
oyd.com/wsperf



\Tobias

_______________________________________________

hybi mailing list

hybi@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/hybi





--f46d04463166bae57304bbc7fb7d--

From stpeter@stpeter.im  Wed Mar 21 16:41:48 2012
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 04DB121E8142 for ; Wed, 21 Mar 2012 16:41:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.637
X-Spam-Level: 
X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxAHb4YtY3u8 for ; Wed, 21 Mar 2012 16:41:47 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8208C21E80ED for ; Wed, 21 Mar 2012 16:41:47 -0700 (PDT)
Received: from squire.local (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7DCFE4005B; Wed, 21 Mar 2012 17:54:32 -0600 (MDT)
Message-ID: <4F6A673A.2010403@stpeter.im>
Date: Wed, 21 Mar 2012 17:41:46 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Bjoern Hoehrmann 
References: <20120307191713.B5D1262179@rfc-editor.org>  <4F57FD15.2030703@stpeter.im> <9fvfl7dc444d23n3539v6ep5a0kighhfjd@hive.bjoern.hoehrmann.de>
In-Reply-To: <9fvfl7dc444d23n3539v6ep5a0kighhfjd@hive.bjoern.hoehrmann.de>
X-Enigmail-Version: 1.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150)
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: Wed, 21 Mar 2012 23:41:48 -0000

On 3/7/12 5:37 PM, Bjoern Hoehrmann wrote:
> * Peter Saint-Andre wrote:
>> On 3/7/12 5:24 PM, Bjoern Hoehrmann wrote:
>>> If this is true, why did we fail to catch this in time? Was it added
>>> late, for instance? (I would like an analysis to support discussions
>>> whether to create a review team specifically for this kind of formal
>>> syntax error.)
>>
>> As far as I can tell from the erratum, this was a problem with
>> generation of an example, not a syntax error.
> 
> Base64 is a formal language. Unlike interpreting english prose, people
> are not good at spotting problems with formal languages, in the case
> here they would most probably have to use software to verify the code.
> That it occurs in an example does not really matter, people would like-
> ly use the examples in the specification for their first tests, and if
> they come up with different results there is costly confusion, to the
> point that people might change their correct implementation so it re-
> produces the example, which would lead to interoperability problems. I
> think we should try to avoid this kind of costly bug, and understanding
> how we ended up with it, if the report is correct, is the first step.

Understood.

Alexey, can you verify that the example is incorrect?

Peter

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



From tyoshino@google.com  Wed Mar 21 21:51:14 2012
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 01A9521E8086 for ; Wed, 21 Mar 2012 21:51:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.959
X-Spam-Level: 
X-Spam-Status: No, score=-102.959 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AM1JuxDDcub1 for ; Wed, 21 Mar 2012 21:51:13 -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 8782521E8027 for ; Wed, 21 Mar 2012 21:51:12 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so1671490ggm.31 for ; Wed, 21 Mar 2012 21:51:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=UZuFcTlycY86T36yr6gMGcuPAYEArlpq2xmqq65HqCE=; b=locYxw/Mj6o11C2EpLtzkQ2O+ofLvct7hPbRmmrlQrT88F7b1f6j4MWT3rk3yekXa5 ENhgtdQywla/1R+ATsTQnYg48pQwB92c6UDKuneuVA5HdT9NjcjjuyKnGCcovqlOwBe9 uf3ZSixiUL5EIl18GJ2mJhHq6ewefEL2/66StEaeERqJnvBOtrcnmWDDjkLww0NuctEd ivLP1BGC1JlhO5nY+FPyf+JHQRs31XzupDNk22f7J13RYAcpX9qEZ/Q/kbBFpc1R9gMi XZfk7E5sT7t9xrhnizAVthjNP/zLNHl+5CBNnNQpFStQfUlTeuI4Ntno2UFo4zN5H28c 5gSw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=UZuFcTlycY86T36yr6gMGcuPAYEArlpq2xmqq65HqCE=; b=U4GtwM0+V8VNYBdyNG6N/XNCkMm/lAdWwN/5CVwckzFd+9Yydf2wDb1wjlFru1ZAUc Uwfys4HbqPwFC8IO/ZEqOeruU4Teb5fp1f8y+SnLFNC+C+lnBt0gG3cFzdeWuABKaN0J 8OSGKmyxijxunYlvyEI14qgpsyff1mdoOmtPCEvqReDxRRv/1WEN9A8RJdIQnzXvbO4T qDfGYQ4odU5tli5I67V0W/RhhkcKz64y0HLdDajn+qGarAKfippbDMAMuf2lXiwH6W2z xHdlUwLjH1izUSlYD6e361TaOTB4WteD0r5WfZys3och3/T4O0g4FSEAe0dA3tHrpVk4 lkvQ==
Received: by 10.236.195.38 with SMTP id o26mr6411818yhn.100.1332391871824; Wed, 21 Mar 2012 21:51:11 -0700 (PDT)
Received: by 10.236.195.38 with SMTP id o26mr6411806yhn.100.1332391871592; Wed, 21 Mar 2012 21:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Wed, 21 Mar 2012 21:50:51 -0700 (PDT)
In-Reply-To: <4F6A673A.2010403@stpeter.im>
References: <20120307191713.B5D1262179@rfc-editor.org>  <4F57FD15.2030703@stpeter.im> <9fvfl7dc444d23n3539v6ep5a0kighhfjd@hive.bjoern.hoehrmann.de> <4F6A673A.2010403@stpeter.im>
From: Takeshi Yoshino 
Date: Thu, 22 Mar 2012 13:50:51 +0900
Message-ID: 
To: Peter Saint-Andre 
Content-Type: multipart/alternative; boundary=20cf305e276335399e04bbcda894
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkVf11E/rgHPnvTtd6SJS4PHqV+4dNjQgsq+93lDZz0Y6zrVvzNrqPXiHd8EKpkAvkNoEMF1ENj9a6/mavKoe1r0r8PfCOZACemFtEO/2pcrzfHjNr7UZYDYz6Z74TGXxpt7OWW
Cc: hybi@ietf.org, Bjoern Hoehrmann 
Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150)
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, 22 Mar 2012 04:51:14 -0000

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

On Thu, Mar 22, 2012 at 08:41, Peter Saint-Andre  wrote:

> On 3/7/12 5:37 PM, Bjoern Hoehrmann wrote:
> > * Peter Saint-Andre wrote:
> >> On 3/7/12 5:24 PM, Bjoern Hoehrmann wrote:
> >>> If this is true, why did we fail to catch this in time? Was it added
> >>> late, for instance? (I would like an analysis to support discussions
> >>> whether to create a review team specifically for this kind of formal
> >>> syntax error.)
>

This text was introduced in 03->04 update to provide example for
Sec-WebSocket-Key and Sec-WebSocket-Nonce (no longer used), and was also
used in the example of opening handshake as a value for Sec-WebSocket-Nonce.
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-04

On 05->06 update, we dropped Sec-WebSocket-Nonce but left the text as an
example of base64 encoding procedure, and it remained in the RFC.
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06


> >>
> >> As far as I can tell from the erratum, this was a problem with
> >> generation of an example, not a syntax error.
> >
> > Base64 is a formal language. Unlike interpreting english prose, people
> > are not good at spotting problems with formal languages, in the case
> > here they would most probably have to use software to verify the code.
> > That it occurs in an example does not really matter, people would like-
> > ly use the examples in the specification for their first tests, and if
> > they come up with different results there is costly confusion, to the
> > point that people might change their correct implementation so it re-
> > produces the example, which would lead to interoperability problems. I
>

It makes sense.

In this particular case, I think it doesn't cause such confusion so much
since it's not used anywhere else and it's unlikely that people implement
base64 encoder by themselves and then check if their implementation is
working correctly using this test vector. It's also the reason why we
didn't notice this error in implementing/testing handshake processor code.
We never thought using this in our tests.


> > think we should try to avoid this kind of costly bug, and understanding
> > how we ended up with it, if the report is correct, is the first step.
>
> Understood.
>
> Alexey, can you verify that the example is incorrect?


+1 for the reported errata.

RFC 4648
- Section 3.5 "These pad bits MUST be set to zero by conforming encoders,
which is described in the descriptions on padding below."
- Section 4 Paragraph 6 "When fewer than 24 input bits are available in an
input group, bits with value zero are added (on the right) to form an
integral number of 6-bit groups."

Values for "EC" are 0b000100 0b000010 in binary. The last unused 4 bits
0010 must be 0000.

Takeshi

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


On Thu, Mar 22, 2012 at 08:41, Peter Saint-Andre=
 <stpeter@stpete=
r.im> wrote:



On 3/7/12 5:37 PM, Bjoern Hoehrmann wrote:

> * Peter Saint-Andre wrote:

>> On 3/7/12 5:24 PM, Bjoern Hoehrmann wrote:

>>> If this is true, why did we fail to catch this in time? Was it=
 added

>>> late, for instance? (I would like an analysis to support discu=
ssions

>>> whether to create a review team specifically for this kind of =
formal

>>> syntax error.)



This text was introduced in 03->0=
4 update to provide example for Sec-WebSocket-Key and Sec-WebSocket-Nonce (=
no longer used), and was also used in the example of opening handshake as a=
 value for Sec-WebSocket-Nonce.




On 05->06 update, we dropped Sec-WebSocket-Non=
ce but left the text as an example of base64 encoding procedure, and it rem=
ained in the RFC.
=A0
>&g=
t;

>> As far as I can tell from the erratum, this was a problem with

>> generation of an example, not a syntax error.

>

> Base64 is a formal language. Unlike interpreting english prose, people=


> are not good at spotting problems with formal languages, in the case
> here they would most probably have to use software to verify the code.=


> That it occurs in an example does not really matter, people would like=
-

> ly use the examples in the specification for their first tests, and if=


> they come up with different results there is costly confusion, to the<=
br>
> point that people might change their correct implementation so it re-<=
br>
> produces the example, which would lead to interoperability problems. I=


It makes sense.

In this particular case, I think it doesn't cause such confusi=
on so much since it's not used anywhere else and it's unlikely that=
 people implement base64 encoder=A0by themselves and then check if their im=
plementation is working correctly using this test vector. It's also the=
 reason why we didn't notice this error in implementing/testing handsha=
ke processor code. We never thought using this in our tests.



=A0

> think we should try to avoid this kind of costly bug, and understandin=
g

> how we ended up with it, if the report is correct, is the first step.<=
br>



Understood.



Alexey, can you verify that the example is incorrect?

=

+1 for the reported errata.

RFC 4648
- Section 3.5 "These pad bits MUST be set to=A0zero by conform=
ing encoders, which is described in the descriptions=A0on padding below.&qu=
ot;



- Section 4 Paragraph 6=A0"When fewer than 24 input=A0bits are av=
ailable in an input group, bits with value zero are added=A0(on the right) =
to form an integral number of 6-bit groups."

=
Values for "EC" are 0b000100 0b000010 in binary. The last unused =
4 bits 0010 must be 0000.




Takeshi
=A0


--20cf305e276335399e04bbcda894--

From stpeter@stpeter.im  Thu Mar 22 11:12:01 2012
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 8A57A21E802B for ; Thu, 22 Mar 2012 11:12:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.693
X-Spam-Level: 
X-Spam-Status: No, score=-102.693 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24DnxJlqZ5Zu for ; Thu, 22 Mar 2012 11:12:00 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7A85321E8027 for ; Thu, 22 Mar 2012 11:12:00 -0700 (PDT)
Received: from dhcp-64-101-72-171.cisco.com (unknown [64.101.72.171]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id EAEC54009B; Thu, 22 Mar 2012 12:24:47 -0600 (MDT)
Message-ID: <4F6B6B6E.1030402@stpeter.im>
Date: Thu, 22 Mar 2012 12:11:58 -0600
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: Takeshi Yoshino 
References: <20120307191713.B5D1262179@rfc-editor.org>  <4F57FD15.2030703@stpeter.im> <9fvfl7dc444d23n3539v6ep5a0kighhfjd@hive.bjoern.hoehrmann.de> <4F6A673A.2010403@stpeter.im> 
In-Reply-To: 
X-Enigmail-Version: 1.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org, Bjoern Hoehrmann 
Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150)
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, 22 Mar 2012 18:12:01 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 3/21/12 10:50 PM, Takeshi Yoshino wrote:
> On Thu, Mar 22, 2012 at 08:41, Peter Saint-Andre
> > wrote:
> 
> On 3/7/12 5:37 PM, Bjoern Hoehrmann wrote:
>> * Peter Saint-Andre wrote:
>>> On 3/7/12 5:24 PM, Bjoern Hoehrmann wrote:
>>>> If this is true, why did we fail to catch this in time? Was
>>>> it added late, for instance? (I would like an analysis to
>>>> support discussions whether to create a review team
>>>> specifically for this kind of formal syntax error.)
> 
> 
> This text was introduced in 03->04 update to provide example for 
> Sec-WebSocket-Key and Sec-WebSocket-Nonce (no longer used), and was
> also used in the example of opening handshake as a value for
> Sec-WebSocket-Nonce. 
> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-04
> 
> On 05->06 update, we dropped Sec-WebSocket-Nonce but left the text
> as an example of base64 encoding procedure, and it remained in the
> RFC. 
> http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06
> 
> 
>>> 
>>> As far as I can tell from the erratum, this was a problem with 
>>> generation of an example, not a syntax error.
>> 
>> Base64 is a formal language. Unlike interpreting english prose,
>> people are not good at spotting problems with formal languages,
>> in the case here they would most probably have to use software to
>> verify the code. That it occurs in an example does not really
>> matter, people would
> like-
>> ly use the examples in the specification for their first tests,
>> and if they come up with different results there is costly
>> confusion, to the point that people might change their correct
>> implementation so it re- produces the example, which would lead
>> to interoperability problems. I
> 
> 
> It makes sense.
> 
> In this particular case, I think it doesn't cause such confusion so
> much since it's not used anywhere else and it's unlikely that
> people implement base64 encoder by themselves and then check if
> their implementation is working correctly using this test vector.
> It's also the reason why we didn't notice this error in
> implementing/testing handshake processor code. We never thought
> using this in our tests.
> 
> 
>> think we should try to avoid this kind of costly bug, and
> understanding
>> how we ended up with it, if the report is correct, is the first
>> step.
> 
> Understood.
> 
> Alexey, can you verify that the example is incorrect?
> 
> 
> +1 for the reported errata.
> 
> RFC 4648 - Section 3.5 "These pad bits MUST be set to zero by
> conforming encoders, which is described in the descriptions on
> padding below." - Section 4 Paragraph 6 "When fewer than 24 input
> bits are available in an input group, bits with value zero are
> added (on the right) to form an integral number of 6-bit groups."
> 
> Values for "EC" are 0b000100 0b000010 in binary. The last unused 4
> bits 0010 must be 0000.

Takeshi, thank you for checking. I shall process this erratum as
"Verified".

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9ra24ACgkQNL8k5A2w/vyw2ACguwbmF4XUYA5DCub9skEdoVgh
RCkAoOF/P4fVbZwJS2kPeN+X+SsQjqki
=Ap9Z
-----END PGP SIGNATURE-----

From tyoshino@google.com  Thu Mar 22 23:22:30 2012
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 DA4BA21E8039 for ; Thu, 22 Mar 2012 23:22:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.96
X-Spam-Level: 
X-Spam-Status: No, score=-102.96 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g+y+TQOisaOH for ; Thu, 22 Mar 2012 23:22:30 -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 D8B8D21E8013 for ; Thu, 22 Mar 2012 23:22:29 -0700 (PDT)
Received: by yenm5 with SMTP id m5so2738744yen.31 for ; Thu, 22 Mar 2012 23:22:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=C314BeXJ+i2uSIpCahWTMmOxrXTsRALaTjYbNuGeHTE=; b=N3fxLM7LM/55JBd99117eN+B66cbrKZv49nV5kD13KWlTCJVAHMJcUIdKxdwiALQwl /q8xD9WzmUOJuxcLs/xQy78En5mTZhaY3VFvayWQ6Wlxb672hC+l2i4w8nE2F624hbIW dEQOu3qPUuE9Rn4YbmQpxHandSeye66SOSTYoe5xuN7PMb0dmN9dMlY/9ENswslZd0OF cZe9eDjqQg4v3O+4U7RXJq21FMz2qG29mnyYc+oEY/FE/vRS2w4PYagUgutjVqn/0Sv+ vv7AEx1F41ZdlguB50y6MxQuL+2FRLOQ9hhOtmT1eyhMn0zWo1hkbfzd70h2rLUNe5SO fygg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=C314BeXJ+i2uSIpCahWTMmOxrXTsRALaTjYbNuGeHTE=; b=Qk/a+KVbdKSgrTIkdMmRZzuWOOeBAMjHCjExy27xhnI5s9eP0uCXZ83Tl3rFB1VtpT MZy94n1hITAQyFm+VBaLLaOuOLEaO3kJ/6mQ8MJvvsv9JhchOaXvzvT4iLnIVAToaUED EzOEwn6OeDZdhtJOdOzVcMMcrFyR6ZVBUGyVsoCXyd/XHeyFv7C7Ml0QL4dQ5KQcTCz9 HOtnP8ASjACX1HMPfDpiTXyINuktIGcLndqq8k6C9U2KzszXnutD7BHk1tATz5AB8u7T blQx/g0o7Y5if0IielaqDaeGp7rJcoraYPZEDKmmzG/4blm45gFQfpp7LOLVcjx6qs+8 RKaQ==
Received: by 10.236.195.38 with SMTP id o26mr10880546yhn.100.1332483748917; Thu, 22 Mar 2012 23:22:28 -0700 (PDT)
Received: by 10.236.195.38 with SMTP id o26mr10880540yhn.100.1332483748749; Thu, 22 Mar 2012 23:22:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Thu, 22 Mar 2012 23:22:08 -0700 (PDT)
In-Reply-To: <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>
From: Takeshi Yoshino 
Date: Fri, 23 Mar 2012 15:22:08 +0900
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf305e276383633304bbe30c43
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmDo0y0h+VvUdo6H4NuphbbPZENfu1yd+rFqLjtS+i2QsXg0+z8Y3grVP9sXpiBzTEMNBvoiPD3J+UJQXoQyig3fYKLAeQBKweWuknoi+qcyZdHC7JygsWtKiwGNxwxPwscAGlq
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 23 Mar 2012 06:22:31 -0000

--20cf305e276383633304bbe30c43
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The idea in my mind is that the DropChannel command works similar to TCP
FIN/RST when no mux is used. I.e., each logical channel still exchanges
close frames (with their channel ID in extension data portion) and uses
status code in them (e.g. CloseEvent's code attribute), and after handling
them, each side issues the DropChannel command as well as TCP shutdown.

So, there's no such problem with graceful shutdown for logical channels'
traffic. In terms of control traffic, we may receive some mux command for
logical channel X after sending DropChannel command for X, but for now we
can just ignore any of control commands safely:
- FlowControl X -> safe to ignore
- DropChannel X -> no problem. it's totally fine that both sides drop the
same channel at the same time.
- AddChannel X -> if we receive this, it just means the other peer is
misbehaving

That said, we can't distinguish this from invalid commands sent by broken
peers (e.g. logical channel Y never existed but received command for Y).
Maybe it's better to have endpoints respond to DropChannel as well as close
frame to sync active channel list.

Thanks
Takeshi


On Mon, Mar 19, 2012 at 23:37, Arman Djusupov  wrote:

> The procedure of closing the logical channel is not detailed enough.
> Closing the logical channel should be performed in a way similar to closi=
ng
> the websocket connection when no mux extension is used. We need a close
> control frame to roundtrip in order to ensure the mutual agreement betwee=
n
> the two sides when a logical channel is closed. Currently the specificati=
on
> does not require the side that receives a DropChannel control frame to
> reply to it (unless I missed something), which does not ensure the gracef=
ul
> closure of logical channels.****
>
> ** **
>
> =93When an endpoint received DropChannel, the endpoint MUST remove the lo=
gical channel and the application instance that used the logical channel MU=
ST treat this as closure of underlying transport.=93****
>
> ** **
>
> One side could be in the process of sending a message when it receives a =
DropChannel frame, so it is important to ensure that the logical channel is=
 closed gracefully without dead channel frames left on the wire. The best w=
ay to do it is to let the DropChannel frame roundtrip back to its sender. W=
hen both sides have received the DropChannel frame they are in mutual agree=
ment to release the channel ID, being sure that no more frames with the sam=
e channel ID are expected to arrive from the remote side.****
>
> ** **
>
> With best regards,****
>
> Arman
>
>

--20cf305e276383633304bbe30c43
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The idea in my mind is that the DropChannel command works similar to TCP FI=
N/RST when no mux is used. I.e., each logical channel still exchanges close=
 frames (with their channel ID in extension data portion) and uses status c=
ode in them (e.g. CloseEvent's code attribute), and after handling them=
, each side issues the DropChannel command as well as TCP shutdown.



So, there's no such problem with graceful shutdown for l=
ogical channels' traffic. In terms of control traffic, we may receive s=
ome mux command for logical channel X after sending DropChannel command for=
 X, but for now we can just ignore any of control commands safely:



- FlowControl X -> safe to ignore
- DropChannel X -> n=
o problem. it's totally fine that both sides drop the same channel at t=
he same time.
- AddChannel X -> if we receive this, =
it just means the other peer is misbehaving



That said, we can't =
distinguish this from invalid commands sent by broken peers (e.g. logical c=
hannel Y never existed but received command for Y). Maybe it's better t=
o have endpoints respond to DropChannel as well as close frame to sync acti=
ve channel list.





Thanks
Takeshi



On Mon, Mar 19, 2012 at 23:37, Arman Dju=
supov <arman@noemax.com> wrote:




The procedure of closing the logical channel=
 is not detailed enough. Closing the logical channel should be performed in=
 a way similar to closing the websocket connection when no mux extension is=
 used. We need a close control frame to roundtrip in order to ensure the mu=
tual agreement between the two sides when a logical channel is closed. Curr=
ently the specification does not require the side that receives a DropChann=
el control frame to reply to it (unless I missed something), which does not=
 ensure the graceful closure of logical channels.




=A0<=
/p>
=93When an endpoint received DropChannel, the endpoint MUST remove <=
span>the logical channel and the application instance that used the logical=
 channel MUST treat this as closure of underlying transport.=93




=A0
One side could be in the process of sending a message wh=
en it receives a DropChannel frame,=A0so it is important to ensure that the=
 logical channel is closed gracefully without dead channel frames left on t=
he wire. The best way to do it is to let the DropChannel frame roundtrip ba=
ck to its sender. When both sides have received the DropChannel frame they =
are in mutual agreement to release the channel ID, being sure that no more =
frames with the same channel ID are expected to arrive from the remote side=
.




=A0
With best regards,




Arman
=





--20cf305e276383633304bbe30c43--

From arman@noemax.com  Fri Mar 23 01:14:36 2012
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 97EE721F8499 for ; Fri, 23 Mar 2012 01:14:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.392
X-Spam-Level: 
X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.206,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqRDSe6WmYFJ for ; Fri, 23 Mar 2012 01:14:30 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 78E4221F8458 for ; Fri, 23 Mar 2012 01:14:29 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id HLL98325; Fri, 23 Mar 2012 10:14:25 +0200
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com> 
In-Reply-To: 
Date: Fri, 23 Mar 2012 10:14:33 +0200
Message-ID: <001b01cd08cc$fe9ac980$fbd05c80$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01CD08DD.C224D200"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZeVD2fj0A==
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 23 Mar 2012 08:14:36 -0000

This is a multipart message in MIME format.

------=_NextPart_000_001C_01CD08DD.C224D200
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Takeshi,

 

Using both a DropChannel and a close frame to close a logical channel seems
like overkill. Exchanging DropChannel control messages should be enough for
mutual shutdown of a logical channel. A more important issue is that if a
close frame is sent through an intermediary that does not understand the mux
extension, the intermediary may simply drop the physical channel /
connection. It's easy to imagine a frame compression intermediary that would
simply stop reading from the network connection once it encounters a close
frame (as per WS spec no data is expected to follow the close frame). So
probably the sending of a close frame should be avoided (i.e. prohibited)
for logical channels.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, March 23, 2012 8:22 AM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

The idea in my mind is that the DropChannel command works similar to TCP
FIN/RST when no mux is used. I.e., each logical channel still exchanges
close frames (with their channel ID in extension data portion) and uses
status code in them (e.g. CloseEvent's code attribute), and after handling
them, each side issues the DropChannel command as well as TCP shutdown.

 

So, there's no such problem with graceful shutdown for logical channels'
traffic. In terms of control traffic, we may receive some mux command for
logical channel X after sending DropChannel command for X, but for now we
can just ignore any of control commands safely:

- FlowControl X -> safe to ignore

- DropChannel X -> no problem. it's totally fine that both sides drop the
same channel at the same time.

- AddChannel X -> if we receive this, it just means the other peer is
misbehaving

 

That said, we can't distinguish this from invalid commands sent by broken
peers (e.g. logical channel Y never existed but received command for Y).
Maybe it's better to have endpoints respond to DropChannel as well as close
frame to sync active channel list.

 

Thanks
Takeshi



On Mon, Mar 19, 2012 at 23:37, Arman Djusupov  wrote:

The procedure of closing the logical channel is not detailed enough. Closing
the logical channel should be performed in a way similar to closing the
websocket connection when no mux extension is used. We need a close control
frame to roundtrip in order to ensure the mutual agreement between the two
sides when a logical channel is closed. Currently the specification does not
require the side that receives a DropChannel control frame to reply to it
(unless I missed something), which does not ensure the graceful closure of
logical channels.

 

"When an endpoint received DropChannel, the endpoint MUST remove the logical
channel and the application instance that used the logical channel MUST
treat this as closure of underlying transport."
 
One side could be in the process of sending a message when it receives a
DropChannel frame, so it is important to ensure that the logical channel is
closed gracefully without dead channel frames left on the wire. The best way
to do it is to let the DropChannel frame roundtrip back to its sender. When
both sides have received the DropChannel frame they are in mutual agreement
to release the channel ID, being sure that no more frames with the same
channel ID are expected to arrive from the remote side.
 
With best regards,
Arman

------=_NextPart_000_001C_01CD08DD.C224D200
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hello =
Takeshi,
 
Using both a DropChannel and a close frame to close =
a logical channel seems like overkill. Exchanging DropChannel control =
messages should be enough for mutual shutdown of a logical channel. A =
more important issue is that if a close frame is sent through an =
intermediary that does not understand the mux extension, the =
intermediary may simply drop the physical channel / connection. =
It’s easy to imagine a frame compression intermediary that would =
simply stop reading from the network connection once it encounters a =
close frame (as per WS spec no data is expected to follow the close =
frame). So probably the sending of a close frame should be avoided (i.e. =
prohibited) for logical channels.
 
With =
best regards,
Arman
 
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, =
March 23, 2012 8:22 AM
To: Arman Djusupov
Cc: =
hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec =
draft 03
 
The idea in =
my mind is that the DropChannel command works similar to TCP FIN/RST =
when no mux is used. I.e., each logical channel still exchanges close =
frames (with their channel ID in extension data portion) and uses status =
code in them (e.g. CloseEvent's code attribute), and after handling =
them, each side issues the DropChannel command as well as TCP =
shutdown.
 
So, there's no such problem with graceful shutdown for =
logical channels' traffic. In terms of control traffic, we may receive =
some mux command for logical channel X after sending DropChannel command =
for X, but for now we can just ignore any of control commands =
safely:
- FlowControl X =
-> safe to ignore
- =
DropChannel X -> no problem. it's totally fine that both sides drop =
the same channel at the same time.
- AddChannel X -> if we receive this, it just means =
the other peer is misbehaving
 
That said, we can't distinguish this from invalid =
commands sent by broken peers (e.g. logical channel Y never existed but =
received command for Y). Maybe it's better to have endpoints respond to =
DropChannel as well as close frame to sync active channel =
list.
 
Thanks
Takeshi

On =
Mon, Mar 19, 2012 at 23:37, Arman Djusupov <arman@noemax.com> =
wrote:
The procedure of closing the logical channel is not detailed enough. =
Closing the logical channel should be performed in a way similar to =
closing the websocket connection when no mux extension is used. We need =
a close control frame to roundtrip in order to ensure the mutual =
agreement between the two sides when a logical channel is closed. =
Currently the specification does not require the side that receives a =
DropChannel control frame to reply to it (unless I missed something), =
which does not ensure the graceful closure of logical =
channels.
 
“When an endpoint =
received DropChannel, the endpoint MUST remove the logical =
channel and the application instance that used the logical channel MUST =
treat this as closure of underlying transport.“
 
One side could be in the process of sending a message when it =
receives a DropChannel frame, so it is important to ensure that the =
logical channel is closed gracefully without dead channel frames left on =
the wire. The best way to do it is to let the DropChannel frame =
roundtrip back to its sender. When both sides have received the =
DropChannel frame they are in mutual agreement to release the channel =
ID, being sure that no more frames with the same channel ID are expected =
to arrive from the remote side.
 
With best regards,
Arman

------=_NextPart_000_001C_01CD08DD.C224D200--


From alexey.melnikov@isode.com  Fri Mar 23 02:00:54 2012
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 67E0F21F84EB for ; Fri, 23 Mar 2012 02:00: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=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeDGcbAlWYyh for ; Fri, 23 Mar 2012 02:00:49 -0700 (PDT)
Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0905821F84B2 for ; Fri, 23 Mar 2012 02:00:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1332493243; d=isode.com; s=selector; i=@isode.com; bh=tUrNGcTziqDHfu/IZuqdRcP41OVNji1SAYaREOJmnZk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=wI6tvYC7oCtaiTBfJQdRGPpdcJoFUAzsrUzYjdC9MUEVCzJLPiRMNZjE63dpFGGB+qgtD0 xYz4ONQwB3YZwv0tAGCijN+pIfyYPB4NBpiCACGeTUiu2Og9oUnoZ13fZDuZawExGH3ph7 rIPEQLS6UuekaB1ruiqUpC18l64Gp6M=;
Received: from [192.168.1.79] (191.49.12.93.rev.sfr.net [93.12.49.191])  by rufus.isode.com (submission channel) via TCP with ESMTPSA  id ; Fri, 23 Mar 2012 09:00:43 +0000
X-SMTP-Protocol-Errors: PIPELINING
Message-ID: <4F6C3BBB.1070904@isode.com>
Date: Fri, 23 Mar 2012 10:00:43 +0100
From: Alexey Melnikov 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
To: Peter Saint-Andre , Takeshi Yoshino 
References: <20120307191713.B5D1262179@rfc-editor.org>  <4F57FD15.2030703@stpeter.im> <9fvfl7dc444d23n3539v6ep5a0kighhfjd@hive.bjoern.hoehrmann.de> <4F6A673A.2010403@stpeter.im>  <4F6B6B6E.1030402@stpeter.im>
In-Reply-To: <4F6B6B6E.1030402@stpeter.im>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org, Bjoern Hoehrmann 
Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3150)
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, 23 Mar 2012 09:00:54 -0000

On 22/03/2012 19:11, Peter Saint-Andre wrote:
> On 3/21/12 10:50 PM, Takeshi Yoshino wrote:
>> On Thu, Mar 22, 2012 at 08:41, Peter Saint-Andre
>> >  wrote:
>>
>> Alexey, can you verify that the example is incorrect?
>>
>>
>> +1 for the reported errata.
>>
>> RFC 4648 - Section 3.5 "These pad bits MUST be set to zero by
>> conforming encoders, which is described in the descriptions on
>> padding below." - Section 4 Paragraph 6 "When fewer than 24 input
>> bits are available in an input group, bits with value zero are
>> added (on the right) to form an integral number of 6-bit groups."
>>
>> Values for "EC" are 0b000100 0b000010 in binary. The last unused 4
>> bits 0010 must be 0000.
> Takeshi, thank you for checking. I shall process this erratum as
> "Verified".
This looks correct. Thank you Takeshi.


From arman@noemax.com  Fri Mar 23 02:38:17 2012
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 B0CCC21F854D for ; Fri, 23 Mar 2012 02:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.412
X-Spam-Level: 
X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0sGdXf20ZFTn for ; Fri, 23 Mar 2012 02:38:14 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 893FA21F8548 for ; Fri, 23 Mar 2012 02:38:14 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id HMJ07711; Fri, 23 Mar 2012 11:38:11 +0200
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com> 
In-Reply-To: 
Date: Fri, 23 Mar 2012 11:38:18 +0200
Message-ID: <003b01cd08d8$b1dd7050$159850f0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_003C_01CD08E9.75692680"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZeVD36uQA==
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 23 Mar 2012 09:38:17 -0000

This is a multipart message in MIME format.

------=_NextPart_000_003C_01CD08E9.75692680
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Takeshi,

 

Currently the specification does not make it clear which side assigns a
channel ID when an AddChannel control message is sent. I think this could be
made flexible; for example if Objective Channel ID is set to 0 then this
means that the client prefers the server to select the channel ID, if it is
greater than 1 then the client requests a specific channel ID.

 

Giving the client the option to select the channel ID can facilitate the use
of application-specific channel IDs, where the predefined logical channel ID
is reserved for a specific role, e.g. 1 - Video channel, 2 - Voice channel,
3 - Control channel, 4 - Subtitles channel (optional). 

 

It is also worth mentioning in the spec that the protocol specified by the
Sec-WebSocket-Protocol header MAY define a default set of logical channels
that are considered as being implicitly established when the mux extension
is agreed. Some protocols, as mentioned above, may require a fixed set of
channels with predefined IDs. Negotiating the same set of channel IDs using
an AddChannel request<->response every time a new connection is established
would not be efficient. It should be permitted for the "protocol" to imply a
default set of channels that don't need to be negotiated (at least this
should not be against the specification).

 

As an example, when Sec-WebSocket-Protocol set to "smart-playback" would
mean then once the mux is negotiated the following logical channels are
considered already established: 1 - Video, 2 - Voice, 3 - Control,  4 -
Subtitles.

 

I think this would make the specification much more versatile.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, March 23, 2012 8:22 AM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

The idea in my mind is that the DropChannel command works similar to TCP
FIN/RST when no mux is used. I.e., each logical channel still exchanges
close frames (with their channel ID in extension data portion) and uses
status code in them (e.g. CloseEvent's code attribute), and after handling
them, each side issues the DropChannel command as well as TCP shutdown.

 

So, there's no such problem with graceful shutdown for logical channels'
traffic. In terms of control traffic, we may receive some mux command for
logical channel X after sending DropChannel command for X, but for now we
can just ignore any of control commands safely:

- FlowControl X -> safe to ignore

- DropChannel X -> no problem. it's totally fine that both sides drop the
same channel at the same time.

- AddChannel X -> if we receive this, it just means the other peer is
misbehaving

 

That said, we can't distinguish this from invalid commands sent by broken
peers (e.g. logical channel Y never existed but received command for Y).
Maybe it's better to have endpoints respond to DropChannel as well as close
frame to sync active channel list.

 

Thanks
Takeshi



On Mon, Mar 19, 2012 at 23:37, Arman Djusupov  wrote:

The procedure of closing the logical channel is not detailed enough. Closing
the logical channel should be performed in a way similar to closing the
websocket connection when no mux extension is used. We need a close control
frame to roundtrip in order to ensure the mutual agreement between the two
sides when a logical channel is closed. Currently the specification does not
require the side that receives a DropChannel control frame to reply to it
(unless I missed something), which does not ensure the graceful closure of
logical channels.

 

"When an endpoint received DropChannel, the endpoint MUST remove the logical
channel and the application instance that used the logical channel MUST
treat this as closure of underlying transport."
 
One side could be in the process of sending a message when it receives a
DropChannel frame, so it is important to ensure that the logical channel is
closed gracefully without dead channel frames left on the wire. The best way
to do it is to let the DropChannel frame roundtrip back to its sender. When
both sides have received the DropChannel frame they are in mutual agreement
to release the channel ID, being sure that no more frames with the same
channel ID are expected to arrive from the remote side.
 
With best regards,
Arman

------=_NextPart_000_003C_01CD08E9.75692680
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hello =
Takeshi,
 
Currently the specification does not make it clear =
which side assigns a channel ID when an AddChannel control message is =
sent. I think this could be made flexible; for example if Objective =
Channel ID is set to 0 then this means that the client prefers the =
server to select the channel ID, if it is greater than 1 then the client =
requests a specific channel ID.
 
Giving =
the client the option to select the channel ID can facilitate the use of =
application-specific channel IDs, where the predefined logical channel =
ID is reserved for a specific role, e.g. 1 - Video channel, 2 - Voice =
channel, 3 - Control channel, 4 - Subtitles channel (optional). =

 
It is also worth mentioning in the spec that the =
protocol specified by the Sec-WebSocket-Protocol header MAY define a =
default set of logical channels that are considered as being implicitly =
established when the mux extension is agreed. Some protocols, as =
mentioned above, may require a fixed set of channels with predefined =
IDs. Negotiating the same set of channel IDs using an AddChannel =
request<->response every time a new connection is established =
would not be efficient. It should be permitted for the =
“protocol” to imply a default set of channels that =
don’t need to be negotiated (at least this should not be against =
the specification).
 
As an =
example, when Sec-WebSocket-Protocol set to “smart-playback” =
would mean then once the mux is negotiated the following logical =
channels are considered already established: 1 - Video, 2 - Voice, 3 - =
Control,  4 - Subtitles.
 
I =
think this would make the specification much more =
versatile.
 
With best regards,
Arman
 
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, =
March 23, 2012 8:22 AM
To: Arman Djusupov
Cc: =
hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec =
draft 03
 
The idea in =
my mind is that the DropChannel command works similar to TCP FIN/RST =
when no mux is used. I.e., each logical channel still exchanges close =
frames (with their channel ID in extension data portion) and uses status =
code in them (e.g. CloseEvent's code attribute), and after handling =
them, each side issues the DropChannel command as well as TCP =
shutdown.
 
So, there's no such problem with graceful shutdown for =
logical channels' traffic. In terms of control traffic, we may receive =
some mux command for logical channel X after sending DropChannel command =
for X, but for now we can just ignore any of control commands =
safely:
- FlowControl X =
-> safe to ignore
- =
DropChannel X -> no problem. it's totally fine that both sides drop =
the same channel at the same time.
- AddChannel X -> if we receive this, it just means =
the other peer is misbehaving
 
That said, we can't distinguish this from invalid =
commands sent by broken peers (e.g. logical channel Y never existed but =
received command for Y). Maybe it's better to have endpoints respond to =
DropChannel as well as close frame to sync active channel =
list.
 
Thanks
Takeshi

On =
Mon, Mar 19, 2012 at 23:37, Arman Djusupov <arman@noemax.com> =
wrote:
The procedure of closing the logical channel is not detailed enough. =
Closing the logical channel should be performed in a way similar to =
closing the websocket connection when no mux extension is used. We need =
a close control frame to roundtrip in order to ensure the mutual =
agreement between the two sides when a logical channel is closed. =
Currently the specification does not require the side that receives a =
DropChannel control frame to reply to it (unless I missed something), =
which does not ensure the graceful closure of logical =
channels.
 
“When an endpoint =
received DropChannel, the endpoint MUST remove the logical =
channel and the application instance that used the logical channel MUST =
treat this as closure of underlying transport.“
 
One side could be in the process of sending a message when it =
receives a DropChannel frame, so it is important to ensure that the =
logical channel is closed gracefully without dead channel frames left on =
the wire. The best way to do it is to let the DropChannel frame =
roundtrip back to its sender. When both sides have received the =
DropChannel frame they are in mutual agreement to release the channel =
ID, being sure that no more frames with the same channel ID are expected =
to arrive from the remote side.
 
With best regards,
Arman

------=_NextPart_000_003C_01CD08E9.75692680--


From tyoshino@google.com  Fri Mar 23 02:45:41 2012
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 DAD0E21F8541 for ; Fri, 23 Mar 2012 02:45:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.961
X-Spam-Level: 
X-Spam-Status: No, score=-102.961 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByifZWZCpWAi for ; Fri, 23 Mar 2012 02:45:37 -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 82B3621F849B for ; Fri, 23 Mar 2012 02:45:37 -0700 (PDT)
Received: by yenm5 with SMTP id m5so2833601yen.31 for ; Fri, 23 Mar 2012 02:45:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=gHYGx7rz5lFm4TlxPjlOZGhSkyAxGK3oB5g4zgzoqFE=; b=kSFRneWm4VUoqv1h6++Two3+T0BfCyBMu19ffN0Ln5f0a4ilLIfaE1aKjjYIbHX+sy zvMLKDKe1+GuoR8v41QvalgA8KiZVMCteDM14Mbrek096zlTo8wC9rQr4X8k9d+AaVQn 26iBiQTlNWbigvZqPQ+KguNjdjHNm/T3hdaBzyU7g68FhPEBLqCJJC330Wd/shpt0VRd t2i5myrJYPj1GUz1OILzVIOJPZ2j5oIwpgaX/cj08d7ivfYuijo5YZh7tU+7OR9BTGC+ HdIcJRwPlrJifEV8+wYZEvBCJOdahzHb/Mpwzf/2tuL2jw6nX/gm13m0u1bWt3/ICR3z Ogrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=gHYGx7rz5lFm4TlxPjlOZGhSkyAxGK3oB5g4zgzoqFE=; b=k5r7Llm+TPhN/yDOoClvj1bpPWkteN/2l2H58O+xecDvty4X+DCGEIHClTFJDtQ1By bDp4gmFjJ/hrUua5qopczuc534NiqFZ+v+wBPAQWjYsqJf5wRhq9iBAluvxYYVVzqL+l bV1eURGW9V6/bkB6I/5QyVFcl7BBMXNocbLimUVVCBDE+TQcpAj10g3SjisoS931HUzH snw8wT4Me6SPrutBo3YjjOPs+Y87TKjrfTmKn3mynW1ildiGwy3uthcmQZy/y3U84dvZ wt/D7WvC2vjRQHNMUcmYZlSBLyCWd+jQ5K55YvuZqB5/sfAl9LpO4bxe7c9yWSWNrKB1 lt9A==
Received: by 10.236.195.38 with SMTP id o26mr11413213yhn.100.1332495933938; Fri, 23 Mar 2012 02:45:33 -0700 (PDT)
Received: by 10.236.195.38 with SMTP id o26mr11413207yhn.100.1332495933856; Fri, 23 Mar 2012 02:45:33 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Fri, 23 Mar 2012 02:45:13 -0700 (PDT)
In-Reply-To: <001b01cd08cc$fe9ac980$fbd05c80$@noemax.com>
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <001b01cd08cc$fe9ac980$fbd05c80$@noemax.com>
From: Takeshi Yoshino 
Date: Fri, 23 Mar 2012 18:45:13 +0900
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf305e2763cd59ed04bbe5e2d0
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmmdtR28snWoSiRZvRs0sxMLhaHaAeWiaAd7Rht9F4K7NyxtCqoDLx8RNj3s4IT5urXk/ufh9s3UfNRBXmMKb50qrP57fb/NOSQdvfNuMKM0ZxTOOmEx8KcXAi9jn3zEJ2z4940
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 23 Mar 2012 09:45:42 -0000

--20cf305e2763cd59ed04bbe5e2d0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 23, 2012 at 17:14, Arman Djusupov  wrote:

> Hello Takeshi,****
>
> ** **
>
> Using both a DropChannel and a close frame to close a logical channel
> seems like overkill.
>
The original aim of addition of DropChannel was only to provide a way to
terminate logical channel which is behaving abnormally by some command out
of that logical channel.

To make abstraction simple, I gave it a role to terminate a logical channel
normally, too. But I'm ok with getting normal close done by only one
command (one close frame, one DropChannel command, etc.)

> Exchanging DropChannel control messages should be enough for mutual
> shutdown of a logical channel. A more important issue is that if a close
> frame is sent through an intermediary that does not understand the mux
> extension, the intermediary may simply drop the physical channel /
> connection.
>
I understand your concern. Actually, IIRC it was one of the motivation to
introduce close frame that a close frame tells intermediaries the end of
session instead of unreliable TCP FIN so that they can release resource for
the session more quickly.

John's original proposal was adding a new framing onto WebSocket framing to
implement multiplexing. There was some discussion about this and some
suggested  reuse of opcode in base framing. See this thread for example
http://www.ietf.org/mail-archive/web/hybi/current/msg07240.html.

> It=92s easy to imagine a frame compression intermediary that would simply
> stop reading from the network connection once it encounters a close frame
> (as per WS spec no data is expected to follow the close frame). So probab=
ly
> the sending of a close frame should be avoided (i.e. prohibited) for
> logical channels.
>
I'd like to disallow any control frame with channel ID !=3D 0 and have
corresponding mux commands for each of them if we take this approach rather
than just converting close frame into DropChannel ad-hoc.

Also we need to give DropChannel some field to hold the information close
frame has (status and reason).

--20cf305e2763cd59ed04bbe5e2d0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Fri, Mar 23, 2012 at 17:14, Arman Djusupov <arman@noemax.com> wrote:



Hello Takeshi,
=A0
Using both a DropChannel and a c=
lose frame to close a logical channel seems like overkill.
<=
/blockquote>


The original aim of addition of DropChannel was only to provide a way =
to terminate logical channel which is behaving abnormally by some command o=
ut of that logical channel.

To make abstraction si=
mple, I gave it a role to terminate a logical channel normally, too. But I&=
#39;m ok with getting normal close done by only one command (one close fram=
e, one DropChannel command, etc.)



 Exchanging DropChannel control messages should be enough fo=
r mutual shutdown of a logical channel. A more important issue is that if a=
 close frame is sent through an intermediary that does not understand the m=
ux extension, the intermediary may simply drop the physical channel / conne=
ction.



I understand your concern. Actually, IIRC it =
was one of the motivation to introduce close frame that a close frame tells=
 intermediaries the end of session instead of unreliable TCP FIN so that th=
ey can release resource for the session more quickly.







It=92s easy to imagine a frame compression intermediary that=
 would simply stop reading from the network connection once it encounters a=
 close frame (as per WS spec no data is expected to follow the close frame)=
. So probably the sending of a close frame should be avoided (i.e. prohibit=
ed) for logical channels.



I'd like to disallow any control frame wi=
th channel ID !=3D 0 and have corresponding mux commands for each of them i=
f we take this approach rather than just converting close frame into DropCh=
annel ad-hoc.




Also we need to give DropChannel some field to hold the=
 information close frame has (status and reason).
=A0


--20cf305e2763cd59ed04bbe5e2d0--

From arman@noemax.com  Fri Mar 23 04:51:49 2012
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 6749A21F853A for ; Fri, 23 Mar 2012 04:51:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.429
X-Spam-Level: 
X-Spam-Status: No, score=-2.429 tagged_above=-999 required=5 tests=[AWL=0.169,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf+1sZXyh9+K for ; Fri, 23 Mar 2012 04:51:45 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id BE00021F854B for ; Fri, 23 Mar 2012 04:51:44 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id HOW13941; Fri, 23 Mar 2012 13:51:41 +0200
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <001b01cd08cc$fe9ac980$fbd05c80$@noemax.com> 
In-Reply-To: 
Date: Fri, 23 Mar 2012 13:51:48 +0200
Message-ID: <005101cd08eb$585ab9d0$09102d70$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01CD08FC.1BE4C250"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZcB1dWGPQEs3XHLlPeOnsA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 23 Mar 2012 11:51:49 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0052_01CD08FC.1BE4C250
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I think it's OK to disallow control frames with a channel ID other than 0.
Since WS control frames apply to a physical channel,  I'm not sure they
should apply to mux logical channels too (it will always confuse
intermediaries that are not mux aware). We could actually create a single
mux command for delivering all types of logical channel control frames,
including custom opCodes that might be assigned in future. In such a case we
need a general purpose mux control command to move control frames of logical
channels with their opCode, RSV bits and payload. 

 

The more I think about it the fewer other options I see. A mux-aware
intermediary will have to forward close frames and their payload, while a
mux-unaware intermediary might kill the connection when encountering such a
frame. This means that the control frames of a logical channel need to be
enveloped into a mux command message, unless we figure out a better
solution.

 

With best regards,

Arman

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, March 23, 2012 11:45 AM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

On Fri, Mar 23, 2012 at 17:14, Arman Djusupov  wrote:

Hello Takeshi,

 

Using both a DropChannel and a close frame to close a logical channel seems
like overkill.

The original aim of addition of DropChannel was only to provide a way to
terminate logical channel which is behaving abnormally by some command out
of that logical channel.

 

To make abstraction simple, I gave it a role to terminate a logical channel
normally, too. But I'm ok with getting normal close done by only one command
(one close frame, one DropChannel command, etc.)

Exchanging DropChannel control messages should be enough for mutual shutdown
of a logical channel. A more important issue is that if a close frame is
sent through an intermediary that does not understand the mux extension, the
intermediary may simply drop the physical channel / connection.

I understand your concern. Actually, IIRC it was one of the motivation to
introduce close frame that a close frame tells intermediaries the end of
session instead of unreliable TCP FIN so that they can release resource for
the session more quickly.

 

John's original proposal was adding a new framing onto WebSocket framing to
implement multiplexing. There was some discussion about this and some
suggested  reuse of opcode in base framing. See this thread for example
http://www.ietf.org/mail-archive/web/hybi/current/msg07240.html.

It's easy to imagine a frame compression intermediary that would simply stop
reading from the network connection once it encounters a close frame (as per
WS spec no data is expected to follow the close frame). So probably the
sending of a close frame should be avoided (i.e. prohibited) for logical
channels.

I'd like to disallow any control frame with channel ID != 0 and have
corresponding mux commands for each of them if we take this approach rather
than just converting close frame into DropChannel ad-hoc.

 

Also we need to give DropChannel some field to hold the information close
frame has (status and reason).

 


------=_NextPart_000_0052_01CD08FC.1BE4C250
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I think it’s OK to disallow control frames with a channel ID =
other than 0. Since WS control frames apply to a physical channel,  =
I’m not sure they should apply to mux logical channels too (it =
will always confuse intermediaries that are not mux aware). We could =
actually create a single mux command for delivering all types of logical =
channel control frames, including custom opCodes that might be assigned =
in future. In such a case we need a general purpose mux control command =
to move control frames of logical channels with their opCode, RSV bits =
and payload. 
 
The more I think about it the fewer other options I see. A mux-aware =
intermediary will have to forward close frames and their payload, while =
a mux-unaware intermediary might kill the connection when encountering =
such a frame. This means that the control frames of a logical channel =
need to be enveloped into a mux command message, unless we figure out a =
better solution…
 
With best regards,
Arman
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, =
March 23, 2012 11:45 AM
To: Arman Djusupov
Cc: =
hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec =
draft 03
 
On Fri, =
Mar 23, 2012 at 17:14, Arman Djusupov <arman@noemax.com> =
wrote:
Hello =
Takeshi,
 
Using both a =
DropChannel and a close frame to close a logical channel seems like =
overkill.
The =
original aim of addition of DropChannel was only to provide a way to =
terminate logical channel which is behaving abnormally by some command =
out of that logical channel.
 
To make abstraction simple, I gave it a role to =
terminate a logical channel normally, too. But I'm ok with getting =
normal close done by only one command (one close frame, one DropChannel =
command, etc.)
Exchanging =
DropChannel control messages should be enough for mutual shutdown of a =
logical channel. A more important issue is that if a close frame is sent =
through an intermediary that does not understand the mux extension, the =
intermediary may simply drop the physical channel / =
connection.
I understand your concern. Actually, IIRC it was one =
of the motivation to introduce close frame that a close frame tells =
intermediaries the end of session instead of unreliable TCP FIN so that =
they can release resource for the session more =
quickly.
 
John's original proposal was adding a new framing onto =
WebSocket framing to implement multiplexing. There was some discussion =
about this and some suggested  reuse of opcode in base framing. See =
this thread for example =
http://www.ietf.org/mail-archive/web/hybi/current/msg07240.html.=

It’s easy =
to imagine a frame compression intermediary that would simply stop =
reading from the network connection once it encounters a close frame (as =
per WS spec no data is expected to follow the close frame). So probably =
the sending of a close frame should be avoided (i.e. prohibited) for =
logical channels.
I'd like to disallow any control frame with channel ID =
!=3D 0 and have corresponding mux commands for each of them if we take =
this approach rather than just converting close frame into DropChannel =
ad-hoc.
 
Also we need to give DropChannel some field to hold =
the information close frame has (status and =
reason).
 

------=_NextPart_000_0052_01CD08FC.1BE4C250--


From tyoshino@google.com  Fri Mar 23 11:57:58 2012
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 4FE0C21F8639 for ; Fri, 23 Mar 2012 11:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level: 
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te2Q2+KyFHjl for ; Fri, 23 Mar 2012 11:57:57 -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 395CA21F8627 for ; Fri, 23 Mar 2012 11:57:57 -0700 (PDT)
Received: by ghbg16 with SMTP id g16so3371510ghb.31 for ; Fri, 23 Mar 2012 11:57:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Qwl736bdQKtHOMVVywnsIYFBT+1iTy2u/TpAUt1sLrA=; b=mNpmHtQdEjcPb+e6LLwoT7M++Gp8cK0IO1BDACNpzTLJHzYE0IPZVO6K/pZnz3v4sS abAT1a/KuwN+FInWbms0/8uLuNXiJJ0y1uCKCqbwMvcjFQmCCfs/Aae6XIufa40y66qP DNjjtt2qaHgrPYRYWWgLYfxVVkVSIu/5EmV4THNoCfHNhZVk/SOMeW7QMa9jIXzNJoQv ubw2z2SBp9n6zqyPjY7r/dr7XnrU66aN7Vx/fyysiC1dHBA5JE8iUtA9uyDZt7d5NH10 8H8+Q8Efk1ElT6dL4KcGBdtwAZFQu455Uyc2rllo9NyYYKlqCuZGFf2C+ESM684haufj qbbA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=Qwl736bdQKtHOMVVywnsIYFBT+1iTy2u/TpAUt1sLrA=; b=WwQrlyt6zuZSmmWqD+zDXnM3rlBxR6ZS/uCgwSky7xxL77QRaqdKq95UPYsfW7Rb7I FwaJcU2wChtkWUIXQr/tAUA/6ISFVXJ6drGKpmD4HvP5TcaLrcT892GvSJsnSVH1iELf nO+XDo5UK5LAG1upZLU83EHzTqKurPbdNrElXPofubEU/rJ4O7usgwlHntuu3fnU3o4c Hd0POfUHyYUldfNpNI5iM+2h3keMrt/8VTRaOi2NRZ1BJRIwMkf5HXRGKHRyppM8L1l3 qZRIK9ZJ+1nG9LACMltdydv4iVuIcwRvYF1rIMlqj8P9/Rio4ncwkkWQlN30jCv6YHNM tT1Q==
Received: by 10.236.195.38 with SMTP id o26mr13411508yhn.100.1332529076438; Fri, 23 Mar 2012 11:57:56 -0700 (PDT)
Received: by 10.236.195.38 with SMTP id o26mr13411499yhn.100.1332529076323; Fri, 23 Mar 2012 11:57:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Fri, 23 Mar 2012 11:57:36 -0700 (PDT)
In-Reply-To: <003b01cd08d8$b1dd7050$159850f0$@noemax.com>
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>
From: Takeshi Yoshino 
Date: Sat, 24 Mar 2012 03:57:36 +0900
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf305e27633f468904bbed9ae1
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkvUj/AEm2vBKbnpqHtLjysSIwicsMpj8yjRwAmpMn7CrWyiRzqjpGegFS0DomPDdNF5s7PbbW5hWjJuP8UZOlDitYHP0OMR7sGEQ7lMfzmpM30n0qad86I6tfr15j2NwhmOqzX
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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, 23 Mar 2012 18:57:58 -0000

--20cf305e27633f468904bbed9ae1
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Hello Arman,

On Fri, Mar 23, 2012 at 18:38, Arman Djusupov  wrote:

> Currently the specification does not make it clear which side assigns a
> channel ID when an AddChannel control message is sent. I think this could
> be made flexible; for example if Objective Channel ID is set to 0 then th=
is
> means that the client prefers the server to select the channel ID, if it =
is
> greater than 1 then the client requests a specific channel ID.
>
> **
>
> ** **
>
> Giving the client the option to select the channel ID can facilitate the
> use of application-specific channel IDs, where the predefined logical
> channel ID is reserved for a specific role, e.g. 1 - Video channel, 2 -
> Voice channel, 3 - Control channel, 4 - Subtitles channel (optional).
>
Some people were discussing intermediaries with mux capacity which
bundle/unbundle logical channels. Here, your proposal seems to try to use
channel ID values as service identifier (like port number of TCP/UDP). It
doesn't go together with such intermediaries. To make this work, we need to
ensure in the spec that channel ID is preserved between endpoints.

IMO, channel IDs should be hidden to application level and resource or
Sec-WebSocket-Protocol should be used for such mapping instead as well as
WebSocket w/o mux.

Are you also going to use mux to provide multiple channels (e.g. video,
voice, ...) but keep them grouped for one session (e.g. video conference
session consists of them)? If so, we need to ensure in the spec that
logical channels must not be unbundled into separate physical channels.

These new restrictions enables the usage as you described, but also
complicates the spec. For me as one of browser developer, they're
unnecessary. The current mux extension's goal is to provide logical
equivalent of normal WebSocket connections in one TCP connection. Your
proposal is beyond that. I'd like to get more opinions on these points.

> ****
>
> ** **
>
> It is also worth mentioning in the spec that the protocol specified by th=
e
> Sec-WebSocket-Protocol header MAY define a default set of logical channel=
s
> that are considered as being implicitly established when the mux extensio=
n
> is agreed. Some protocols, as mentioned above, may require a fixed set of
> channels with predefined IDs. Negotiating the same set of channel IDs usi=
ng
> an AddChannel request<->response every time a new connection is establish=
ed
> would not be efficient.
>
Providing a way to open multiple logical connections at once is
interesting. As I said above, basically I prefer to realizing it by adding
some way to issue AddChannel commands (different resources may be used to
tell which service each logical channel wants to access) on handshake.

How about this, for example?

C->S Sec-WebSocket-Extensions: mux; preopen=3D"vc-video, vc-voice,
vc-control, vc-subtitle"
(each comma-separated element in preopen parameter's value means value of
Sec-WebSocket-Protocol)

S->C Sec-WebSocket-Extensions: mux; preopen=3D"vc-video=3D1, vc-voice=3D2,
vc-control=3D3, vc-subtitle=3D4"
and the server sends back 4 AddChannel responses.

We don't have to pay additional RTT though change on request headers is
limited to Sec-WebSocket-Protocol.

We may also add some grouping annotation.

(OT. I don't want core specs to say that Sec-WebSocket-Protocol has
capability to change WebSocket protocol's behavior. Such modification
should be made using extension framework. Also, for now,
Sec-WebSocket-Protocol is an attribute for each logical channel. I'm
disinclined to invite headers other than Sec-WebSocket-Extensions to
determine physical channel (mux extension)'s behavior.)

> It should be permitted for the =93protocol=94 to imply a default set of
> channels that don=92t need to be negotiated (at least this should not be
> against the specification).****
>
> **
>
I don't object to make it able to define/use such preset. Maybe useful.

> **
>
> As an example, when Sec-WebSocket-Protocol set to =93smart-playback=94 wo=
uld
> mean then once the mux is negotiated the following logical channels are
> considered already established: 1 - Video, 2 - Voice, 3 - Control,  4 -
> Subtitles.****
>
> ** **
>
> I think this would make the specification much more versatile.
>

--20cf305e27633f468904bbed9ae1
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Hello Arman,
On Fri, Mar 23, 2012 at 18:38, Arman Djus=
upov <arman@noemax.com> wrote:





Currently the specifi=
cation does not make it clear which side assigns a channel ID when an AddCh=
annel control message is sent. I think this could be made flexible; for exa=
mple if Objective Channel ID is set to 0 then this means that the client pr=
efers the server to select the channel ID, if it is greater than 1 then the=
 client requests a specific channel ID.





=A0
Giving the client the option to select the chann=
el ID can facilitate the use of application-specific channel IDs, where the=
 predefined logical channel ID is reserved for a specific role, e.g. 1 - Vi=
deo channel, 2 - Voice channel, 3 - Control channel, 4 - Subtitles channel =
(optional).




Some people were discussing intermediaries with mux=
 capacity which bundle/unbundle logical channels. Here, your proposal seems=
 to try to use channel ID values as service identifier (like port number of=
 TCP/UDP). It doesn't go together with such intermediaries. To make thi=
s work, we need to ensure in the spec that channel ID is preserved between =
endpoints.




IMO, channel IDs should be hidden to application level =
and resource or Sec-WebSocket-Protocol should be used for such mapping inst=
ead as well as WebSocket w/o mux.

Are you also goi=
ng to use mux to provide multiple channels (e.g. video, voice, ...) but kee=
p them grouped for one session (e.g. video conference session consists of t=
hem)? If so, we need to ensure in the spec that logical channels must not b=
e unbundled into separate physical channels.




These new restrictions enables the usage as you describ=
ed, but also complicates the spec. For me as one of browser developer, they=
're unnecessary. The current mux extension's goal is to provide log=
ical equivalent of normal WebSocket connections in one TCP connection. Your=
 proposal is beyond that. I'd like to get more opinions on these points=
.




 
=A0
It is also wor=
th mentioning in the spec that the protocol specified by the Sec-WebSocket-=
Protocol header MAY define a default set of logical channels that are consi=
dered as being implicitly established when the mux extension is agreed. Som=
e protocols, as mentioned above, may require a fixed set of channels with p=
redefined IDs. Negotiating the same set of channel IDs using an AddChannel =
request<->response every time a new connection is established would n=
ot be efficient.




Providing a way to open multiple logical conn=
ections at once is interesting. As I said above, basically I prefer to real=
izing it by adding some way to issue AddChannel commands (different resourc=
es may be used to tell which service each logical channel wants to access) =
on handshake.




How about this, for example?

C=
->S Sec-WebSocket-Extensions: mux; preopen=3D"vc-video, vc-voice, v=
c-control, vc-subtitle"
(each comma-separated element in pre=
open parameter's value means value of Sec-WebSocket-Protocol)




S->C Sec-WebSocket-Extensions: mux; preopen=3D"=
vc-video=3D1, vc-voice=3D2, vc-control=3D3, vc-subtitle=3D4"
and the server sends back 4 AddChannel responses.

We don't have to pay additional RTT though change on request headers i=
s limited to Sec-WebSocket-Protocol.




We may also add some grouping annotation.
(OT. I don't want core specs to say that Sec-WebSocket-Prot=
ocol has capability to change WebSocket protocol's behavior. Such modif=
ication should be made using extension framework. Also, for now, Sec-WebSoc=
ket-Protocol is an attribute for each logical channel. I'm disinclined =
to invite headers other than Sec-WebSocket-Extensions to determine physical=
 channel (mux extension)'s behavior.)




 It should be permitted for the =93protocol=94 to imply a de=
fault set of channels that don=92t need to be negotiated (at least this sho=
uld not be against the specification).




=A0
I don't object to make i=
t able to define/use such preset. Maybe useful.



As an e=
xample, when Sec-WebSocket-Protocol set to =93smart-playback=94 would mean =
then once the mux is negotiated the following logical channels are consider=
ed already established: 1 - Video, 2 - Voice, 3 - Control,=A0 4 - Subtitles=
.




=A0
I think this would make the specification much m=
ore versatile.


--20cf305e27633f468904bbed9ae1--

From tyoshino@google.com  Fri Mar 23 19:56:49 2012
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 EBB9521F84F1 for ; Fri, 23 Mar 2012 19:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level: 
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nJ4Wk4zTLfK for ; Fri, 23 Mar 2012 19:56:49 -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 F08E121F84EC for ; Fri, 23 Mar 2012 19:56:48 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so3574620ggm.31 for ; Fri, 23 Mar 2012 19:56:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=OSksdgYu94IBcL6erk5gfUygHSwNFcWWvoIhrs+UEMw=; b=iy3kcqXPKXUXlKREMap/rGCGDML7x30LRGuppikjDcVUU8gy0CdzK+78DK1108QUE0 86GO4hG4MC415htl0+SmKLVHz+2mqzCZfJyIJCdaffOOEHSS+K+7OGPy/xgpNd2SKOgE rdsa4tIEO9dHFvmj1eyGo2HhUWZQDkEub8YAx0x+kg5q2tXdbmoLC1cpJyqctzwGWl8d 8KvJK2INP9vQnXBGZJqEvWo4Tf6xnbeoAm1Z8W5xbhp+JTvpXaMlifcxO60Ctov8sFTQ RTG478T4TVptDbG0wgiL7KHF3S3zXwnKHvAIjCS9ciphe8vUGWa2CRr45LeUzK1vBeoJ GTIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=OSksdgYu94IBcL6erk5gfUygHSwNFcWWvoIhrs+UEMw=; b=NgzeJDEEYlm12y0fi1o1UH+bBgKbHGkhau1kU8CkAne+dmfFtCi4Otrr7vtLqKyKLT TcAZHSf1irItw/KCPMEyleTb4mk3gbqJ7ttw599rOjhU2cUXFxJG5iOs9ELvYI9DQBXW iBDbHGLF5H+0imVCmO1bbKGeO96LrHEIkRlFkhcekzfEP39ECNvwhXbYGhpwKruj4OeL z+yfh8YzfsEYz5GkHoqvBjjx80HFhilFBxKdgCsvtmkwwVHR36lIlB+z7EtHZXLL9Vy+ UJ6f+e/ZkeGsqxk9PRh1+nA+PaMLpXVVLkRw6uzxYrP57vCLJuWSGycwYLXolneUeocG Eeow==
Received: by 10.236.174.106 with SMTP id w70mr14317837yhl.68.1332557808161; Fri, 23 Mar 2012 19:56:48 -0700 (PDT)
Received: by 10.236.174.106 with SMTP id w70mr14317830yhl.68.1332557807993; Fri, 23 Mar 2012 19:56:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Fri, 23 Mar 2012 19:56:27 -0700 (PDT)
In-Reply-To: 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com> 
From: Takeshi Yoshino 
Date: Sat, 24 Mar 2012 11:56:27 +0900
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf3040e3bcc9c54d04bbf44a4f
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmz+X0dxB9bsXM/AXXClrLxHvmDeZ1XxbCazQy2ySM+68pRvapBbyrQrO3lfl5Y0YN665Kph3lK6AMdadtcVE7xBysNXPoxwZ0vlWx561ySL6gtC0k604oE+NIQqdIflO4KR7Jj
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Sat, 24 Mar 2012 02:56:50 -0000

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

On Sat, Mar 24, 2012 at 03:57, Takeshi Yoshino  wrote:

> How about this, for example?
>
> C->S Sec-WebSocket-Extensions: mux; preopen="vc-video, vc-voice,
> vc-control, vc-subtitle"
> (each comma-separated element in preopen parameter's value means value of
> Sec-WebSocket-Protocol)
>
> S->C Sec-WebSocket-Extensions: mux; preopen="vc-video=1, vc-voice=2,
> vc-control=3, vc-subtitle=4"
> and the server sends back 4 AddChannel responses.
>

Sorry. This example was wrong.

C->S
- Sec-WebSocket-Extensions: mux; add="vc-video=1, vc-voice=2, vc-control=3,
vc-subtitle=4"
(Format: =)

S->C
- Sec-WebSocket-Extensions: mux; add="vc-video, vc-voice, vc-control,
vc-subtitle"
- 4 AddChannel responses

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


On Sat, Mar 24, 2012 at 03:57, Takeshi Yoshino <=
span dir=3D"ltr"><tyoshino@google=
.com> wrote:



How about this, for example?

C->S Sec-WebSocket-Extensions: mux; pre=
open=3D"vc-video, vc-voice, vc-control, vc-subtitle"
(e=
ach comma-separated element in preopen parameter's value means value of=
 Sec-WebSocket-Protocol)





S->C Sec-WebSocket-Extensions: mux; preopen=3D"=
vc-video=3D1, vc-voice=3D2, vc-control=3D3, vc-subtitle=3D4"
and the server sends back 4 AddChannel responses.
=




Sorry. This example was wrong.

C-&g=
t;S
- Sec-WebSocket-Extensions: mux; add=3D"vc-video=3D1, vc=
-voice=3D2, vc-control=3D3, vc-subtitle=3D4"
(Format: <su=
bprotocol>=3D<channel ID>)




S->C
- Sec-WebSocket-Extensions: mux; add=
=3D"vc-video, vc-voice, vc-control, vc-subtitle"

- 4 AddChannel responses


--20cf3040e3bcc9c54d04bbf44a4f--

From gregw@intalio.com  Sun Mar 25 14:54:52 2012
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 6592821E8012 for ; Sun, 25 Mar 2012 14:54:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.814
X-Spam-Level: 
X-Spam-Status: No, score=-2.814 tagged_above=-999 required=5 tests=[AWL=0.163,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 978NxJYRIIZE for ; Sun, 25 Mar 2012 14:54:51 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id B79B221E800C for ; Sun, 25 Mar 2012 14:54:51 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so3420191qcs.31 for ; Sun, 25 Mar 2012 14:54:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=r0s6rdh3T0e0Z/eAcOkGxUJdOEJwkEX4Pk+F+7ky4Qo=; b=VDJLW3Ei0pcD4S/zuFcfOV79wBB2SJ8y7yctot5iviTbgOdbUT6yuDocbijJjcOx1i QJcgsZOlO+BkBfCvOvVLoXfaEEDgR9OKyi1q9i7KGAHJmquyg/ddkrNr35HdZ1V2S1Bw v0lmfFR5Q/Q+ZWTg2agLJ1A+i6ONbzhYHRE/yOnsX83GAHgDMhYiZFOO41+ON12iuNJx 9RSp52NxiwmXeNvf9BjYgIcalHX7I3ZBOXfhRiWGNdmD0Gd1nTDFeXkteFlsYEAWmW1/ QvmyhE3vcL1V8vc5AMcGbn3ItrraoQN4wMzIBDsJ8c/KSBjyUg8c9iQOqx8eIGgLVnkf oolg==
MIME-Version: 1.0
Received: by 10.224.105.79 with SMTP id s15mr25254505qao.35.1332712491126; Sun, 25 Mar 2012 14:54:51 -0700 (PDT)
Received: by 10.229.249.18 with HTTP; Sun, 25 Mar 2012 14:54:51 -0700 (PDT)
In-Reply-To: <20120316192113.GC13250@1wt.eu>
References: <20120316101850.GA10202@1wt.eu> <634914A010D0B943A035D226786325D42D5BE6DBBF@EXVMBX020-12.exch020.serverdata.net> <20120316110657.GG9940@1wt.eu> <90B18B4B-4CD4-4454-9C77-2DF3F6D5F7DB@bbn.com> <20120316192113.GC13250@1wt.eu>
Date: Mon, 26 Mar 2012 08:54:51 +1100
Message-ID: 
From: Greg Wilkins 
To: Willy Tarreau 
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlAL+1iND+vXK2UL6dzdrHS5fnm3x3unJS6irYx9h/GFGuB550hNx2W4C8xOONi0RPlXNJ7
Cc: Jason Strimpel , "hybi@ietf.org" 
Subject: Re: [hybi] Report of a dirty WS blocking issue with OfficeScan
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: Sun, 25 Mar 2012 21:54:52 -0000

Willy,

I agree that fast fail is desirable, but in this case I cannot see how
we can really change the protocol in order to achieve this.   The
fault for your 3 month search really is that the product does not have
sufficient logging of it's actions to make it obvious that it is
rejecting traffic.

RFC2616 says:

   All 1xx (informational), 204 (no content), and 304 (not modified) responses
   MUST NOT include a message-body. All other responses do include a
   message-body, although it MAY be of zero length.

  4.4
   1.Any response message which "MUST NOT" include a message-body (such
     as the 1xx, 204, and 304 responses and any response to a HEAD
     request) is always terminated by the first empty line after the
     header fields, regardless of the entity-header fields present in
     the message.

  14.13 Applications SHOULD use this field [Content-length] to
indicate the transfer-length of
   the message-body, unless this is prohibited by the rules in section
   4.4.

I certainly have had issues with SOAP clients that have broken on
content-length:0 being sent with a 100 continue response, so I'd fear
that adding that header to 101's might break code that is written
against the RFC.


As for adding a Connection:close to the 101 response, I'm dubious
about it's effectiveness in this situation.   If the intermediary is
thinking this is a 200 response, this it will expect the server to
send a response and then close the connection.  I can't see how this
header would force the intermediary to close the connection on it's
own.  Perhaps if you could conduct some experiments with this product
and some similar ones to see if it would be effective, then that would
strengthen the case to consider it.

cheers








On 17 March 2012 06:21, Willy Tarreau  wrote:
> No, it should have been a connection close by the scanner, that would have
> been detected by the client. When an error happens with an active close, it
> is much easier to spot the culprit because both ends would observe the close,
> so it's easy to find the middle point. But when everything gets stuck with
> everyone thinking the data was properly transmitted, it's very hard to find
> where the problem is.

From arman@noemax.com  Tue Mar 27 03:42:03 2012
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 ECC2821E817A for ; Tue, 27 Mar 2012 03:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.236
X-Spam-Level: 
X-Spam-Status: No, score=-1.236 tagged_above=-999 required=5 tests=[AWL=-1.052, BAYES_40=-0.185, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB07PIFCgC2G for ; Tue, 27 Mar 2012 03:42:02 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id B84C421E8179 for ; Tue, 27 Mar 2012 03:42:01 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id LNQ34255; Tue, 27 Mar 2012 13:41:55 +0300
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  
In-Reply-To: 
Date: Tue, 27 Mar 2012 13:41:54 +0300
Message-ID: <000d01cd0c06$3defdf80$b9cf9e80$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000E_01CD0C1F.633D1780"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZcCh7t1pgGkm8LGAf86ZtaU5H3tUA==
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 10:42:04 -0000

This is a multipart message in MIME format.

------=_NextPart_000_000E_01CD0C1F.633D1780
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The sample is OK. But it would add complexity to the handshake. On the
positive side what we get as a result of such communication is actually
named-channels.

 

So the API can specify a channel by name e.g. socket["voice"].send(data) .

 

I would also like to read more opinions on this.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Saturday, March 24, 2012 4:56 AM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

On Sat, Mar 24, 2012 at 03:57, Takeshi Yoshino  wrote:

How about this, for example?

 

C->S Sec-WebSocket-Extensions: mux; preopen="vc-video, vc-voice, vc-control,
vc-subtitle"

(each comma-separated element in preopen parameter's value means value of
Sec-WebSocket-Protocol)

 

S->C Sec-WebSocket-Extensions: mux; preopen="vc-video=1, vc-voice=2,
vc-control=3, vc-subtitle=4"

and the server sends back 4 AddChannel responses.

 

Sorry. This example was wrong.

 

C->S

- Sec-WebSocket-Extensions: mux; add="vc-video=1, vc-voice=2, vc-control=3,
vc-subtitle=4"

(Format: =)

 

S->C

- Sec-WebSocket-Extensions: mux; add="vc-video, vc-voice, vc-control,
vc-subtitle" 

- 4 AddChannel responses


------=_NextPart_000_000E_01CD0C1F.633D1780
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The =
sample is OK. But it would add complexity to the handshake. On the =
positive side what we get as a result of such communication is actually =
named-channels.
 
So the =
API can specify a channel by name e.g. =
socket[“voice”].send(data) .
 
I =
would also like to read more opinions on this.
 
With =
best regards,
Arman
 
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Saturday, =
March 24, 2012 4:56 AM
To: Arman Djusupov
Cc: =
hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec =
draft 03
 
On Sat, =
Mar 24, 2012 at 03:57, Takeshi Yoshino <tyoshino@google.com> =
wrote:
How about this, for =
example?
 
C->S Sec-WebSocket-Extensions: mux; =
preopen=3D"vc-video, vc-voice, vc-control, =
vc-subtitle"
(each =
comma-separated element in preopen parameter's value means value of =
Sec-WebSocket-Protocol)
 
S->C Sec-WebSocket-Extensions: mux; =
preopen=3D"vc-video=3D1, vc-voice=3D2, vc-control=3D3, =
vc-subtitle=3D4"
and =
the server sends back 4 AddChannel =
responses.
 
Sorry. This example was =
wrong.
 
C->S
- Sec-WebSocket-Extensions: mux; =
add=3D"vc-video=3D1, vc-voice=3D2, vc-control=3D3, =
vc-subtitle=3D4"
(Format: <subprotocol>=3D<channel =
ID>)
 
S->C
- Sec-WebSocket-Extensions: mux; add=3D"vc-video, =
vc-voice, vc-control, vc-subtitle" 
- 4 AddChannel =
responses

------=_NextPart_000_000E_01CD0C1F.633D1780--


From arman@noemax.com  Tue Mar 27 03:42:07 2012
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 64BFC21F85AE for ; Tue, 27 Mar 2012 03:42:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level: 
X-Spam-Status: No, score=-2.362 tagged_above=-999 required=5 tests=[AWL=0.236,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBElWsmwP-J8 for ; Tue, 27 Mar 2012 03:42:03 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 0CCF521E8180 for ; Tue, 27 Mar 2012 03:42:02 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id LNQ46756; Tue, 27 Mar 2012 13:41:56 +0300
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com> 
In-Reply-To: 
Date: Tue, 27 Mar 2012 13:41:54 +0300
Message-ID: <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CD0C1F.63EABCA0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZcCh7t1pgGkm8LGlPR3mEA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 10:42:07 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0013_01CD0C1F.63EABCA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Takeshi,

 

We are not implementing mux for providing video streams specifically, but
for general purpose mux support. I see the mux extension being useful not
only to the browser, but certainly to other types of software too which need
multiple channels in a single connection. It is applicable to all cases when
the client has to reduce the number of concurrent connections to the server
pool.

 

Client-mux intermediary-servers is just one specific use case, once which is
required by browsers. Consider for example a MMO game engine that also uses
mux between the client application and server poo, where the mux
intermediary does not simply bundle and unbundle channels but is designed
specifically for the game requirements and has specific logic on how to
forward each channel based on the channel ID or other criteria. We can
assume that in such cases an incompatible intermediary is not expected to
occur on the wire between the client and server. So the specification is not
required to prohibit the bundling/unbundling of the logical channel or the
change of channel ID.

 

BTW it still unclear which of the communicating sides assigns a channel ID
when an AddChannel request is sent. Since the Objective Channel ID can be
sent both ways, what should be the Objective Channel ID for an AddChannel
request message?

 

It's ok with me if the channel ID cannot be assigned by the client side,
since the application may identify the type of the channel by the first
message sent through the channel. This may cause an extra roundtrip, but it
is not a big deal if we implement some way of opening multiple logical
connections at once.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, March 23, 2012 8:58 PM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

Hello Arman,

 

On Fri, Mar 23, 2012 at 18:38, Arman Djusupov  wrote:

Currently the specification does not make it clear which side assigns a
channel ID when an AddChannel control message is sent. I think this could be
made flexible; for example if Objective Channel ID is set to 0 then this
means that the client prefers the server to select the channel ID, if it is
greater than 1 then the client requests a specific channel ID.

 

Giving the client the option to select the channel ID can facilitate the use
of application-specific channel IDs, where the predefined logical channel ID
is reserved for a specific role, e.g. 1 - Video channel, 2 - Voice channel,
3 - Control channel, 4 - Subtitles channel (optional).

Some people were discussing intermediaries with mux capacity which
bundle/unbundle logical channels. Here, your proposal seems to try to use
channel ID values as service identifier (like port number of TCP/UDP). It
doesn't go together with such intermediaries. To make this work, we need to
ensure in the spec that channel ID is preserved between endpoints.

 

IMO, channel IDs should be hidden to application level and resource or
Sec-WebSocket-Protocol should be used for such mapping instead as well as
WebSocket w/o mux.

 

Are you also going to use mux to provide multiple channels (e.g. video,
voice, ...) but keep them grouped for one session (e.g. video conference
session consists of them)? If so, we need to ensure in the spec that logical
channels must not be unbundled into separate physical channels.

 

These new restrictions enables the usage as you described, but also
complicates the spec. For me as one of browser developer, they're
unnecessary. The current mux extension's goal is to provide logical
equivalent of normal WebSocket connections in one TCP connection. Your
proposal is beyond that. I'd like to get more opinions on these points.

 

It is also worth mentioning in the spec that the protocol specified by the
Sec-WebSocket-Protocol header MAY define a default set of logical channels
that are considered as being implicitly established when the mux extension
is agreed. Some protocols, as mentioned above, may require a fixed set of
channels with predefined IDs. Negotiating the same set of channel IDs using
an AddChannel request<->response every time a new connection is established
would not be efficient.

Providing a way to open multiple logical connections at once is interesting.
As I said above, basically I prefer to realizing it by adding some way to
issue AddChannel commands (different resources may be used to tell which
service each logical channel wants to access) on handshake.

 

How about this, for example?

 

C->S Sec-WebSocket-Extensions: mux; preopen="vc-video, vc-voice, vc-control,
vc-subtitle"

(each comma-separated element in preopen parameter's value means value of
Sec-WebSocket-Protocol)

 

S->C Sec-WebSocket-Extensions: mux; preopen="vc-video=1, vc-voice=2,
vc-control=3, vc-subtitle=4"

and the server sends back 4 AddChannel responses.

 

We don't have to pay additional RTT though change on request headers is
limited to Sec-WebSocket-Protocol.

 

We may also add some grouping annotation.

 

(OT. I don't want core specs to say that Sec-WebSocket-Protocol has
capability to change WebSocket protocol's behavior. Such modification should
be made using extension framework. Also, for now, Sec-WebSocket-Protocol is
an attribute for each logical channel. I'm disinclined to invite headers
other than Sec-WebSocket-Extensions to determine physical channel (mux
extension)'s behavior.)

It should be permitted for the "protocol" to imply a default set of channels
that don't need to be negotiated (at least this should not be against the
specification).

 

I don't object to make it able to define/use such preset. Maybe useful.

As an example, when Sec-WebSocket-Protocol set to "smart-playback" would
mean then once the mux is negotiated the following logical channels are
considered already established: 1 - Video, 2 - Voice, 3 - Control,  4 -
Subtitles.

 

I think this would make the specification much more versatile.


------=_NextPart_000_0013_01CD0C1F.63EABCA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Hello =
Takeshi,
 
We are not implementing mux for providing video =
streams specifically, but for general purpose mux support. I see the mux =
extension being useful not only to the browser, but certainly to other =
types of software too which need multiple channels in a single =
connection. It is applicable to all cases when the client has to reduce =
the number of concurrent connections to the server =
pool.
 
Client-mux intermediary-servers is just one =
specific use case, once which is required by browsers. Consider for =
example a MMO game engine that also uses mux between the client =
application and server poo, where the mux intermediary does not simply =
bundle and unbundle channels but is designed specifically for the game =
requirements and has specific logic on how to forward each channel based =
on the channel ID or other criteria. We can assume that in such cases an =
incompatible intermediary is not expected to occur on the wire between =
the client and server. So the specification is not required to prohibit =
the bundling/unbundling of the logical channel or the change of channel =
ID.
 
BTW it still unclear which of the communicating =
sides assigns a channel ID when an AddChannel request is sent. Since the =
Objective Channel ID can be sent both ways, what should be the Objective =
Channel ID for an AddChannel request message?
 
It's =
ok with me if the channel ID cannot be assigned by the client side, =
since the application may identify the type of the channel by the first =
message sent through the channel. This may cause an extra roundtrip, but =
it is not a big deal if we implement some way of opening multiple =
logical connections at once.
 
With =
best regards,
Arman
 
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Friday, =
March 23, 2012 8:58 PM
To: Arman Djusupov
Cc: =
hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec =
draft 03
 
Hello =
Arman,
 
On Fri, Mar 23, 2012 at 18:38, Arman Djusupov <arman@noemax.com> =
wrote:
Currently the specification does not make =
it clear which side assigns a channel ID when an AddChannel control =
message is sent. I think this could be made flexible; for example if =
Objective Channel ID is set to 0 then this means that the client prefers =
the server to select the channel ID, if it is greater than 1 then the =
client requests a specific channel =
ID.
 
Giving the client the =
option to select the channel ID can facilitate the use of =
application-specific channel IDs, where the predefined logical channel =
ID is reserved for a specific role, e.g. 1 - Video channel, 2 - Voice =
channel, 3 - Control channel, 4 - Subtitles channel =
(optional).
Some people =
were discussing intermediaries with mux capacity which bundle/unbundle =
logical channels. Here, your proposal seems to try to use channel ID =
values as service identifier (like port number of TCP/UDP). It doesn't =
go together with such intermediaries. To make this work, we need to =
ensure in the spec that channel ID is preserved between =
endpoints.
 
IMO, channel IDs should be hidden to application level =
and resource or Sec-WebSocket-Protocol should be used for such mapping =
instead as well as WebSocket w/o mux.
 
Are you also going to use mux to provide multiple =
channels (e.g. video, voice, ...) but keep them grouped for one session =
(e.g. video conference session consists of them)? If so, we need to =
ensure in the spec that logical channels must not be unbundled into =
separate physical channels.
 
These new restrictions enables the usage as you =
described, but also complicates the spec. For me as one of browser =
developer, they're unnecessary. The current mux extension's goal is to =
provide logical equivalent of normal WebSocket connections in one TCP =
connection. Your proposal is beyond that. I'd like to get more opinions =
on these points.
 <=
/p>
It is also worth mentioning in the spec that the protocol =
specified by the Sec-WebSocket-Protocol header MAY define a default set =
of logical channels that are considered as being implicitly established =
when the mux extension is agreed. Some protocols, as mentioned above, =
may require a fixed set of channels with predefined IDs. Negotiating the =
same set of channel IDs using an AddChannel request<->response =
every time a new connection is established would not be =
efficient.
Providing a way to open multiple logical connections =
at once is interesting. As I said above, basically I prefer to realizing =
it by adding some way to issue AddChannel commands (different resources =
may be used to tell which service each logical channel wants to access) =
on handshake.
 
How about this, for =
example?
 
C->S Sec-WebSocket-Extensions: mux; =
preopen=3D"vc-video, vc-voice, vc-control, =
vc-subtitle"
(each =
comma-separated element in preopen parameter's value means value of =
Sec-WebSocket-Protocol)
 
S->C Sec-WebSocket-Extensions: mux; =
preopen=3D"vc-video=3D1, vc-voice=3D2, vc-control=3D3, =
vc-subtitle=3D4"
and =
the server sends back 4 AddChannel =
responses.
 
We don't have to pay additional RTT though change on =
request headers is limited to =
Sec-WebSocket-Protocol.
 
We may also add some grouping =
annotation.
 
(OT. I don't want core specs to say that =
Sec-WebSocket-Protocol has capability to change WebSocket protocol's =
behavior. Such modification should be made using extension framework. =
Also, for now, Sec-WebSocket-Protocol is an attribute for each logical =
channel. I'm disinclined to invite headers other than =
Sec-WebSocket-Extensions to determine physical channel (mux extension)'s =
behavior.)
It should be =
permitted for the “protocol” to imply a default set of =
channels that don’t need to be negotiated (at least this should =
not be against the =
specification).
 
I don't object to make it able to =
define/use such preset. Maybe useful.
As an example, when =
Sec-WebSocket-Protocol set to “smart-playback” would mean =
then once the mux is negotiated the following logical channels are =
considered already established: 1 - Video, 2 - Voice, 3 - Control,  =
4 - Subtitles.
 
I think this =
would make the specification much more =
versatile.

------=_NextPart_000_0013_01CD0C1F.63EABCA0--


From tyoshino@google.com  Tue Mar 27 05:35:16 2012
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 2DDA621E8141 for ; Tue, 27 Mar 2012 05:35:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vizRUOHCnrAh for ; Tue, 27 Mar 2012 05:35:15 -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 68B3821E813C for ; Tue, 27 Mar 2012 05:35:12 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so5059540ggm.31 for ; Tue, 27 Mar 2012 05:35:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=waeWVCgtSUhLHt2rUe4SwEu8ibgwIsGuJtGV8s6RFrs=; b=mI7ZskrI2mPFeqqcT89gVDmZXYFTNiLzVfMgrpNz8ocp2CY/pFj7LBNgcA3kCc/va4 zPGy2lnhirjsOGxgT5H6AmN3rr1nJZ2BkFRvZMFs42mQCgprEbIraeRWPkZYBt+iary/ uANeYTMmzwCXqTvGJjjYeHxZZwhJKRARfc26BnEc2rRyqGIJkVWWQIpz05Nd9QDL0rZh uLDQCYhzJPXVKArdQdwBO6hBBNH6g1fLz5xXPrYKrHDygldOHtEZg+WOH2LmNIS40YX8 Ysv3SvzpJmQiNlAXXFT8yOehqRNOXoLkXZoxaByiV5HRGpwH62SVpY6Px969vkHTRWBY EVAw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=waeWVCgtSUhLHt2rUe4SwEu8ibgwIsGuJtGV8s6RFrs=; b=Fq3AP5y4cBoOGEfSx/krktjTsXrTqqadlhjSruOs9h559AZG86g2fGMySp8lFbx4Q0 1zOdcjy1F8mkf792CfmkK3n7JNkMAeZ2UMSRY/Lhgy7gqfFBw5R73w+Skks7Z3sCP52z fgAAO6/Kj+tCQSEMkytpUlLJg84Iqs6tJ9ryaLVgnKRbGftsYtVZvlGwnmynCxSR51Eo KivuIgyh3EZWtbN3hBb9M0KShRWZB/iKxyTk4q9w+R0Ve1sZ4fxd91HzAzaYnzokiu9X qIUEUxOC4Ae3jQnwxmBQ+rEKV8j+mexGJoola6BqTmBkiMMRzpCrKUUoV+Crt5Gc1qJm s4Rw==
Received: by 10.236.195.38 with SMTP id o26mr25775365yhn.100.1332851711960; Tue, 27 Mar 2012 05:35:11 -0700 (PDT)
Received: by 10.236.195.38 with SMTP id o26mr25775353yhn.100.1332851711863; Tue, 27 Mar 2012 05:35:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Tue, 27 Mar 2012 05:34:51 -0700 (PDT)
In-Reply-To: <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com>
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com>
From: Takeshi Yoshino 
Date: Tue, 27 Mar 2012 14:34:51 +0200
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf305e2763d2ec2904bc38b869
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkQYYqX/I2k+eToqqNaUrqKM8ih/ql9+8nyDxSNW/wa0iqsRgYLhqhkOhF5a/xk2yKWlcedvzicH8jm4rju7P8IvdBGPuMJiLP4l6j4rdN/qDNkCL0PFuBLWaA7N1koT7DdzSy4
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 12:35:16 -0000

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

Hi,

On Tue, Mar 27, 2012 at 12:41, Arman Djusupov  wrote:

> We are not implementing mux for providing video streams specifically, but
> for general purpose mux support. I see the mux extension being useful not
> only to the browser, but certainly to other types of software too which
> need multiple channels in a single connection.
>
Yes, that's why I didn't object to use of mux ID but just showed concern
about intermediaries' bundle/unbundle.

>  It is applicable to all cases when the client has to reduce the number of
> concurrent connections to the server pool.****
>
> ** **
>
> Client-mux intermediary-servers is just one specific use case, once which
> is required by browsers. Consider for example a MMO game engine that also
> uses mux between the client application and server poo, where the mux
> intermediary does not simply bundle and unbundle channels but is designed
> specifically for the game requirements and has specific logic on how to
> forward each channel based on the channel ID or other criteria. We can
> assume that in such cases an incompatible intermediary is not expected to
> occur on the wire between the client and server. So the specification is
> not required to prohibit the bundling/unbundling of the logical channel or
> the change of channel ID.****
>
> **
>
So, ... your point is that we should clarify which side assigns a channel
ID, and then you can divert WebSocket for such an application which gives
special meaning for each channel ID. Right?

My question is whether you're suggesting that we explicitly mention/allow
the use of channel IDs from application level or not.

> **
>
> BTW it still unclear which of the communicating sides assigns a channel ID
> when an AddChannel request is sent. Since the Objective Channel ID can be
> sent both ways, what should be the Objective Channel ID for an AddChannel
> request message?****
>
> **
>
Sorry. Yes, I'll do this clarification. My understanding is that the
AddChannel request specifies the channel ID for the new logical channel by
putting the ID in the Objective Channel ID part.


> **
>
> It's ok with me if the channel ID cannot be assigned by the client side,
> since the application may identify the type of the channel by the first
> message sent through the channel. This may cause an extra roundtrip, but it
> is not a big deal if we implement some way of opening multiple logical
> connections at once
>
We may allow clients to send some value meaning "undefined" in the
Objective Channel ID part to get ID assigned by the server with AddChannel
response. For now, I'm not going to put this in the spec because of
additional complexity.

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


Hi,

On Tue, Mar 27, 2012 at 12:41, Arman Djusupov <arman@noemax.com&=
gt; wrote:



We are not implementing mux for providing video streams specifica=
lly, but for general purpose mux support. I see the mux extension being use=
ful not only to the browser, but certainly to other types of software too w=
hich need multiple channels in a single connection.



Yes, that's why I didn't object to use of m=
ux ID but just showed concern about intermediaries' bundle/unbundle.



 It is applicabl=
e to all cases when the client has to reduce the number of concurrent conne=
ctions to the server pool.
=A0
Clie=
nt-mux intermediary-servers is just one specific use case, once which is re=
quired by browsers. Consider for example a MMO game engine that also uses m=
ux between the client application and server poo, where the mux intermediar=
y does not simply bundle and unbundle channels but is designed specifically=
 for the game requirements and has specific logic on how to forward each ch=
annel based on the channel ID or other criteria. We can assume that in such=
 cases an incompatible intermediary is not expected to occur on the wire be=
tween the client and server. So the specification is not required to prohib=
it the bundling/unbundling of the logical channel or the change of channel =
ID.



=A0
So, ... your point is that w=
e should clarify which side assigns a channel ID, and then you can divert W=
ebSocket for such an application which gives special meaning for each chann=
el ID. Right?




My question is whether you're suggesting that we ex=
plicitly mention/allow the use of channel IDs from application level or not=
.



BT=
W it still unclear which of the communicating sides assigns a channel ID wh=
en an AddChannel request is sent. Since the Objective Channel ID can be sen=
t both ways, what should be the Objective Channel ID for an AddChannel requ=
est message?



=A0
Sorry. Yes, I'll do this=
 clarification. My understanding is that the AddChannel request specifies t=
he channel ID for the new logical channel by putting the ID in the Objectiv=
e Channel ID part.



=A0
It's ok with me if the channel ID=
 cannot be assigned by the client side, since the application may identify =
the type of the channel by the first message sent through the channel. This=
 may cause an extra roundtrip, but it is not a big deal if we implement som=
e way of opening multiple logical connections at once



We may allow clients to send some value meaning &qu=
ot;undefined" in the Objective Channel ID part to get ID assigned by t=
he server with AddChannel response. For now, I'm not going to put this =
in the spec because of additional complexity.



=A0


--20cf305e2763d2ec2904bc38b869--

From arman@noemax.com  Tue Mar 27 07:06:56 2012
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 D4B3321E8201 for ; Tue, 27 Mar 2012 07:06:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.379
X-Spam-Level: 
X-Spam-Status: No, score=-2.379 tagged_above=-999 required=5 tests=[AWL=0.219,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40sY0tqgwAHX for ; Tue, 27 Mar 2012 07:06:56 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id B15BE21E81FC for ; Tue, 27 Mar 2012 07:06:55 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id LRH73254; Tue, 27 Mar 2012 17:06:54 +0300
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com> 
In-Reply-To: 
Date: Tue, 27 Mar 2012 17:06:48 +0300
Message-ID: <002c01cd0c22$dd9e8fb0$98dbaf10$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01CD0C3C.02EBC7B0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZcCh7t1pgGkm8LGAowvP5UCsn+LAZTKuhbw
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 14:06:56 -0000

This is a multipart message in MIME format.

------=_NextPart_000_002D_01CD0C3C.02EBC7B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

 

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Tuesday, March 27, 2012 3:35 PM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

Hi,

 

On Tue, Mar 27, 2012 at 12:41, Arman Djusupov  wrote:

Client-mux intermediary-servers is just one specific use case, once which is
required by browsers. Consider for example a MMO game engine that also uses
mux between the client application and server poo, where the mux
intermediary does not simply bundle and unbundle channels but is designed
specifically for the game requirements and has specific logic on how to
forward each channel based on the channel ID or other criteria. We can
assume that in such cases an incompatible intermediary is not expected to
occur on the wire between the client and server. So the specification is not
required to prohibit the bundling/unbundling of the logical channel or the
change of channel ID.

 

So, ... your point is that we should clarify which side assigns a channel
ID, and then you can divert WebSocket for such an application which gives
special meaning for each channel ID. Right?

 

My question is whether you're suggesting that we explicitly mention/allow
the use of channel IDs from application level or not.

 

think we should and if there is an intermediary that messes up with channel
IDs or completely strips off the mux, it would be normal for such an
application to fail (so such an application would require that there is no
de-multiplexing intermediary in between). Using fixed channel IDs like
TCP/IP port numbers is optional, there are alternative ways to negotiate the
protocol used by the logical channel using the AddChannel request handshake.
But the general idea is that Yes the application layer should be permitted
to access a specific logical channel by ID, protocol or other criteria, at
least the specification should not require that logical channels are
completely abstracted from the application layer. 

BTW it still unclear which of the communicating sides assigns a channel ID
when an AddChannel request is sent. Since the Objective Channel ID can be
sent both ways, what should be the Objective Channel ID for an AddChannel
request message?

 

Sorry. Yes, I'll do this clarification. My understanding is that the
AddChannel request specifies the channel ID for the new logical channel by
putting the ID in the Objective Channel ID part.

 

This is fine with me J

It's ok with me if the channel ID cannot be assigned by the client side,
since the application may identify the type of the channel by the first
message sent through the channel. This may cause an extra roundtrip, but it
is not a big deal if we implement some way of opening multiple logical
connections at once

We may allow clients to send some value meaning "undefined" in the Objective
Channel ID part to get ID assigned by the server with AddChannel response.
For now, I'm not going to put this in the spec because of additional
complexity.

 

Both options are OK with me.


------=_NextPart_000_002D_01CD0C3C.02EBC7B0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


 
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Tuesday, =
March 27, 2012 3:35 PM
To: Arman Djusupov
Cc: =
hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec =
draft 03
 
Hi,
 
On Tue, Mar 27, 2012 at 12:41, Arman Djusupov <arman@noemax.com> =
wrote:
Client-mux =
intermediary-servers is just one specific use case, once which is =
required by browsers. Consider for example a MMO game engine that also =
uses mux between the client application and server poo, where the mux =
intermediary does not simply bundle and unbundle channels but is =
designed specifically for the game requirements and has specific logic =
on how to forward each channel based on the channel ID or other =
criteria. We can assume that in such cases an incompatible intermediary =
is not expected to occur on the wire between the client and server. So =
the specification is not required to prohibit the bundling/unbundling of =
the logical channel or the change of channel =
ID.
 
<=
p class=3DMsoNormal>So, ... your point is that we should clarify which =
side assigns a channel ID, and then you can divert WebSocket for such an =
application which gives special meaning for each channel ID. =
Right?
 
My question is whether you're suggesting that we =
explicitly mention/allow the use of channel IDs from application level =
or not.
 
 think we should and if there is an intermediary that messes up with =
channel IDs or completely strips off the mux, it would be normal for =
such an application to fail (so such an application would require that =
there is no de-multiplexing intermediary in between). Using fixed =
channel IDs like TCP/IP port numbers is optional, there are alternative =
ways to negotiate the protocol used by the logical channel using the =
AddChannel request handshake. But the general idea is that Yes the =
application layer should be permitted to access a specific logical =
channel by ID, protocol or other criteria, at least the specification =
should not require that logical channels are completely abstracted from =
the application layer. 
BTW it still =
unclear which of the communicating sides assigns a channel ID when an =
AddChannel request is sent. Since the Objective Channel ID can be sent =
both ways, what should be the Objective Channel ID for an AddChannel =
request =
message?
 
<=
div>
Sorry. Yes, I'll do this clarification. My =
understanding is that the AddChannel request specifies the channel ID =
for the new logical channel by putting the ID in the Objective Channel =
ID part.
 
This is fine with me J
It's ok with me if the =
channel ID cannot be assigned by the client side, since the application =
may identify the type of the channel by the first message sent through =
the channel. This may cause an extra roundtrip, but it is not a big deal =
if we implement some way of opening multiple logical connections at =
once
We may =
allow clients to send some value meaning "undefined" in the =
Objective Channel ID part to get ID assigned by the server with =
AddChannel response. For now, I'm not going to put this in the spec =
because of additional complexity.
 
Both options are OK with =
me.

------=_NextPart_000_002D_01CD0C3C.02EBC7B0--


From jat@google.com  Tue Mar 27 07:16:50 2012
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 6603621F881D for ; Tue, 27 Mar 2012 07:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-4PaNtDF22N for ; Tue, 27 Mar 2012 07:16:49 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9120521F8821 for ; Tue, 27 Mar 2012 07:16:48 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so3932931vbb.31 for ; Tue, 27 Mar 2012 07:16:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=C8/+dyDP7mOdkwqsV9weH9RSUvV9J0+pvM4QFu5Fgw0=; b=iX7oXRWzrBL8GZlqJtqNg/szSuIjVxm/x+R+UxV73QZUQgD+d7YwgQ16PNzIcGejub W2uPDJzdaoALtVvbMFYAQbB8BZWu81Ywu3f6lkNpeiAZW1+gL6XKGRstM8LsQjuYvHOp P0uG2U1WMILkoNgYcbtDd3042FNuHqtRtPkno6hjC95cNLzzHxQWhgWWwDaH5fLKIxKD Fa0/O7g98v2hQjIVsg4WJplkodlZVn/rRe+il3fVGtxsUKTjTStXYyco2Bax0RaUxCxT DbpARZEn9LcNpJ+yfGuKjr0W1pfD+4BqdJrZ2Xejb60Gp6ukI4xxTRcxqgxlMmZn9D1D GruA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=C8/+dyDP7mOdkwqsV9weH9RSUvV9J0+pvM4QFu5Fgw0=; b=BQRjv9xMjcLlKfOxLyP0otbcfbpmuTOdWlAttKbkLm49CGncY1qhiFDGmyn1hNK64U Hb+HCASRIqCB6VOfFl6/dm/FU/kA+KohA5jt29XvMe9yuv/7NoIzwt7jFcaGBRYEBnfq K0NZbyUTekMWI/OWK2jl76q1TCxZWNEPWzObr1od6C+yhmLlLVJK66MUOPseL4MZTCej PuLucaf1+vjBKX+E3f1BsUeqHBb/eFHFrAhoXygfwKs6gwxbfNFghqRiixCZDkQJy4xR miT/8OflNQr8oxq+O1efKnJOk8lggmh5tXbM7nuK+lLwiumnGzNQQWG7FG1wfDNsNgA/ IM/g==
Received: by 10.220.228.200 with SMTP id jf8mr12091547vcb.0.1332857808060; Tue, 27 Mar 2012 07:16:48 -0700 (PDT)
Received: by 10.220.228.200 with SMTP id jf8mr12091534vcb.0.1332857807885; Tue, 27 Mar 2012 07:16:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.67 with HTTP; Tue, 27 Mar 2012 07:16:27 -0700 (PDT)
In-Reply-To: <002c01cd0c22$dd9e8fb0$98dbaf10$@noemax.com>
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com>  <002c01cd0c22$dd9e8fb0$98dbaf10$@noemax.com>
From: John Tamplin 
Date: Tue, 27 Mar 2012 10:16:27 -0400
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=14dae9cdc0f92cd3d604bc3a24cd
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQm8crKkL0r2+oizVmQTLfNxAYvp7E9dICYoDY8yrIKxnGy8CfPEvF6/N8qaMrc2CMxrtQdRNG9PBihJstKPjurDPbs9FEiz0Fh/8TYkN3P/PvLYftSxdVQdaPGGxmaYtMaIW8mW
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 14:16:50 -0000

--14dae9cdc0f92cd3d604bc3a24cd
Content-Type: text/plain; charset=UTF-8

I really don't think exposing channels to JS is the proper thing to do.
 For one, that means that the application must be prepared to deal with
browsers which support and don't support MUX (and therefore don't even
provide that API), and connections that go through an intermediary that
doesn't support it.

Instead, I think applications that want multiple channels should just open
them as they do today.  If the browser and server negotiate MUX, then the
browser will aggregate those connections, and if not it will continue to
work.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


I really don't think exposing channels to JS=
 is the proper thing to do. =C2=A0For one, that means that the application =
must be prepared to deal with browsers which support and don't support =
MUX (and therefore don't even provide that API), and connections that g=
o through an intermediary that doesn't support it.




Instead, I =
think applications that want multiple channels should just open them as the=
y do today. =C2=A0If the browser and server negotiate MUX, then the browser=
 will aggregate those connections, and if not it will continue to work.



-- 
John A. Tamplin
Software Engineer (GWT), Google

--14dae9cdc0f92cd3d604bc3a24cd--

From tyoshino@google.com  Tue Mar 27 08:48:49 2012
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 B05C321E820F for ; Tue, 27 Mar 2012 08:48:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBFNvY60gwJ5 for ; Tue, 27 Mar 2012 08:48:49 -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 3B81121E8135 for ; Tue, 27 Mar 2012 08:48:49 -0700 (PDT)
Received: by yenm5 with SMTP id m5so36704yen.31 for ; Tue, 27 Mar 2012 08:48:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=EzSN/ivkA8liGznmeaWMT7DdzAdD+LconFWaji0GKWk=; b=Oi4qZ6XpszAxPJJJJFf1oJ7tdlUTGWg2+Xh5sDCjGWDBv400N/e/mp4nQFL1fNn1iP KnwfD3VKYlr3KVm2Rnunih3zftYKuyGU32PtEnCBb/IuQK/cyECjLPtnvsPM0ORBwM+H L9w2Spinx5QAmGGX28uFTBQqKvEJMGSGhXlkLEoGzoRqfRflhkL2tXyJbREo9wkb696D hctvbUdNvOgGr0v0UIh/Q2ItXBbmPoDR398ZQGRZXbYIm63tK8uG6bmTSVJtcJOQ40lj uTzNdjvX2cb8xoXUydfsFXvRYLVbWdLULmSpiDiNw+eN7nwYgPfeuUJe0begsp7miVLK Z9BA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=EzSN/ivkA8liGznmeaWMT7DdzAdD+LconFWaji0GKWk=; b=Ew0kkPZvKqAlki2p66z96j1jGl2wkTT4lVH+ROks7k+smjBlgd8QH+yq+3LCqmNuKc vhOY5xcE2Mq708NPmV1X+7HzVHcBE21yihwvyP/0I9NVySthAwmasU7KOujxQmYUlzG9 Z4W0uS8tcxYgKgv2lvlJp86phSRxnsxNVreKt+Vttd/DhLe3qMyIyydrAmcoVD176zZa 1o/+jvAreJaAr2xdLCghheLjP0aHKLoFv6LFvUp/SOgPj0nj/RWDw3o4z4tnDn8UJkYH yB8vvPdME5VjgOHj9la+upzIK7MKHNG05/taxOn5vQwhZCC6HxIvJJPsxqiVwp+nNm3m 4AVA==
Received: by 10.236.170.41 with SMTP id o29mr26484145yhl.83.1332863328791; Tue, 27 Mar 2012 08:48:48 -0700 (PDT)
Received: by 10.236.170.41 with SMTP id o29mr26484132yhl.83.1332863328702; Tue, 27 Mar 2012 08:48:48 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Tue, 27 Mar 2012 08:48:28 -0700 (PDT)
In-Reply-To: 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com>  <002c01cd0c22$dd9e8fb0$98dbaf10$@noemax.com> 
From: Takeshi Yoshino 
Date: Tue, 27 Mar 2012 17:48:28 +0200
Message-ID: 
To: John Tamplin 
Content-Type: multipart/alternative; boundary=20cf303b38e33dd30d04bc3b6d72
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQl18lQIZr3w7vDskWbEB+JLgvCDnAuIAoNu9KfNiTpPR2UqfY4OYbSaCtvdd4+iLlXUyCpdTQ+NGykWoLoB3t4UWI7A2pnV+SOp0UrCcca0El+cjPHesTpuI8y8ywyXa8JaIqeA
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 15:48:49 -0000

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

OK. I will
- clarify that channel IDs are assigned by clients
- leave assignment algorithm up to implementations but warn that channel
IDs may be changed by intermediaries
but I will NOT
- add any constraint for intermediaries (so, intermediaries may reassign
channel IDs)
- explicitly expose channel ID to application layer (i.e. I won't add any
section like RFC 6455's section 12)

Are you fine with this, Arman?

--20cf303b38e33dd30d04bc3b6d72
Content-Type: text/html; charset=ISO-8859-1


OK. I will
- clarify that channel IDs are assigned by clients
- leave assignment algorithm up to implementations but warn that channel IDs may be changed by intermediaries
but I will NOT



- add any constraint for intermediaries (so, intermediaries may reassign channel IDs)
- explicitly expose channel ID to application layer (i.e. I won't add any section like RFC 6455's section 12)



Are you fine with this, Arman?


--20cf303b38e33dd30d04bc3b6d72--

From tyoshino@google.com  Tue Mar 27 08:57:02 2012
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 DE5FB21E8135 for ; Tue, 27 Mar 2012 08:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.964
X-Spam-Level: 
X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RGnvRr-MTfSV for ; Tue, 27 Mar 2012 08:57:02 -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 4D5EB21E8269 for ; Tue, 27 Mar 2012 08:57:02 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so51716ggm.31 for ; Tue, 27 Mar 2012 08:57:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=SPXtpUaPElD3JbZ/inRpuH9vw3f/5QPRKnxYORZvC6o=; b=IFyaLArPnPI7/q76I9SaSeupJJageUNzjQWJ32htrYabmZP7VWusXphDu/3BIAJwjp Wa3DyFM4rOed05fnVBRbdjsJh1uhYX/OfyyYODAdqmnPNw41SY42NTjK4xjsGMgKsCL2 6h11AZOy0ItlOdJbnSY6D9vvc1RBrjafCqgSBnnlW/jeLc998+UDnYMW1M3m1Ymj+sil D3KEJgPWZIGensy7lFlUp+tVECY0WG8CWDiYp9jcxvdre6JsuABbfkeqvFRBNusl8xN/ RLncc54rIpVdr4uMFq5Sqj59ocpRPYLhiTw8iRVcinkZiGxVS1r8mYshbJLuhvTVfSK4 NasA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=SPXtpUaPElD3JbZ/inRpuH9vw3f/5QPRKnxYORZvC6o=; b=e4/MYME7c0irO0b/PcUA5wiyW9I5xvmHxc+P77x/L+2i6zS07OXAh5vJg7nuv8gzyX 8p6RajD3FqSLCOTAkoS39YSHgVho6DjYT+mqrNP8rFRxkhoRv0Vc+hE6IuJ5Um9D8gPY nMehUmGw+uRaVD8aP4W0C+U2dif2JpHpw5K6QBtuFfcFKEd8mA1yIB6kQ4BvmL6XtXU9 seDod+3culYhl+4lnI6Y3yKzHGl5IEBhMEMrNuHzA8YFtD1W2iij+Rw9cQJNGcIZMGSP AaPDwxNg9HgYAln+wtNbrWnRjj51NMfPTNPX2DSi6ZZ769NHNXpMapskpNyce5Ia1rpp +OMg==
Received: by 10.236.170.41 with SMTP id o29mr26516562yhl.83.1332863821888; Tue, 27 Mar 2012 08:57:01 -0700 (PDT)
Received: by 10.236.170.41 with SMTP id o29mr26516549yhl.83.1332863821767; Tue, 27 Mar 2012 08:57:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Tue, 27 Mar 2012 08:56:41 -0700 (PDT)
In-Reply-To: <005101cd08eb$585ab9d0$09102d70$@noemax.com>
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <001b01cd08cc$fe9ac980$fbd05c80$@noemax.com>  <005101cd08eb$585ab9d0$09102d70$@noemax.com>
From: Takeshi Yoshino 
Date: Tue, 27 Mar 2012 17:56:41 +0200
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf303b38e3a1628304bc3b8ad0
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmlYj2dQdDrWlgRzWxA88cB4fy0TB6t2aVyA5aa+inVfqgDFFc0uGiLU5e62TYO095KonBQ96Zgv3IygtgRYPsWa2pEza7R3LzT9NrSQoH5c23+Y17Y96OQpkz+7EVVEDqZlBME
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 15:57:03 -0000

--20cf303b38e3a1628304bc3b8ad0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 23, 2012 at 12:51, Arman Djusupov  wrote:

> I think it=92s OK to disallow control frames with a channel ID other than=
 0.
> Since WS control frames apply to a physical channel,  I=92m not sure they
> should apply to mux logical channels too (it will always confuse
> intermediaries that are not mux aware). We could actually create a single
> mux command for delivering all types of logical channel control frames,
> including custom opCodes that might be assigned in future.
>

Anyone objects to this? I heard from John that some people objected to put
everything into application data portion. Here, instead, we're going to
- use WebSocket frames' opcode to convey data frames' opcode of logical
channels
- use application data portion to convey control frames' opcode of logical
channels

--20cf303b38e3a1628304bc3b8ad0
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


On Fri, Mar 23, 2012 at 12:51, Arman Djusupov <arman@noemax.com> wrote:



I think it=92s OK to disallow control frames=
 with a channel ID other than 0. Since WS control frames apply to a physica=
l channel,=A0 I=92m not sure they should apply to mux logical channels too =
(it will always confuse intermediaries that are not mux aware). We could ac=
tually create a single mux command for delivering all types of logical chan=
nel control frames, including custom opCodes that might be assigned in futu=
re.




Anyone objects to this? I hear=
d from John that some people objected to put everything into application da=
ta portion. Here, instead, we're going to
- use WebSocket fra=
mes' opcode to convey data frames' opcode of logical channels



- use application data portion to convey control frames' opcode of=
 logical channels



--20cf303b38e3a1628304bc3b8ad0--

From tyoshino@google.com  Tue Mar 27 09:16:36 2012
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 B9DF121F89BC for ; Tue, 27 Mar 2012 09:16:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.964
X-Spam-Level: 
X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgjTiEDt3GlS for ; Tue, 27 Mar 2012 09:16:36 -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 1713521F89AF for ; Tue, 27 Mar 2012 09:16:36 -0700 (PDT)
Received: by yenm5 with SMTP id m5so69419yen.31 for ; Tue, 27 Mar 2012 09:16:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=QXDBUJYEIBedhD2lKwKrDc/r5TtsQYUIfsJb0UIS7Hk=; b=fOdYhEueQ1KyKZm2j4E1QuRzOtlC9o/v5gpYZHd0MCwFwkkbRzevRzuY+e7q2ymTxM J1zREgesJQ5kIHXYmZwL496u7GZ//y1lI8BnvSTp/bBocF4uH2aMyBZkqOvbDoaLEfw7 NNCs5+PaMASmSBYQyJCjxRvzRAK6zYzpQ+tdWqsdvjN+WQwshJ27X0wmQExMhPTBRZzL HrB+7PKloq/X3hStNc77G/lYjIW+CJcP7qeD8yfFOhDG1++ZEDSPLbUZphupzLCWIx/c sMbx22cxBRnCbEMdH6NHXtkoi1/lL+UDg38SPPZio3SUvx1J9uSymiIHV9nFEq579PDC AlNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record:x-gm-message-state; bh=QXDBUJYEIBedhD2lKwKrDc/r5TtsQYUIfsJb0UIS7Hk=; b=SIA8+ou7OycOsKP+CnmTA7mMxj1eKatwalpv8Kzlo8U0MT60ZHg8lUGTdAApcHYw3C XllJ9G/j0aHH7CgBvLH6hDzSpiwyooHgApbzjHEjlskRHgAPU+BYWCQXLP95XpXTdkr1 1hFFHCiC4K8bGipjiRJRftv28hVeHggHbDosLpNKTtr9JzAUWmGBRRBqi+Krg0Qf/lgU nkFshDYSWQd+fgXVMsT0+HpPqBjnNEroLPYQQ9TRjrw1ShwNVBr9xApTre9brJOy4xYY o7QJnRMbqSaLh3oSosguXugrG88P0I8Ek39ERGJjARp+Lfz6Uoy8tUWGTNMTWrCJ/PZP pQwQ==
Received: by 10.236.170.41 with SMTP id o29mr26592283yhl.83.1332864995744; Tue, 27 Mar 2012 09:16:35 -0700 (PDT)
Received: by 10.236.170.41 with SMTP id o29mr26592278yhl.83.1332864995667; Tue, 27 Mar 2012 09:16:35 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Tue, 27 Mar 2012 09:16:14 -0700 (PDT)
In-Reply-To: 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  
From: Takeshi Yoshino 
Date: Tue, 27 Mar 2012 18:16:14 +0200
Message-ID: 
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=20cf303b38e399acd904bc3bd06d
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkgTaN+Lge24o0JiBo+BtrJu1sYPS+3J2np2qPc8c7Lcoz4aMVVXBbTv0S/uv53OXqvSnIJxDUXpwdziQ2So9er4XCGdCIvXFWOa/PammK9OpzQUoKrkrYMpfi4+TVWcgxeoNgJ
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 16:16:36 -0000

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

BTW, it looks like we need to clarify what to set to _Extensions In Use_.

I can come up with two options
- cut off mux token and everything after mux token that are applied to the
physical channel
- as-is

IIRC, the motivation to expose the list of extensions in use to JavaScripts
is to allow them to switch their behavior based on availability of
optimization (compress, mux), e.g. fallback to HTTP when compression is not
available. This can be done by server side too (We can reject the
connection if mandatory extensions are not available to ask the client side
to do something else. We also have close status 1010 to do this now), so
not critical, but respecting the motivation, we should expose extensions in
use "as-is".

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

BTW, it looks like we need to clarify what to set to _Extensions In Use_.



- as-is

IIRC, the motivation to expose the li=
st of extensions in use to JavaScripts is to allow them to switch their beh=
avior based on availability of optimization (compress, mux), e.g. fallback =
to HTTP when compression is not available. This can be done by server side =
too (We can reject the connection if mandatory extensions are not available=
 to ask the client side to do something else. We also have close status 101=
0 to do this now), so not critical, but respecting the motivation, we shoul=
d expose extensions in use "as-is".






--20cf303b38e399acd904bc3bd06d--

From jat@google.com  Tue Mar 27 09:38:38 2012
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 98C4521E8087 for ; Tue, 27 Mar 2012 09:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.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, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhz9Df16BYhW for ; Tue, 27 Mar 2012 09:38: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 B101321E8097 for ; Tue, 27 Mar 2012 09:38:37 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so79897vcb.31 for ; Tue, 27 Mar 2012 09:38:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=VtOuFDBj+99WV+doXx9bZ7aPP8L4456LxzK5CPeG8PU=; b=EXQ6k3yCWFpdxIlxbFWuM9NWiz/5KPbCjqykwKl4KpPzim3106IBupzm2OepnA0P63 QdwBDEJXL+x2zo5G6Q+LO5JP0VyxiWjr60mmTocVdaQ1KKSQuraQtudiuYU5GlZ7NcX7 IuLZhOzrqdbSNDlI7mWrvLd2PlK7Oe0qlRL4TWgGv/Npy0RTIW2Vo2l58hE2SEqPeK5K ZU4TGUuipVB5+9VwMSuTlmNXYHYLpPATwtX6Wglkkf4sVTSRu5SmTekDl+ZgyluVuJvt +lzHh+e9iqeHA2+6D9Au1rSM/8iMoPnJFf2/oEeyY2RUy3jAqpaq321ZhM97EnuE2o8n gfEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=VtOuFDBj+99WV+doXx9bZ7aPP8L4456LxzK5CPeG8PU=; b=AbVfXrQGcmhDRGSLbjVRutQOJqtVBFfQTL7tZd10RXfKDPN/7hQDknoFffJdz0kGXN HKHjofSA/IUFLqlGwWOxiWMR3N17eI2EuBW7yrW7xU4b96tis9CqI+H0ZP1VvkSMWpQq /UonNqmejoHuH0P5p2MgtjElaNL6RhPkOI7iOL4JgdxeOUpwrmUdf/ebez3FycfE1JF7 YEIgvljmzyCJ7YwjS6Epg/UtD9r1AiQvhVhymMQTMrDQPTzOXvrKg7Jr09Aq+2Yw660/ o0IUAe7wXHMOQMFkCB5RqAx92CdAkvjvhaqJa1F1vM6HhZvae8ct3hqgTf/q0L5/Nvmo dhWw==
Received: by 10.52.95.42 with SMTP id dh10mr3309926vdb.37.1332866317258; Tue, 27 Mar 2012 09:38:37 -0700 (PDT)
Received: by 10.52.95.42 with SMTP id dh10mr3309918vdb.37.1332866317187; Tue, 27 Mar 2012 09:38:37 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.67 with HTTP; Tue, 27 Mar 2012 09:38:16 -0700 (PDT)
In-Reply-To: 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>   
From: John Tamplin 
Date: Tue, 27 Mar 2012 12:38:16 -0400
Message-ID: 
To: Takeshi Yoshino 
Content-Type: multipart/alternative; boundary=20cf307cfef85e7b3f04bc3c1f7c
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn72uiqQH42zlu9Tjv7KI0zoKj/aPNIoLvbKhPzLIsgq9kotzpjnv84dZvcLlnrZ8dIlRRjpz43wJ0M/L2m2ftRqendPQhoT3iJE29x7svRm3bgO/Cn/hstariM99KoU61QiMek
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Tue, 27 Mar 2012 16:38:38 -0000

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

On Tue, Mar 27, 2012 at 12:16 PM, Takeshi Yoshino wrote:

> BTW, it looks like we need to clarify what to set to _Extensions In Use_.
>
> I can come up with two options
> - cut off mux token and everything after mux token that are applied to the
> physical channel
> - as-is
>
> IIRC, the motivation to expose the list of extensions in use to
> JavaScripts is to allow them to switch their behavior based on availability
> of optimization (compress, mux), e.g. fallback to HTTP when compression is
> not available. This can be done by server side too (We can reject the
> connection if mandatory extensions are not available to ask the client side
> to do something else. We also have close status 1010 to do this now), so
> not critical, but respecting the motivation, we should expose extensions in
> use "as-is".
>

hybi has no control over the JS API -- if you want to change the API
exposed to JS, that has to go through WHATWG.  This also doesn't seem
specific to any of the extensions we are discussing here, but rather a
general facility for exposing which extensions are in use.  AFAIK, there is
no standard API for the server side, so this would have to be done by each
implementation.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Tue, Mar 27, 2012 at 12:16 PM, Takeshi Yoshin=
o <tyoshino@goo=
gle.com> wrote:


BTW, it looks like we need to clarify what to set to _Extensions In Use_.
I can come up with two options
- cut off mux to=
ken and everything after mux token that are applied to the physical channel=






- as-is

IIRC, the motivation to expose the li=
st of extensions in use to JavaScripts is to allow them to switch their beh=
avior based on availability of optimization (compress, mux), e.g. fallback =
to HTTP when compression is not available. This can be done by server side =
too (We can reject the connection if mandatory extensions are not available=
 to ask the client side to do something else. We also have close status 101=
0 to do this now), so not critical, but respecting the motivation, we shoul=
d expose extensions in use "as-is".




hybi has no control over the JS API -- if =
you want to change the API exposed to JS, that has to go through WHATWG. =
=C2=A0This also doesn't seem specific to any of the extensions we are d=
iscussing here, but rather a general facility for exposing which extensions=
 are in use. =C2=A0AFAIK, there is no standard API for the server side, so =
this would have to be done by each implementation.




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--20cf307cfef85e7b3f04bc3c1f7c--

From hapner.mark@huawei.com  Tue Mar 27 22:58:51 2012
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 B964621E80F2 for ; Tue, 27 Mar 2012 22:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWxhLqWTuBNI for ; Tue, 27 Mar 2012 22:58:50 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id B628E21E80E7 for ; Tue, 27 Mar 2012 22:58:50 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEL26139; Wed, 28 Mar 2012 01:58:50 -0400 (EDT)
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 27 Mar 2012 22:57:28 -0700
Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.003; Tue, 27 Mar 2012 22:57:23 -0700
From: Hapner mark 
To: "hybi@ietf.org" 
Thread-Topic: [HyBi] MBWS Subprotocol
Thread-Index: AQHNDKekW2KuKoBfG0iiuCMT/k96Kg==
Date: Wed, 28 Mar 2012 05:57:21 +0000
Message-ID: <92457F4F764A5C4785FCDBDDDD76477A33184B5D@dfweml505-mbx>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.18.9.109]
Content-Type: multipart/alternative; boundary="_000_92457F4F764A5C4785FCDBDDDD76477A33184B5Ddfweml505mbx_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: Sohrab modi , "smalladi@ebay.com" , "csuconic@redhat.com" , "tonyng@ebay.com" , Gaoyongguang 
Subject: [hybi] [HyBi] MBWS Subprotocol
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: Wed, 28 Mar 2012 05:58:51 -0000

--_000_92457F4F764A5C4785FCDBDDDD76477A33184B5Ddfweml505mbx_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


This version of the Message Broker Web Socket Subprotocols (MBWS and MBLWS)=
) has been revised to conform to RFC 6455's definition of a WebSocket Subpr=
otocol. The purpose of this subprotocol remains the same - to add the metad=
ata required to support a message queueing intermediary that allows clients=
 to communicate via a shared set of message addresses without having to dir=
ectly expose themselves to; or, know about the other clients of the interme=
diary.

Clebert and I would be very interested in HyBi's feedback on this draft. If=
 there are no significant issues, we plan to register the two subprotocols =
it defines with IANA.

A binary binding is provided that allows binary WebSocket messages to trans=
mit both binary and text subprotocol messages. A text binding for text WebS=
ocket messages is defined for those applications that prefer to transmit on=
ly text.

http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.txt
http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.pdf
http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.xml

--_000_92457F4F764A5C4785FCDBDDDD76477A33184B5Ddfweml505mbx_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable















This version of the Message Broker Web Socket Subprotocols (MBWS and M=
BLWS)) has been revised to conform to RFC 6455's definition of a WebSocket =
Subprotocol. The purpose of this subprotocol remains the same - to add the =
metadata required to support a message
 queueing intermediary that allows clients to communicate via a shared set =
of message addresses without having to directly expose themselves to; or, k=
now about the other clients of the intermediary.







Clebert and I would be very interested in HyBi's feedback on this draf=
t. If there are no significant issues, we plan to register the two subproto=
cols it defines with IANA. 







A binary binding is provided that allows binary WebSocket messages to =
transmit both binary and text subprotocol messages. A text binding for text=
 WebSocket messages is defined for those applications that prefer to transm=
it only text.









http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.=
txt


http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.=
pdf


http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.=
xml








--_000_92457F4F764A5C4785FCDBDDDD76477A33184B5Ddfweml505mbx_--

From arman@noemax.com  Tue Mar 27 23:48:40 2012
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 620B621E80E7 for ; Tue, 27 Mar 2012 23:48:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.394
X-Spam-Level: 
X-Spam-Status: No, score=-2.394 tagged_above=-999 required=5 tests=[AWL=0.204,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMT-4pYwPS5j for ; Tue, 27 Mar 2012 23:48:39 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5C03921E8126 for ; Tue, 27 Mar 2012 23:48:39 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MJY17043; Wed, 28 Mar 2012 09:48:43 +0300
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" , "'John Tamplin'" 
References:  <000301cd05dd$c8f9fc70$5aedf550$@noemax.com>  <003b01cd08d8$b1dd7050$159850f0$@noemax.com>  <001201cd0c06$3e9b3ab0$bbd1b010$@noemax.com>  <002c01cd0c22$dd9e8fb0$98dbaf10$@noemax.com>  
In-Reply-To: 
Date: Wed, 28 Mar 2012 09:48:34 +0300
Message-ID: <002f01cd0cae$cff3b2f0$6fdb18d0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CD0CC7.F540EAF0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQJyksDj69tXg0EBn6jyTi4rbdnguwGRJ3ibAhBToZcCh7t1pgGkm8LGAowvP5UCsn+LAQFWWAl2AlZ0RF8CgcuNKpSaXqAg
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03
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: Wed, 28 Mar 2012 06:48:40 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0030_01CD0CC7.F540EAF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Yes, Thanks!  That is fine with me.

 

With best regards,

Arman

 

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Tuesday, March 27, 2012 6:48 PM
To: John Tamplin
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec draft 03

 

OK. I will

- clarify that channel IDs are assigned by clients

- leave assignment algorithm up to implementations but warn that channel IDs
may be changed by intermediaries

but I will NOT

- add any constraint for intermediaries (so, intermediaries may reassign
channel IDs)

- explicitly expose channel ID to application layer (i.e. I won't add any
section like RFC 6455's section 12)

 

Are you fine with this, Arman?


------=_NextPart_000_0030_01CD0CC7.F540EAF0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Yes, Thanks!  That is fine with me.
 
With best regards,
Arman
 
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Tuesday, =
March 27, 2012 6:48 PM
To: John Tamplin
Cc: Arman =
Djusupov; hybi@ietf.org
Subject: Re: [hybi] Multiplexing =
extension spec draft 03
 
OK. I =
will
- clarify that =
channel IDs are assigned by clients
- leave assignment algorithm up to implementations but =
warn that channel IDs may be changed by =
intermediaries
but I will =
NOT
- add any constraint =
for intermediaries (so, intermediaries may reassign channel =
IDs)
- explicitly expose =
channel ID to application layer (i.e. I won't add any section like RFC =
6455's section 12)
 
Are you =
fine with this, Arman?

------=_NextPart_000_0030_01CD0CC7.F540EAF0--


From salvatore.loreto@ericsson.com  Wed Mar 28 00:27:09 2012
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 2C23721F850B for ; Wed, 28 Mar 2012 00:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.116
X-Spam-Level: 
X-Spam-Status: No, score=-110.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgBySd4sLiOO for ; Wed, 28 Mar 2012 00:27:07 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 667BB21F841A for ; Wed, 28 Mar 2012 00:27:07 -0700 (PDT)
X-AuditID: c1b4fb3d-b7c6fae0000045c0-0d-4f72bd494855
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A6.C2.17856.94DB27F4; Wed, 28 Mar 2012 09:27:05 +0200 (CEST)
Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.213.0; Wed, 28 Mar 2012 09:27:05 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id B91692321	for ; Wed, 28 Mar 2012 10:27:04 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A758E5262C	for ; Wed, 28 Mar 2012 10:27:04 +0300 (EEST)
Received: from dhcp-1324.meeting.ietf.org (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 58E2B5206C	for ; Wed, 28 Mar 2012 10:27:04 +0300 (EEST)
Message-ID: <4F72BD47.9080809@ericsson.com>
Date: Wed, 28 Mar 2012 09:27:03 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2
MIME-Version: 1.0
To: "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] slides for today meeting at IETF83
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: Wed, 28 Mar 2012 07:27:09 -0000

Hi there,

I have just uploaded the slides for the today meeting at IETF83
here the link:

https://datatracker.ietf.org/meeting/83/materials.html


cheers
Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


From Gabriel.Montenegro@microsoft.com  Wed Mar 28 04:14:01 2012
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 94AB021F89B6 for ; Wed, 28 Mar 2012 04:14:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.973
X-Spam-Level: 
X-Spam-Status: No, score=-3.973 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFO7Qjffdckh for ; Wed, 28 Mar 2012 04:13:59 -0700 (PDT)
Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe010.messaging.microsoft.com [216.32.180.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05621F89C7 for ; Wed, 28 Mar 2012 04:13:56 -0700 (PDT)
Received: from mail48-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 11:13:54 +0000
Received: from mail48-va3 (localhost [127.0.0.1])	by mail48-va3-R.bigfish.com (Postfix) with ESMTP id C7819160099; Wed, 28 Mar 2012 11:13:54 +0000 (UTC)
X-SpamScore: -15
X-BigFish: VS-15(z1725nzc85fh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail48-va3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail48-va3 (localhost.localdomain [127.0.0.1]) by mail48-va3 (MessageSwitch) id 1332933232175296_29205; Wed, 28 Mar 2012 11:13:52 +0000 (UTC)
Received: from VA3EHSMHS027.bigfish.com (unknown [10.7.14.246])	by mail48-va3.bigfish.com (Postfix) with ESMTP id 1E98C18009A; Wed, 28 Mar 2012 11:13:52 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by VA3EHSMHS027.bigfish.com (10.7.99.37) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 11:13:47 +0000
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.2.283.4; Wed, 28 Mar 2012 11:13:46 +0000
Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.25]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0283.004; Wed, 28 Mar 2012 04:13:46 -0700
From: Gabriel Montenegro 
To: Salvatore Loreto , "hybi@ietf.org" 
Thread-Topic: Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
Thread-Index: AQHNANc6AO5e0fNaskme3RpAYhv/uZZ/pZsQ
Date: Wed, 28 Mar 2012 11:13:45 +0000
Message-ID: 
References: <4F5ED619.4040503@ericsson.com>
In-Reply-To: <4F5ED619.4040503@ericsson.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_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5514BTK5EX14MBXW602w_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: SM 
Subject: Re: [hybi] Call for Consensus: draft-tamplin-hybi-google-mux as WG Item
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: Wed, 28 Mar 2012 11:14:01 -0000

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5514BTK5EX14MBXW602w_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

This call for adoption has been over for a few days. As announced a few mom=
ents ago in the f2f meeting, we are declaring consensus on adoption of draf=
t-tamplin-hybi-google-mux as an official WG item.

Thanks,

Salvatore and Gabriel

From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com]
Sent: Tuesday, 13 March, 2012 06:08
To: hybi@ietf.org
Cc: Gabriel Montenegro; SM
Subject: Call for Consensus: draft-tamplin-hybi-google-mux as WG Item

Hi there,

the second optimization/extension (or milestone if you prefer)
in the new approved HyBi charter (see http://tools.ietf.org/wg/hybi/charter=
s )
is about:

A multiplexing extension to improve the scalability of the

WebSocket protocol

John Tamplin has been working on a draft proposal since 2011 or even before=
.
The MUX issue has been largely discussed in the mailing list,
and the so far result have been included in the draft
John Tamplin and Takeshi Yoshino are now co-authoring.

The current version is:
http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03


Gabriel and I, as chairs, want to check the consensus to adopt the draft as
baseline for the working group item that will fulfill the following Goal in=
 the current charter:

  Adopt a WG for the multiplexing extension

This consensus call will run until Friday March 23, 2012
(so to not overlap with the IETF83 meeting)


Ciao
Salvatore and Gabriel

--

Salvatore Loreto

www.sloreto.com

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5514BTK5EX14MBXW602w_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











This call for adoption ha=
s been over for a few days. As announced a few moments ago in the f2f meeti=
ng, we are declaring consensus on adoption of draft-tamplin-hybi-google-mux
 as an official WG item.


 <=
/p>

Thanks,=



 <=
/p>

Salvatore and Gabriel


 <=
/p>







From: Salvatore Loreto [mailto:salvatore.loreto@ericsso=
n.com]


Sent: Tuesday, 13 March, 2012 06:08

To: hybi@ietf.org

Cc: Gabriel Montenegro; SM

Subject: Call for Consensus: draft-tamplin-hybi-google-mux as WG Ite=
m






 


Hi there,



the second optimization/extension (or milestone if you prefer)

in the new approved HyBi charter (see 
http://tools.ietf.org/wg/hybi/charters )

is about:


A multiplexing extension to improve the scalability of the<=
/pre>

WebSocket protocol




John Tamplin has been working on a draft proposal since 2011 or even before=
.

The MUX issue has been largely discussed in the mailing list,

and the so far result have been included in the draft

John Tamplin and Takeshi Yoshino are now co-authoring.



The current version is:

http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03





Gabriel and I, as chairs, want to check the consensus to adopt the draft as=
 

baseline for the working group item that will fulfill the following Goal in=
 the current charter:


  Adopt a WG for the multiplexing extension




This consensus call will run until Friday March 23, 2012

(so to not overlap with the IETF83 meeting)





Ciao 

Salvatore and Gabriel 


-- 


Salvatore Loreto


www.sloreto.com







--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5514BTK5EX14MBXW602w_--

From stpeter@stpeter.im  Wed Mar 28 04:51:34 2012
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 02ECE21E80F9 for ; Wed, 28 Mar 2012 04:51:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.879
X-Spam-Level: 
X-Spam-Status: No, score=-102.879 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wi4a-XiLx5P for ; Wed, 28 Mar 2012 04:51:33 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 2CC6221E80AA for ; Wed, 28 Mar 2012 04:51:33 -0700 (PDT)
Received: from dhcp-153f.meeting.ietf.org (unknown [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id CD59E40058 for ; Wed, 28 Mar 2012 06:04:38 -0600 (MDT)
Message-ID: <4F72FB42.8080600@stpeter.im>
Date: Wed, 28 Mar 2012 13:51:30 +0200
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: "hybi@ietf.org" 
X-Enigmail-Version: 1.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 11:51:34 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In Paris just now, Takeshi mentioned that a channel ID could be used
as a service identifier by higher-level apps. Could someone perhaps
explain what that means?

Thanks!

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9y+0IACgkQNL8k5A2w/vxTDwCfXNSBsZfZ27JSUZKiLxfYNMXD
V/MAn0bNf8SHwETzbWJCqGBT1V/1sSDq
=8jI/
-----END PGP SIGNATURE-----

From arman@noemax.com  Wed Mar 28 05:11:27 2012
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 C8E2321E8097 for ; Wed, 28 Mar 2012 05:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.407
X-Spam-Level: 
X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[AWL=0.192,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmBa3xHjyCOH for ; Wed, 28 Mar 2012 05:11:26 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4A021E8192 for ; Wed, 28 Mar 2012 05:11:25 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MPN95330; Wed, 28 Mar 2012 15:11:30 +0300
From: "Arman Djusupov" 
To: "'Peter Saint-Andre'" , 
References: <4F72FB42.8080600@stpeter.im>
In-Reply-To: <4F72FB42.8080600@stpeter.im>
Date: Wed, 28 Mar 2012 15:11:21 +0300
Message-ID: <004101cd0cdb$e75bd9e0$b6138da0$@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: AQBwER93EEogAGIwJzoTe3koNCITEJk5k2Ng
Content-Language: en-us
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 12:11:27 -0000

This means using the channel ID to identify the type of the service in the
same way as TCP/IP port numbers. Where the application reserves a specific
channel ID for a special use. E.g. channel ID: 1 - voice , 2 - chat, 3 -
video. This is meant to be used by non-browser apps that build their
protocols based on mux to decrease the number of client connections to the
server.

With best regards,
Arman

-----Original Message-----
From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of
Peter Saint-Andre
Sent: Wednesday, March 28, 2012 2:52 PM
To: hybi@ietf.org
Subject: [hybi] MUC: channel ID semantics

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In Paris just now, Takeshi mentioned that a channel ID could be used as a
service identifier by higher-level apps. Could someone perhaps explain what
that means?

Thanks!

Peter

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk9y+0IACgkQNL8k5A2w/vxTDwCfXNSBsZfZ27JSUZKiLxfYNMXD
V/MAn0bNf8SHwETzbWJCqGBT1V/1sSDq
=8jI/
-----END PGP SIGNATURE-----
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi


From stpeter@stpeter.im  Wed Mar 28 05:34:00 2012
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 7BBD621E8179 for ; Wed, 28 Mar 2012 05:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.844
X-Spam-Level: 
X-Spam-Status: No, score=-102.844 tagged_above=-999 required=5 tests=[AWL=-0.245, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpBx1LTQs4dd for ; Wed, 28 Mar 2012 05:34:00 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F2BCB21E8093 for ; Wed, 28 Mar 2012 05:33:59 -0700 (PDT)
Received: from dhcp-153f.meeting.ietf.org (unknown [64.103.25.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DC38240058; Wed, 28 Mar 2012 06:47:05 -0600 (MDT)
Message-ID: <4F730535.8040901@stpeter.im>
Date: Wed, 28 Mar 2012 14:33:57 +0200
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:11.0) Gecko/20120313 Thunderbird/11.0
MIME-Version: 1.0
To: Arman Djusupov 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com>
In-Reply-To: <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com>
X-Enigmail-Version: 1.4
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 12:34:00 -0000

On 3/28/12 2:11 PM, Arman Djusupov wrote:
> This means using the channel ID to identify the type of the service in the
> same way as TCP/IP port numbers. Where the application reserves a specific
> channel ID for a special use. E.g. channel ID: 1 - voice , 2 - chat, 3 -
> video. This is meant to be used by non-browser apps that build their
> protocols based on mux to decrease the number of client connections to the
> server.

I see. So you're assuming that the client will generate the channel IDs,
right?

/psa

From arman@noemax.com  Wed Mar 28 05:57:02 2012
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 9BE0521E821A for ; Wed, 28 Mar 2012 05:57:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.418
X-Spam-Level: 
X-Spam-Status: No, score=-2.418 tagged_above=-999 required=5 tests=[AWL=0.181,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6gP0hDfnJVzC for ; Wed, 28 Mar 2012 05:57:02 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id C5EC121E820F for ; Wed, 28 Mar 2012 05:57:01 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MPH38407; Wed, 28 Mar 2012 15:57:07 +0300
From: "Arman Djusupov" 
To: "'Peter Saint-Andre'" 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im>
In-Reply-To: <4F730535.8040901@stpeter.im>
Date: Wed, 28 Mar 2012 15:56:57 +0300
Message-ID: <004301cd0ce2$464f0b60$d2ed2220$@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: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzmZIeuq0A==
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 12:57:02 -0000

As currently designed, it's the client side that assigns the channel ID =
when sending an AddChannel request.

However even if it's the server side that assigns the channel ID there =
are still workarounds that would allow similar functionality.

With best regards,
Arman

-----Original Message-----
From: Peter Saint-Andre [mailto:stpeter@stpeter.im]=20
Sent: Wednesday, March 28, 2012 3:34 PM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

On 3/28/12 2:11 PM, Arman Djusupov wrote:
> This means using the channel ID to identify the type of the service in =

> the same way as TCP/IP port numbers. Where the application reserves a=20
> specific channel ID for a special use. E.g. channel ID: 1 - voice , 2=20
> - chat, 3 - video. This is meant to be used by non-browser apps that=20
> build their protocols based on mux to decrease the number of client=20
> connections to the server.

I see. So you're assuming that the client will generate the channel IDs, =
right?

/psa


From tyoshino@google.com  Wed Mar 28 06:09:43 2012
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 3E9FE21E81A1 for ; Wed, 28 Mar 2012 06:09:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.665
X-Spam-Level: 
X-Spam-Status: No, score=-102.665 tagged_above=-999 required=5 tests=[AWL=-0.289, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13ZwYOHKnHEo for ; Wed, 28 Mar 2012 06:09:42 -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 7E6BC21F88E8 for ; Wed, 28 Mar 2012 06:09:42 -0700 (PDT)
Received: by ggmi1 with SMTP id i1so722413ggm.31 for ; Wed, 28 Mar 2012 06:09:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=cVKLmi38MOvYckUPAfcfZxEqOeAeHouuHe+JIFbWJIw=; b=PK4AwRKiXjspW2tE96ZONJqez7TQiQT3ykGwriFq+zJiVwdXF5KOty/zLk21pRdYpQ xJD1pL/fuggNcD/SlYJqQAGoqZQCw8jN/AxtngSzsENPZMSO4lpOy8VpbzV+avURlyVK 5izeUirXWLJggZdrMsjpoz4zNkJsFqetnbzfkmCQ23VpyxFtVsgtujicGP3ftfjSB+rH fKe0XaMKuhp9hyBZ4KsdmteH/FkhuAia7H7j3yDMvk1l8os5AvCI7b2rdYBKEWmxPaoi lUwfsBPrJURNNL2NMlsmhQM/FNYuOJVIU6b5V7CefbAFECUvLL+W8O+nqS5+nMF7Ddxx YzDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=cVKLmi38MOvYckUPAfcfZxEqOeAeHouuHe+JIFbWJIw=; b=oWdg7w9u1JifXIRiYrLJDRTcw05BjOwepxNRTEGIb1GCqi+e4c8Zw8xLgR67KjwZoD +THbc2Igx8/tJAE6/vx2jmFAMmChD/wCgDOBmDB/hBHJuX/xfpK6ktZ89zKpn8RGC0R7 rMMfXVtRxHradr+8UeUTwz3OzZ5EF7aw5gOKdAVS5YZ5UOTB22dNtNHJCl+M98QRPOIL GeGaFHcMDV3w+EAQAumkryM/4278wttoP5P15PHdMIWTi+CJyHZEoo4d+pnb4QpO45AU XVXUB8Iw0YKTl1Xw/35wf8AaTM5hl6Ad4K9kB13kUYljp7boy8RIqck0XiQmiuR7Pe51 VWZg==
Received: by 10.236.76.41 with SMTP id a29mr29444716yhe.117.1332940181930; Wed, 28 Mar 2012 06:09:41 -0700 (PDT)
Received: by 10.236.76.41 with SMTP id a29mr29444684yhe.117.1332940181585; Wed, 28 Mar 2012 06:09:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.101.155.5 with HTTP; Wed, 28 Mar 2012 06:09:21 -0700 (PDT)
In-Reply-To: <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>
From: Takeshi Yoshino 
Date: Wed, 28 Mar 2012 15:09:21 +0200
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf303b40e307c13904bc4d5245
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlI0EMt1vYmxVuIRQ6IJouY2BHBlv4wcZMyaKJMWwV9420fwEthB9LxOI/lpRxECq92oBTqLqeb7DBCb8CKgKjaDKEJWPUrO+QHVBtmgBS3bS2J4nr86o4Gkmh7fpSpvhnrTkwu
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 13:09:43 -0000

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

Please note that I'm not going to make channel ID values to be a new
dimension of WebSocket protocol's interface for its users, but just going
to leave channel ID assignment algorithm up to implementors so that some
non-browser apps may assign channel IDs as they like and give some meaning
as Arman described below.

I won't add any new restriction on intermediaries to ensure that channel ID
values are the same on both endpoints. There's no such guarantee. We're
gonna just make WebSocket available for developers of special application
who want to divert WebSocket+MUX for their own service.

Takeshi


On Wed, Mar 28, 2012 at 14:56, Arman Djusupov  wrote:

> As currently designed, it's the client side that assigns the channel ID
> when sending an AddChannel request.
>
> However even if it's the server side that assigns the channel ID there are
> still workarounds that would allow similar functionality.
>
> With best regards,
> Arman
>
> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> Sent: Wednesday, March 28, 2012 3:34 PM
> To: Arman Djusupov
> Cc: hybi@ietf.org
> Subject: Re: [hybi] MUC: channel ID semantics
>
> On 3/28/12 2:11 PM, Arman Djusupov wrote:
> > This means using the channel ID to identify the type of the service in
> > the same way as TCP/IP port numbers. Where the application reserves a
> > specific channel ID for a special use. E.g. channel ID: 1 - voice , 2
> > - chat, 3 - video. This is meant to be used by non-browser apps that
> > build their protocols based on mux to decrease the number of client
> > connections to the server.
>
> I see. So you're assuming that the client will generate the channel IDs,
> right?
>
> /psa
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

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

Please note that I'm not going to make channel ID values to be a new di=
mension of WebSocket protocol's interface for its users, but just going=
 to leave channel ID assignment algorithm up to implementors so that some n=
on-browser apps may assign channel IDs as they like and give some meaning a=
s Arman described below.



I won't add any new restriction on intermediaries to ens=
ure that channel ID values are the same on both endpoints. There's no s=
uch guarantee. We're gonna just make WebSocket available for developers=
 of special application who want to divert WebSocket+MUX for their own serv=
ice.




Takeshi



On Wed, Mar 28, 2012 at 14:56, Arman Dju=
supov <arman@noema=
x.com> wrote:


As currently designed, it's the client side that assigns the channel ID=
 when sending an AddChannel request.



However even if it's the server side that assigns the channel ID there =
are still workarounds that would allow similar functionality.




With best regards,

Arman



-----Original Message-----


From: Peter Saint-Andre [mail=
to:stpeter@stpeter.im]

Sent: Wednesday, March 28, 2012 3:34 PM

To: Arman Djusupov

Cc: hybi@ietf.org

Subject: Re: [hybi] MUC: channel ID semantics



On 3/28/12 2:11 PM, Arman Djusupov wrote:

> This means using the channel ID to identify the type of the service in=


> the same way as TCP/IP port numbers. Where the application reserves a<=
br>
> specific channel ID for a special use. E.g. channel ID: 1 - voice , 2<=
br>
> - chat, 3 - video. This is meant to be used by non-browser apps that
> build their protocols based on mux to decrease the number of client
> connections to the server.



I see. So you're assuming that the client will generate the channel IDs=
, right?



/psa



_______________________________________________

hybi mailing list

hybi@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/hybi





--20cf303b40e307c13904bc4d5245--

From w@1wt.eu  Wed Mar 28 06:09:45 2012
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 0805421E81AC for ; Wed, 28 Mar 2012 06:09:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.178
X-Spam-Level: 
X-Spam-Status: No, score=-5.178 tagged_above=-999 required=5 tests=[AWL=-3.135, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6xe4FR+PbXI for ; Wed, 28 Mar 2012 06:09:44 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3CF21F88E8 for ; Wed, 28 Mar 2012 06:09:44 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2SD9fwH030139; Wed, 28 Mar 2012 15:09:41 +0200
Date: Wed, 28 Mar 2012 15:09:41 +0200
From: Willy Tarreau 
To: Arman Djusupov 
Message-ID: <20120328130941.GB30088@1wt.eu>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 13:09:45 -0000

On Wed, Mar 28, 2012 at 03:56:57PM +0300, Arman Djusupov wrote:
> As currently designed, it's the client side that assigns the channel ID when
> sending an AddChannel request.
> 
> However even if it's the server side that assigns the channel ID there are
> still workarounds that would allow similar functionality.

If you consider the channel ID to be hop-by-hop only, you eliminate the
need for assignment and you can still let the client open them in a
preference order (if that matters to some apps).

Willy


From arman@noemax.com  Wed Mar 28 06:20:13 2012
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 7348E21E8216 for ; Wed, 28 Mar 2012 06:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.128
X-Spam-Level: 
X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F38vdBSp15ON for ; Wed, 28 Mar 2012 06:20:11 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2AA21E81FF for ; Wed, 28 Mar 2012 06:20:11 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MQW60416; Wed, 28 Mar 2012 16:20:16 +0300
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> 
In-Reply-To: 
Date: Wed, 28 Mar 2012 16:20:06 +0300
Message-ID: <004a01cd0ce5$82556110$87002330$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004B_01CD0CFE.A7A55830"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAJixsSUmQDzUyA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 13:20:13 -0000

This is a multipart message in MIME format.

------=_NextPart_000_004B_01CD0CFE.A7A55830
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Thank you. That's exactly what I would like.

 

With best regards,

Arman

 

From: Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Wednesday, March 28, 2012 4:09 PM
To: Arman Djusupov
Cc: Peter Saint-Andre; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

 

Please note that I'm not going to make channel ID values to be a new
dimension of WebSocket protocol's interface for its users, but just going to
leave channel ID assignment algorithm up to implementors so that some
non-browser apps may assign channel IDs as they like and give some meaning
as Arman described below.

 

I won't add any new restriction on intermediaries to ensure that channel ID
values are the same on both endpoints. There's no such guarantee. We're
gonna just make WebSocket available for developers of special application
who want to divert WebSocket+MUX for their own service.


Takeshi



On Wed, Mar 28, 2012 at 14:56, Arman Djusupov  wrote:

As currently designed, it's the client side that assigns the channel ID when
sending an AddChannel request.

However even if it's the server side that assigns the channel ID there are
still workarounds that would allow similar functionality.


With best regards,
Arman

-----Original Message-----

From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
Sent: Wednesday, March 28, 2012 3:34 PM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

On 3/28/12 2:11 PM, Arman Djusupov wrote:
> This means using the channel ID to identify the type of the service in
> the same way as TCP/IP port numbers. Where the application reserves a
> specific channel ID for a special use. E.g. channel ID: 1 - voice , 2
> - chat, 3 - video. This is meant to be used by non-browser apps that
> build their protocols based on mux to decrease the number of client
> connections to the server.

I see. So you're assuming that the client will generate the channel IDs,
right?

/psa

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

 


------=_NextPart_000_004B_01CD0CFE.A7A55830
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


Thank you. That’s exactly what I would =
like.
 
With best regards,
Arman
 
From:=
 =
Takeshi Yoshino [mailto:tyoshino@google.com] 
Sent: Wednesday, =
March 28, 2012 4:09 PM
To: Arman Djusupov
Cc: Peter =
Saint-Andre; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID =
semantics
 
Please note =
that I'm not going to make channel ID values to be a new dimension of =
WebSocket protocol's interface for its users, but just going to leave =
channel ID assignment algorithm up to implementors so that some =
non-browser apps may assign channel IDs as they like and give some =
meaning as Arman described below.
 
I =
won't add any new restriction on intermediaries to ensure that channel =
ID values are the same on both endpoints. There's no such guarantee. =
We're gonna just make WebSocket available for developers of special =
application who want to divert WebSocket+MUX for their own =
service.

Takeshi

On =
Wed, Mar 28, 2012 at 14:56, Arman Djusupov <arman@noemax.com> =
wrote:
As currently designed, it's =
the client side that assigns the channel ID when sending an AddChannel =
request.

However even if it's the server side that assigns the =
channel ID there are still workarounds that would allow similar =
functionality.

With best =
regards,
Arman

-----Original =
Message-----
From: =
Peter Saint-Andre [mailto:stpeter@stpeter.im]
Sent: =
Wednesday, March 28, 2012 3:34 PM
To: Arman Djusupov
Cc: hybi@ietf.org
Subject: Re: [hybi] =
MUC: channel ID semantics

On 3/28/12 2:11 PM, Arman Djusupov =
wrote:
> This means using the channel ID to identify the type of =
the service in
> the same way as TCP/IP port numbers. Where the =
application reserves a
> specific channel ID for a special use. =
E.g. channel ID: 1 - voice , 2
> - chat, 3 - video. This is meant =
to be used by non-browser apps that
> build their protocols based =
on mux to decrease the number of client
> connections to the =
server.

I see. So you're assuming that the client will generate =
the channel IDs, =
right?

/psa

_______________________________________________=

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

------=_NextPart_000_004B_01CD0CFE.A7A55830--


From jat@google.com  Wed Mar 28 06:49:13 2012
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 114C521E81D7 for ; Wed, 28 Mar 2012 06:49:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.676
X-Spam-Level: 
X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwjbifcTWxPL for ; Wed, 28 Mar 2012 06:49:12 -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 E605F21E8188 for ; Wed, 28 Mar 2012 06:49:11 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so841280vcb.31 for ; Wed, 28 Mar 2012 06:49:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=XsV0U78FETdYiS9Tw32W0kos6fOR9TpHsEyd5AAH4KE=; b=D31WebntdOj+ciE+usrU+Vcb8hbtmCDNvPhiMuzL7jCVPvu9DBgyqfeZ6sgO1auAVS tTF1f7yTGZTXrziBNCqstfk4yUXJ6ocyFmlvB2XOqKYnHSTmV9XFUM0pOWOoFxQTz9zD hZELU/DH1qhxJcwh+lfoe1jszvMe/B+xxcntcZa6vgtKJE3LFhDjlmZV204BZQ2+8XqM DudO8pzZFy5SwqlzsPMkLdsGFJAuXXWUizh79+rxtKg6lce3b+M69M4QZ+dm/gHP8mtY zGu5xgtS0eqrDDhC4p5Exl5L7NN7p8cqqvmPa+ADJAplC/G3NWAyoogF3pGWVT2dEwV5 jF4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=XsV0U78FETdYiS9Tw32W0kos6fOR9TpHsEyd5AAH4KE=; b=OtQsQiIAZSk6X7B++yyB/VeKEUdQx+Fu8Ue3FkJZ/IA6HGEzqCK1CXLS5FKLUTNhUw f1psO5i1YKeg/d41cTjGP0IKk8yJAe6XkXt+a8uNCHtzag9Mvo6EvTY02YeyuC/dotwM F7mM1KrmlR6bu7mo8LN6Vfdwhxf/YL2dTrsWGbmbmIPZhCA3N2QvwBMCjA3aVw9Qe7SE IrU4BrInhGKFPP3dj6xrmZArpd7TcGy85Zuu8LLDfGZb/KOF7IwfEtjTvMBzHz0MR80j 3cuxCW8J8iJyY5SUp6OpNHAWUimQVtkhzB1UFa01sYN8WNzr6m0bbFAo4UTOodOuxZU/ CKwg==
Received: by 10.52.28.178 with SMTP id c18mr11518325vdh.45.1332942551389; Wed, 28 Mar 2012 06:49:11 -0700 (PDT)
Received: by 10.52.28.178 with SMTP id c18mr11518315vdh.45.1332942551098; Wed, 28 Mar 2012 06:49:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.67 with HTTP; Wed, 28 Mar 2012 06:48:50 -0700 (PDT)
In-Reply-To: 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> 
From: John Tamplin 
Date: Wed, 28 Mar 2012 09:48:50 -0400
Message-ID: 
To: Takeshi Yoshino 
Content-Type: multipart/alternative; boundary=20cf307ac3f343a51b04bc4ddfc9
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmngs+LadDkuq4ShQBUpWyRr4/suyjfZfYYxeT3OIxlWl7ihHSvKI6Uh8wXFgFNplKCAvWOo4gUWL9uWb1LLMmKAplNonExPf43o+89XdVw2qf56pXE+RWka3OOfu1kgYj1yfov
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 13:49:13 -0000

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

On Wed, Mar 28, 2012 at 9:09 AM, Takeshi Yoshino wrote:

> Please note that I'm not going to make channel ID values to be a new
> dimension of WebSocket protocol's interface for its users, but just going
> to leave channel ID assignment algorithm up to implementors so that some
> non-browser apps may assign channel IDs as they like and give some meaning
> as Arman described below.
>
> I won't add any new restriction on intermediaries to ensure that channel
> ID values are the same on both endpoints. There's no such guarantee. We're
> gonna just make WebSocket available for developers of special application
> who want to divert WebSocket+MUX for their own service.
>

I'm really not sure what the benefit is if intermediaries aren't required
to preserve channel assignment (and I agree they shouldn't).  If someone
controls both endpoints and the intervening network so they can enforce
such a mapping, then they can already do what they want and if they want to
use a variant of WS that's fine, but it shouldn't constrain what the WS
spec can do.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Wed, Mar 28, 2012 at 9:09 AM, Takeshi Yoshino=
 <tyoshino@goog=
le.com> wrote:


Please note that I'm not going to make channel ID values to be a new di=
mension of WebSocket protocol's interface for its users, but just going=
 to leave channel ID assignment algorithm up to implementors so that some n=
on-browser apps may assign channel IDs as they like and give some meaning a=
s Arman described below.





I won't add any new restriction on intermediaries to ens=
ure that channel ID values are the same on both endpoints. There's no s=
uch guarantee. We're gonna just make WebSocket available for developers=
 of special application who want to divert WebSocket+MUX for their own serv=
ice.




I'm really not sure what the benefit i=
s if intermediaries aren't required to preserve channel assignment (and=
 I agree they shouldn't). =C2=A0If someone controls both endpoints and =
the intervening network so they can enforce such a mapping, then they can a=
lready do what they want and if they want to use a variant of WS that's=
 fine, but it shouldn't constrain what the WS spec can do.




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--20cf307ac3f343a51b04bc4ddfc9--

From arman@noemax.com  Wed Mar 28 07:02:59 2012
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 0DD9C21F8A4D for ; Wed, 28 Mar 2012 07:02:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.421
X-Spam-Level: 
X-Spam-Status: No, score=-2.421 tagged_above=-999 required=5 tests=[AWL=0.178,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id unt6t8O0Oc4Y for ; Wed, 28 Mar 2012 07:02:58 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 5E85721E808E for ; Wed, 28 Mar 2012 07:02:58 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MRF71303; Wed, 28 Mar 2012 17:03:03 +0300
From: "Arman Djusupov" 
To: "'Willy Tarreau'" 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> <20120328130941.GB30088@1wt.eu>
In-Reply-To: <20120328130941.GB30088@1wt.eu>
Date: Wed, 28 Mar 2012 17:02:53 +0300
Message-ID: <005c01cd0ceb$7c7f2e50$757d8af0$@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: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAIWiDeDmQNhncA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 14:02:59 -0000

Yes, using the Channel IDs are not strictly necessary, the client can also
use the protocol or any other header during logical channel handshake as a
criteria to specify the type of the service being requested. 

With best regards,
Arman

-----Original Message-----
From: Willy Tarreau [mailto:w@1wt.eu] 
Sent: Wednesday, March 28, 2012 4:10 PM
To: Arman Djusupov
Cc: 'Peter Saint-Andre'; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

On Wed, Mar 28, 2012 at 03:56:57PM +0300, Arman Djusupov wrote:
> As currently designed, it's the client side that assigns the channel 
> ID when sending an AddChannel request.
> 
> However even if it's the server side that assigns the channel ID there 
> are still workarounds that would allow similar functionality.

If you consider the channel ID to be hop-by-hop only, you eliminate the need
for assignment and you can still let the client open them in a preference
order (if that matters to some apps).

Willy


From arman@noemax.com  Wed Mar 28 07:18:33 2012
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 18FA321E81BF for ; Wed, 28 Mar 2012 07:18:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.43
X-Spam-Level: 
X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.168,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KmflQ3NBrN+w for ; Wed, 28 Mar 2012 07:18:32 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 7322721E816A for ; Wed, 28 Mar 2012 07:18:31 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MRU97936; Wed, 28 Mar 2012 17:18:36 +0300
From: "Arman Djusupov" 
To: "'Takeshi Yoshino'" 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> 
In-Reply-To: 
Date: Wed, 28 Mar 2012 17:18:27 +0300
Message-ID: <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005E_01CD0D06.CE14D8D0"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAJixsSUmQEBKcA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 14:18:33 -0000

This is a multipart message in MIME format.

------=_NextPart_000_005E_01CD0D06.CE14D8D0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I would also like to suggest that we make it possible for an entire set of
channels to be established together during/after the physical channel
handshake. This would speed up the creation of logical channels for all
types of clients.

 

There are various options how to perform this.

 

a) Include the request for the set of channels into the physical channel
handshake.

 

b) Use a more advanced format for the AddChannel request. For example it
could specify the number of channels to create using the same handshake, so
that a single handshake results in creating a range of identical logical
channels.

 

c) When the application needs to create multiple channels with different
settings (e.g. protocol, compression and so on), it should be able to send a
batch of AddChannel requests at once and then wait for each of those
channels to be confirmed by the server.

 

With best regards,

Arman 

 


------=_NextPart_000_005E_01CD0D06.CE14D8D0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


I would also like to suggest that we make it possible for an entire =
set of channels to be established together during/after the physical =
channel handshake. This would speed up the creation of logical channels =
for all types of clients.
 
There are various options how to perform =
this.
 
a) Include the request for the set of channels into the physical =
channel handshake.
 
b) Use a more advanced format for the AddChannel request. For example =
it could specify the number of channels to create using the same =
handshake, so that a single handshake results in creating a range of =
identical logical channels.
 
c) When the application needs to create multiple channels with =
different settings (e.g. protocol, compression and so on), it should be =
able to send a batch of AddChannel requests at once and then wait for =
each of those channels to be confirmed by the =
server.
 
With best regards,
Arman 
 

------=_NextPart_000_005E_01CD0D06.CE14D8D0--


From jat@google.com  Wed Mar 28 07:37:03 2012
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 BCE2B21E81AD for ; Wed, 28 Mar 2012 07:37:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.962
X-Spam-Level: 
X-Spam-Status: No, score=-102.962 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhPORhzooqBy for ; Wed, 28 Mar 2012 07:37:03 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D368C21E818A for ; Wed, 28 Mar 2012 07:37:02 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so856547vbb.31 for ; Wed, 28 Mar 2012 07:37:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=/M9qKf9oXTxuiTB7xUUhuJ3Dsp8TFK88CzygBaMf32k=; b=cBOFliG0c9lJfAjA2FY7ZabV9cArdQIH7tbvpXHRq0i53h/JMBPECkVUuNvPKCb4KS Wzb0GvpO0D7k/jadKyo4fYxs8y4/Lo3ZcncigWxulWVQK8T4jIh2Db7N38DmNFaVWhZa ZLEgPY29mxgJztt0v2izgD63LFf5WXp5NZab+5eBV0HmcUhTT4GdQ3QVXmlZVE1OuWN1 Dr14lR5zZ0OKy/FZ6EHFssrM7OAMFS1Me0twCiOds0WxGNOUtkcy7Rf49xNg2DPgfnqs U4bMrLqaEOC/KOjM4i1Ifa4TAOpOPRtfQfHtfx3TepBpAigGScIZ7notQbSspbZqOo7X HeWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=/M9qKf9oXTxuiTB7xUUhuJ3Dsp8TFK88CzygBaMf32k=; b=J1y4M1wtfiblTi1NWsGAAxgKqXmXkhsjPq7zMgvOASQuEDf/YzmJXypajDq2KPoScT SJT4QS7oc5x1Hcr6ZuO7EEfHtESzdScjNIRr510tDuGuBh26qshHudHu20bGokLbIXtr pKxknANB+zD3rcNEkNme0c2HnCRWd5BgV1/kMf745FToFdWgPNhjIOrngCjGgV4pDNfo T/uIsD5zFSiArj9i2FsiRH9y11JRztTm82IkHt8S/wOMBHTmJw0zqocCV8vtjGlaVXi5 rxSBnepnEpMtNBWk1iWAQ7DnJCVdYyFZvqN3hIP7gpY04AlhfYdv8l/GB+wZ/EdvCJhl 3bEA==
Received: by 10.52.91.47 with SMTP id cb15mr11615093vdb.76.1332945422337; Wed, 28 Mar 2012 07:37:02 -0700 (PDT)
Received: by 10.52.91.47 with SMTP id cb15mr11615078vdb.76.1332945421874; Wed, 28 Mar 2012 07:37:01 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.67 with HTTP; Wed, 28 Mar 2012 07:36:41 -0700 (PDT)
In-Reply-To: <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>
From: John Tamplin 
Date: Wed, 28 Mar 2012 10:36:41 -0400
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf307f31d26034d404bc4e8ae6
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmGp6ke/3wyHkutkqW2Hs2KlfPdDKlp9GS8y3aHpT97m+X3r5f5rOhHz0eowk/auBE+7vTRXBMCx1lvUWb5myRuXNZFVWUbFbbhcpwPpnD2WMY6Z4nKNBa+RLKI+GwUR90y9Hsr
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 14:37:03 -0000

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

On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov  wrote:

> I would also like to suggest that we make it possible for an entire set of
> channels to be established together during/after the physical channel
> handshake. This would speed up the creation of logical channels for all
> types of clients.****
>
> ** **
>
> There are various options how to perform this.****
>
> ** **
>
> a) Include the request for the set of channels into the physical channel
> handshake.****
>
> ** **
>
> b) Use a more advanced format for the AddChannel request. For example it
> could specify the number of channels to create using the same handshake, so
> that a single handshake results in creating a range of identical logical
> channels.****
>
> ** **
>
> c) When the application needs to create multiple channels with different
> settings (e.g. protocol, compression and so on), it should be able to send
> a batch of AddChannel requests at once and then wait for each of those
> channels to be confirmed by the server.
>

Again, this requires changes to the JS API, which isn't the purview of hybi
but rather WHATWG.  With the current JS API, you can only create one
channel at a time, so the only opportunity for bundling AddChannels
together would be if another tab creates a channel at exactly the same time
(or you delay the first request long enough to wait for another one).

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov=
 <arman@noemax.com=
> wrote:



I would also like to suggest that we make it=
 possible for an entire set of channels to be established together during/a=
fter the physical channel handshake. This would speed up the creation of lo=
gical channels for all types of clients.



=C2=A0
There are various o=
ptions how to perform this.



=C2=A0
a) Include the requ=
est for the set of channels into the physical channel handshake.<=
/u>



=C2=A0
b) Use a more advan=
ced format for the AddChannel request. For example it could specify the num=
ber of channels to create using the same handshake, so that a single handsh=
ake results in creating a range of identical logical channels.



=C2=A0
c) When the applica=
tion needs to create multiple channels with different settings (e.g. protoc=
ol, compression and so on), it should be able to send a batch of AddChannel=
 requests at once and then wait for each of those channels to be confirmed =
by the server.




Again, this requires changes t=
o the JS API, which isn't the purview of hybi but rather WHATWG. =C2=A0=
With the current JS API, you can only create one channel at a time, so the =
only opportunity for bundling AddChannels together would be if another tab =
creates a channel at exactly the same time (or you delay the first request =
long enough to wait for another one).=C2=A0




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--20cf307f31d26034d404bc4e8ae6--

From Gabriel.Montenegro@microsoft.com  Wed Mar 28 08:50:39 2012
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 172CF21E80B8 for ; Wed, 28 Mar 2012 08:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.932
X-Spam-Level: 
X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8khHbZajkngz for ; Wed, 28 Mar 2012 08:50:38 -0700 (PDT)
Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 5559921E80BD for ; Wed, 28 Mar 2012 08:50:37 -0700 (PDT)
Received: from mail98-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 15:50:35 +0000
Received: from mail98-ch1 (localhost [127.0.0.1])	by mail98-ch1-R.bigfish.com (Postfix) with ESMTP id DAF963A087B; Wed, 28 Mar 2012 15:50:35 +0000 (UTC)
X-SpamScore: -11
X-BigFish: VS-11(zz9371Ic89bhc857h98dK139buzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail98-ch1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail98-ch1 (localhost.localdomain [127.0.0.1]) by mail98-ch1 (MessageSwitch) id 1332949833387092_27593; Wed, 28 Mar 2012 15:50:33 +0000 (UTC)
Received: from CH1EHSMHS018.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.242])	by mail98-ch1.bigfish.com (Postfix) with ESMTP id 5A1BD16018F;	Wed, 28 Mar 2012 15:50:33 +0000 (UTC)
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS018.bigfish.com (10.43.70.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 15:50:32 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 28 Mar 2012 15:50:24 +0000
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.283.4; Wed, 28 Mar 2012 08:50:24 -0700
Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Wed, 28 Mar 2012 08:50:24 -0700
From: Gabriel Montenegro 
To: John Tamplin , Arman Djusupov 
Thread-Topic: [hybi] MUC: channel ID semantics
Thread-Index: AQHNDNklSTVu2fS4zUeg2jegLhAELZaAE2yAgAAGUYCAAAZtgIAAA3eAgAATToCAAAUYgP//nVHQ
Date: Wed, 28 Mar 2012 15:50:23 +0000
Message-ID: 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com>	<4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com> 
In-Reply-To: 
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: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F55C34TK5EX14MBXW602w_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 15:50:39 -0000

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

SnVzdCBhIG5vdGUgdGhhdCB0aGUgQVBJIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBpbiB0aGUgZjJm
IHRvZGF5LiBJZiB0aGVyZSBhcmUgYW55IHN1Y2ggaXNzdWVzIChhbmQgZHVyaW5nIHRoZSBtZWV0
aW5nIGl0IGRpZCBub3Qgc2VlbSB0byBiZSB0aGUgY2FzZSksIHRoZSBXRyB3aWxsIGNvb3JkaW5h
dGUgd2l0aCB0aGUgVzNDIHdlYmFwcHMgV0csIHdoaWNoIGlzIHRoZSBvcmdhbml6YXRpb24gd2Ug
bGlhaXNlIHdpdGguDQoNCkFzIGl0IHR1cm5zIG91dCwgdGhleeKAmXJlIGluIHRoZSBwcm9jZXNz
IG9mIHJlY2hhcnRlcmluZzoNCg0KV2ViIEFwcGxpY2F0aW9ucyBXb3JraW5nIEdyb3VwOg0KDQpo
dHRwOi8vd3d3LnczLm9yZy8yMDEyLzAzL3dlYmFwcHMtcHJvcG9zZWQtY2hhcnRlci5odG1sDQoN
CklmIGFueWJvZHkgZmVlbHMgc3Ryb25nbHkgdGhhdCB0aGVyZSBpcyBhbnkgQVBJIGltcGFjdCBv
ZiBlaXRoZXIgdGhlIG11eCBvciBjb21wcmVzc2lvbiwgcGxlYXNlIHN1cHBvcnQgc3VjaCBjbGFp
bXMuDQoNCkZyb206IGh5YmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEpvaG4gVGFtcGxpbg0KU2VudDogV2VkbmVzZGF5LCAyOCBN
YXJjaCwgMjAxMiAxNjozNw0KVG86IEFybWFuIERqdXN1cG92DQpDYzogaHliaUBpZXRmLm9yZw0K
U3ViamVjdDogUmU6IFtoeWJpXSBNVUM6IGNoYW5uZWwgSUQgc2VtYW50aWNzDQoNCk9uIFdlZCwg
TWFyIDI4LCAyMDEyIGF0IDEwOjE4IEFNLCBBcm1hbiBEanVzdXBvdiA8YXJtYW5Abm9lbWF4LmNv
bTxtYWlsdG86YXJtYW5Abm9lbWF4LmNvbT4+IHdyb3RlOg0KSSB3b3VsZCBhbHNvIGxpa2UgdG8g
c3VnZ2VzdCB0aGF0IHdlIG1ha2UgaXQgcG9zc2libGUgZm9yIGFuIGVudGlyZSBzZXQgb2YgY2hh
bm5lbHMgdG8gYmUgZXN0YWJsaXNoZWQgdG9nZXRoZXIgZHVyaW5nL2FmdGVyIHRoZSBwaHlzaWNh
bCBjaGFubmVsIGhhbmRzaGFrZS4gVGhpcyB3b3VsZCBzcGVlZCB1cCB0aGUgY3JlYXRpb24gb2Yg
bG9naWNhbCBjaGFubmVscyBmb3IgYWxsIHR5cGVzIG9mIGNsaWVudHMuDQoNClRoZXJlIGFyZSB2
YXJpb3VzIG9wdGlvbnMgaG93IHRvIHBlcmZvcm0gdGhpcy4NCg0KYSkgSW5jbHVkZSB0aGUgcmVx
dWVzdCBmb3IgdGhlIHNldCBvZiBjaGFubmVscyBpbnRvIHRoZSBwaHlzaWNhbCBjaGFubmVsIGhh
bmRzaGFrZS4NCg0KYikgVXNlIGEgbW9yZSBhZHZhbmNlZCBmb3JtYXQgZm9yIHRoZSBBZGRDaGFu
bmVsIHJlcXVlc3QuIEZvciBleGFtcGxlIGl0IGNvdWxkIHNwZWNpZnkgdGhlIG51bWJlciBvZiBj
aGFubmVscyB0byBjcmVhdGUgdXNpbmcgdGhlIHNhbWUgaGFuZHNoYWtlLCBzbyB0aGF0IGEgc2lu
Z2xlIGhhbmRzaGFrZSByZXN1bHRzIGluIGNyZWF0aW5nIGEgcmFuZ2Ugb2YgaWRlbnRpY2FsIGxv
Z2ljYWwgY2hhbm5lbHMuDQoNCmMpIFdoZW4gdGhlIGFwcGxpY2F0aW9uIG5lZWRzIHRvIGNyZWF0
ZSBtdWx0aXBsZSBjaGFubmVscyB3aXRoIGRpZmZlcmVudCBzZXR0aW5ncyAoZS5nLiBwcm90b2Nv
bCwgY29tcHJlc3Npb24gYW5kIHNvIG9uKSwgaXQgc2hvdWxkIGJlIGFibGUgdG8gc2VuZCBhIGJh
dGNoIG9mIEFkZENoYW5uZWwgcmVxdWVzdHMgYXQgb25jZSBhbmQgdGhlbiB3YWl0IGZvciBlYWNo
IG9mIHRob3NlIGNoYW5uZWxzIHRvIGJlIGNvbmZpcm1lZCBieSB0aGUgc2VydmVyLg0KDQpBZ2Fp
biwgdGhpcyByZXF1aXJlcyBjaGFuZ2VzIHRvIHRoZSBKUyBBUEksIHdoaWNoIGlzbid0IHRoZSBw
dXJ2aWV3IG9mIGh5YmkgYnV0IHJhdGhlciBXSEFUV0cuICBXaXRoIHRoZSBjdXJyZW50IEpTIEFQ
SSwgeW91IGNhbiBvbmx5IGNyZWF0ZSBvbmUgY2hhbm5lbCBhdCBhIHRpbWUsIHNvIHRoZSBvbmx5
IG9wcG9ydHVuaXR5IGZvciBidW5kbGluZyBBZGRDaGFubmVscyB0b2dldGhlciB3b3VsZCBiZSBp
ZiBhbm90aGVyIHRhYiBjcmVhdGVzIGEgY2hhbm5lbCBhdCBleGFjdGx5IHRoZSBzYW1lIHRpbWUg
KG9yIHlvdSBkZWxheSB0aGUgZmlyc3QgcmVxdWVzdCBsb25nIGVub3VnaCB0byB3YWl0IGZvciBh
bm90aGVyIG9uZSkuDQoNCi0tDQpKb2huIEEuIFRhbXBsaW4NClNvZnR3YXJlIEVuZ2luZWVyIChH
V1QpLCBHb29nbGUNCg==

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

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVC
My0xMWQxLUEyOUYtMDBBQTAwQzE0ODgyIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3Nv
ZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S
RUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250
ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBj
b250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEt
LQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMg
TWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg
MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl
LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25z
b2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv
bnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9
DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2
Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0K
YTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s
b3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5N
c29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVy
cGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1z
b1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ
bXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4t
Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy
aSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl
cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s
b3I6IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWlu
IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQ
bGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD
YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g
MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp
b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld
Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K
PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91
dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz
aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT
IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+SnVzdCBhIG5vdGUgdGhhdCB0aGUgQVBJIGlzc3VlcyB3ZXJlIGRpc2N1c3NlZCBp
biB0aGUgZjJmIHRvZGF5LiBJZiB0aGVyZSBhcmUgYW55IHN1Y2ggaXNzdWVzIChhbmQgZHVyaW5n
IHRoZSBtZWV0aW5nIGl0IGRpZCBub3Qgc2VlbSB0byBiZSB0aGUgY2FzZSksIHRoZSBXRw0KIHdp
bGwgY29vcmRpbmF0ZSB3aXRoIHRoZSBXM0Mgd2ViYXBwcyBXRywgd2hpY2ggaXMgdGhlIG9yZ2Fu
aXphdGlvbiB3ZSBsaWFpc2Ugd2l0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFzIGl0IHR1cm5zIG91dCwgdGhleeKA
mXJlIGluIHRoZSBwcm9jZXNzIG9mIHJlY2hhcnRlcmluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5XZWIgQXBwbGljYXRpb25zIFdvcmtpbmcgR3JvdXA6
PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48YSBocmVmPSJodHRwOi8v
d3d3LnczLm9yZy8yMDEyLzAzL3dlYmFwcHMtcHJvcG9zZWQtY2hhcnRlci5odG1sIj5odHRwOi8v
d3d3LnczLm9yZy8yMDEyLzAzL3dlYmFwcHMtcHJvcG9zZWQtY2hhcnRlci5odG1sPC9hPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5J
ZiBhbnlib2R5IGZlZWxzIHN0cm9uZ2x5IHRoYXQgdGhlcmUgaXMgYW55IEFQSSBpbXBhY3Qgb2Yg
ZWl0aGVyIHRoZSBtdXggb3IgY29tcHJlc3Npb24sIHBsZWFzZSBzdXBwb3J0IHN1Y2ggY2xhaW1z
Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41
cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy
Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp
biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IGh5YmktYm91
bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs
ZiBPZiA8L2I+Sm9obiBUYW1wbGluPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgMjggTWFy
Y2gsIDIwMTIgMTY6Mzc8YnI+DQo8Yj5Ubzo8L2I+IEFybWFuIERqdXN1cG92PGJyPg0KPGI+Q2M6
PC9iPiBoeWJpQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gTVVDOiBj
aGFubmVsIElEIHNlbWFudGljczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIE1hciAyOCwgMjAxMiBhdCAxMDoxOCBBTSwgQXJtYW4g
RGp1c3Vwb3YgJmx0OzxhIGhyZWY9Im1haWx0bzphcm1hbkBub2VtYXguY29tIj5hcm1hbkBub2Vt
YXguY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu
LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkkgd291bGQgYWxzbyBsaWtlIHRvIHN1Z2dlc3QgdGhhdCB3ZSBtYWtlIGl0IHBvc3NpYmxl
IGZvciBhbiBlbnRpcmUgc2V0IG9mIGNoYW5uZWxzIHRvIGJlIGVzdGFibGlzaGVkDQogdG9nZXRo
ZXIgZHVyaW5nL2FmdGVyIHRoZSBwaHlzaWNhbCBjaGFubmVsIGhhbmRzaGFrZS4gVGhpcyB3b3Vs
ZCBzcGVlZCB1cCB0aGUgY3JlYXRpb24gb2YgbG9naWNhbCBjaGFubmVscyBmb3IgYWxsIHR5cGVz
IG9mIGNsaWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu
PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t
dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgYXJlIHZhcmlvdXMgb3B0aW9ucyBob3cg
dG8gcGVyZm9ybSB0aGlzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6
YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPmEpIEluY2x1ZGUgdGhlIHJlcXVlc3QgZm9y
IHRoZSBzZXQgb2YgY2hhbm5lbHMgaW50byB0aGUgcGh5c2ljYWwgY2hhbm5lbCBoYW5kc2hha2Uu
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90
O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv
O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7
Y29sb3I6IzFGNDk3RCI+YikgVXNlIGEgbW9yZSBhZHZhbmNlZCBmb3JtYXQgZm9yIHRoZSBBZGRD
aGFubmVsIHJlcXVlc3QuIEZvciBleGFtcGxlIGl0IGNvdWxkIHNwZWNpZnkgdGhlIG51bWJlcg0K
IG9mIGNoYW5uZWxzIHRvIGNyZWF0ZSB1c2luZyB0aGUgc2FtZSBoYW5kc2hha2UsIHNvIHRoYXQg
YSBzaW5nbGUgaGFuZHNoYWtlIHJlc3VsdHMgaW4gY3JlYXRpbmcgYSByYW5nZSBvZiBpZGVudGlj
YWwgbG9naWNhbCBjaGFubmVscy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t
YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz
cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1
b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5jKSBXaGVuIHRoZSBhcHBsaWNhdGlv
biBuZWVkcyB0byBjcmVhdGUgbXVsdGlwbGUgY2hhbm5lbHMgd2l0aCBkaWZmZXJlbnQgc2V0dGlu
Z3MgKGUuZy4gcHJvdG9jb2wsDQogY29tcHJlc3Npb24gYW5kIHNvIG9uKSwgaXQgc2hvdWxkIGJl
IGFibGUgdG8gc2VuZCBhIGJhdGNoIG9mIEFkZENoYW5uZWwgcmVxdWVzdHMgYXQgb25jZSBhbmQg
dGhlbiB3YWl0IGZvciBlYWNoIG9mIHRob3NlIGNoYW5uZWxzIHRvIGJlIGNvbmZpcm1lZCBieSB0
aGUgc2VydmVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BZ2FpbiwgdGhpcyByZXF1aXJlcyBjaGFuZ2VzIHRvIHRo
ZSBKUyBBUEksIHdoaWNoIGlzbid0IHRoZSBwdXJ2aWV3IG9mIGh5YmkgYnV0IHJhdGhlciBXSEFU
V0cuICZuYnNwO1dpdGggdGhlIGN1cnJlbnQgSlMgQVBJLCB5b3UgY2FuIG9ubHkgY3JlYXRlIG9u
ZSBjaGFubmVsIGF0IGEgdGltZSwgc28gdGhlIG9ubHkgb3Bwb3J0dW5pdHkgZm9yIGJ1bmRsaW5n
IEFkZENoYW5uZWxzIHRvZ2V0aGVyIHdvdWxkIGJlIGlmIGFub3RoZXINCiB0YWIgY3JlYXRlcyBh
IGNoYW5uZWwgYXQgZXhhY3RseSB0aGUgc2FtZSB0aW1lIChvciB5b3UgZGVsYXkgdGhlIGZpcnN0
IHJlcXVlc3QgbG9uZyBlbm91Z2ggdG8gd2FpdCBmb3IgYW5vdGhlciBvbmUpLiZuYnNwOzxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJy
Pg0KSm9obiBBLiBUYW1wbGluPGJyPg0KU29mdHdhcmUgRW5naW5lZXIgKEdXVCksIEdvb2dsZTxv
OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F55C34TK5EX14MBXW602w_--

From jat@google.com  Wed Mar 28 11:09:09 2012
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 A75D421E81EA for ; Wed, 28 Mar 2012 11:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcp3hVBM6zbz for ; Wed, 28 Mar 2012 11:09:09 -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 C0D3D21E81DA for ; Wed, 28 Mar 2012 11:09:08 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1072155vcb.31 for ; Wed, 28 Mar 2012 11:09:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=F62tOHtdHoicqaeiVdRP/W5h6xZbW93wtZucC055G/4=; b=AdKnAmANK9UyJPgPav3mg7xlPlWesaUteGkn81+deGeUkggqWzQPSDfQOwCFvMhU54 ol8tyuFK7259SV3ZYaxIlQ3S48ksh5hT4LBLplMqSnZ0ZgePgYPD+g2DheUSxtWTicED JlACUZTay9TfURoRDWt2qHPOVvn2poljjOpR1k7TDD1bnLR7sZ8XNJ1P4gabKwz71qH2 NJfNIdrmnpxXdY7FbHGEuny7PW3ggDht19gpsnH0iDlWU4rVbPgLeca0TfUxBs6jjKcJ 9l6RhbJQeTkF5xmBwxb8Rx7Xi8CbXB/UYIfWNJE7GvEK+muwc5AVPF6Jv4YF/l47A1Mi VVNQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=F62tOHtdHoicqaeiVdRP/W5h6xZbW93wtZucC055G/4=; b=n8vMgbRgbQIjYxph/WHwQV31uEKR1DHCvGI72zHFFDTpEGH57lCLf2E+qUSOlDZX2r FpYsMHjBTcLesOKjPs8Be/1o56BD+IMR6kx+uXZfFDN+XvvFwLk3zxnLzISWlhrMMSL1 tSVMNSSC1CqIjH2L2uhbUWpCgKLUI/mkpKY4wlsIruuNduGuCwecifSyaOzsJVZNUzVJ N6mZ0W3uMLbAf5DcE1PjYjoVlZ9GgKuVgfb1uq6cWdPoKojVrP84LxH9CuzibwuM4lGU CNoiyk0D9lYHmTLSya7FD3p23Eu27hVrFVw22/LM+CCcF6X7Qw/B3t97i5lVfQPcQ6gJ nQYQ==
Received: by 10.220.156.72 with SMTP id v8mr2352457vcw.45.1332958148221; Wed, 28 Mar 2012 11:09:08 -0700 (PDT)
Received: by 10.220.156.72 with SMTP id v8mr2352444vcw.45.1332958147978; Wed, 28 Mar 2012 11:09:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.67 with HTTP; Wed, 28 Mar 2012 11:08:45 -0700 (PDT)
In-Reply-To: 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>  
From: John Tamplin 
Date: Wed, 28 Mar 2012 14:08:45 -0400
Message-ID: 
To: Gabriel Montenegro 
Content-Type: multipart/alternative; boundary=f46d043c7fb2e9270304bc51807f
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQl8qLGpS5cXyJfDBA12VZyxdWKB2uux8DDQdi9Wa+Xa/vHvD3josgbE4Ft6AARDo9KM0o5miToQpMeqQQb9GFSwSX4+cXauCpkqOcSVVxzKATImHJrBjZ9Dp2GcgGDXnD26wAZ8
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 18:09:10 -0000

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

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> wrote:

>  If anybody feels strongly that there is any API impact of either the mux
> or compression, please support such claims.
>

I think there should not be at this point, in either one -- which means
that I think exposing the existing of MUX channels (including being able to
open multiple at a time) should be off the table at this point.

In the long term, I suspect we may want to alter the API to let the
application have better control over compression, but I don't think we want
to do that until we have more experience about exactly what is useful.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Monten=
egro <Gabriel.Montenegro@microsoft.com> wrote:













If anybody feels strongly that there is any =
API impact of either the mux or compression, please support such claims.




I think there should not be at=
 this point, in either one -- which means that I think exposing the existin=
g of MUX channels (including being able to open multiple at a time) should =
be off the table at this point.




In the long term, I suspect we may want to alter the AP=
I to let the application have better control over compression, but I don=
9;t think we want to do that until we have more experience about exactly wh=
at is useful.




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--f46d043c7fb2e9270304bc51807f--

From Brian.Raymor@microsoft.com  Wed Mar 28 11:20:59 2012
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 BBB0921E8096 for ; Wed, 28 Mar 2012 11:20:57 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXqikKtU1sbQ for ; Wed, 28 Mar 2012 11:20:56 -0700 (PDT)
Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 5359D21E808F for ; Wed, 28 Mar 2012 11:20:55 -0700 (PDT)
Received: from mail78-am1-R.bigfish.com (10.3.201.247) by AM1EHSOBE006.bigfish.com (10.3.204.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 28 Mar 2012 18:20:53 +0000
Received: from mail78-am1 (localhost [127.0.0.1])	by mail78-am1-R.bigfish.com (Postfix) with ESMTP id C436D420596	for ; Wed, 28 Mar 2012 18:20:53 +0000 (UTC)
X-SpamScore: -22
X-BigFish: VS-22(zz936eKzz1202hz31iz1033IL8275dhz2fh2a8h668h839h944hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC105.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail78-am1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Brian.Raymor@microsoft.com; helo=TK5EX14HUBC105.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail78-am1 (localhost.localdomain [127.0.0.1]) by mail78-am1 (MessageSwitch) id 1332958852215632_12915; Wed, 28 Mar 2012 18:20:52 +0000 (UTC)
Received: from AM1EHSMHS007.bigfish.com (unknown [10.3.201.235])	by mail78-am1.bigfish.com (Postfix) with ESMTP id 289EC80049	for ; Wed, 28 Mar 2012 18:20:52 +0000 (UTC)
Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS007.bigfish.com (10.3.207.107) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 28 Mar 2012 18:20:50 +0000
Received: from TK5EX14MBXC296.redmond.corp.microsoft.com ([169.254.2.110]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.02.0283.004; Wed, 28 Mar 2012 18:20:48 +0000
From: Brian Raymor 
To: "'hybi@ietf.org'" 
Thread-Topic: New Version Notification for draft-montenegro-httpbis-speed-mobility-01.txt
Thread-Index: Ac0NDsYQgEMDf2jJRRuxEpvpTkcwHg==
Date: Wed, 28 Mar 2012 18:20:48 +0000
Message-ID: <091D81BBEE0E8D4383D186C9F916580003F2579E@TK5EX14MBXC296.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [157.54.51.70]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-Mailman-Approved-At: Wed, 28 Mar 2012 12:23:37 -0700
Subject: [hybi] New Version Notification for draft-montenegro-httpbis-speed-mobility-01.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: Wed, 28 Mar 2012 18:21:00 -0000

This may be of interest to HyBi. As noted below - "The proposal starts from=
 both the Google SPDY protocol and the work the IETF has done around WebSoc=
kets."


http://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility/


A new version of I-D, draft-montenegro-httpbis-speed-mobility-01.txt has be=
en successfully submitted by Gabriel Montenegro and posted to the IETF repo=
sitory.

Filename:	 draft-montenegro-httpbis-speed-mobility
Revision:	 01
Title:		 HTTP Speed+Mobility
Creation date:	 2012-03-28
WG ID:		 Individual Submission
Number of pages: 25

Abstract:
   The design of HTTP--how every application and service on the web
   communicates today--can positively impact user experience,
   operational and environmental costs, and even the battery life of the
   devices you carry around.

   Improving HTTP starts with speed.  Apps--not just browsers--should
   get faster too.  More and more, apps are how people access web
   services, in addition to their browser.  Improving HTTP should also
   make mobile better, particularly to ensure great battery life and low
   network cost on constrained devices.  People and their apps should
   stay in control of network access.  Finally, to achieve rapid
   adoption, HTTP 2.0 needs to retain as much compatibility as possible
   with the existing Web infrastructure.  Done right, HTTP 2.0 can help
   people connect their devices and applications to the Internet fast,
   reliably, and securely over a number of diverse networks, with great
   battery life and low cost.

   This document describes "HTTP Speed+Mobility," a proposal for =
HTTP
   2.0 that emphasizes performance improvements and security while at
   the same time accounting for the important needs of mobile devices
   and applications.  The proposal starts from both the Google SPDY
   protocol and the work the IETF has done around WebSockets.  The
   proposal is not a final product but rather is intended to form a
   baseline for working group discussion.

                                                                           =
      =20


The IETF Secretariat




From w@1wt.eu  Wed Mar 28 13:06:48 2012
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 CECFA21E80F1 for ; Wed, 28 Mar 2012 13:06:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.854
X-Spam-Level: 
X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=-3.411, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_93=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTYz8vjhzZFK for ; Wed, 28 Mar 2012 13:06:48 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0218821E80F4 for ; Wed, 28 Mar 2012 13:06:47 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2SK6iXV032419; Wed, 28 Mar 2012 22:06:44 +0200
Date: Wed, 28 Mar 2012 22:06:44 +0200
From: Willy Tarreau 
To: John Tamplin 
Message-ID: <20120328200644.GJ31508@1wt.eu>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 20:06:48 -0000

Hi John,

On Wed, Mar 28, 2012 at 09:48:50AM -0400, John Tamplin wrote:
> On Wed, Mar 28, 2012 at 9:09 AM, Takeshi Yoshino wrote:
> 
> > Please note that I'm not going to make channel ID values to be a new
> > dimension of WebSocket protocol's interface for its users, but just going
> > to leave channel ID assignment algorithm up to implementors so that some
> > non-browser apps may assign channel IDs as they like and give some meaning
> > as Arman described below.
> >
> > I won't add any new restriction on intermediaries to ensure that channel
> > ID values are the same on both endpoints. There's no such guarantee. We're
> > gonna just make WebSocket available for developers of special application
> > who want to divert WebSocket+MUX for their own service.
> >
> 
> I'm really not sure what the benefit is if intermediaries aren't required
> to preserve channel assignment (and I agree they shouldn't).  If someone
> controls both endpoints and the intervening network so they can enforce
> such a mapping, then they can already do what they want and if they want to
> use a variant of WS that's fine, but it shouldn't constrain what the WS
> spec can do.

I wonder whether you have added one extra negation in your first sentence,
since it sounds awkwards to me.

In my opinion, not being required to preserve the channel ID allows MUXes
to easily concentrate multiple incoming WS connections into one single,
which is the most important purpose. For instance, since channel zero is
the raw socket, you want it mapped to another channel when passing via
the muxer to the origin server.

But maybe that's what you already intended to say, so I won't insist :-)

Regards,
Willy


From jat@google.com  Wed Mar 28 13:32:56 2012
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 198BE21F8697 for ; Wed, 28 Mar 2012 13:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.963
X-Spam-Level: 
X-Spam-Status: No, score=-102.963 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzDkVaM+EKpA for ; Wed, 28 Mar 2012 13:32:53 -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 6680921F8680 for ; Wed, 28 Mar 2012 13:32:53 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1183873vcb.31 for ; Wed, 28 Mar 2012 13:32:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=FB2wbzdmF9u9b49Hef9VQFBsVSwC31YM+ecAtAAjFaQ=; b=eCAuTYKdx5AtpdZLAXgtVSr++cAvzKhcWKVrfYVrXcnqFAmTuT17Mmys/oSZu/T/yT ELyD8Y1t8NBoaMHx+pez7OG9w+WQAY+cW2GMLIe3k1JG15tYO1IThywhfLo4cQ8z2j7D /vYoCurnxgmNohlseaQhLxFBfpCpkXcLiruLAooFuTzAlI9P3iXnOFDc2h2Be60skvZn wCloXfC3PpUf3YtIrbrTyQSUYNW1WvSW+IeZvZhylhT3OmQY2l571gZ25ee2YE2sW2tN 1x9PEHDDB9Mgvl1wi8OJLkAZj80OdaAdXkGvzEuJ4+uXSjwPA/RYg9l3PziWrsbVRq8K w0tw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=FB2wbzdmF9u9b49Hef9VQFBsVSwC31YM+ecAtAAjFaQ=; b=o6xLYnrALy2YINmXlv6JWMZOzwPtRKXiYyAeSe66Drl6v5Lph/A6LhRaZdDwuPtImC hlZn5XUfjG++StBoAXAnOUXWjx08Nv1r8C4QIIQSS4mLiGa1Qw/zeNEU3hatWLG0scxk 22C5AEjgfDxG1WZPcV4yLQbyo6VZsv3MX2WuVRyq5yuAdKX522DGnqrQMSP2cFElh2ZN PiV/rxXjtHVz1zA+dJBI570YtbShp4MX75nkJw6BhV3fA7fUI3HScHLc7gTnVziYmj2b rx2q3VSdCFU/Sgq+NIh6wYBZ8dJ1QA2FMfuBPlWckLAMZXky78N6AWBFSswcqR66HWTI 27BQ==
Received: by 10.52.28.178 with SMTP id c18mr12055572vdh.45.1332966772946; Wed, 28 Mar 2012 13:32:52 -0700 (PDT)
Received: by 10.52.28.178 with SMTP id c18mr12055565vdh.45.1332966772854; Wed, 28 Mar 2012 13:32:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.191.67 with HTTP; Wed, 28 Mar 2012 13:32:31 -0700 (PDT)
In-Reply-To: <20120328200644.GJ31508@1wt.eu>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>   <20120328200644.GJ31508@1wt.eu>
From: John Tamplin 
Date: Wed, 28 Mar 2012 16:32:31 -0400
Message-ID: 
To: Willy Tarreau 
Content-Type: multipart/alternative; boundary=20cf307ac3f3fe4e9f04bc538252
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmVE3Y4f5TLMDklNPPNe5LBd0ioCU+BT+jxM2+NyDhNOHKGHfWt36WLD61Hw8S1EIRJvQkjG/kIlkvuFf/HIt3mxKZnJ5gaEQOZlPRcctHieQoGiU2ZsfXfhKp0fZGURKnhvO/z
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 20:32:56 -0000

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

On Wed, Mar 28, 2012 at 4:06 PM, Willy Tarreau  wrote:

> I wonder whether you have added one extra negation in your first sentence,
> since it sounds awkwards to me.
>
> In my opinion, not being required to preserve the channel ID allows MUXes
> to easily concentrate multiple incoming WS connections into one single,
> which is the most important purpose. For instance, since channel zero is
> the raw socket, you want it mapped to another channel when passing via
> the muxer to the origin server.
>
> But maybe that's what you already intended to say, so I won't insist :-)
>

My mistake -- what I meant was that I don't think intermediaries should be
required to maintain any mapping.  Indeed, some of the envisioned use-cases
involve an intermediary muxing or demuxing connections, which would
necessarily require mapping channels (since the client controls channel
allocation and doesn't know about other channels the mux max be handling).

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Wed, Mar 28, 2012 at 4:06 PM, Willy Tarreau <=
span dir=3D"ltr"><w@1wt.eu> wr=
ote:



I wonder whether you have added one extra negation i=
n your first sentence,

since it sounds awkwards to me.



In my opinion, not being required to preserve the channel ID allows MUXes
to easily concentrate multiple incoming WS connections into one single,

which is the most important purpose. For instance, since channel zero is
the raw socket, you want it mapped to another channel when passing via

the muxer to the origin server.



But maybe that's what you already intended to say, so I won't insis=
t :-)

My mistake -- what I meant was t=
hat I don't think intermediaries should be required to maintain any map=
ping. =C2=A0Indeed, some of the envisioned use-cases involve an intermediar=
y muxing or demuxing connections, which would necessarily require mapping c=
hannels (since the client controls channel allocation and doesn't know =
about other channels the mux max be handling).




-- 
John A. Tamplin
Software Engineer (GWT), Google

--20cf307ac3f3fe4e9f04bc538252--

From w@1wt.eu  Wed Mar 28 14:32:55 2012
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 00D1621E8089 for ; Wed, 28 Mar 2012 14:32:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.129
X-Spam-Level: 
X-Spam-Status: No, score=-5.129 tagged_above=-999 required=5 tests=[AWL=-3.086, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mk2cHH8qVwRi for ; Wed, 28 Mar 2012 14:32:54 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id A005321E8040 for ; Wed, 28 Mar 2012 14:32:53 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2SLWl6L000466; Wed, 28 Mar 2012 23:32:47 +0200
Date: Wed, 28 Mar 2012 23:32:47 +0200
From: Willy Tarreau 
To: John Tamplin 
Message-ID: <20120328213247.GK31508@1wt.eu>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>   <20120328200644.GJ31508@1wt.eu> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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: Wed, 28 Mar 2012 21:32:55 -0000

On Wed, Mar 28, 2012 at 04:32:31PM -0400, John Tamplin wrote:
> On Wed, Mar 28, 2012 at 4:06 PM, Willy Tarreau  wrote:
> 
> > I wonder whether you have added one extra negation in your first sentence,
> > since it sounds awkwards to me.
> >
> > In my opinion, not being required to preserve the channel ID allows MUXes
> > to easily concentrate multiple incoming WS connections into one single,
> > which is the most important purpose. For instance, since channel zero is
> > the raw socket, you want it mapped to another channel when passing via
> > the muxer to the origin server.
> >
> > But maybe that's what you already intended to say, so I won't insist :-)
> >
> 
> My mistake -- what I meant was that I don't think intermediaries should be
> required to maintain any mapping.  Indeed, some of the envisioned use-cases
> involve an intermediary muxing or demuxing connections, which would
> necessarily require mapping channels (since the client controls channel
> allocation and doesn't know about other channels the mux max be handling).

OK thanks for clarifying, we're clearly in line :-)

Willy


From martin.thomson@gmail.com  Wed Mar 28 22:21:22 2012
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 2F10021F87E5 for ; Wed, 28 Mar 2012 22:21:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.857
X-Spam-Level: 
X-Spam-Status: No, score=-4.857 tagged_above=-999 required=5 tests=[AWL=-1.258, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AH6vRFblxlJ for ; Wed, 28 Mar 2012 22:21:21 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3A21F87DE for ; Wed, 28 Mar 2012 22:21:20 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so1754693bku.31 for ; Wed, 28 Mar 2012 22:21:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=QKnIlvNajClzcSUR87EL1L00OgapINwY9o5k6EMAcbQ=; b=tb7rTSSiVL2QIWB/UD23KacweUYIgxt16ovAP9TgZoZQ3itAfAuzs1UlD4cl4vPDay kBd5RHiYDvgzz2uwoDaRsGeXENcPjgKpt9LjA1ZlsjJkiGPgX+5nTkaasBsb10WxvM+R Dip2sfFYxt4QSyWWUuuPbsVCgZfnYA2+mEmAWFXK7MiYmHMyd+wuuvuvkMDoplb5tub/ QzcQqTUUumC7P0XyHSrKtTKhhaDXCOzPD3RNnKZ6cSOyckWuB5ex3IZCRtWP9ztVciWi P1+oe5BdemKgonlAI24NLSXNSx6Bm/AJqxhqci3hbdJdULEAZsSnDZd0T65MwGCZ99R6 p5Tw==
MIME-Version: 1.0
Received: by 10.204.131.84 with SMTP id w20mr13144535bks.65.1332998479633; Wed, 28 Mar 2012 22:21:19 -0700 (PDT)
Received: by 10.205.38.73 with HTTP; Wed, 28 Mar 2012 22:21:19 -0700 (PDT)
Date: Thu, 29 Mar 2012 07:21:19 +0200
Message-ID: 
From: Martin Thomson 
To: hybi@ietf.org
Content-Type: text/plain; charset=UTF-8
Cc: Roberto Peon 
Subject: [hybi] Keep-Alive analysis
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, 29 Mar 2012 05:21:22 -0000

I think that the discussion on Keep-Alive yesterday was quite
productive.  I've had some time to consider this and I'd like to share
those thoughts.  It's a very long email, but I think that I've reached
some conclusions.

The arguments against a mechanism were all predicated on two things:
connection termination events are largely unpredictable, and that
keep-alives (ping/pong as opposed to the proposed header) are
expensive.  I should point out that from a formal logic perspective,
keep-alives are not implied by the draft, but it is certainly
something that this enables.

There are a few things that are missing from the argument, but there
is a compelling case in here.  Ultimately, any decision to use the
mechanism will be a subjective trade-off, as is the case for many such
engineering decisions.  So I'd also like to share some of the
reasoning that goes with my particular trade-off.

I'm not that much of a statistician, so after a little reading, it
became clear that I couldn't really apply anything from reliability
analysis (MTBF and those sorts of thins).  Over-analysis paralysis
almost caught me.  It's better (and simpler) to think of the problem
like so:

In the absence of a declared policy, the state of an idle connection
over time is largely determined by the probability of ...stuff
happening.  In the absence of a declared policy, ...stuff includes
termination by the remote end due to expiration of a timer (i.e. their
policy).  At the point that this probability reaches some non-trivial
proportion, then the state of the connection is no longer reliable.

Note that this probability only really covers the probability of
connection badness that might affect the next request that the client
attempts.  This is important.  This covers the probability that the
connection has gone away in the past without notification (for
example, because a TCP RST was suppressed or lost) and the probability
that the connection will fail between the time that the client makes
the request and the response is received.  Probability of failure
therefore increases with RTT.

You can imagine that an client with an understanding of these
probabilities might use this information to advise their behavior.
Given a sufficiently low probability of connection badness - such as
might be the case immediately after establishing the connection, or
after having received data - the implementation might simply use the
connection without precaution.  However, as the subjective view of the
probability of connection failure increases beyond a certain
threshold, the client might alter its behavior.  For instance, a
client might avoid the use of non-idempotent requests, or use some
sort of liveness test.

If a client does not alter behavior in response to its understanding
of the probability of connection loss, then there is no point in any
mechanism.  I'll get back to what I care about later.

Where policy is declared, the overall probability function can be
considered to have a step, where the probability of disconnection
jumps at the declared idle connection timeout.  Over the time period
allowed by the minimum declared policy, it is only the probability of
...stuff happening that influences whether a connection is usable,
declared policy is not a factor.

There are certainly cases where knowledge of policy does absolutely no
good.  If, as was indicated yesterday, a 45 second TCP keep-alive is
necessary to deal with some class of unreliable middleboxes that can't
be reliably detected, then something like this is not going to be very
much use.  (I happen to think that in this case, extreme behavior of
that sort shouldn't be triggered until something bad happens).
Certainly, if you don't actually implement a policy, or you don't have
one imposed on you, then it simply doesn't make sense to declare one.

But I think that in some cases, this knowledge can be enabling.

Modern operating systems are starting to constrain access to network
resources, primarily for power management reasons.  This is especially
true of mobile platforms where radio is very expensive, but Windows 8
is imposing some tight constraints on native applications that are
idle.  In Windows 8, an idle application is given one "lifeline"
connection.  Being able to rely upon that connection is really
important.  I'd like to think that the connection will be an HTTP/?
connection.

In practice, the probability of losing a connection due to random
events is quite low, despite some of the rather evocative examples to
the contrary.  More often than not, it's the server policy, or (in the
case of Windows Azure) the loadbalancer right in front of the server,
that drops the connection.  And I know that the Windows Azure load
balancer doesn't send a TCP RST when it cleans house, as much as I
might like it to do otherwise.

Because I care so strongly about this connection, I am prepared to pay
(in processing time, battery, etc...) to keep it.  I will send
keep-alive messages just to make sure that the connection is
available.  But I really want to pay as little as possible.  That's
where declarative timeout policy helps out.  If I have some idea what
these policies are, then I can make certain that I send keep-alives as
infrequently as possible.  That matters to me a lot, because the
difference between 45s keep alives and 10m keep alives is probably the
difference between needing a stupidly large backup battery for my
weekend trip and not.

In some sense, I recognize that this is saying: "people are going to
do bad things (i.e. waste effort on keep-alives), let us help make it
less bad", but I think that's still a valid argument.

One conclusion that I've reached is that sending a Keep-Alive header
from a client is actually more wasteful than helpful.  It's actually
the server policy that is most useful.  A client is usually
constrained more by the needs of the application than by any sort of
resource management during active operation.  The server, in a passive
role, really doesn't benefit from knowledge about client policies.
It's the client - in periods of idleness - that is most affected by
the indeterminate state of the connection.

--Martin

p.s. Chrome sends Connection: Keep-Alive without a Keep-Alive header.
I'd be interested to learn why those bytes are still being spent given
the (current) status of Keep-Alive.

From w@1wt.eu  Wed Mar 28 22:37:26 2012
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 7D36D21F8555 for ; Wed, 28 Mar 2012 22:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.132
X-Spam-Level: 
X-Spam-Status: No, score=-5.132 tagged_above=-999 required=5 tests=[AWL=-3.089, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa0f8YAg4Fa3 for ; Wed, 28 Mar 2012 22:37:25 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 82BC721F8547 for ; Wed, 28 Mar 2012 22:37:24 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2T5bHbL003041; Thu, 29 Mar 2012 07:37:17 +0200
Date: Thu, 29 Mar 2012 07:37:17 +0200
From: Willy Tarreau 
To: Martin Thomson 
Message-ID: <20120329053717.GR31508@1wt.eu>
References: 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org, Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 05:37:26 -0000

Hi Martin,

interesting reading, you gave me some ideas I'll probably try to
describe to you today. In the mean time I have a response to your
last comment below :

On Thu, Mar 29, 2012 at 07:21:19AM +0200, Martin Thomson wrote:
> p.s. Chrome sends Connection: Keep-Alive without a Keep-Alive header.
> I'd be interested to learn why those bytes are still being spent given
> the (current) status of Keep-Alive.

This is simply to benefit from persistent connections via HTTP/1.0 proxies :-)

Willy


From arman@noemax.com  Thu Mar 29 00:07:26 2012
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 54CEC21E8092 for ; Thu, 29 Mar 2012 00:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Hq1u8h-lN9j for ; Thu, 29 Mar 2012 00:07:25 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED0521F8576 for ; Thu, 29 Mar 2012 00:07:24 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id NKK29128; Thu, 29 Mar 2012 10:07:28 +0300
From: "Arman Djusupov" 
To: "'John Tamplin'" 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>   
In-Reply-To: 
Date: Thu, 29 Mar 2012 10:07:19 +0300
Message-ID: <000501cd0d7a$991dca50$cb595ef0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01CD0D93.BE6D4C40"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAJixsSUAcHoFyEB2DsVhgLSPJtbAXlAGB6YwuumAA==
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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, 29 Mar 2012 07:07:26 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0006_01CD0D93.BE6D4C40
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

The JS API is just one of the APIs that uses the WebSocket protocol, =
there are already multiple Java, .NET, Mono, Python  etc. client and =
server libraries available for Windows, Android, iOS etc. These =
obviously have their own APIs that do not depend on browser =
functionality. It doesn=E2=80=99t really matter what is supported by a =
particular API, it is fine if that API supports a subset of the =
functionality. A little back JS didn=E2=80=99t support binary data, but =
that didn't mean that we shouldn't have introduced binary frames. If the =
JS API cannot support some specific functionality then let it not, but =
this functionality should be available to other platforms.

=20

With respect, I don=E2=80=99t agree that we should look at any WebSocket =
related specs using only =E2=80=9CChrome to Google server pool=E2=80=9D =
point of view.

=20

With best regards,

Arman

=20

=20

From: John Tamplin [mailto:jat@google.com]=20
Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

=20

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro =
 wrote:

If anybody feels strongly that there is any API impact of either the mux =
or compression, please support such claims.

=20

I think there should not be at this point, in either one -- which means =
that I think exposing the existing of MUX channels (including being able =
to open multiple at a time) should be off the table at this point.

=20

In the long term, I suspect we may want to alter the API to let the =
application have better control over compression, but I don't think we =
want to do that until we have more experience about exactly what is =
useful.

=20

--=20
John A. Tamplin
Software Engineer (GWT), Google


------=_NextPart_000_0006_01CD0D93.BE6D4C40
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


The JS API is just one of the APIs that uses the WebSocket protocol, =
there are already multiple Java, .NET, Mono, Python  etc. client =
and server libraries available for Windows, Android, iOS etc. These =
obviously have their own APIs that do not depend on browser =
functionality. It doesn=E2=80=99t really matter what is supported by a =
particular API, it is fine if that API supports a subset of the =
functionality. A little back JS didn=E2=80=99t support binary data, but =
that didn't mean that we shouldn't have introduced binary frames. If the =
JS API cannot support some specific functionality then let it not, but =
this functionality should be available to other =
platforms.
 
With respect, I don=E2=80=99t agree that we should look at any =
WebSocket related specs using only =E2=80=9CChrome to Google server =
pool=E2=80=9D point of view.
 
With best regards,
Arman
 
 
From:=
 =
John Tamplin [mailto:jat@google.com] 
Sent: Wednesday, March =
28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman =
Djusupov; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID =
semantics
 
On Wed, =
Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <Gabriel.Montenegro@micro=
soft.com> wrote:
If anybody feels strongly that there is any API impact of either the =
mux or compression, please support such =
claims.
 
I =
think there should not be at this point, in either one -- which means =
that I think exposing the existing of MUX channels (including being able =
to open multiple at a time) should be off the table at this =
point.
 
In the long term, I suspect we may want to alter the =
API to let the application have better control over compression, but I =
don't think we want to do that until we have more experience about =
exactly what is useful.
 
-- =

John A. Tamplin
Software Engineer (GWT), =
Google

------=_NextPart_000_0006_01CD0D93.BE6D4C40--


From tobias.oberstein@tavendo.de  Thu Mar 29 00:32:06 2012
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 68DCD21F86B1 for ; Thu, 29 Mar 2012 00:32:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.339
X-Spam-Level: 
X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyJRw7zeb+LZ for ; Thu, 29 Mar 2012 00:32:05 -0700 (PDT)
Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id C04B321F867B for ; Thu, 29 Mar 2012 00:32:05 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.68]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Thu, 29 Mar 2012 00:32:04 -0700
From: Tobias Oberstein 
To: Martin Thomson , "hybi@ietf.org" 
Date: Thu, 29 Mar 2012 00:32:01 -0700
Thread-Topic: [hybi] Keep-Alive analysis
Thread-Index: Ac0Na8vg2r29pt/ARyWnzPD/9YA1hwAEVz1w
Message-ID: <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>
References: 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 07:32:06 -0000

I'd like to add: there are use cases where it isn't only about keeping a co=
nnection _alive_, but keep it fast.

Mobiles and carrier networks will downgrade idle connections from 3.5G to 3=
G. That makes a difference
in RTT between 300-800ms (3G) to 80-120ms (3.5G).

I have seen that being done within seconds of idle connections. I have seen=
 it being downgraded even with
a 1 sec heartbeat in place. Probably because the bandwidth consumed by the =
connection was deemed too
low to justify a 3.5G channel.

So if your prime goal is to keep up a very low latency connection, then you=
 even might need very short
heartbeat (3-20s), with substantial payload.

From Gabriel.Montenegro@microsoft.com  Thu Mar 29 00:32:35 2012
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 276EA21F84BF for ; Thu, 29 Mar 2012 00:32:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.898
X-Spam-Level: 
X-Spam-Status: No, score=-3.898 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfOsGgRxuDsB for ; Thu, 29 Mar 2012 00:32:34 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1996521F8747 for ; Thu, 29 Mar 2012 00:32:29 -0700 (PDT)
Received: from mail24-db3-R.bigfish.com (10.3.81.247) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 07:32:27 +0000
Received: from mail24-db3 (localhost [127.0.0.1])	by mail24-db3-R.bigfish.com (Postfix) with ESMTP id 9EFAE160933; Thu, 29 Mar 2012 07:32:27 +0000 (UTC)
X-SpamScore: -24
X-BigFish: VS-24(zz9371Ic89bhc857h98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail24-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail24-db3 (localhost.localdomain [127.0.0.1]) by mail24-db3 (MessageSwitch) id 1333006346315983_6091; Thu, 29 Mar 2012 07:32:26 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.232])	by mail24-db3.bigfish.com (Postfix) with ESMTP id 3D2D93C0050; Thu, 29 Mar 2012 07:32:26 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 07:32:24 +0000
Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 07:32:04 +0000
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 00:32:03 -0700
Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 00:32:03 -0700
From: Gabriel Montenegro 
To: Arman Djusupov , 'John Tamplin' 
Thread-Topic: W3C WebApps Working Group WebSocket API (was: RE: [hybi] MUC: channel ID semantics)
Thread-Index: Ac0Nfgept4WvGB5oTIObANHzUWU9Yg==
Date: Thu, 29 Mar 2012 07:32:03 +0000
Message-ID: 
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: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5AF99TK5EX14MBXW602w_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "hybi@ietf.org" 
Subject: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)
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, 29 Mar 2012 07:32:35 -0000

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

WWVzLCBpdOKAmXMgdHJ1ZSB0aGF0IHRoZXJlIGFyZSBtYW55IEFQSXMsIGhvd2V2ZXIsIGZyb20g
dGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgd2UgYXJlIGNvb3JkaW5hdGlu
ZyB3aXRoIG9ubHkgb25lIG9mIHRob3NlLg0KDQpGcm9tIG91ciBjaGFydGVyOg0KICAgIFRoZSBn
cm91cCB3aWxsIGNvbnRpbnVlIGNvb3JkaW5hdGluZyB3aXRoIHRoZSBXM0MgV2VwQXBwcyB3b3Jr
aW5nDQogICAgZ3JvdXAgd2l0aCByZXNwZWN0IHRvIHRoZSBhYm92ZSBkZWxpdmVyYWJsZXMgYW5k
IHRvIGVuc3VyZSB0aGUgYmVzdA0KICAgIG1hdGNoIHBvc3NpYmxlIGJldHdlZW4gdGhlIFdlYlNv
Y2tldCBwcm90b2NvbCBhbmQgdGhlIFdlYlNvY2tldCBBUEkuDQoNClRoaXMgZG9lc27igJl0IHBy
ZWNsdWRlIGFib3V0IGluZm9ybWFsIGRpc2N1c3Npb24gcmVnYXJkaW5nIG90aGVyIEFQSXMsIGJ1
dCB0aGUgb25seSBvbmUgdGhlIFdHIHNob3VsZCBsb3NlIHNsZWVwIG92ZXIgaXMgdGhlIGFib3Zl
IGFzIGl04oCZcyBpbiBvdXIgY2hhcnRlci4gUmlnaHQgbm93IHRoZSBxdWVzdGlvbiBpcyByZWxl
dmFudCB3aXRoIHJlc3BlY3QgdG8gdGhlIFczQyBXZWJBcHBzIFdlYlNvY2tldCBBUEksIGJlY2F1
c2UgdGhhdCB3b3JraW5nIGdyb3VwIGlzIHVuZGVyZ29pbmcgcmVjaGFydGVyaW5nLCBzbyBpZiBh
bnkgZnVydGhlciBjaGFuZ2UgaXMgbmVlZGVkIHRvIHRoZSBhYm92ZSBpdCBiZWhvb3ZlcyB1cyB0
byBtYWtlIHRoYXQgY2xlYXIgc2hvcnRseS4NCg0KU28gZmFyLCBpdCBzZWVtcyBsaWtlIHdl4oCZ
cmUgZmluZSB3aXRob3V0IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9uIHRoYXQgQVBJLg0KDQpG
cm9tOiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBBcm1hbiBEanVzdXBvdg0KU2VudDogVGh1cnNkYXksIDI5IE1hcmNoLCAy
MDEyIDA5OjA3DQpUbzogJ0pvaG4gVGFtcGxpbicNCkNjOiBoeWJpQGlldGYub3JnDQpTdWJqZWN0
OiBSZTogW2h5YmldIE1VQzogY2hhbm5lbCBJRCBzZW1hbnRpY3MNCg0KVGhlIEpTIEFQSSBpcyBq
dXN0IG9uZSBvZiB0aGUgQVBJcyB0aGF0IHVzZXMgdGhlIFdlYlNvY2tldCBwcm90b2NvbCwgdGhl
cmUgYXJlIGFscmVhZHkgbXVsdGlwbGUgSmF2YSwgLk5FVCwgTW9ubywgUHl0aG9uICBldGMuIGNs
aWVudCBhbmQgc2VydmVyIGxpYnJhcmllcyBhdmFpbGFibGUgZm9yIFdpbmRvd3MsIEFuZHJvaWQs
IGlPUyBldGMuIFRoZXNlIG9idmlvdXNseSBoYXZlIHRoZWlyIG93biBBUElzIHRoYXQgZG8gbm90
IGRlcGVuZCBvbiBicm93c2VyIGZ1bmN0aW9uYWxpdHkuIEl0IGRvZXNu4oCZdCByZWFsbHkgbWF0
dGVyIHdoYXQgaXMgc3VwcG9ydGVkIGJ5IGEgcGFydGljdWxhciBBUEksIGl0IGlzIGZpbmUgaWYg
dGhhdCBBUEkgc3VwcG9ydHMgYSBzdWJzZXQgb2YgdGhlIGZ1bmN0aW9uYWxpdHkuIEEgbGl0dGxl
IGJhY2sgSlMgZGlkbuKAmXQgc3VwcG9ydCBiaW5hcnkgZGF0YSwgYnV0IHRoYXQgZGlkbid0IG1l
YW4gdGhhdCB3ZSBzaG91bGRuJ3QgaGF2ZSBpbnRyb2R1Y2VkIGJpbmFyeSBmcmFtZXMuIElmIHRo
ZSBKUyBBUEkgY2Fubm90IHN1cHBvcnQgc29tZSBzcGVjaWZpYyBmdW5jdGlvbmFsaXR5IHRoZW4g
bGV0IGl0IG5vdCwgYnV0IHRoaXMgZnVuY3Rpb25hbGl0eSBzaG91bGQgYmUgYXZhaWxhYmxlIHRv
IG90aGVyIHBsYXRmb3Jtcy4NCg0KV2l0aCByZXNwZWN0LCBJIGRvbuKAmXQgYWdyZWUgdGhhdCB3
ZSBzaG91bGQgbG9vayBhdCBhbnkgV2ViU29ja2V0IHJlbGF0ZWQgc3BlY3MgdXNpbmcgb25seSDi
gJxDaHJvbWUgdG8gR29vZ2xlIHNlcnZlciBwb29s4oCdIHBvaW50IG9mIHZpZXcuDQoNCldpdGgg
YmVzdCByZWdhcmRzLA0KQXJtYW4NCg0KDQpGcm9tOiBKb2huIFRhbXBsaW4gW21haWx0bzpqYXRA
Z29vZ2xlLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgOTowOSBQTQ0KVG86
IEdhYnJpZWwgTW9udGVuZWdybw0KQ2M6IEFybWFuIERqdXN1cG92OyBoeWJpQGlldGYub3JnDQpT
dWJqZWN0OiBSZTogW2h5YmldIE1VQzogY2hhbm5lbCBJRCBzZW1hbnRpY3MNCg0KT24gV2VkLCBN
YXIgMjgsIDIwMTIgYXQgMTE6NTAgQU0sIEdhYnJpZWwgTW9udGVuZWdybyA8R2FicmllbC5Nb250
ZW5lZ3JvQG1pY3Jvc29mdC5jb208bWFpbHRvOkdhYnJpZWwuTW9udGVuZWdyb0BtaWNyb3NvZnQu
Y29tPj4gd3JvdGU6DQpJZiBhbnlib2R5IGZlZWxzIHN0cm9uZ2x5IHRoYXQgdGhlcmUgaXMgYW55
IEFQSSBpbXBhY3Qgb2YgZWl0aGVyIHRoZSBtdXggb3IgY29tcHJlc3Npb24sIHBsZWFzZSBzdXBw
b3J0IHN1Y2ggY2xhaW1zLg0KDQpJIHRoaW5rIHRoZXJlIHNob3VsZCBub3QgYmUgYXQgdGhpcyBw
b2ludCwgaW4gZWl0aGVyIG9uZSAtLSB3aGljaCBtZWFucyB0aGF0IEkgdGhpbmsgZXhwb3Npbmcg
dGhlIGV4aXN0aW5nIG9mIE1VWCBjaGFubmVscyAoaW5jbHVkaW5nIGJlaW5nIGFibGUgdG8gb3Bl
biBtdWx0aXBsZSBhdCBhIHRpbWUpIHNob3VsZCBiZSBvZmYgdGhlIHRhYmxlIGF0IHRoaXMgcG9p
bnQuDQoNCkluIHRoZSBsb25nIHRlcm0sIEkgc3VzcGVjdCB3ZSBtYXkgd2FudCB0byBhbHRlciB0
aGUgQVBJIHRvIGxldCB0aGUgYXBwbGljYXRpb24gaGF2ZSBiZXR0ZXIgY29udHJvbCBvdmVyIGNv
bXByZXNzaW9uLCBidXQgSSBkb24ndCB0aGluayB3ZSB3YW50IHRvIGRvIHRoYXQgdW50aWwgd2Ug
aGF2ZSBtb3JlIGV4cGVyaWVuY2UgYWJvdXQgZXhhY3RseSB3aGF0IGlzIHVzZWZ1bC4NCg0KLS0N
CkpvaG4gQS4gVGFtcGxpbg0KU29mdHdhcmUgRW5naW5lZXIgKEdXVCksIEdvb2dsZQ0K

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5AF99TK5EX14MBXW602w_
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
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy
c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0
OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9
DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZv
cm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCi5Nc29D
aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w
cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox
LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl
Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl
ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+
PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8
bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48
IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu
az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp
YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBpdOKA
mXMgdHJ1ZSB0aGF0IHRoZXJlIGFyZSBtYW55IEFQSXMsIGhvd2V2ZXIsIGZyb20gdGhlIHBvaW50
IG9mIHZpZXcgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgd2UgYXJlIGNvb3JkaW5hdGluZyB3aXRoIG9u
bHkgb25lIG9mIHRob3NlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbSBv
dXIgY2hhcnRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxs
b3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPlRoZSBncm91cCB3aWxsIGNvbnRpbnVlIGNvb3JkaW5h
dGluZyB3aXRoIHRoZSBXM0MgV2VwQXBwcyB3b3JraW5nPG86cD48L286cD48L3NwYW4+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6eWVsbG93O21z
by1oaWdobGlnaHQ6eWVsbG93Ij4mbmJzcDsmbmJzcDsmbmJzcDsgZ3JvdXAgd2l0aCByZXNwZWN0
IHRvIHRoZSBhYm92ZSBkZWxpdmVyYWJsZXMgYW5kIHRvIGVuc3VyZSB0aGUgYmVzdDxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6
eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4mbmJzcDsmbmJzcDsmbmJzcDsgbWF0Y2ggcG9z
c2libGUgYmV0d2VlbiB0aGUgV2ViU29ja2V0IHByb3RvY29sIGFuZCB0aGUgV2ViU29ja2V0IEFQ
SS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U
aGlzIGRvZXNu4oCZdCBwcmVjbHVkZSBhYm91dCBpbmZvcm1hbCBkaXNjdXNzaW9uIHJlZ2FyZGlu
ZyBvdGhlciBBUElzLCBidXQgdGhlIG9ubHkgb25lIHRoZSBXRyBzaG91bGQgbG9zZSBzbGVlcCBv
dmVyIGlzIHRoZSBhYm92ZSBhcyBpdOKAmXMgaW4gb3VyIGNoYXJ0ZXIuIFJpZ2h0DQogbm93IHRo
ZSBxdWVzdGlvbiBpcyByZWxldmFudCB3aXRoIHJlc3BlY3QgdG8gdGhlIFczQyBXZWJBcHBzIFdl
YlNvY2tldCBBUEksIGJlY2F1c2UgdGhhdCB3b3JraW5nIGdyb3VwIGlzIHVuZGVyZ29pbmcgcmVj
aGFydGVyaW5nLCBzbyBpZiBhbnkgZnVydGhlciBjaGFuZ2UgaXMgbmVlZGVkIHRvIHRoZSBhYm92
ZSBpdCBiZWhvb3ZlcyB1cyB0byBtYWtlIHRoYXQgY2xlYXIgc2hvcnRseS4NCjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
U28gZmFyLCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUgZmluZSB3aXRob3V0IGFkZGl0aW9uYWwgcmVx
dWlyZW1lbnRzIG9uIHRoYXQgQVBJLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90
O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt
bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4N
CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw
YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy
aWYmcXVvdDsiPiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpoeWJpLWJvdW5jZXNAaWV0
Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFybWFuIERqdXN1cG92PGJyPg0KPGI+U2VudDo8
L2I+IFRodXJzZGF5LCAyOSBNYXJjaCwgMjAxMiAwOTowNzxicj4NCjxiPlRvOjwvYj4gJ0pvaG4g
VGFtcGxpbic8YnI+DQo8Yj5DYzo8L2I+IGh5YmlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv
Yj4gUmU6IFtoeWJpXSBNVUM6IGNoYW5uZWwgSUQgc2VtYW50aWNzPG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7
O2NvbG9yOiMxRjQ5N0QiPlRoZSBKUyBBUEkgaXMganVzdCBvbmUgb2YgdGhlIEFQSXMgdGhhdCB1
c2VzIHRoZSBXZWJTb2NrZXQgcHJvdG9jb2wsIHRoZXJlIGFyZSBhbHJlYWR5IG11bHRpcGxlIEph
dmEsIC5ORVQsIE1vbm8sIFB5dGhvbiZuYnNwOyBldGMuIGNsaWVudCBhbmQgc2VydmVyIGxpYnJh
cmllcyBhdmFpbGFibGUNCiBmb3IgV2luZG93cywgQW5kcm9pZCwgaU9TIGV0Yy4gVGhlc2Ugb2J2
aW91c2x5IGhhdmUgdGhlaXIgb3duIEFQSXMgdGhhdCBkbyBub3QgZGVwZW5kIG9uIGJyb3dzZXIg
ZnVuY3Rpb25hbGl0eS4gSXQgZG9lc27igJl0IHJlYWxseSBtYXR0ZXIgd2hhdCBpcyBzdXBwb3J0
ZWQgYnkgYSBwYXJ0aWN1bGFyIEFQSSwgaXQgaXMgZmluZSBpZiB0aGF0IEFQSSBzdXBwb3J0cyBh
IHN1YnNldCBvZiB0aGUgZnVuY3Rpb25hbGl0eS4gQSBsaXR0bGUgYmFjayBKUw0KIGRpZG7igJl0
IHN1cHBvcnQgYmluYXJ5IGRhdGEsIGJ1dCB0aGF0IGRpZG4ndCBtZWFuIHRoYXQgd2Ugc2hvdWxk
bid0IGhhdmUgaW50cm9kdWNlZCBiaW5hcnkgZnJhbWVzLiBJZiB0aGUgSlMgQVBJIGNhbm5vdCBz
dXBwb3J0IHNvbWUgc3BlY2lmaWMgZnVuY3Rpb25hbGl0eSB0aGVuIGxldCBpdCBub3QsIGJ1dCB0
aGlzIGZ1bmN0aW9uYWxpdHkgc2hvdWxkIGJlIGF2YWlsYWJsZSB0byBvdGhlciBwbGF0Zm9ybXMu
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz
YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv
cjojMUY0OTdEIj5XaXRoIHJlc3BlY3QsIEkgZG9u4oCZdCBhZ3JlZSB0aGF0IHdlIHNob3VsZCBs
b29rIGF0IGFueSBXZWJTb2NrZXQgcmVsYXRlZCBzcGVjcyB1c2luZyBvbmx5IOKAnENocm9tZSB0
byBHb29nbGUgc2VydmVyIHBvb2zigJ0gcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGggYmVz
dCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv
dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bcm1hbjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx
dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90OyI+IEpvaG4gVGFtcGxpbiBbbWFpbHRvOmphdEBnb29nbGUuY29tXQ0KPGJyPg0K
PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggMjgsIDIwMTIgOTowOSBQTTxicj4NCjxiPlRv
OjwvYj4gR2FicmllbCBNb250ZW5lZ3JvPGJyPg0KPGI+Q2M6PC9iPiBBcm1hbiBEanVzdXBvdjsg
aHliaUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW2h5YmldIE1VQzogY2hhbm5l
bCBJRCBzZW1hbnRpY3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX
ZWQsIE1hciAyOCwgMjAxMiBhdCAxMTo1MCBBTSwgR2FicmllbCBNb250ZW5lZ3JvICZsdDs8YSBo
cmVmPSJtYWlsdG86R2FicmllbC5Nb250ZW5lZ3JvQG1pY3Jvc29mdC5jb20iPkdhYnJpZWwuTW9u
dGVuZWdyb0BtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6
YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIGFueWJvZHkgZmVlbHMgc3Ryb25nbHkgdGhhdCB0aGVyZSBp
cyBhbnkgQVBJIGltcGFjdCBvZiBlaXRoZXIgdGhlIG11eCBvciBjb21wcmVzc2lvbiwgcGxlYXNl
IHN1cHBvcnQNCiBzdWNoIGNsYWltcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGVyZSBzaG91bGQg
bm90IGJlIGF0IHRoaXMgcG9pbnQsIGluIGVpdGhlciBvbmUgLS0gd2hpY2ggbWVhbnMgdGhhdCBJ
IHRoaW5rIGV4cG9zaW5nIHRoZSBleGlzdGluZyBvZiBNVVggY2hhbm5lbHMgKGluY2x1ZGluZyBi
ZWluZyBhYmxlIHRvIG9wZW4gbXVsdGlwbGUgYXQgYSB0aW1lKSBzaG91bGQgYmUgb2ZmIHRoZSB0
YWJsZSBhdCB0aGlzIHBvaW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgbG9uZyB0ZXJtLCBJIHN1c3BlY3Qgd2UgbWF5IHdhbnQg
dG8gYWx0ZXIgdGhlIEFQSSB0byBsZXQgdGhlIGFwcGxpY2F0aW9uIGhhdmUgYmV0dGVyIGNvbnRy
b2wgb3ZlciBjb21wcmVzc2lvbiwgYnV0IEkgZG9uJ3QgdGhpbmsgd2Ugd2FudCB0byBkbyB0aGF0
IHVudGlsIHdlIGhhdmUgbW9yZSBleHBlcmllbmNlIGFib3V0IGV4YWN0bHkgd2hhdCBpcyB1c2Vm
dWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4tLSA8YnI+DQpKb2huIEEuIFRhbXBsaW48YnI+DQpTb2Z0d2FyZSBFbmdpbmVlciAoR1dUKSwg
R29vZ2xlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5AF99TK5EX14MBXW602w_--

From tyoshino@google.com  Thu Mar 29 00:35:18 2012
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 D0A4421F87BC for ; Thu, 29 Mar 2012 00:35:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.955
X-Spam-Level: 
X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeu86ZHqLhMr for ; Thu, 29 Mar 2012 00:35:17 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B2DD621F87CA for ; Thu, 29 Mar 2012 00:35:17 -0700 (PDT)
Received: by mail-iy0-f172.google.com with SMTP id z13so3089491iaz.31 for ; Thu, 29 Mar 2012 00:35:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=N39sVpBd2Aeo3gmxgrhDA6dBkreGzT2UplilWCaBKAE=; b=d3S+9mscc/wC9eU/5/bTImurT3HZfsGFdmm8gT8HXKMSfxRTpGsevKSzgPZWZc+kAc Z+ZyQJ9wXM8WBAP4V4HpZzJkIbaZFQzuBGEKEUMj4+QklttDiJK3jMaRwHN6cM2T/mgW h5rkTzRJYJrfm0eWAVoeTTkcTArAfJFZm37Zx7aXMdWJwWD/p5WScXBWbZeoF6Vee9Me T7deJcW2kX7XFHkLiE66f+OK0dP52TqW+KuKsMHwK3ZNLupcBgMO6vjb6Q1ntUkhZ+V1 h+P7jxHzUU/G9EvSiMPHiXX1ZJph/iy6vog81BfSCxXCF+/+RWOROLA7K/OGUDve8txj z2hw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=N39sVpBd2Aeo3gmxgrhDA6dBkreGzT2UplilWCaBKAE=; b=ag8KLDzeAZ7vUU8MkP/Gqz5/AVdmwQx2zxez+rGMfhXbavE35SZ26nJpbuGGIC509R 1YnO85TAkPXL5u2Ftbe8PZj68gLcEQPZeLvInQ13JP5LqbN0zdl3zoHlVREFdhkcZAiB M3bCl2TZguhikICqG+At5Nij4cBcoRq3D1PtAj30B5gVTGXHO4lZ+963hhimE430MPOc TW/O8BRJCkksezh1UCK9nMnTgvDTt+rOFcpQs5xMcoyufq5mLs46zKi3rBfbLpb01RIE S9t3FW8hHoXJ3VNqHaspYL+RPSKwLQo8IJmMRcywI7Qcs8RFIxeQMVEhdVv19DAOMNV3 HSKg==
Received: by 10.42.97.200 with SMTP id p8mr17871488icn.2.1333006517570; Thu, 29 Mar 2012 00:35:17 -0700 (PDT)
Received: by 10.42.97.200 with SMTP id p8mr17871475icn.2.1333006517345; Thu, 29 Mar 2012 00:35:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.178.203 with HTTP; Thu, 29 Mar 2012 00:34:57 -0700 (PDT)
From: Takeshi Yoshino 
Date: Thu, 29 Mar 2012 09:34:57 +0200
Message-ID: 
To: Gabriel Montenegro 
Content-Type: multipart/alternative; boundary=20cf303bf94cf31fa004bc5cc3fb
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQnEs6hkn71HEahL4iIJHcIp7yN2G0Xa3ASobq/x9qlJunrvQCZ6uE6Kxt7ED0LVgoGlp/JCuJL1KQD3TJpCZePXtKFXnDxFki00kvfVfjBtFbbDr1YoiXJwYBmAB1r4l8dcnEXL
Cc: "hybi@ietf.org" 
Subject: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics)
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, 29 Mar 2012 07:35:19 -0000

--20cf303bf94cf31fa004bc5cc3fb
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Not the issue discussed in the f2f meeting, but I'm sure that introduction
of extensions we're now working on impacts extensions attribute of the
WebSocket API.

1. the API must define in what form it exports _Extensions In Use_. What to
include (just token? parameters together?), formatting, etc.

2. under use of the multiplexing extension, Sec-WebSocket-Extensions header
will contain both extensions applied to physical channel and logical
channels. We must figure out what should be exported from this mixture and
which side should do such transformation if any by coordinating with
webapps WG.

Takeshi


On Wed, Mar 28, 2012 at 17:50, Gabriel Montenegro <
Gabriel.Montenegro@microsoft.com> wrote:

>  Just a note that the API issues were discussed in the f2f today. If
> there are any such issues (and during the meeting it did not seem to be t=
he
> case), the WG will coordinate with the W3C webapps WG, which is the
> organization we liaise with.****
>
> ** **
>
> As it turns out, they=92re in the process of rechartering:****
>
> Web Applications Working Group:****
>
> http://www.w3.org/2012/03/webapps-proposed-charter.html****
>
> ** **
>
> If anybody feels strongly that there is any API impact of either the mux
> or compression, please support such claims. ****
>
> ** **
>
> *From:* hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] *On Behalf
> Of *John Tamplin
> *Sent:* Wednesday, 28 March, 2012 16:37
>
> *To:* Arman Djusupov
> *Cc:* hybi@ietf.org
> *Subject:* Re: [hybi] MUC: channel ID semantics****
>
>  ** **
>
> On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov  wrote=
:
> ****
>
> I would also like to suggest that we make it possible for an entire set o=
f
> channels to be established together during/after the physical channel
> handshake. This would speed up the creation of logical channels for all
> types of clients.****
>
>  ****
>
> There are various options how to perform this.****
>
>  ****
>
> a) Include the request for the set of channels into the physical channel
> handshake.****
>
>  ****
>
> b) Use a more advanced format for the AddChannel request. For example it
> could specify the number of channels to create using the same handshake, =
so
> that a single handshake results in creating a range of identical logical
> channels.****
>
>  ****
>
> c) When the application needs to create multiple channels with different
> settings (e.g. protocol, compression and so on), it should be able to sen=
d
> a batch of AddChannel requests at once and then wait for each of those
> channels to be confirmed by the server.****
>
> ** **
>
> Again, this requires changes to the JS API, which isn't the purview of
> hybi but rather WHATWG.  With the current JS API, you can only create one
> channel at a time, so the only opportunity for bundling AddChannels
> together would be if another tab creates a channel at exactly the same ti=
me
> (or you delay the first request long enough to wait for another one). ***=
*
>
> ** **
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google****
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>
>

--20cf303bf94cf31fa004bc5cc3fb
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable


Not the issue discussed in the f2f meeting, but I'm sure that intr=
oduction of extensions we're now working on impacts extensions attribut=
e of the WebSocket API.

1. the API must define in =
what form it exports _Extensions In Use_. What to include (just token? para=
meters together?), formatting, etc.






2. under use of the multiplexing extension, Sec-WebSocket-Extensions h=
eader will contain both extensions applied to physical channel and logical =
channels. We must figure out what should be exported from this mixture and =
which side should do such transformation if any by coordinating with webapp=
s WG.




Takeshi



On Wed, Mar 28, 2012 at 17:50, Gabriel M=
ontenegro <Gabriel.Montenegro@microsoft.com> =
wrote:















Just a note that the API =
issues were discussed in the f2f today. If there are any such issues (and d=
uring the meeting it did not seem to be the case), the WG
 will coordinate with the W3C webapps WG, which is the organization we liai=
se with.


=A0<=
/p>

As it turns out, they=92r=
e in the process of rechartering:


Web Applications Working Group:


http://www.w3.org/2012/03/webapps-proposed-charter.html


=A0<=
/p>

If anybody feels strongly=
 that there is any API impact of either the mux or compression, please supp=
ort such claims.



=A0<=
/p>







From: hybi-bounces@ietf.org [mailto:hybi-=
bounces@ietf.org]
On Behalf Of John Tamplin

Sent: Wednesday, 28 March, 2012 16:37


To: Arman Djusupov

Cc: hybi@ietf.org=


Subject: Re: [hybi] MUC: channel ID semantics
=







=A0




On Wed, Mar 28, 2012 at 10:18 AM, Arman Djusupov <=
;arman@noemax.com=
> wrote:






I would also like to sugg=
est that we make it possible for an entire set of channels to be establishe=
d
 together during/after the physical channel handshake. This would speed up =
the creation of logical channels for all types of clients.=



=A0<=
/p>

There are various options=
 how to perform this.


=A0<=
/p>

a) Include the request fo=
r the set of channels into the physical channel handshake.=






=A0<=
/p>

b) Use a more advanced fo=
rmat for the AddChannel request. For example it could specify the number
 of channels to create using the same handshake, so that a single handshake=
 results in creating a range of identical logical channels.


=A0<=
/p>

c) When the application n=
eeds to create multiple channels with different settings (e.g. protocol,
 compression and so on), it should be able to send a batch of AddChannel re=
quests at once and then wait for each of those channels to be confirmed by =
the server.








=A0






Again, this requires changes to the JS API, which is=
n't the purview of hybi but rather WHATWG. =A0With the current JS API, =
you can only create one channel at a time, so the only opportunity for bund=
ling AddChannels together would be if another
 tab creates a channel at exactly the same time (or you delay the first req=
uest long enough to wait for another one).=A0








=A0




-- 

John A. Tamplin

Software Engineer (GWT), Google









_______________________________________________

hybi mailing list

hybi@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/hybi





--20cf303bf94cf31fa004bc5cc3fb--

From martin.thomson@gmail.com  Thu Mar 29 00:42:29 2012
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 928F721F8670 for ; Thu, 29 Mar 2012 00:42:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.827
X-Spam-Level: 
X-Spam-Status: No, score=-4.827 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6e6Rc9MLi6UI for ; Thu, 29 Mar 2012 00:42:28 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5856B21F85FB for ; Thu, 29 Mar 2012 00:42:28 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so1836413bku.31 for ; Thu, 29 Mar 2012 00:42:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Mr88qpTzCFI5V0jjKAwbK7ZXkuWlDw6PhEfNCWwwa0U=; b=LpENDxEW4Dzhuj8YnWsET2x4YYu7k7LeQScyO0h6Wnn3TvH9Y/0W9/GQEda9iTQU1x 1bafHtahcSYBnMkDWeeoqBuY2i0FZyH+gZLwDT60uNVg/W0THkVClXzZnh+UlytY6yBA fKGDH7TBGXJ2lYWrs//XaOdiKjCtuhy49maaXdiRWci+71rhAv32v/f0Gqiy27Mzfj2y RRSaeodmyAWwgs3I5C9EdebX0UXIX6SAfCxqS/NIsTMqVuz+ne5PAzmHTTXJQwlUiZ2Y oMe1EIDVGRnw7VWO7B1ng3J5jIxy/yEFwlDMAjoMZW1dK3oeEql4VrqXETPxugG9mgni ffcg==
MIME-Version: 1.0
Received: by 10.204.156.2 with SMTP id u2mr13384913bkw.101.1333006947472; Thu, 29 Mar 2012 00:42:27 -0700 (PDT)
Received: by 10.205.38.73 with HTTP; Thu, 29 Mar 2012 00:42:27 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>
References:  <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>
Date: Thu, 29 Mar 2012 09:42:27 +0200
Message-ID: 
From: Martin Thomson 
To: Tobias Oberstein 
Content-Type: text/plain; charset=UTF-8
Cc: "hybi@ietf.org" , Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 07:42:29 -0000

On 29 March 2012 09:32, Tobias Oberstein  wrote:
> So if your prime goal is to keep up a very low latency connection, then you even might need very short
> heartbeat (3-20s), with substantial payload.

That's grossly wasteful.  But whatever you need.

From tobias.oberstein@tavendo.de  Thu Mar 29 00:47:11 2012
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 C63D021F844F for ; Thu, 29 Mar 2012 00:47:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.382
X-Spam-Level: 
X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tY2Q4-3jfLcl for ; Thu, 29 Mar 2012 00:47:11 -0700 (PDT)
Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACE521F881E for ; Thu, 29 Mar 2012 00:47:07 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.68]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Thu, 29 Mar 2012 00:47:06 -0700
From: Tobias Oberstein 
To: Martin Thomson 
Date: Thu, 29 Mar 2012 00:47:04 -0700
Thread-Topic: [hybi] Keep-Alive analysis
Thread-Index: Ac0Nf34krrnKSseoQ7ODi0rJai1WggAACJgA
Message-ID: <634914A010D0B943A035D226786325D42D5D0FE612@EXVMBX020-12.exch020.serverdata.net>
References:  <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net> 
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: "hybi@ietf.org" , Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 07:47:12 -0000

PiA+IFNvIGlmIHlvdXIgcHJpbWUgZ29hbCBpcyB0byBrZWVwIHVwIGEgdmVyeSBsb3cgbGF0ZW5j
eSBjb25uZWN0aW9uLA0KPiA+IHRoZW4geW91IGV2ZW4gbWlnaHQgbmVlZCB2ZXJ5IHNob3J0IGhl
YXJ0YmVhdCAoMy0yMHMpLCB3aXRoIHN1YnN0YW50aWFsDQo+IHBheWxvYWQuDQo+IA0KPiBUaGF0
J3MgZ3Jvc3NseSB3YXN0ZWZ1bC4gIEJ1dCB3aGF0ZXZlciB5b3UgbmVlZC4NCg0KWWVzIGl0IGlz
Lg0KDQpJdCB3b3VsZG4ndCBiZSBuZWVkZWQgaWYgdGhlcmUgd2VyZSAxKSBtZWNoYW5pc21zIGZv
ciBhIG1vYmlsZSBkZXZpY2VzDQp0byBwcm9oaWJpdCBkb3duZ3JhZGluZyBhIDMuNUcgY29ubmVj
dGlvbiB0byAzRyBhbmQgMikgYW4gQVBJIHVzYWJsZQ0KZnJvbSBhcHBzIHRvIGNvbnRyb2wgdGhh
dC4NCg0KQXMgZmFyIGFzIEkga25vdyBuZWl0aGVyIDEpIG5vciAyKSBpcyB0aGVyZS4gSWYgeW91
IGtub3cgaG93IHRvIGRvIHRoYXQsDQpJJ2QgYmUgaGFwcHkgdG8gbGVhcm4hDQoNCg==

From tyoshino@google.com  Thu Mar 29 01:00:25 2012
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 E384421F8971 for ; Thu, 29 Mar 2012 01:00:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.955
X-Spam-Level: 
X-Spam-Status: No, score=-102.955 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EYl4YuzedoK8 for ; Thu, 29 Mar 2012 01:00:25 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8C021F895B for ; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
Received: by iazz13 with SMTP id z13so3126199iaz.31 for ; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=YoPaFAU6oDQBV1lATilY7c8P2JCZTxhQrx6EBtpzEwM=; b=d/yURDQYSOMInxPUHBEkw2dWIJ4dHcv94JLK8Mp/B8ouNDeS7R93a8Eq+itqSUobPG Ig/RYp0YVBuNFQgRToy0HSMY05wLApo/kvPP4N2r9aDrErOrRZyhXAwGCx6LJvLmMbpL JQwCbM7Y+1PpHrUNS9mPvfPVTQujLp7I1YjEf86iThp1BQbmspYukLkQSpxy98VTfrQd ev9Xv4oeJC5TblvZUX9Ps4EfpSwMb4UvxG8pw3uoeOOj5kOLRcnFSfItC0ktwxw8DPXQ nEwsfjUifUA0YgsknzZwclVjX2pGW3cKLn0leHpQGqIr4Gr6aJ/+S5oIeX3/+cR7hS7N S10g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=YoPaFAU6oDQBV1lATilY7c8P2JCZTxhQrx6EBtpzEwM=; b=VG4hT8M5hwYzYXpe+kHxJ5vDRlyvRxEcv+VZwXD0v7p0yeINE+8vQeRiLx6VM2oT1o d9DEJL0HvUGhLxFjOSTmNVm2FODEdsbnhJ0FdtG/nhu78UpevTAhXS64MMLYKTzsdk22 xCrL1So2/+86TIveMgtgus7b2F4IvWD8jLBI88Fp1By7B2MebAQpChto1LCfmddcf1p4 HWGqra7uFLQzZgq1p8WVSfXrun7F8N1pxic/96Bx8cJ1VBDhSLisYWg1r8VYOskzoRkk lqy8Xn0SrmITnrKNNvdIVKUTG2ykM88K2Ev6aua1VyW0CEanRTAX+3b8EbYi4a63GE8N NtBQ==
Received: by 10.50.89.200 with SMTP id bq8mr239639igb.45.1333008024678; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
Received: by 10.50.89.200 with SMTP id bq8mr239634igb.45.1333008024604; Thu, 29 Mar 2012 01:00:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.178.203 with HTTP; Thu, 29 Mar 2012 01:00:00 -0700 (PDT)
From: Takeshi Yoshino 
Date: Thu, 29 Mar 2012 10:00:00 +0200
Message-ID: 
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=e89a8f3ba32dca0e9d04bc5d1d53
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkLrvbByQfuGuNMYg8WhPUOCDC0cZ6pP2nhnxwaKCCDXg8CRxSXlrOWuFMLz3OG/EYRUtt8DLRs8sHjVpGW5mNGPe73r7iE2xcsF3qi+7//LxeeXExt14ll+um61p1ooaxT7CFB
Subject: [hybi] Channel ID encoding of multiplexing extension
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, 29 Mar 2012 08:00:26 -0000

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

In the latest mux extension draft, we're using a new 4-mode integer
encoding for channel ID field.
http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03#section-6

ID : field length
0 - : 1 octet
128 (2^7) - : 2 octet
16384 (2^14) - : 3 octet
2097152 (2^21) - 536870912 (2^29 - 1) : 4 octet

It's designed and put in the spec by John considering that distribution of
channel ID would have distribution different from payload.

In the f2f meeting yesterday, Gabriel showed concern about introduction of
a new variable length encoding as we already have 1 a bit complicated
encoding for the payload length.

Here I want to call for opinions and alternative suggestions on this
specific point. Thoughts?

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

In the latest mux extension draft, we're using a new 4-mode integer enc=
oding for channel ID field.



ID : field length


0 - : 1 octet


128 (2^7) - : 2 octet
16384 (2^14) - : 3 octet
209=
7152 (2^21) - 536870912 (2^29 - 1) : 4 octet

It=
9;s designed and put in the spec by John considering that distribution of c=
hannel ID would have distribution=A0different=A0from payload.





In the f2f meeting yesterday, Gabriel showed concern ab=
out introduction of a new variable length encoding as we already have 1 a b=
it complicated encoding for the payload length.



Here I want to call for opinions and alternative suggestions on this specif=
ic point. Thoughts?



--e89a8f3ba32dca0e9d04bc5d1d53--

From tyoshino@google.com  Thu Mar 29 01:06:04 2012
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 2A32B21F89AC for ; Thu, 29 Mar 2012 01:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.956
X-Spam-Level: 
X-Spam-Status: No, score=-102.956 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89pV5nNoTbr1 for ; Thu, 29 Mar 2012 01:06:03 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 57AF721F8998 for ; Thu, 29 Mar 2012 01:06:03 -0700 (PDT)
Received: by iazz13 with SMTP id z13so3134727iaz.31 for ; Thu, 29 Mar 2012 01:06:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=32DQ3nVOagkLj5gDBwqbPRpy1zDMOyEJH2Bpb4ZbLCs=; b=cBNyfqJadLUPqMHTgO/H0LYsq75hbT4QQLK0uHqnkJiT2z1Aj15oVt9UR1NzU0yZta IjYLEcK0qyMTunEOOeoRz68rhALKdDXM0x19Xg7aKzFFH6Oy/9omWwzPhMgRU0MbMuOV D26nfia7Nm2SadKl7VnguPOgvj7W2rdL46nBjFFPI1peKF38CDMwxsJiIsxjSqCDzHMC dXHtYUF0zKmzIseOc7nwC1HXiuM4aP+Kus86XKFyOuSqkK2ALYNvpbY8Ej8Jk0l6b261 HSk3wi0zMdWdrTFZ5xWLdsn0z3AoTqN3sJaPqUqjNnR7aAukUdi5TXGT918BMIuCCqag dh6g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=32DQ3nVOagkLj5gDBwqbPRpy1zDMOyEJH2Bpb4ZbLCs=; b=gwSbvULdFd4uNGSyAOe2xcvS/0/eyGf/SKOuRoSdcNpVnAV9cVPVjKgRYXMdhSNsOu kQ0DyCNSODqE0agpYQ4VJaxU/QJ1WH49GIyJym/Vmu6dE0hsEYgXcjLEXow9FNeG1Gw9 KKI5QBgI/9nYGrFyMe0EzzhYfJc9S2mEnAYYPKg3DySYi6kAlQLkFrHdKL+nuRyu1/5V ee15m2ohuxWcegt2SyuGdGhrIUwsZ6SqSutu8KOSsVbZScwVqJQXHQiDcLmP37awUKT7 3WkeQdPAwtSa8Qf11nknHbxAIpfY/+Dkzl93n+PpmgN9TVb181T8Q9tkf4tmUubnbziE 5cNA==
Received: by 10.50.36.193 with SMTP id s1mr780014igj.45.1333008362934; Thu, 29 Mar 2012 01:06:02 -0700 (PDT)
Received: by 10.50.36.193 with SMTP id s1mr780007igj.45.1333008362862; Thu, 29 Mar 2012 01:06:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.178.203 with HTTP; Thu, 29 Mar 2012 01:05:42 -0700 (PDT)
In-Reply-To: 
References: 
From: Takeshi Yoshino 
Date: Thu, 29 Mar 2012 10:05:42 +0200
Message-ID: 
To: hybi@ietf.org
Content-Type: multipart/alternative; boundary=14dae9340b8bf3765a04bc5d31f4
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQn6r1+pQWf/uRLkZNjM81lWDDAIBotHovQKKQHfKhZ3wPDfEojF48njPcMfSntUy+Mze3MuJZ2lDsg3TU2r9MMAY5ow13hojRqZka61GOno2zsylM7ugLrmMjLnyXiGfwcKqYY8
Subject: Re: [hybi] Channel ID encoding of multiplexing extension
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, 29 Mar 2012 08:06:04 -0000

--14dae9340b8bf3765a04bc5d31f4
Content-Type: text/plain; charset=ISO-8859-1

And, John, could you provide some text to explain reasoning to choose this
encoding which we can put in the spec?

Data / thoughts on the expected distribution of the number of concurrent
logical channels are also welcome.

--14dae9340b8bf3765a04bc5d31f4
Content-Type: text/html; charset=ISO-8859-1

And, John, could you provide some text to explain reasoning to choose this encoding which we can put in the spec?

Data / thoughts on the expected distribution of the number of concurrent logical channels are also welcome.






--14dae9340b8bf3765a04bc5d31f4--

From grmocg@gmail.com  Thu Mar 29 00:50:51 2012
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 0594221F88B9 for ; Thu, 29 Mar 2012 00:50:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.473
X-Spam-Level: 
X-Spam-Status: No, score=-6.473 tagged_above=-999 required=5 tests=[AWL=-2.875, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8NPPDtRRfiAG for ; Thu, 29 Mar 2012 00:50:49 -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 4C0BD21F88B3 for ; Thu, 29 Mar 2012 00:50:49 -0700 (PDT)
Received: by vcbfk13 with SMTP id fk13so1507114vcb.31 for ; Thu, 29 Mar 2012 00:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=++Cfdfu6con+04gqS/OJTR7usW7WUGnivkjrY2qU3Tw=; b=O26+oOyvBu1QjHBZv5FHpZPvwMZGPIbCmO2g64QlI6JE8bO5bc27XHkuYJhgaJs6fO v+/UO7YUVnBXvy9mpCMSE4ZjC90seBh08zHLA4q/J6IcgUrwOjImm623p/5woleaqXbp c+ViIXp4GAx+d2tMpX/4ZgNzsZShwDtlvxEbL94Ka5F5vwkeWL1DnqBnNMiJtuy6ssjK Trhlp3TkZtnztUsHxIFhpmNowpQsngkiBZjICHTepJiyhcvK1A5AsfrNVsJVgK04W1Zz olashNs15kj3qii1WXrpZOy81Bhi0Bc8/OataF3MazQZzl56FI0KEGacaz7CR4Shignu XMOw==
MIME-Version: 1.0
Received: by 10.52.37.228 with SMTP id b4mr8546464vdk.131.1333007448397; Thu, 29 Mar 2012 00:50:48 -0700 (PDT)
Received: by 10.52.31.40 with HTTP; Thu, 29 Mar 2012 00:50:48 -0700 (PDT)
In-Reply-To: <634914A010D0B943A035D226786325D42D5D0FE612@EXVMBX020-12.exch020.serverdata.net>
References:  <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>  <634914A010D0B943A035D226786325D42D5D0FE612@EXVMBX020-12.exch020.serverdata.net>
Date: Thu, 29 Mar 2012 09:50:48 +0200
Message-ID: 
From: Roberto Peon 
To: Tobias Oberstein 
Content-Type: multipart/alternative; boundary=bcaec51b9a0371d65104bc5cfb3f
X-Mailman-Approved-At: Thu, 29 Mar 2012 01:10:59 -0700
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 07:50:51 -0000

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

It is all tradeoffs. For some applications, perhaps the  increased
signaling cost, bandwidth cost, cpu cost, and battery-life cost is a
reasonable tradeoff. At least until the carrier attempts to ban the
application and/or charge you for it :)

-=R

On Thu, Mar 29, 2012 at 9:47 AM, Tobias Oberstein <
tobias.oberstein@tavendo.de> wrote:

> > > So if your prime goal is to keep up a very low latency connection,
> > > then you even might need very short heartbeat (3-20s), with substantial
> > payload.
> >
> > That's grossly wasteful.  But whatever you need.
>
> Yes it is.
>
> It wouldn't be needed if there were 1) mechanisms for a mobile devices
> to prohibit downgrading a 3.5G connection to 3G and 2) an API usable
> from apps to control that.
>
> As far as I know neither 1) nor 2) is there. If you know how to do that,
> I'd be happy to learn!
>
>

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

It is all tradeoffs. For some applications, perhaps the =A0increased signal=
ing cost, bandwidth cost, cpu cost, and battery-life cost is a reasonable t=
radeoff. At least until the carrier attempts to ban the application and/or =
charge you for it :)


-=3DR

On Thu, Mar 29, 2012 at 9:=
47 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:


> > So if your prime goal is to keep up a very low =
latency connection,

> > then you even might need very short heartbeat (3-20s), with subst=
antial

> payload.

>

> That's grossly wasteful. =A0But whatever you need.




Yes it is.



It wouldn't be needed if there were 1) mechanisms for a mobile devices<=
br>
to prohibit downgrading a 3.5G connection to 3G and 2) an API usable

from apps to control that.



As far as I know neither 1) nor 2) is there. If you know how to do that,
I'd be happy to learn!







--bcaec51b9a0371d65104bc5cfb3f--

From w@1wt.eu  Thu Mar 29 01:54:26 2012
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 92D1921F89EB for ; Thu, 29 Mar 2012 01:54:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level: 
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[AWL=-3.067,  BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG5Hl0KxK4n4 for ; Thu, 29 Mar 2012 01:54:25 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id BC95E21F89EC for ; Thu, 29 Mar 2012 01:54:24 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2T8sCsw004068; Thu, 29 Mar 2012 10:54:12 +0200
Date: Thu, 29 Mar 2012 10:54:12 +0200
From: Willy Tarreau 
To: Roberto Peon 
Message-ID: <20120329085412.GA4052@1wt.eu>
References:  <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>  <634914A010D0B943A035D226786325D42D5D0FE612@EXVMBX020-12.exch020.serverdata.net> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 08:54:26 -0000

Hi,

On Thu, Mar 29, 2012 at 09:50:48AM +0200, Roberto Peon wrote:
> It is all tradeoffs. For some applications, perhaps the  increased
> signaling cost, bandwidth cost, cpu cost, and battery-life cost is a
> reasonable tradeoff. At least until the carrier attempts to ban the
> application and/or charge you for it :)

The problem is that in an ideal world we'd like the application to
communicate QoS preferences to the upper layers (including the OS).

There should be a lot of thinking done around mobile-specific usages
and tradeoffs I think, as these are not specific to websocket.

Willy


From alex@noemax.com  Thu Mar 29 02:03:00 2012
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 B944821F88E8 for ; Thu, 29 Mar 2012 02:03:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkLcNYZcvBZH for ; Thu, 29 Mar 2012 02:02:59 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id EB89621F88D0 for ; Thu, 29 Mar 2012 02:02:58 -0700 (PDT)
Received: from HPdv73190ev by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id NMG41603; Thu, 29 Mar 2012 12:03:03 +0300
From: "Alexander Philippou" 
To: "'Gabriel Montenegro'" , "'Arman Djusupov'" , "'John Tamplin'" 
References: 
In-Reply-To: 
Date: Thu, 29 Mar 2012 12:02:43 +0300
Message-ID: <00a001cd0d8a$b85f8c90$291ea5b0$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A1_01CD0DA3.DDAF3590"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH1n1+Ojm+MgDnEYO0LBiekP5MbYpYvz9Zg
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)
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, 29 Mar 2012 09:03:00 -0000

This is a multipart message in MIME format.

------=_NextPart_000_00A1_01CD0DA3.DDAF3590
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi Gabriel, can you please clarify for me the new charter, does it mean =
that we intend to move away from the original charter which stated that:

=20

Wide browser support is a goal for the bidirectional communication =
mechanism, however the solution should also be suitable for clients =
other than Web Browsers

=20

The Working Group will work to standardize a generic solution that can =
work efficiently in as many of the deployed environments as possible and =
in particular in all the elements of the web infrastructure (e.g. web =
browser, generic HTTP client, HTTP server and HTTP-aware intermediaries =
like proxies, load balancers, caches, etc.) and it is not specific for =
just one.

=20

Alexander

=20

=20

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of =
Gabriel Montenegro
Sent: Thursday 29 March 2012 10:32
To: Arman Djusupov; 'John Tamplin'
Cc: hybi@ietf.org
Subject: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: =
channel ID semantics)

=20

Yes, it=E2=80=99s true that there are many APIs, however, from the point =
of view of the working group we are coordinating with only one of those.

=20

>From our charter:

    The group will continue coordinating with the W3C WepApps working

    group with respect to the above deliverables and to ensure the best

    match possible between the WebSocket protocol and the WebSocket API. =


=20

This doesn=E2=80=99t preclude about informal discussion regarding other =
APIs, but the only one the WG should lose sleep over is the above as =
it=E2=80=99s in our charter. Right now the question is relevant with =
respect to the W3C WebApps WebSocket API, because that working group is =
undergoing rechartering, so if any further change is needed to the above =
it behooves us to make that clear shortly.=20

=20

So far, it seems like we=E2=80=99re fine without additional requirements =
on that API.

=20

From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of =
Arman Djusupov
Sent: Thursday, 29 March, 2012 09:07
To: 'John Tamplin'
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

=20

The JS API is just one of the APIs that uses the WebSocket protocol, =
there are already multiple Java, .NET, Mono, Python  etc. client and =
server libraries available for Windows, Android, iOS etc. These =
obviously have their own APIs that do not depend on browser =
functionality. It doesn=E2=80=99t really matter what is supported by a =
particular API, it is fine if that API supports a subset of the =
functionality. A little back JS didn=E2=80=99t support binary data, but =
that didn't mean that we shouldn't have introduced binary frames. If the =
JS API cannot support some specific functionality then let it not, but =
this functionality should be available to other platforms.

=20

With respect, I don=E2=80=99t agree that we should look at any WebSocket =
related specs using only =E2=80=9CChrome to Google server pool=E2=80=9D =
point of view.

=20

With best regards,

Arman

=20

=20

From: John Tamplin [mailto:jat@google.com]=20
Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics

=20

On Wed, Mar 28, 2012 at 11:50 AM, Gabriel Montenegro =
 wrote:

If anybody feels strongly that there is any API impact of either the mux =
or compression, please support such claims.

=20

I think there should not be at this point, in either one -- which means =
that I think exposing the existing of MUX channels (including being able =
to open multiple at a time) should be off the table at this point.

=20

In the long term, I suspect we may want to alter the API to let the =
application have better control over compression, but I don't think we =
want to do that until we have more experience about exactly what is =
useful.

=20

--=20
John A. Tamplin
Software Engineer (GWT), Google


------=_NextPart_000_00A1_01CD0DA3.DDAF3590
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable


Hi Gabriel, can you please clarify for me the new charter, does it =
mean that we intend to move away from the original charter which stated =
that:
 
Wide =
browser support is a goal for the bidirectional communication mechanism, =
however the solution should also be suitable for clients other than =
Web Browsers
 
The =
Working Group will work to standardize a generic =
solution that can work efficiently in as many of the deployed =
environments as possible and in particular in all the elements of the =
web infrastructure (e.g. web browser, generic HTTP =
client, HTTP server and HTTP-aware intermediaries like proxies, =
load balancers, caches, etc.) and it is not specific for just =
one.
 
Alexander
 
 
From:=
 =
hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of =
Gabriel Montenegro
Sent: Thursday 29 March 2012 =
10:32
To: Arman Djusupov; 'John Tamplin'
Cc: =
hybi@ietf.org
Subject: [hybi] W3C WebApps Working Group =
WebSocket API (was: RE: MUC: channel ID =
semantics)
 
Yes, it=E2=80=99s true that there are many APIs, however, from the =
point of view of the working group we are coordinating with only one of =
those.
 
From our =
charter:
    =
The group will =
continue coordinating with the W3C WepApps =
working
    group =
with respect to the above deliverables and to ensure the =
best
    match =
possible between the WebSocket protocol and the WebSocket =
API. =

 
This doesn=E2=80=99t preclude about informal discussion regarding =
other APIs, but the only one the WG should lose sleep over is the above =
as it=E2=80=99s in our charter. Right now the question is relevant with =
respect to the W3C WebApps WebSocket API, because that working group is =
undergoing rechartering, so if any further change is needed to the above =
it behooves us to make that clear shortly. 
 
So far, it seems like we=E2=80=99re fine without additional =
requirements on that API.
 
From:=
 =
hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.=
org] On Behalf Of Arman Djusupov
Sent: Thursday, 29 =
March, 2012 09:07
To: 'John Tamplin'
Cc: hybi@ietf.org
Subject: Re: =
[hybi] MUC: channel ID semantics
 
The JS API is just one of the APIs that uses the WebSocket protocol, =
there are already multiple Java, .NET, Mono, Python  etc. client =
and server libraries available for Windows, Android, iOS etc. These =
obviously have their own APIs that do not depend on browser =
functionality. It doesn=E2=80=99t really matter what is supported by a =
particular API, it is fine if that API supports a subset of the =
functionality. A little back JS didn=E2=80=99t support binary data, but =
that didn't mean that we shouldn't have introduced binary frames. If the =
JS API cannot support some specific functionality then let it not, but =
this functionality should be available to other =
platforms.
 
With respect, I don=E2=80=99t agree that we should look at any =
WebSocket related specs using only =E2=80=9CChrome to Google server =
pool=E2=80=9D point of view.
 
With best regards,
Arman
 
 
From:=
 =
John Tamplin [mailto:jat@google.com] =

Sent: Wednesday, March 28, 2012 9:09 PM
To: Gabriel =
Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: =
[hybi] MUC: channel ID semantics
 
On Wed, =
Mar 28, 2012 at 11:50 AM, Gabriel Montenegro <Gabriel.Montenegro@micro=
soft.com> wrote:
If anybody feels strongly that there is any API impact of either the =
mux or compression, please support such =
claims.
 
I =
think there should not be at this point, in either one -- which means =
that I think exposing the existing of MUX channels (including being able =
to open multiple at a time) should be off the table at this =
point.
 
In the long term, I suspect we may want to alter the =
API to let the application have better control over compression, but I =
don't think we want to do that until we have more experience about =
exactly what is useful.
 
-- =

John A. Tamplin
Software Engineer (GWT), =
Google

------=_NextPart_000_00A1_01CD0DA3.DDAF3590--


From fenix@google.com  Thu Mar 29 02:29:50 2012
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 E6ADD21F8992 for ; Thu, 29 Mar 2012 02:29:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.726
X-Spam-Level: 
X-Spam-Status: No, score=-104.726 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVRTQRhZlGXv for ; Thu, 29 Mar 2012 02:29:49 -0700 (PDT)
Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41D0121F8970 for ; Thu, 29 Mar 2012 02:29:48 -0700 (PDT)
Received: by lagj5 with SMTP id j5so2651902lag.31 for ; Thu, 29 Mar 2012 02:29:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=fwCFMR+MZ6XSA7AFGWw+UGTTJqcA0bxE88p3eXjFcvc=; b=XSx/iQzJgDkXD3xSaAUV0eM22jXAC/Fodu7/QqQPkkkS6x+pOQbs3SkgLVomg8Ugk8 HMZo+lZQqyAc9rIBJlUGTXftMJOo8ahOHs6Q2Z3sPEgeZlZB0gA6oohd5aeoGCGW0b/p xhR7EZFYO0xZr82PY/c7R56rtgjrTygZ/pBMKMRPrwXDT6VAMxgfx1AkEkqFCHy+q7bu sMxAXSMv3spR0im1FLhhY5IDmvARjnmB6CyfRyf5OdUS8MIa4O0M/jC1bOPQuTWQFslK WjVban8Jx77GQye2caLuA04LGJc+3j3m5tglrEOPXjCyc8Vp6fTnLaVYzlGZgdBV2gGC 57uA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=fwCFMR+MZ6XSA7AFGWw+UGTTJqcA0bxE88p3eXjFcvc=; b=DLl50TSdBk9CaqZ6KBgsn1dYMb63R5Q4D5tFIM9QYNZuy7FGDlkUpgykzjRm0zkn5y sXsLytk4VgzGMMfdQ65gxQKCpKJX4vSbRYacukTslhIu8BRo10nGZxlphkXDRGjI9n5h RLrGFOZJGf3XrYRG3Gi3CyHKVg7NgUsD+QY2Dkd98qvQph8NksSaZMxiHbxvZ/RniFk3 IssPfXhgwzFIDFrtxK7AUyXuGzOkx0fD4sk8q+oPlJI9vwlDash9dc5ajCiHKrIsTKCR vZCuOjENsor/Nn/w9JZEgVwE71oy3vSMD7TaO75oRgxdtqu1Le0P+1YeHfGRjAyHFXIf kPMA==
Received: by 10.152.146.39 with SMTP id sz7mr27188582lab.3.1333013386472; Thu, 29 Mar 2012 02:29:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.152.146.39 with SMTP id sz7mr27188562lab.3.1333013386326; Thu, 29 Mar 2012 02:29:46 -0700 (PDT)
Received: by 10.112.20.137 with HTTP; Thu, 29 Mar 2012 02:29:46 -0700 (PDT)
Received: by 10.112.20.137 with HTTP; Thu, 29 Mar 2012 02:29:46 -0700 (PDT)
In-Reply-To: <20120329085412.GA4052@1wt.eu>
References:  <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>  <634914A010D0B943A035D226786325D42D5D0FE612@EXVMBX020-12.exch020.serverdata.net>  <20120329085412.GA4052@1wt.eu>
Date: Thu, 29 Mar 2012 02:29:46 -0700
Message-ID: 
From: Roberto Peon 
To: Willy Tarreau 
Content-Type: multipart/alternative; boundary=e89a8f2347255f73d604bc5e5db2
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlw5/GBVF0YaiCW9Q9chOHb2Rx3UUmq+oN8PF6rCvLGhyHoVzEDx/JCW146GOfZLM72zVDfXuKi9rGDr17ChkJl8LuZWOcnYq2kVMguisp6WGaepaAa2NdAyYa5Nn+Z1gpUcCdR
Cc: hybi@ietf.org, Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 09:29:51 -0000

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

I agree that the issues are not solely owned by the WG, but the
implementation is.

In an ideal world, the battery wouldn't be consumed so much by the radio
and the signaling protocols would be cheaper for all parties. Saving that,
a mechanism for synchronizing periodic updates so the radio had few/minimal
state changes would be good... that may be something we should talk about
finding or chartering a WG to discuss...
On Mar 29, 2012 1:54 AM, "Willy Tarreau"  wrote:

> Hi,
>
> On Thu, Mar 29, 2012 at 09:50:48AM +0200, Roberto Peon wrote:
> > It is all tradeoffs. For some applications, perhaps the  increased
> > signaling cost, bandwidth cost, cpu cost, and battery-life cost is a
> > reasonable tradeoff. At least until the carrier attempts to ban the
> > application and/or charge you for it :)
>
> The problem is that in an ideal world we'd like the application to
> communicate QoS preferences to the upper layers (including the OS).
>
> There should be a lot of thinking done around mobile-specific usages
> and tradeoffs I think, as these are not specific to websocket.
>
> Willy
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
>

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


I agree that the issues are not solely owned by the WG, but the implemen=
tation is. 


In an ideal world, the battery wouldn't be consumed so much by the r=
adio and the signaling protocols would be cheaper for all parties. Saving t=
hat, a mechanism for synchronizing periodic updates so the radio had few/mi=
nimal state changes would be good... that may be something we should talk a=
bout finding or chartering a WG to discuss...



On Mar 29, 2012 1:54 AM, "Willy Tarreau&quo=
t; <w@1wt.eu> wrote:

Hi,



On Thu, Mar 29, 2012 at 09:50:48AM +0200, Roberto Peon wrote:

> It is all tradeoffs. For some applications, perhaps the =A0increased
> signaling cost, bandwidth cost, cpu cost, and battery-life cost is a
> reasonable tradeoff. At least until the carrier attempts to ban the
> application and/or charge you for it :)



The problem is that in an ideal world we'd like the application to

communicate QoS preferences to the upper layers (including the OS).



There should be a lot of thinking done around mobile-specific usages

and tradeoffs I think, as these are not specific to websocket.



Willy



_______________________________________________

hybi mailing list

hybi@ietf.org

ht=
tps://www.ietf.org/mailman/listinfo/hybi




--e89a8f2347255f73d604bc5e5db2--

From Gabriel.Montenegro@microsoft.com  Thu Mar 29 04:08:22 2012
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 D771A21F850D for ; Thu, 29 Mar 2012 04:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.871
X-Spam-Level: 
X-Spam-Status: No, score=-3.871 tagged_above=-999 required=5 tests=[AWL=-0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3MuxdwOzLcB for ; Thu, 29 Mar 2012 04:08:20 -0700 (PDT)
Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 3417621F87EE for ; Thu, 29 Mar 2012 04:08:19 -0700 (PDT)
Received: from mail18-db3-R.bigfish.com (10.3.81.254) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Thu, 29 Mar 2012 11:08:16 +0000
Received: from mail18-db3 (localhost [127.0.0.1])	by mail18-db3-R.bigfish.com (Postfix) with ESMTP id 991864211DA; Thu, 29 Mar 2012 11:08:16 +0000 (UTC)
X-SpamScore: -24
X-BigFish: VS-24(zz9371Ic89bhc857h98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h)
X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI
Received-SPF: pass (mail18-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC102.redmond.corp.microsoft.com ; icrosoft.com ; 
Received: from mail18-db3 (localhost.localdomain [127.0.0.1]) by mail18-db3 (MessageSwitch) id 1333019294129424_11259; Thu, 29 Mar 2012 11:08:14 +0000 (UTC)
Received: from DB3EHSMHS017.bigfish.com (unknown [10.3.81.252])	by mail18-db3.bigfish.com (Postfix) with ESMTP id 1A9914C0056; Thu, 29 Mar 2012 11:08:14 +0000 (UTC)
Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS017.bigfish.com (10.3.87.117) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 29 Mar 2012 11:08:11 +0000
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.2.283.4; Thu, 29 Mar 2012 11:08:08 +0000
Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 29 Mar 2012 04:08:08 -0700
Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.25]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0283.004; Thu, 29 Mar 2012 04:08:07 -0700
From: Gabriel Montenegro 
To: Alexander Philippou , 'Arman Djusupov' , 'John Tamplin' 
Thread-Topic: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)
Thread-Index: AQHNDYrBD/bssiJuXkm/mB7rUXAQTpaBG/Dw
Date: Thu, 29 Mar 2012 11:08:07 +0000
Message-ID: 
References:  <00a001cd0d8a$b85f8c90$291ea5b0$@noemax.com>
In-Reply-To: <00a001cd0d8a$b85f8c90$291ea5b0$@noemax.com>
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: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5C50CTK5EX14MBXW602w_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] W3C WebApps Working Group WebSocket API (was: RE: MUC: channel ID semantics)
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, 29 Mar 2012 11:08:22 -0000

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

SeKAmW0gYXNzdW1pbmcgeW914oCZcmUgbG9va2luZyBhdCB0aGUgb2xkIGNoYXJ0ZXIgYXMgZm91
bmQgaGVyZToNCg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL3dnL2h5YmkvY2hhcnRlcnM/aXRlbT1j
aGFydGVyLWh5YmktMjAxMS0wNC0yOC50eHQNCg0KDQpUaGVzZSBhcmUgb3J0aG9nb25hbC4gV2hh
dCB5b3UgcG9pbnQgb3V0IGlzIHRoZSBndWlkZWxpbmUgZm9yIHRoZSAqcHJvdG9jb2wqIGRldmVs
b3BtZW50LiBUaGVyZSBpcyBubyBkaWZmZXJlbmNlIHRoZXJlLiAgV2hhdCB5b3UgbGVmdCBvdXQg
b2YgeW91ciBxdW90ZSBpcyBpbiB0aGUgcGFyYWdyYXBoIHByZXZpb3VzIHRvIHRoZSBvbmUgeW91
IHF1b3RlOg0KDQoNCiAgSW4gcGFydGljdWxhciwgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIGxpYWlz
ZWQgd2l0aCB0aGUgVzNDIFdlYkFwcHMNCiAgd29ya2luZyBncm91cCBhcm91bmQgdGhlIFdlYlNv
Y2tldHMgcHJvdG9jb2wgYW5kIHRoZSBuZWVkIHRvIHN1cHBvcnQNCiAgdGhlIFdlYlNvY2tldCBB
UEk7DQoNCg0KTm8gZGlmZmVyZW5jZTogcHJvdG9jb2wgd29yayBpcyBnZW5lcmFsLiBBUEkgY29v
cmRpbmF0aW9uIGlzIHdpdGggVzNDIFdlYkFwcHMuDQoNCkZyb206IEFsZXhhbmRlciBQaGlsaXBw
b3UgW21haWx0bzphbGV4QG5vZW1heC5jb21dDQpTZW50OiBUaHVyc2RheSwgMjkgTWFyY2gsIDIw
MTIgMTE6MDMNClRvOiBHYWJyaWVsIE1vbnRlbmVncm87ICdBcm1hbiBEanVzdXBvdic7ICdKb2hu
IFRhbXBsaW4nDQpDYzogaHliaUBpZXRmLm9yZw0KU3ViamVjdDogUkU6IFtoeWJpXSBXM0MgV2Vi
QXBwcyBXb3JraW5nIEdyb3VwIFdlYlNvY2tldCBBUEkgKHdhczogUkU6IE1VQzogY2hhbm5lbCBJ
RCBzZW1hbnRpY3MpDQoNCkhpIEdhYnJpZWwsIGNhbiB5b3UgcGxlYXNlIGNsYXJpZnkgZm9yIG1l
IHRoZSBuZXcgY2hhcnRlciwgZG9lcyBpdCBtZWFuIHRoYXQgd2UgaW50ZW5kIHRvIG1vdmUgYXdh
eSBmcm9tIHRoZSBvcmlnaW5hbCBjaGFydGVyIHdoaWNoIHN0YXRlZCB0aGF0Og0KDQpXaWRlIGJy
b3dzZXIgc3VwcG9ydCBpcyBhIGdvYWwgZm9yIHRoZSBiaWRpcmVjdGlvbmFsIGNvbW11bmljYXRp
b24gbWVjaGFuaXNtLCBob3dldmVyIHRoZSBzb2x1dGlvbiBzaG91bGQgYWxzbyBiZSBzdWl0YWJs
ZSBmb3IgY2xpZW50cyBvdGhlciB0aGFuIFdlYiBCcm93c2Vycw0KDQpUaGUgV29ya2luZyBHcm91
cCB3aWxsIHdvcmsgdG8gc3RhbmRhcmRpemUgYSBnZW5lcmljIHNvbHV0aW9uIHRoYXQgY2FuIHdv
cmsgZWZmaWNpZW50bHkgaW4gYXMgbWFueSBvZiB0aGUgZGVwbG95ZWQgZW52aXJvbm1lbnRzIGFz
IHBvc3NpYmxlIGFuZCBpbiBwYXJ0aWN1bGFyIGluIGFsbCB0aGUgZWxlbWVudHMgb2YgdGhlIHdl
YiBpbmZyYXN0cnVjdHVyZSAoZS5nLiB3ZWIgYnJvd3NlciwgZ2VuZXJpYyBIVFRQIGNsaWVudCwg
SFRUUCBzZXJ2ZXIgYW5kIEhUVFAtYXdhcmUgaW50ZXJtZWRpYXJpZXMgbGlrZSBwcm94aWVzLCBs
b2FkIGJhbGFuY2VycywgY2FjaGVzLCBldGMuKSBhbmQgaXQgaXMgbm90IHNwZWNpZmljIGZvciBq
dXN0IG9uZS4NCg0KQWxleGFuZGVyDQoNCg0KRnJvbTogaHliaS1ib3VuY2VzQGlldGYub3JnPG1h
aWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3Jn
XTxtYWlsdG86W21haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgR2Fi
cmllbCBNb250ZW5lZ3JvDQpTZW50OiBUaHVyc2RheSAyOSBNYXJjaCAyMDEyIDEwOjMyDQpUbzog
QXJtYW4gRGp1c3Vwb3Y7ICdKb2huIFRhbXBsaW4nDQpDYzogaHliaUBpZXRmLm9yZzxtYWlsdG86
aHliaUBpZXRmLm9yZz4NClN1YmplY3Q6IFtoeWJpXSBXM0MgV2ViQXBwcyBXb3JraW5nIEdyb3Vw
IFdlYlNvY2tldCBBUEkgKHdhczogUkU6IE1VQzogY2hhbm5lbCBJRCBzZW1hbnRpY3MpDQoNClll
cywgaXTigJlzIHRydWUgdGhhdCB0aGVyZSBhcmUgbWFueSBBUElzLCBob3dldmVyLCBmcm9tIHRo
ZSBwb2ludCBvZiB2aWV3IG9mIHRoZSB3b3JraW5nIGdyb3VwIHdlIGFyZSBjb29yZGluYXRpbmcg
d2l0aCBvbmx5IG9uZSBvZiB0aG9zZS4NCg0KRnJvbSBvdXIgY2hhcnRlcjoNCiAgICBUaGUgZ3Jv
dXAgd2lsbCBjb250aW51ZSBjb29yZGluYXRpbmcgd2l0aCB0aGUgVzNDIFdlcEFwcHMgd29ya2lu
Zw0KICAgIGdyb3VwIHdpdGggcmVzcGVjdCB0byB0aGUgYWJvdmUgZGVsaXZlcmFibGVzIGFuZCB0
byBlbnN1cmUgdGhlIGJlc3QNCiAgICBtYXRjaCBwb3NzaWJsZSBiZXR3ZWVuIHRoZSBXZWJTb2Nr
ZXQgcHJvdG9jb2wgYW5kIHRoZSBXZWJTb2NrZXQgQVBJLg0KDQpUaGlzIGRvZXNu4oCZdCBwcmVj
bHVkZSBhYm91dCBpbmZvcm1hbCBkaXNjdXNzaW9uIHJlZ2FyZGluZyBvdGhlciBBUElzLCBidXQg
dGhlIG9ubHkgb25lIHRoZSBXRyBzaG91bGQgbG9zZSBzbGVlcCBvdmVyIGlzIHRoZSBhYm92ZSBh
cyBpdOKAmXMgaW4gb3VyIGNoYXJ0ZXIuIFJpZ2h0IG5vdyB0aGUgcXVlc3Rpb24gaXMgcmVsZXZh
bnQgd2l0aCByZXNwZWN0IHRvIHRoZSBXM0MgV2ViQXBwcyBXZWJTb2NrZXQgQVBJLCBiZWNhdXNl
IHRoYXQgd29ya2luZyBncm91cCBpcyB1bmRlcmdvaW5nIHJlY2hhcnRlcmluZywgc28gaWYgYW55
IGZ1cnRoZXIgY2hhbmdlIGlzIG5lZWRlZCB0byB0aGUgYWJvdmUgaXQgYmVob292ZXMgdXMgdG8g
bWFrZSB0aGF0IGNsZWFyIHNob3J0bHkuDQoNClNvIGZhciwgaXQgc2VlbXMgbGlrZSB3ZeKAmXJl
IGZpbmUgd2l0aG91dCBhZGRpdGlvbmFsIHJlcXVpcmVtZW50cyBvbiB0aGF0IEFQSS4NCg0KRnJv
bTogaHliaS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmc+IFtt
YWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnXTxtYWlsdG86W21haWx0bzpoeWJpLWJvdW5jZXNA
aWV0Zi5vcmddPiBPbiBCZWhhbGYgT2YgQXJtYW4gRGp1c3Vwb3YNClNlbnQ6IFRodXJzZGF5LCAy
OSBNYXJjaCwgMjAxMiAwOTowNw0KVG86ICdKb2huIFRhbXBsaW4nDQpDYzogaHliaUBpZXRmLm9y
ZzxtYWlsdG86aHliaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaHliaV0gTVVDOiBjaGFubmVs
IElEIHNlbWFudGljcw0KDQpUaGUgSlMgQVBJIGlzIGp1c3Qgb25lIG9mIHRoZSBBUElzIHRoYXQg
dXNlcyB0aGUgV2ViU29ja2V0IHByb3RvY29sLCB0aGVyZSBhcmUgYWxyZWFkeSBtdWx0aXBsZSBK
YXZhLCAuTkVULCBNb25vLCBQeXRob24gIGV0Yy4gY2xpZW50IGFuZCBzZXJ2ZXIgbGlicmFyaWVz
IGF2YWlsYWJsZSBmb3IgV2luZG93cywgQW5kcm9pZCwgaU9TIGV0Yy4gVGhlc2Ugb2J2aW91c2x5
IGhhdmUgdGhlaXIgb3duIEFQSXMgdGhhdCBkbyBub3QgZGVwZW5kIG9uIGJyb3dzZXIgZnVuY3Rp
b25hbGl0eS4gSXQgZG9lc27igJl0IHJlYWxseSBtYXR0ZXIgd2hhdCBpcyBzdXBwb3J0ZWQgYnkg
YSBwYXJ0aWN1bGFyIEFQSSwgaXQgaXMgZmluZSBpZiB0aGF0IEFQSSBzdXBwb3J0cyBhIHN1YnNl
dCBvZiB0aGUgZnVuY3Rpb25hbGl0eS4gQSBsaXR0bGUgYmFjayBKUyBkaWRu4oCZdCBzdXBwb3J0
IGJpbmFyeSBkYXRhLCBidXQgdGhhdCBkaWRuJ3QgbWVhbiB0aGF0IHdlIHNob3VsZG4ndCBoYXZl
IGludHJvZHVjZWQgYmluYXJ5IGZyYW1lcy4gSWYgdGhlIEpTIEFQSSBjYW5ub3Qgc3VwcG9ydCBz
b21lIHNwZWNpZmljIGZ1bmN0aW9uYWxpdHkgdGhlbiBsZXQgaXQgbm90LCBidXQgdGhpcyBmdW5j
dGlvbmFsaXR5IHNob3VsZCBiZSBhdmFpbGFibGUgdG8gb3RoZXIgcGxhdGZvcm1zLg0KDQpXaXRo
IHJlc3BlY3QsIEkgZG9u4oCZdCBhZ3JlZSB0aGF0IHdlIHNob3VsZCBsb29rIGF0IGFueSBXZWJT
b2NrZXQgcmVsYXRlZCBzcGVjcyB1c2luZyBvbmx5IOKAnENocm9tZSB0byBHb29nbGUgc2VydmVy
IHBvb2zigJ0gcG9pbnQgb2Ygdmlldy4NCg0KV2l0aCBiZXN0IHJlZ2FyZHMsDQpBcm1hbg0KDQoN
CkZyb206IEpvaG4gVGFtcGxpbiBbbWFpbHRvOmphdEBnb29nbGUuY29tXTxtYWlsdG86W21haWx0
bzpqYXRAZ29vZ2xlLmNvbV0+DQpTZW50OiBXZWRuZXNkYXksIE1hcmNoIDI4LCAyMDEyIDk6MDkg
UE0NClRvOiBHYWJyaWVsIE1vbnRlbmVncm8NCkNjOiBBcm1hbiBEanVzdXBvdjsgaHliaUBpZXRm
Lm9yZzxtYWlsdG86aHliaUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaHliaV0gTVVDOiBjaGFu
bmVsIElEIHNlbWFudGljcw0KDQpPbiBXZWQsIE1hciAyOCwgMjAxMiBhdCAxMTo1MCBBTSwgR2Fi
cmllbCBNb250ZW5lZ3JvIDxHYWJyaWVsLk1vbnRlbmVncm9AbWljcm9zb2Z0LmNvbTxtYWlsdG86
R2FicmllbC5Nb250ZW5lZ3JvQG1pY3Jvc29mdC5jb20+PiB3cm90ZToNCklmIGFueWJvZHkgZmVl
bHMgc3Ryb25nbHkgdGhhdCB0aGVyZSBpcyBhbnkgQVBJIGltcGFjdCBvZiBlaXRoZXIgdGhlIG11
eCBvciBjb21wcmVzc2lvbiwgcGxlYXNlIHN1cHBvcnQgc3VjaCBjbGFpbXMuDQoNCkkgdGhpbmsg
dGhlcmUgc2hvdWxkIG5vdCBiZSBhdCB0aGlzIHBvaW50LCBpbiBlaXRoZXIgb25lIC0tIHdoaWNo
IG1lYW5zIHRoYXQgSSB0aGluayBleHBvc2luZyB0aGUgZXhpc3Rpbmcgb2YgTVVYIGNoYW5uZWxz
IChpbmNsdWRpbmcgYmVpbmcgYWJsZSB0byBvcGVuIG11bHRpcGxlIGF0IGEgdGltZSkgc2hvdWxk
IGJlIG9mZiB0aGUgdGFibGUgYXQgdGhpcyBwb2ludC4NCg0KSW4gdGhlIGxvbmcgdGVybSwgSSBz
dXNwZWN0IHdlIG1heSB3YW50IHRvIGFsdGVyIHRoZSBBUEkgdG8gbGV0IHRoZSBhcHBsaWNhdGlv
biBoYXZlIGJldHRlciBjb250cm9sIG92ZXIgY29tcHJlc3Npb24sIGJ1dCBJIGRvbid0IHRoaW5r
IHdlIHdhbnQgdG8gZG8gdGhhdCB1bnRpbCB3ZSBoYXZlIG1vcmUgZXhwZXJpZW5jZSBhYm91dCBl
eGFjdGx5IHdoYXQgaXMgdXNlZnVsLg0KDQotLQ0KSm9obiBBLiBUYW1wbGluDQpTb2Z0d2FyZSBF
bmdpbmVlciAoR1dUKSwgR29vZ2xlDQo=

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5C50CTK5EX14MBXW602w_
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
dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K
CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0K
CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNl
dGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24g
VGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250
LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4u
SFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVk
IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ
cmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5CYWxsb29u
VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5
bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m
YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1z
dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpw
ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx
RjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJ
Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNw
YW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw
RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0
O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w
aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0
aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh
dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh
LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86
aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb
ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9
InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPknigJltIGFzc3Vt
aW5nIHlvdeKAmXJlIGxvb2tpbmcgYXQgdGhlIG9sZCBjaGFydGVyIGFzIGZvdW5kIGhlcmU6PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z
LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvd2cvaHliaS9jaGFydGVycz9p
dGVtPWNoYXJ0ZXItaHliaS0yMDExLTA0LTI4LnR4dCI+aHR0cDovL3Rvb2xzLmlldGYub3JnL3dn
L2h5YmkvY2hhcnRlcnM/aXRlbT1jaGFydGVyLWh5YmktMjAxMS0wNC0yOC50eHQ8L2E+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl
cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1
b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlc2UgYXJlIG9ydGhv
Z29uYWwuIFdoYXQgeW91IHBvaW50IG91dCBpcyB0aGUgZ3VpZGVsaW5lIGZvciB0aGUgKjxiPnBy
b3RvY29sPC9iPiogZGV2ZWxvcG1lbnQuIFRoZXJlIGlzIG5vIGRpZmZlcmVuY2UgdGhlcmUuICZu
YnNwO1doYXQgeW91IGxlZnQgb3V0IG9mIHlvdXIgcXVvdGUNCiBpcyBpbiB0aGUgcGFyYWdyYXBo
IHByZXZpb3VzIHRvIHRoZSBvbmUgeW91IHF1b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0
OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll
ciBOZXcmcXVvdDsiPiZuYnNwOyBJbiBwYXJ0aWN1bGFyLCB0aGUgd29ya2luZyBncm91cCBoYXMg
bGlhaXNlZCB3aXRoIHRoZSBXM0MgV2ViQXBwczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgd29ya2luZyBncm91cCBhcm91bmQgdGhl
IFdlYlNvY2tldHMgcHJvdG9jb2wgYW5kIHRoZSBuZWVkIHRvIHN1cHBvcnQ8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgdGhlIFdlYlNvY2tldCBBUEk7
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv
dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv
dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk5vIGRpZmZlcmVuY2U6IHByb3RvY29s
IHdvcmsgaXMgZ2VuZXJhbC4gQVBJIGNvb3JkaW5hdGlvbiBpcyB3aXRoIFczQyBXZWJBcHBzLjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBBbGV4YW5kZXIgUGhp
bGlwcG91IFttYWlsdG86YWxleEBub2VtYXguY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJz
ZGF5LCAyOSBNYXJjaCwgMjAxMiAxMTowMzxicj4NCjxiPlRvOjwvYj4gR2FicmllbCBNb250ZW5l
Z3JvOyAnQXJtYW4gRGp1c3Vwb3YnOyAnSm9obiBUYW1wbGluJzxicj4NCjxiPkNjOjwvYj4gaHli
aUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW2h5YmldIFczQyBXZWJBcHBzIFdv
cmtpbmcgR3JvdXAgV2ViU29ja2V0IEFQSSAod2FzOiBSRTogTVVDOiBjaGFubmVsIElEIHNlbWFu
dGljcyk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7
LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgR2FicmllbCwgY2FuIHlv
dSBwbGVhc2UgY2xhcmlmeSBmb3IgbWUgdGhlIG5ldyBjaGFydGVyLCBkb2VzIGl0IG1lYW4gdGhh
dCB3ZSBpbnRlbmQgdG8gbW92ZSBhd2F5IGZyb20gdGhlIG9yaWdpbmFsIGNoYXJ0ZXIgd2hpY2gg
c3RhdGVkIHRoYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx
dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr
Ij5XaWRlIGJyb3dzZXIgc3VwcG9ydCBpcyBhIGdvYWwgZm9yIHRoZSBiaWRpcmVjdGlvbmFsIGNv
bW11bmljYXRpb24gbWVjaGFuaXNtLCBob3dldmVyIHRoZSBzb2x1dGlvbiBzaG91bGQgYWxzbyBi
ZSBzdWl0YWJsZQ0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6
eWVsbG93Ij5mb3IgY2xpZW50cyBvdGhlciB0aGFuIFdlYiBCcm93c2Vyczwvc3Bhbj48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj
ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm
cXVvdDs7Y29sb3I6YmxhY2siPlRoZSBXb3JraW5nIEdyb3VwIHdpbGwgd29yayB0byBzdGFuZGFy
ZGl6ZQ0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93
Ij5hIGdlbmVyaWMgc29sdXRpb248L3NwYW4+IHRoYXQgY2FuIHdvcmsgZWZmaWNpZW50bHkgaW4g
YXMgbWFueSBvZiB0aGUgZGVwbG95ZWQgZW52aXJvbm1lbnRzIGFzIHBvc3NpYmxlIGFuZCBpbiBw
YXJ0aWN1bGFyIGluIGFsbCB0aGUgZWxlbWVudHMgb2YgdGhlIHdlYiBpbmZyYXN0cnVjdHVyZSAo
ZS5nLiB3ZWIgYnJvd3NlciwNCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOnllbGxvdzttc28taGln
aGxpZ2h0OnllbGxvdyI+Z2VuZXJpYyBIVFRQIGNsaWVudDwvc3Bhbj4sIEhUVFAgc2VydmVyIGFu
ZCBIVFRQLWF3YXJlIGludGVybWVkaWFyaWVzIGxpa2UgcHJveGllcywgbG9hZCBiYWxhbmNlcnMs
IGNhY2hlcywgZXRjLikgYW5kIGl0IGlzDQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7
bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPm5vdCBzcGVjaWZpYyBmb3IganVzdCBvbmU8L3NwYW4+Ljxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250
LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6
IzFGNDk3RCI+QWxleGFuZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs
aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh
ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l
O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5G
cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFp
bHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZyI+aHliaS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBo
cmVmPSJtYWlsdG86W21haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86aHli
aS1ib3VuY2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5HYWJyaWVsIE1vbnRl
bmVncm88YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXkgMjkgTWFyY2ggMjAxMiAxMDozMjxicj4N
CjxiPlRvOjwvYj4gQXJtYW4gRGp1c3Vwb3Y7ICdKb2huIFRhbXBsaW4nPGJyPg0KPGI+Q2M6PC9i
PiA8YSBocmVmPSJtYWlsdG86aHliaUBpZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwvYT48YnI+DQo8
Yj5TdWJqZWN0OjwvYj4gW2h5YmldIFczQyBXZWJBcHBzIFdvcmtpbmcgR3JvdXAgV2ViU29ja2V0
IEFQSSAod2FzOiBSRTogTVVDOiBjaGFubmVsIElEIHNlbWFudGljcyk8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+WWVzLCBpdOKAmXMgdHJ1ZSB0aGF0IHRoZXJlIGFyZSBtYW55IEFQ
SXMsIGhvd2V2ZXIsIGZyb20gdGhlIHBvaW50IG9mIHZpZXcgb2YgdGhlIHdvcmtpbmcgZ3JvdXAg
d2UgYXJlIGNvb3JkaW5hdGluZyB3aXRoIG9ubHkgb25lIG9mIHRob3NlLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90
Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv
dDtDb3VyaWVyIE5ldyZxdW90OyI+RnJvbSBvdXIgY2hhcnRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8
c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp5ZWxsb3c7bXNvLWhpZ2hsaWdodDp5ZWxsb3ciPlRoZSBn
cm91cCB3aWxsIGNvbnRpbnVlIGNvb3JkaW5hdGluZyB3aXRoIHRoZSBXM0MgV2VwQXBwcyB3b3Jr
aW5nPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4mbmJzcDsmbmJz
cDsmbmJzcDsgZ3JvdXAgd2l0aCByZXNwZWN0IHRvIHRoZSBhYm92ZSBkZWxpdmVyYWJsZXMgYW5k
IHRvIGVuc3VyZSB0aGUgYmVzdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7O2JhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4m
bmJzcDsmbmJzcDsmbmJzcDsgbWF0Y2ggcG9zc2libGUgYmV0d2VlbiB0aGUgV2ViU29ja2V0IHBy
b3RvY29sIGFuZCB0aGUgV2ViU29ja2V0IEFQSS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPg0KPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z
ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGlzIGRvZXNu4oCZdCBwcmVjbHVkZSBhYm91dCBp
bmZvcm1hbCBkaXNjdXNzaW9uIHJlZ2FyZGluZyBvdGhlciBBUElzLCBidXQgdGhlIG9ubHkgb25l
IHRoZSBXRyBzaG91bGQgbG9zZSBzbGVlcCBvdmVyIGlzIHRoZSBhYm92ZSBhcyBpdOKAmXMgaW4g
b3VyIGNoYXJ0ZXIuIFJpZ2h0DQogbm93IHRoZSBxdWVzdGlvbiBpcyByZWxldmFudCB3aXRoIHJl
c3BlY3QgdG8gdGhlIFczQyBXZWJBcHBzIFdlYlNvY2tldCBBUEksIGJlY2F1c2UgdGhhdCB3b3Jr
aW5nIGdyb3VwIGlzIHVuZGVyZ29pbmcgcmVjaGFydGVyaW5nLCBzbyBpZiBhbnkgZnVydGhlciBj
aGFuZ2UgaXMgbmVlZGVkIHRvIHRoZSBhYm92ZSBpdCBiZWhvb3ZlcyB1cyB0byBtYWtlIHRoYXQg
Y2xlYXIgc2hvcnRseS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli
cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+U28gZmFyLCBpdCBzZWVtcyBsaWtlIHdl4oCZcmUg
ZmluZSB3aXRob3V0IGFkZGl0aW9uYWwgcmVxdWlyZW1lbnRzIG9uIHRoYXQgQVBJLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp
ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6
MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl
ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7
VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmh5
YmktYm91bmNlc0BpZXRmLm9yZyI+aHliaS1ib3VuY2VzQGlldGYub3JnPC9hPiA8YSBocmVmPSJt
YWlsdG86W21haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddIj4NClttYWlsdG86aHliaS1ib3Vu
Y2VzQGlldGYub3JnXTwvYT4gPGI+T24gQmVoYWxmIE9mIDwvYj5Bcm1hbiBEanVzdXBvdjxicj4N
CjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMjkgTWFyY2gsIDIwMTIgMDk6MDc8YnI+DQo8Yj5Ubzo8
L2I+ICdKb2huIFRhbXBsaW4nPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aHliaUBp
ZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtoeWJp
XSBNVUM6IGNoYW5uZWwgSUQgc2VtYW50aWNzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPlRoZSBKUyBBUEkgaXMganVzdCBvbmUgb2YgdGhlIEFQSXMgdGhhdCB1c2VzIHRoZSBXZWJT
b2NrZXQgcHJvdG9jb2wsIHRoZXJlIGFyZSBhbHJlYWR5IG11bHRpcGxlIEphdmEsIC5ORVQsIE1v
bm8sIFB5dGhvbiZuYnNwOyBldGMuIGNsaWVudCBhbmQgc2VydmVyIGxpYnJhcmllcyBhdmFpbGFi
bGUNCiBmb3IgV2luZG93cywgQW5kcm9pZCwgaU9TIGV0Yy4gVGhlc2Ugb2J2aW91c2x5IGhhdmUg
dGhlaXIgb3duIEFQSXMgdGhhdCBkbyBub3QgZGVwZW5kIG9uIGJyb3dzZXIgZnVuY3Rpb25hbGl0
eS4gSXQgZG9lc27igJl0IHJlYWxseSBtYXR0ZXIgd2hhdCBpcyBzdXBwb3J0ZWQgYnkgYSBwYXJ0
aWN1bGFyIEFQSSwgaXQgaXMgZmluZSBpZiB0aGF0IEFQSSBzdXBwb3J0cyBhIHN1YnNldCBvZiB0
aGUgZnVuY3Rpb25hbGl0eS4gQSBsaXR0bGUgYmFjayBKUw0KIGRpZG7igJl0IHN1cHBvcnQgYmlu
YXJ5IGRhdGEsIGJ1dCB0aGF0IGRpZG4ndCBtZWFuIHRoYXQgd2Ugc2hvdWxkbid0IGhhdmUgaW50
cm9kdWNlZCBiaW5hcnkgZnJhbWVzLiBJZiB0aGUgSlMgQVBJIGNhbm5vdCBzdXBwb3J0IHNvbWUg
c3BlY2lmaWMgZnVuY3Rpb25hbGl0eSB0aGVuIGxldCBpdCBub3QsIGJ1dCB0aGlzIGZ1bmN0aW9u
YWxpdHkgc2hvdWxkIGJlIGF2YWlsYWJsZSB0byBvdGhlciBwbGF0Zm9ybXMuPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1
b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx
dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5X
aXRoIHJlc3BlY3QsIEkgZG9u4oCZdCBhZ3JlZSB0aGF0IHdlIHNob3VsZCBsb29rIGF0IGFueSBX
ZWJTb2NrZXQgcmVsYXRlZCBzcGVjcyB1c2luZyBvbmx5IOKAnENocm9tZSB0byBHb29nbGUgc2Vy
dmVyIHBvb2zigJ0gcG9pbnQgb2Ygdmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom
cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm
cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldpdGggYmVzdCByZWdhcmRzLDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu
cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Bcm1hbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp
JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt
c2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+
IEpvaG4gVGFtcGxpbg0KPGEgaHJlZj0ibWFpbHRvOlttYWlsdG86amF0QGdvb2dsZS5jb21dIj5b
bWFpbHRvOmphdEBnb29nbGUuY29tXTwvYT4gPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg
TWFyY2ggMjgsIDIwMTIgOTowOSBQTTxicj4NCjxiPlRvOjwvYj4gR2FicmllbCBNb250ZW5lZ3Jv
PGJyPg0KPGI+Q2M6PC9iPiBBcm1hbiBEanVzdXBvdjsgPGEgaHJlZj0ibWFpbHRvOmh5YmlAaWV0
Zi5vcmciPmh5YmlAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0g
TVVDOiBjaGFubmVsIElEIHNlbWFudGljczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPk9uIFdlZCwgTWFyIDI4LCAyMDEyIGF0IDExOjUwIEFNLCBHYWJyaWVsIE1vbnRlbmVn
cm8gJmx0OzxhIGhyZWY9Im1haWx0bzpHYWJyaWVsLk1vbnRlbmVncm9AbWljcm9zb2Z0LmNvbSI+
R2FicmllbC5Nb250ZW5lZ3JvQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw
PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh
bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgYW55Ym9keSBmZWVscyBzdHJvbmdseSB0
aGF0IHRoZXJlIGlzIGFueSBBUEkgaW1wYWN0IG9mIGVpdGhlciB0aGUgbXV4IG9yIGNvbXByZXNz
aW9uLCBwbGVhc2Ugc3VwcG9ydA0KIHN1Y2ggY2xhaW1zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRo
ZXJlIHNob3VsZCBub3QgYmUgYXQgdGhpcyBwb2ludCwgaW4gZWl0aGVyIG9uZSAtLSB3aGljaCBt
ZWFucyB0aGF0IEkgdGhpbmsgZXhwb3NpbmcgdGhlIGV4aXN0aW5nIG9mIE1VWCBjaGFubmVscyAo
aW5jbHVkaW5nIGJlaW5nIGFibGUgdG8gb3BlbiBtdWx0aXBsZSBhdCBhIHRpbWUpIHNob3VsZCBi
ZSBvZmYgdGhlIHRhYmxlIGF0IHRoaXMgcG9pbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIHRoZSBsb25nIHRlcm0sIEkgc3VzcGVjdCB3
ZSBtYXkgd2FudCB0byBhbHRlciB0aGUgQVBJIHRvIGxldCB0aGUgYXBwbGljYXRpb24gaGF2ZSBi
ZXR0ZXIgY29udHJvbCBvdmVyIGNvbXByZXNzaW9uLCBidXQgSSBkb24ndCB0aGluayB3ZSB3YW50
IHRvIGRvIHRoYXQgdW50aWwgd2UgaGF2ZSBtb3JlIGV4cGVyaWVuY2UgYWJvdXQgZXhhY3RseSB3
aGF0IGlzIHVzZWZ1bC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPi0tIDxicj4NCkpvaG4gQS4gVGFtcGxpbjxicj4NClNvZnR3YXJlIEVuZ2lu
ZWVyIChHV1QpLCBHb29nbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147F5C50CTK5EX14MBXW602w_--

From jat@google.com  Thu Mar 29 08:52:19 2012
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 A2F7521E8088 for ; Thu, 29 Mar 2012 08:52:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.964
X-Spam-Level: 
X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7c4meaSGVaWr for ; Thu, 29 Mar 2012 08:52:18 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7DC21F8817 for ; Thu, 29 Mar 2012 08:52:18 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1825501vbb.31 for ; Thu, 29 Mar 2012 08:52:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=mvW4dWXbln54JBTx13kecbHoJHRyKN1CLcv023t9gYw=; b=PMZA81RrQP73x10TKf01AWroMUAsNLHH/cnlGEut1XQc7qWBBncbLUQIAh0ReOwNng JxAIrAjTnfIXVfOFh0iVVFFfXZqms7+rJQcOsD6TP2vEclqchVpoCKo2dYU5y3B2JE0H nXFP78uFwwEhgO228TvUh5o4jvvhKMzhh1BgegNnjTUv48nv+gafQTnHmTKB8Xfck/zO 8GseHfWdCX6CmowYZWfDn9DtVMwfNQrYd7ixVS37Q1sO8wkPnqZH2VvzG6/SUUpyK1EE eHelWv8+0pzTnK1PJ1klyW5SoXcZWU0nU93gaWzM65WyEXhEzZL+MHNmf6e8fMyCa8Wr y0SQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=mvW4dWXbln54JBTx13kecbHoJHRyKN1CLcv023t9gYw=; b=abreEAHKruEsMaViNsm1bcLqOKDTar162mPz99y6Nuy3GJyDxGz++MavAa5lW/WkJC HyWww4G6Mn/w4mGhSLINtWJiO2/hIe6BhVnS88+7AivAIUi8H6w2HNRVWOYfE63WAoUh mCIRfJ3Ll9/ko5DxKFTkr7sFJiNCzu7ulI8g7XTeYjxOrl05L/gefiezUguJnKAxgDSH SVKEAGLiZHgBg2uny/1p7Qa7aTNcKbDWwatBgmMqd9qLBKJCHffkV1kINHoqMz9vi7s2 Sst/3UL2cstoJh/pPvK8KjaX7pYJwmJZ8TZGVPOBdExFVTs9qYfSDNWjDz8FqKCdbmw2 dtFw==
Received: by 10.220.156.72 with SMTP id v8mr4153123vcw.45.1333036337900; Thu, 29 Mar 2012 08:52:17 -0700 (PDT)
Received: by 10.220.156.72 with SMTP id v8mr4153115vcw.45.1333036337803; Thu, 29 Mar 2012 08:52:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.17.193 with HTTP; Thu, 29 Mar 2012 08:51:57 -0700 (PDT)
In-Reply-To: 
References:  
From: John Tamplin 
Date: Thu, 29 Mar 2012 11:51:57 -0400
Message-ID: 
To: Takeshi Yoshino 
Content-Type: multipart/alternative; boundary=f46d043c7fb26333a204bc63b54b
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlFq17uXN2O9UZmzm+EzqSab+WMMf4I4I0+pRSl+UtGeF1WdLEcBPUo8tZDK9tTY+gU5/ptmSVOq7OcbHQWMdwp/cKsVb7JdGQ0E2cY6sessBlxEATqNWGvj095yaotDkR+dDBK
Cc: hybi@ietf.org
Subject: Re: [hybi] Channel ID encoding of multiplexing extension
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, 29 Mar 2012 15:52:19 -0000

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

On Thu, Mar 29, 2012 at 4:05 AM, Takeshi Yoshino wrote:

> And, John, could you provide some text to explain reasoning to choose this
> encoding which we can put in the spec?
>
> Data / thoughts on the expected distribution of the number of concurrent
> logical channels are also welcome.
>

The idea was simply that many uses would require a small number of
channels, so we wanted a variable-length encoding that made that case as
efficient as possible.  For the upper end, it wasn't clear how many to
support, but with a variable encoding supporting much higher channel ids
has only a tiny cost, as it will likely be represented as a 32-bit int in
implementations anyway.  IIRC, SPDY only supports 4096 channels and I have
no information about how often that became a limitation, but my guess would
be very rare.

Regarding a new variable-length encoding, I initially planned on using the
same length encoding as frame lengths, but I couldn't think of a use for
the unused bit and it has a steep jump when going from 125 channels to 126
channels (1->3 bytes overhead) -- that is a range which seems likely to
achieve in browsers with lots of open tabs, each containing independent
modules with their own connections.

If others would prefer a different encoding, I have no objection.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Thu, Mar 29, 2012 at 4:05 AM, Takeshi Yoshino=
 <tyoshino@goog=
le.com> wrote:


And, John, could you provide some text to explain reasoning to choose this =
encoding which we can put in the spec?

Data / thoughts o=
n the expected distribution of the number of concurrent logical channels ar=
e also welcome.





The idea was simply that many uses would require a s=
mall number of channels, so we wanted a variable-length encoding that made =
that case as efficient as possible. =C2=A0For the upper end, it wasn't =
clear how many to support, but with a variable encoding supporting much hig=
her channel ids has only a tiny cost, as it will likely be represented as a=
 32-bit int in implementations anyway. =C2=A0IIRC, SPDY only supports 4096 =
channels and I have no information about how often that became a limitation=
, but my guess would be very rare.



Regarding a new variable-length encoding, I initially planne=
d on using the same length encoding as frame lengths, but I couldn't th=
ink of a use for the unused bit and it has a steep jump when going from 125=
 channels to 126 channels (1->3 bytes overhead) -- that is a range which=
 seems likely to achieve in browsers with lots of open tabs, each containin=
g independent modules with their own connections.




If others would prefer a different encoding, I have no =
objection.

-- 
John A. Tamplin
Softwa=
re Engineer (GWT), Google




--f46d043c7fb26333a204bc63b54b--

From jat@google.com  Thu Mar 29 08:56:33 2012
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 D00EB21E81FC for ; Thu, 29 Mar 2012 08:56:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.964
X-Spam-Level: 
X-Spam-Status: No, score=-102.964 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDmTBIt9rcp8 for ; Thu, 29 Mar 2012 08:56:33 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB80321E81F0 for ; Thu, 29 Mar 2012 08:56:32 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1829195vbb.31 for ; Thu, 29 Mar 2012 08:56:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=2PQi4vo4m/5QFtg8lZOm66gi5h2zcB5Dr2UpkMBoieo=; b=hd8Pq/KBOscUj/wyE3untwrolFM7yzd5HT0446tBCmL9tvV6qDhMsusAF80Dqu9sMp VsPvIR4//uiykfk4XpwdZ9oup1fRozi1faAV60N6nf9GsQEhAMdZwb1+Z0kfarqI121R S0uH1yldTup7GIvMAb7jU8cUUhiLJ9JN2gKxzAyD4Y+ewgimO90zkEbo9iUmMt33IqG/ nexIubCv8oq2CGitk/ea4o7h+TmznMUvkL9r9Y8y0X4wgh23iuld6GKb5M1iFSmext1G 9jfVu0yc8iyZW+UWZF8J7z/14BH6nx/6Qr0ydYZ4ixpTlKL+EOhO/2+WkFySUHuxe7ok p6TA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=2PQi4vo4m/5QFtg8lZOm66gi5h2zcB5Dr2UpkMBoieo=; b=JXS/Y/dsMWVkAapC9Q27CW/IOiuAXScQv0Y3uslQFbKMbhtRUgUgLWdliUM3ofvWf+ W8dYl73Md7JM7CcecS0h/BlTczZaQb/jeuztBkRLKw5NkqTHwMyXCn5ip3QzflnLl4lq RpSdkagwibVF/Nu1w6hKly+st4LjIVvnEJGweVdRG663WnKiR4tf+hwIXNWrhkajKNUR XQ60EKiiLNkfabr8D3KWwMi3iVWa6N9/NKAhpLCFMDzQ2mbSh0h+73HfexkX0rkBVwKI 9FxVOL+1swH7vIoczUD1ri/vHcOyAnUQmKn5ZmFAZEzsp786ntgEsTN+JOUW5KOdJSMl oG/A==
Received: by 10.220.228.200 with SMTP id jf8mr16227959vcb.0.1333036592371; Thu, 29 Mar 2012 08:56:32 -0700 (PDT)
Received: by 10.220.228.200 with SMTP id jf8mr16227947vcb.0.1333036592265; Thu, 29 Mar 2012 08:56:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.17.193 with HTTP; Thu, 29 Mar 2012 08:56:12 -0700 (PDT)
In-Reply-To: 
References: 
From: John Tamplin 
Date: Thu, 29 Mar 2012 11:56:12 -0400
Message-ID: 
To: Takeshi Yoshino 
Content-Type: multipart/alternative; boundary=14dae9cdc0f98df94704bc63c443
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQlTvmkchEi2UXqlZnErwVczkUdP//CPSMldzcBMVQfqVZ9eMjIM+/Zj4BbMbP8AGxms9cHfIhKV+kaqbpp6OM1Qys6+e6GKLwwn1KGBvzn2pi4lo7sH3Puxw78Px86PgGDex6qe
Cc: "hybi@ietf.org" , Gabriel Montenegro 
Subject: Re: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics)
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, 29 Mar 2012 15:56:34 -0000

--14dae9cdc0f98df94704bc63c443
Content-Type: text/plain; charset=UTF-8

On Thu, Mar 29, 2012 at 3:34 AM, Takeshi Yoshino wrote:

> Not the issue discussed in the f2f meeting, but I'm sure that introduction
> of extensions we're now working on impacts extensions attribute of the
> WebSocket API.
>
> 1. the API must define in what form it exports _Extensions In Use_. What
> to include (just token? parameters together?), formatting, etc.
>

Ah, I wasn't aware they added that.  Making WeSocket.extensions be a
DOMString seems like a poor idea, as you now have to encode the list of
extensions (possibly with their parameters) into a string, and the JS will
have to decode it.  It seems making it return a list of objects with
defined properties would be much better.


> 2. under use of the multiplexing extension, Sec-WebSocket-Extensions
> header will contain both extensions applied to physical channel and logical
> channels. We must figure out what should be exported from this mixture and
> which side should do such transformation if any by coordinating with
> webapps WG.
>

Since the WebSocket object in the browser may be a physical or logical
channel and applications shouldn't know the difference, it seems to me that
the extensions have to be that of the logical channel in the mux case.

-- 
John A. Tamplin
Software Engineer (GWT), Google

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


On Thu, Mar 29, 2012 at 3:34 AM, Takeshi Yoshino=
 <tyoshino@goog=
le.com> wrote:



Not the issue discussed in the f2f meeting, but I'm sure that intr=
oduction of extensions we're now working on impacts extensions attribut=
e of the WebSocket API.

1. the API must define in =
what form it exports _Extensions In Use_. What to include (just token? para=
meters together?), formatting, etc.




Ah, I wasn't aware they added that. =
=C2=A0Making WeSocket.extensions be a DOMString seems like a poor idea, as =
you now have to encode the list of extensions (possibly with their paramete=
rs) into a string, and the JS will have to decode it. =C2=A0It seems making=
 it return a list of objects with defined properties would be much better.<=
/div>


=C2=A0


2. under use of the multiplexing extension, Sec-WebSocket-Extensions h=
eader will contain both extensions applied to physical channel and logical =
channels. We must figure out what should be exported from this mixture and =
which side should do such transformation if any by coordinating with webapp=
s WG.




Since the WebSocket object in the browser =
may be a physical or logical channel and applications shouldn't know th=
e difference, it seems to me that the extensions have to be that of the log=
ical channel in the mux case.=C2=A0




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--14dae9cdc0f98df94704bc63c443--

From jat@google.com  Thu Mar 29 09:04:00 2012
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 D3F0621E816B for ; Thu, 29 Mar 2012 09:04:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.965
X-Spam-Level: 
X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWPERPfuf05T for ; Thu, 29 Mar 2012 09:04:00 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E2F4921E819D for ; Thu, 29 Mar 2012 09:03:59 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so1835904vbb.31 for ; Thu, 29 Mar 2012 09:03:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=RzqiXe/DJ1oZFkTDdzwvndXsC1V9eRkwElEkocynO6k=; b=GGh4Urz0iQwRb+n7zua6XyYTgF2xgAhJRPtevKypwfDI93Rl7ng4AKbpG1/ZVKVTGx 9RN6DLfLcN7WYUx1jch6hlsUY4SI3FweEPlVa1NJrYQ+K6AxWMqA9tVE5sW1tbhgPJvs 7aFd8OkYX+h8c5GzJdh2mAmmKCroOrJ4XtgWgXTmXWqyHkeclGJyySTseEzNfMgROLja D5zZZIq8mWbUvqsy+Echl4oTZxNEVT86ySvZ/PUiOCbWoZZfGxTWVwI/SYe8H0ZdNAq6 rHM9TjOWr3VkxvndfooNDtIRfReVNcBJs7Ei2hFGpn7helJRMGIg2LrxHpW3bjlFHvFY otyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=RzqiXe/DJ1oZFkTDdzwvndXsC1V9eRkwElEkocynO6k=; b=DBdiI7j1leKx/xXK4SFjV4kAVkNgHtxvD35B7htu7gA1DgKwYjScWXr1dYI2d1uXC2 eDEhKnkTAYIMxx9tbk5IQ8q0oV0lXwqCR/HXa68+Ql7CsivGjV+S5wR+eCsmdIunRPLr yW+l2/OY2nfozA+14aUCFIQkD8M+pWsWftX+nj0lTWwep4wccppTaB4GmxAOWXhJLaTM UnDhSuAOQTfpF8SCxnZBzWBZimANMIhMiixqER25qZhpD6fxBc0MFj1XVbnMWMqDdBsA hvqHJMZfbX6vvhi+uNUWfbHaKyiGGewaMTCqm3bqdgiiD0FSiRurPIqBqzobhMqUixzv SlWA==
Received: by 10.52.28.134 with SMTP id b6mr996755vdh.130.1333037039461; Thu, 29 Mar 2012 09:03:59 -0700 (PDT)
Received: by 10.52.28.134 with SMTP id b6mr996745vdh.130.1333037039310; Thu, 29 Mar 2012 09:03:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.17.193 with HTTP; Thu, 29 Mar 2012 09:03:39 -0700 (PDT)
In-Reply-To: <000501cd0d7a$991dca50$cb595ef0$@noemax.com>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>    <000501cd0d7a$991dca50$cb595ef0$@noemax.com>
From: John Tamplin 
Date: Thu, 29 Mar 2012 12:03:39 -0400
Message-ID: 
To: Arman Djusupov 
Content-Type: multipart/alternative; boundary=20cf307cfdca33568604bc63dffc
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQm3v+FriHZ/LG2lzHZ55VPx/7HC9kHbbhPGWIMzfXSJhEtvaqY0bvgvpZrzEOg/dNGlAsHjs8b07/zYnoAY3c6d/oUOufhS+xbBGCvO9EECUU615FTtwY3bZTKFIrKt0Y7DcxXH
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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, 29 Mar 2012 16:04:00 -0000

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

On Thu, Mar 29, 2012 at 3:07 AM, Arman Djusupov  wrote:

> The JS API is just one of the APIs that uses the WebSocket protocol, ther=
e
> are already multiple Java, .NET, Mono, Python  etc. client and server
> libraries available for Windows, Android, iOS etc. These obviously have
> their own APIs that do not depend on browser functionality. It doesn=E2=
=80=99t
> really matter what is supported by a particular API, it is fine if that A=
PI
> supports a subset of the functionality. A little back JS didn=E2=80=99t s=
upport
> binary data, but that didn't mean that we shouldn't have introduced binar=
y
> frames. If the JS API cannot support some specific functionality then let
> it not, but this functionality should be available to other platforms.
>

If you don't have the limitations of the browser (ie, it may be executing
attacker-controlled code behind a firewall), I am not sure why you would
choose to use WebSockets over other options.

Assuming you do, I still don't think you want to expose the internals of
mux channels to that API -- instead, the client should create a connection
and if that happens to be muxed over an already-established connection then
great, and if not great.


> **
>
> With respect, I don=E2=80=99t agree that we should look at any WebSocket =
related
> specs using only =E2=80=9CChrome to Google server pool=E2=80=9D point of =
view.
>

Clearly many of the requirements that fed into the design of WebSockets
came from the browser context where the origination of the WS connection
may be from hostile code, but it clearly isn't Chrome or Google specific.
 In fact if you look at my posts about mux in the past, you will see that I
have pushed for scenarios like a mobile carrier or business deploying an
intermediary mux between their clients and the ultimate servers.

--=20
John A. Tamplin
Software Engineer (GWT), Google

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


On Thu, Mar 29, 2012 at 3:07 AM, Arman Djusupov =
<arman@noemax.com<=
/a>> wrote:



<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif";color:#1f497d">The JS API is just one of the APIs that uses the =
WebSocket protocol, there are already multiple Java, .NET, Mono, Python=C2=
=A0 etc. client and server libraries available for Windows, Android, iOS et=
c. These obviously have their own APIs that do not depend on browser functi=
onality. It doesn=E2=80=99t really matter what is supported by a particular=
 API, it is fine if that API supports a subset of the functionality. A litt=
le back JS didn=E2=80=99t support binary data, but that didn't mean tha=
t we shouldn't have introduced binary frames. If the JS API cannot supp=
ort some specific functionality then let it not, but this functionality sho=
uld be available to other platforms.=C2=A0




If you don't have the limitation=
s of the browser (ie, it may be executing attacker-controlled code behind a=
 firewall), I am not sure why you would choose to use WebSockets over other=
 options.




Assuming you do, I still don't think you want to ex=
pose the internals of mux channels to that API -- instead, the client shoul=
d create a connection and if that happens to be muxed over an already-estab=
lished connection then great, and if not great.



=C2=A0



With respect, I don=E2=80=
=99t agree that we should look at any WebSocket related specs using only =
=E2=80=9CChrome to Google server pool=E2=80=9D point of view.




Clearly many of the requiremen=
ts that fed into the design of WebSockets came from the browser context whe=
re the origination of the WS connection may be from hostile code, but it cl=
early isn't Chrome or Google specific. =C2=A0In fact if you look at my =
posts about mux in the past, you will see that I have pushed for scenarios =
like a mobile carrier or business deploying an intermediary mux between the=
ir clients and the ultimate servers.




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--20cf307cfdca33568604bc63dffc--

From tobias.oberstein@tavendo.de  Thu Mar 29 09:21:51 2012
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 C98AB21E8252 for ; Thu, 29 Mar 2012 09:21:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.937
X-Spam-Level: 
X-Spam-Status: No, score=-2.937 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7xanw0Qcnu8 for ; Thu, 29 Mar 2012 09:21:48 -0700 (PDT)
Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE6F21E8251 for ; Thu, 29 Mar 2012 09:21:48 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.68]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Thu, 29 Mar 2012 09:21:47 -0700
From: Tobias Oberstein 
To: Willy Tarreau , Roberto Peon 
Date: Thu, 29 Mar 2012 09:21:45 -0700
Thread-Topic: [hybi] Keep-Alive analysis
Thread-Index: Ac0NiYzz1KVyCRpbTHOXy7C8Hj1zpAAPkF6w
Message-ID: <634914A010D0B943A035D226786325D42D5D0FE7F3@EXVMBX020-12.exch020.serverdata.net>
References:  <634914A010D0B943A035D226786325D42D5D0FE611@EXVMBX020-12.exch020.serverdata.net>  <634914A010D0B943A035D226786325D42D5D0FE612@EXVMBX020-12.exch020.serverdata.net>  <20120329085412.GA4052@1wt.eu>
In-Reply-To: <20120329085412.GA4052@1wt.eu>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Keep-Alive analysis
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, 29 Mar 2012 16:21:52 -0000

> > It is all tradeoffs. For some applications, perhaps the  increased
> > signaling cost, bandwidth cost, cpu cost, and battery-life cost is a
> > reasonable tradeoff. At least until the carrier attempts to ban the
> > application and/or charge you for it :)
>=20
> The problem is that in an ideal world we'd like the application to commun=
icate
> QoS preferences to the upper layers (including the OS).
>=20
> There should be a lot of thinking done around mobile-specific usages and
> tradeoffs I think, as these are not specific to websocket.

I did some experiments.

On the HSPA network I use, I need 4kb/s traffic to keep the radio in fully =
active,
low-latency HSPA DCH state. Lower rates won't cut it. Payload is WS Ping/Po=
ng.

http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/1083.html



From gregw@intalio.com  Thu Mar 29 17:34:08 2012
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 664DE21F8687 for ; Thu, 29 Mar 2012 17:34:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.832
X-Spam-Level: 
X-Spam-Status: No, score=-2.832 tagged_above=-999 required=5 tests=[AWL=0.145,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JJNBDukM8hbh for ; Thu, 29 Mar 2012 17:34:07 -0700 (PDT)
Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id BD6EE21F8686 for ; Thu, 29 Mar 2012 17:34:07 -0700 (PDT)
Received: by qaea16 with SMTP id a16so88708qae.10 for ; Thu, 29 Mar 2012 17:34:07 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type:content-transfer-encoding; bh=vB797Ux/+mOMHApcGypi/aNp6Xz1eGAUTe59F/k75Kk=; b=VN84UY6nMDc6r57AXo4PCLeL8/J63+jICKnsNZWTmjYu6IibV1TjiPOl5iTeSZmfER S/mqdCxXH+4sIb4c1E5GGTsNhkFJyQrTHP5Zr1UkNe9PoWKzXLIVzFmSzKcqAIOQ7vRi FO4M7jhYaM0anLHHSvwM2e5zR9HEsbst46sgpaP3tM+n58yyo4tzi9LPhy8R2W7MevzJ mnLpvwxqNf5TU5GWzvMEv5Etj6lEmFo2kd5z0yWEUJ8FMQdeAcgkVSmBDIt+eAfkUQZZ OGptH0zfuzV5zSC4HPKNsGsbRzllcNC+D2RwVv9cjKRtGa+fdo6+E6Jfp1I/szddVwPh pelQ==
MIME-Version: 1.0
Received: by 10.229.77.15 with SMTP id e15mr76286qck.66.1333067647185; Thu, 29 Mar 2012 17:34:07 -0700 (PDT)
Received: by 10.229.249.18 with HTTP; Thu, 29 Mar 2012 17:34:06 -0700 (PDT)
In-Reply-To: 
References: 
Date: Fri, 30 Mar 2012 11:34:06 +1100
Message-ID: 
From: Greg Wilkins 
To: Martin Thomson 
X-Gm-Message-State: ALoCoQmkeABGt7EPIjlZX+kFeCTtjzfShHCkOypluQg4lCPwPd4cZ24I0+6+C2p+lHVWEz0RwppC
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: hybi@ietf.org, Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 30 Mar 2012 00:34:08 -0000

On 29 March 2012 16:21, Martin Thomson  wrote:
>
> One conclusion that I've reached is that sending a Keep-Alive header
> from a client is actually more wasteful than helpful. =A0It's actually
> the server policy that is most useful. =A0A client is usually
> constrained more by the needs of the application than by any sort of
> resource management during active operation. =A0The server, in a passive
> role, really doesn't benefit from knowledge about client policies.
> It's the client - in periods of idleness - that is most affected by
> the indeterminate state of the connection.


The way that I think about it, is that the client is the entity that
best knows if a connection should be persisted or not.  It knows if
the chat room is open or if the portfolio is displayed, and thus it
knows if the UI is still interested in receiving updates, not matter
how infrequent they may be.  The problem is that the client does not
know what it has to do to keep itself in the connected state and I
agree that the client sending a keep-alive;timeout=3Dx header does not
help.   It does not tell the server if the client wants to keep the
connection open to stay in a connected state, or if it is simply
suggesting a time in which it might use the connection again.

In the HTTP scenario, I think a client sending keep-alive;max=3Dy  can
be useful, as it can tell the server if the client is interested in
persisting the  connection or not, but I think connection:close on the
last request also provides that capability.  I can see how ;max can be
applied to WS.

So I agree that the real value is in the keep alive message from the
server to the client.  This tells the client something concrete that
it can take action about.  If the application wants to stay connected,
then it must at least send some data (message or ping) as frequently
as indicated in the servers keepalive.

Although, we must remember that keep-alive is hop by hop, so it is not
so much the servers keep-alive, but a keep-alives sent from the
direction of the server towards the client.

cheers

From martin.thomson@gmail.com  Fri Mar 30 00:54:23 2012
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 6D0B921F8802 for ; Fri, 30 Mar 2012 00:54:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.71
X-Spam-Level: 
X-Spam-Status: No, score=-4.71 tagged_above=-999 required=5 tests=[AWL=-1.111,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edo1B2HIzNfu for ; Fri, 30 Mar 2012 00:54:23 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id E447021F87FF for ; Fri, 30 Mar 2012 00:54:22 -0700 (PDT)
Received: by obbta17 with SMTP id ta17so710835obb.31 for ; Fri, 30 Mar 2012 00:54:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dMKJJppmZPqKBKapmkAFoaU/ATodM0OGe1tIxC0bdyQ=; b=gR8VI6CcV1rZh0PvSbSj4IEvJvzPJ43UZhkBh3vB7sYhue/9u5fD9fDVGxSpsWDaEy 6qYG962WpLaEczwFeS33VTrzMvi5CgFiBzA9vPXFwY3H/8s+yfOHQcO+5ZUaSerDrAQ/ 0rvW1OXKBjOw+17UzGTaKNCiCRPWLiC60rK5D2N5f1U51XrqeBnR4uJDfhO5JEzwym+x VChAu18D59CD/AKY3o/pizqzAcvuq9wi+xp6FzhNGtHsv9ducZfhEMcBWwF+jcOOvO66 EAZxymeUIDMxi7PNcKj3kwvBhkj82svA8MGdhVDfuxxNiDVPBYgoYoSB05B/fDzftFWF ZacA==
MIME-Version: 1.0
Received: by 10.182.53.106 with SMTP id a10mr1280735obp.43.1333094062583; Fri, 30 Mar 2012 00:54:22 -0700 (PDT)
Received: by 10.60.34.67 with HTTP; Fri, 30 Mar 2012 00:54:22 -0700 (PDT)
In-Reply-To: 
References:  
Date: Fri, 30 Mar 2012 09:54:22 +0200
Message-ID: 
From: Martin Thomson 
To: Greg Wilkins 
Content-Type: text/plain; charset=UTF-8
Cc: hybi@ietf.org, Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 30 Mar 2012 07:54:23 -0000

On 30 March 2012 02:34, Greg Wilkins  wrote:
> The way that I think about it, is that the client is the entity that
> best knows if a connection should be persisted or not.

That's the key.  As we've seen, some clients do some borderline
lunatic things to meet their goals, and better information can help
them recognize when they can do less than completely bat-guano.

> I can see how ;max can be applied to WS.

Can you elaborate, or did you mean "can't"?

> Although, we must remember that keep-alive is hop by hop, so it is not
> so much the servers keep-alive, but a keep-alives sent from the
> direction of the server towards the client.

Yeah, good point.  To be perfectly clear, the word "server" as I have
used it in this discussion applies to the serving end of the
_connection_, not the request.

--Martin

From tobias.oberstein@tavendo.de  Fri Mar 30 01:32:24 2012
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 2DBB021F873E for ; Fri, 30 Mar 2012 01:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.824
X-Spam-Level: 
X-Spam-Status: No, score=-3.824 tagged_above=-999 required=5 tests=[AWL=-1.225, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHuJNCzY7zHt for ; Fri, 30 Mar 2012 01:32:22 -0700 (PDT)
Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id A91B521F8730 for ; Fri, 30 Mar 2012 01:32:22 -0700 (PDT)
Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.68]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Fri, 30 Mar 2012 01:32:21 -0700
From: Tobias Oberstein 
To: Greg Wilkins , Martin Thomson 
Date: Fri, 30 Mar 2012 01:32:15 -0700
Thread-Topic: [hybi] Keep-Alive analysis
Thread-Index: Ac0ODNU2geI2QnuKSL6PkJpOcYbyggAQZcBg
Message-ID: <634914A010D0B943A035D226786325D42D5D0FEAF7@EXVMBX020-12.exch020.serverdata.net>
References:  
In-Reply-To: 
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: de-DE, en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "hybi@ietf.org" , Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 30 Mar 2012 08:32:24 -0000

> The way that I think about it, is that the client is the entity that best=
 knows if a
> connection should be persisted or not.  It knows if the chat room is open=
 or if

Tend to agree. Keeping a connection alive, and in some use cases not only a=
live,
but in a low-latency state, is something the client should control.

Even when that does not only mean consuming resources on the client, but
also on the network and server side. In a user-centric world, the user shou=
ld
be in control.

At least for HSPA connections, keeping a connection in low-latency state se=
ems
to involve hacks, lack of optimized radio states and device APIs.

Imagine a mobile 2 player Memory-like game. Messaging volume is very small,
but if there is a message, it needs to be low-latency.

It's an example where the client not only wants to keep a connection alive,=
 but
more so in a low-latency state.


From w@1wt.eu  Fri Mar 30 02:19:24 2012
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 21A8E21F8666 for ; Fri, 30 Mar 2012 02:19:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.112
X-Spam-Level: 
X-Spam-Status: No, score=-5.112 tagged_above=-999 required=5 tests=[AWL=-3.069, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Gn1Nx0aepDi for ; Fri, 30 Mar 2012 02:19:23 -0700 (PDT)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4D7FC21F879A for ; Fri, 30 Mar 2012 02:19:21 -0700 (PDT)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q2U9JIfr012069; Fri, 30 Mar 2012 11:19:18 +0200
Date: Fri, 30 Mar 2012 11:19:18 +0200
From: Willy Tarreau 
To: Martin Thomson 
Message-ID: <20120330091918.GB12047@1wt.eu>
References:   
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.4.2.3i
Cc: hybi@ietf.org, Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 30 Mar 2012 09:19:24 -0000

On Fri, Mar 30, 2012 at 09:54:22AM +0200, Martin Thomson wrote:
> On 30 March 2012 02:34, Greg Wilkins  wrote:
> > Although, we must remember that keep-alive is hop by hop, so it is not
> > so much the servers keep-alive, but a keep-alives sent from the
> > direction of the server towards the client.
> 
> Yeah, good point.  To be perfectly clear, the word "server" as I have
> used it in this discussion applies to the serving end of the
> _connection_, not the request.

That's my point too, so I think we're all in line :-)

Willy


From grmocg@gmail.com  Fri Mar 30 02:52:58 2012
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 57D6B21F88E4 for ; Fri, 30 Mar 2012 02:52:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.898
X-Spam-Level: 
X-Spam-Status: No, score=-5.898 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8d2KaFolsNY for ; Fri, 30 Mar 2012 02:52:52 -0700 (PDT)
Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 883E621F8701 for ; Fri, 30 Mar 2012 02:52:52 -0700 (PDT)
Received: by obbta17 with SMTP id ta17so883167obb.31 for ; Fri, 30 Mar 2012 02:52:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vHmKBGHvvZRVH4Jyzw/fAoIbit+LfUWPDIqXsQOKS0U=; b=b3BT4O+UzrEFOL5yuXcL7Yh719JHcqo6JtKfid+McYiXFtr+Qbqt95zB/RD+Hwd4yu hfKsSc3UyIZ/jngUH6Uf4l8XxYooBXCK5HbWcFEomhQviv+R2y6tPwWbqz8gyteucvtT l2xWj11N7cK+sgNMKaR8yQuoDLK6OMRYzXtT4PTGDGCJglH6H4Voi5mtoFdCwWYBNqw5 Jr6mhQp5Wtm2By6HZqEi5XQXm8w8Q8z+tf1xZRdklQWQEweuHvR4a87AZVVx3+gFgtyf UP7phcz1MW0p0ypoIcWy+orwstv9zlPYqg78JGE8no++eZjClJHKlXU/gsYlV/CdW2Dj oYow==
MIME-Version: 1.0
Received: by 10.182.147.99 with SMTP id tj3mr1759845obb.40.1333101172211; Fri, 30 Mar 2012 02:52:52 -0700 (PDT)
Received: by 10.182.109.102 with HTTP; Fri, 30 Mar 2012 02:52:52 -0700 (PDT)
In-Reply-To: <20120330091918.GB12047@1wt.eu>
References:    <20120330091918.GB12047@1wt.eu>
Date: Fri, 30 Mar 2012 11:52:52 +0200
Message-ID: 
From: Roberto Peon 
To: Willy Tarreau 
Content-Type: multipart/alternative; boundary=f46d044473c9d1bf1f04bc72cd71
X-Mailman-Approved-At: Fri, 30 Mar 2012 02:55:14 -0700
Cc: hybi@ietf.org
Subject: Re: [hybi] Keep-Alive analysis
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, 30 Mar 2012 09:52:58 -0000

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

yup

On Fri, Mar 30, 2012 at 11:19 AM, Willy Tarreau  wrote:

> On Fri, Mar 30, 2012 at 09:54:22AM +0200, Martin Thomson wrote:
> > On 30 March 2012 02:34, Greg Wilkins  wrote:
> > > Although, we must remember that keep-alive is hop by hop, so it is not
> > > so much the servers keep-alive, but a keep-alives sent from the
> > > direction of the server towards the client.
> >
> > Yeah, good point.  To be perfectly clear, the word "server" as I have
> > used it in this discussion applies to the serving end of the
> > _connection_, not the request.
>
> That's my point too, so I think we're all in line :-)
>
> Willy
>
>

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

yup

On Fri, Mar 30, 2012 at 11:19 AM, Wil=
ly Tarreau <w@1wt.eu&g=
t; wrote:


On Fri, Mar 30, 2012 at 09:54:22AM +0200, Martin Thomson =
wrote:

> On 30 March 2012 02:34, Greg Wilkins <gregw@intalio.com> wrote:


> > Although, we must remember that keep-aliv=
e is hop by hop, so it is not

> > so much the servers keep-alive, but a keep-alives sent from the
> > direction of the server towards the client.

>

> Yeah, good point. =A0To be perfectly clear, the word "server"=
; as I have

> used it in this discussion applies to the serving end of the

> _connection_, not the request.




That's my point too, so I think we're all in line :-)



Willy







--f46d044473c9d1bf1f04bc72cd71--

From arman@noemax.com  Fri Mar 30 04:42:18 2012
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 2DC7621F86C2 for ; Fri, 30 Mar 2012 04:42:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=0.153,  BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoilM9QbthcZ for ; Fri, 30 Mar 2012 04:42:17 -0700 (PDT)
Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3B41B21F869C for ; Fri, 30 Mar 2012 04:42:15 -0700 (PDT)
Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id OOU24518; Fri, 30 Mar 2012 14:42:18 +0300
From: "Arman Djusupov" 
To: "'John Tamplin'" 
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>    <000501cd0d7a$991dca50$cb595ef0$@noemax.com> 
In-Reply-To: 
Date: Fri, 30 Mar 2012 14:42:15 +0300
Message-ID: <003201cd0e6a$2b871e10$82955a30$@noemax.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0033_01CD0E83.50D56780"
X-Mailer: Microsoft Outlook 14.0
thread-index: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAJixsSUAcHoFyEB2DsVhgLSPJtbAXlAGB4BaXQDtQJIEPnGmKdDdmA=
Content-Language: en-us
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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, 30 Mar 2012 11:42:18 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0033_01CD0E83.50D56780
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hello John,

=20

If you don't have the limitations of the browser (ie, it may be =
executing attacker-controlled code behind a firewall), I am not sure why =
you would choose to use WebSockets over other options.

=20

There is no other IETF standard protocol that offers duplex =
communication, multiplexing and reuse of existing infrastructure. Using =
a standardized, efficient and well thought out protocol produced by an =
open process is definitely a better option than building proprietary =
solutions. The ability to expose a service to all clients universally, =
including browser applications as well as mobile and desktop =
applications, is another indisputable benefit of using WS. And of course =
there is also the benefit of being able to traverse intermediaries with =
the same ease as HTTP or at least almost.  My view is that of an =
implementer of client-side and server-side transport components that are =
used by others developers to build their own clients and servers that =
communicate over the Internet and so I have to take into account all =
sides and all requirements ranging from mobile devices to intermediary =
boxes to enterprise servers.

=20

Assuming you do, I still don't think you want to expose the internals of =
mux channels to that API -- instead, the client should create a =
connection and if that happens to be muxed over an already-established =
connection then great, and if not great.

=20

General purpose protocol features should be discussed even when they are =
not currently exposed by its API. There is no need for the API to =
provide all protocol capabilities right from start, more capabilities =
can be exposed by the API over time, while upgrading a deployed protocol =
with more functionality is a much harder challenge. In the particular =
case we are discussing the JS API currently does not allow the =
allocation of logical channels in batches, but this does not prevent the =
underlying browser implementation to transparently preallocate batches =
of logical channels when it can predict that more than one logical =
channel will be required soon.

=20

I=E2=80=99m not sure that multiplexing should/can be kept completely =
transparent to in-browser JS applications. There could be use cases when =
such applications would require exclusive use of the WS connection. So I =
would expect the API to have a parameter that allow it to specify =
whether the mux or compression extensions are desired. The use of mux =
and compression can also be enabled/disabled by the server endpoint, but =
I doubt that it will be a solution for all cases.

=20

Clearly many of the requirements that fed into the design of WebSockets =
came from the browser context where the origination of the WS connection =
may be from hostile code, but it clearly isn't Chrome or Google =
specific.  In fact if you look at my posts about mux in the past, you =
will see that I have pushed for scenarios like a mobile carrier or =
business deploying an intermediary mux between their clients and the =
ultimate servers.

=20

The only requirement that was fed from the browser context that comes to =
mind was payload masking, the remaining parts of the WS spec are common =
requirements for duplex protocols. Actually we had been looking forward =
to such an IETF standard for many years. Since it=E2=80=99s not just =
browser specific, features that are welcome by mobile carriers, =
intermediaries, servers etc. should be taken into account. We cannot =
predict all possible use cases for all intermediaries and servers so =
providing flexibility is never a bad idea. Whether these features should =
be transparent and how they should be exposed to the API is =
orthogonal...

=20

With best regards,

Arman

=20


------=_NextPart_000_0033_01CD0E83.50D56780
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hello John,
 
If you don't have =
the limitations of the browser (ie, it may be executing =
attacker-controlled code behind a firewall), I am not sure why you would =
choose to use WebSockets over other options.
 
There is no other IETF standard protocol that offers duplex =
communication, multiplexing and reuse of existing infrastructure. Using =
a standardized, efficient and well thought out protocol produced by an =
open process is definitely a better option than building proprietary =
solutions. The ability to expose a service to all clients universally, =
including browser applications as well as mobile and desktop =
applications, is another indisputable benefit of using WS. And of course =
there is also the benefit of being able to traverse intermediaries with =
the same ease as HTTP or at least almost. =C2=A0My view is that of an =
implementer of client-side and server-side transport components that are =
used by others developers to build their own clients and servers that =
communicate over the Internet and so I have to take into account all =
sides and all requirements ranging from mobile devices to intermediary =
boxes to enterprise servers.
 
Assuming you do, I =
still don't think you want to expose the internals of mux channels to =
that API -- instead, the client should create a connection and if that =
happens to be muxed over an already-established connection then great, =
and if not great.
 
General purpose protocol features should be discussed even when they =
are not currently exposed by its API. There is no need for the API to =
provide all protocol capabilities right from start, more capabilities =
can be exposed by the API over time, while upgrading a deployed protocol =
with more functionality is a much harder challenge. In the particular =
case we are discussing the JS API currently does not allow the =
allocation of logical channels in batches, but this does not prevent the =
underlying browser implementation to transparently preallocate batches =
of logical channels when it can predict that more than one logical =
channel will be required soon.
 
I=E2=80=99m not sure that multiplexing should/can be kept completely =
transparent to in-browser JS applications. There could be use cases when =
such applications would require exclusive use of the WS connection. So I =
would expect the API to have a parameter that allow it to specify =
whether the mux or compression extensions are desired. The use of mux =
and compression can also be enabled/disabled by the server endpoint, but =
I doubt that it will be a solution for all =
cases.
 
Clearly many of the requirements that fed into the =
design of WebSockets came from the browser context where the origination =
of the WS connection may be from hostile code, but it clearly isn't =
Chrome or Google specific.  In fact if you look at my posts about =
mux in the past, you will see that I have pushed for scenarios like a =
mobile carrier or business deploying an intermediary mux between their =
clients and the ultimate servers.
 
The only requirement that was fed from the browser context that comes =
to mind was payload masking, the remaining parts of the WS spec are =
common requirements for duplex protocols. Actually we had been looking =
forward to such an IETF standard for many years. Since it=E2=80=99s not =
just browser specific, features that are welcome by mobile carriers, =
intermediaries, servers etc. should be taken into account. We cannot =
predict all possible use cases for all intermediaries and servers so =
providing flexibility is never a bad idea. Whether these features should =
be transparent and how they should be exposed to the API is =
orthogonal...
 
With best regards,
Arman
 

------=_NextPart_000_0033_01CD0E83.50D56780--


From gregw@intalio.com  Fri Mar 30 07:26:55 2012
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 D979021F850D for ; Fri, 30 Mar 2012 07:26:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.847
X-Spam-Level: 
X-Spam-Status: No, score=-2.847 tagged_above=-999 required=5 tests=[AWL=0.130,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wF72+dMZmTqI for ; Fri, 30 Mar 2012 07:26:54 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7221F84D4 for ; Fri, 30 Mar 2012 07:26:54 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so471135qcs.31 for ; Fri, 30 Mar 2012 07:26:54 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-gm-message-state:content-type; bh=WyLPbWmZdRHfSdH/yepMm9ePiTC+R0hWbR30DYgiLp4=; b=erPpYTW9mqQAou8ORR0iwR1UgOO+6w5pWn5NnOmfI35kWwqlVx/VKaSM9fUkBq3sGa W/CRPcLFX2LRA3YlCLSGygE+i3+GWb2zZvHdg5rktzGJZkqzJDcGcySFClodzeYo7zh3 Wx9FNYZtho2eKg5eeRAc+xrIgNAfiXXdxkVnRjHDaUZn7Lf7RtIS+3oVo6A3a1lzijVx cbwe2YB3HXCUMe76/Ija5E98wyUKoDnC8jTdiQlfJYoQkQdKYDyZroSN4J35ec4TyraZ NgG9c2JxHDutlBk7C0pLULWpx7GOTC00h1yIgSOKked/5fwnwwlYyUO1r/TYpjr8ARKI O3cg==
MIME-Version: 1.0
Received: by 10.224.202.66 with SMTP id fd2mr5911419qab.9.1333117614275; Fri, 30 Mar 2012 07:26:54 -0700 (PDT)
Received: by 10.229.249.18 with HTTP; Fri, 30 Mar 2012 07:26:54 -0700 (PDT)
In-Reply-To: 
References:   
Date: Sat, 31 Mar 2012 01:26:54 +1100
Message-ID: 
From: Greg Wilkins 
To: Martin Thomson 
X-Gm-Message-State: ALoCoQlV8Gt9HQGhaj3ee0J1Rb+2q0VnSobHoErMlU4WC89/2++/EkxI/kH5Gay1oJ4Lu/fpkoHn
Content-Type: text/plain; charset=ISO-8859-1
Cc: hybi@ietf.org, Roberto Peon 
Subject: Re: [hybi] Keep-Alive analysis
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, 30 Mar 2012 14:26:56 -0000

On 30 March 2012 18:54, Martin Thomson  wrote:
>
>> I can see how ;max can be applied to WS.
>
> Can you elaborate, or did you mean "can't"?

opps - s/can/can't/

From jat@google.com  Fri Mar 30 08:17:52 2012
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 6480021F8667 for ; Fri, 30 Mar 2012 08:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.965
X-Spam-Level: 
X-Spam-Status: No, score=-102.965 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xUkx7wHr2Frp for ; Fri, 30 Mar 2012 08:17:51 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4D82721F864B for ; Fri, 30 Mar 2012 08:17:51 -0700 (PDT)
Received: by vbbez10 with SMTP id ez10so529043vbb.31 for ; Fri, 30 Mar 2012 08:17:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=mGZJcFUPaNUmI3qxKIRhpuCFqSjrHG/4S4BqAEuMywM=; b=kZdPvF3Nw7NXlyZYKyZytnpePBIBMys6ggXJPy7FY2/GEQJHp7WteAdXiFx2Fu9ewC Ik5jDxZjxSRdQ3OtQS5RCgyDPk3e81Wsl74+TORlBMPmFjYiZVF04Lir/qaEWNtrYLNZ Y2OwyuP5+a3vFbm8RfvUoNQlFf2MpkU/NOxOBaN5K/NPBSNY/0I2VN87QU4Md8z0bn17 /FnoGuTN5766TGIhda3dgK0uMlovGQ9JBgT+RsZQ88+NzVPrtKmfsdAw6diP51P5xLGp 8LlWJ5jJ649DNKcDD5MRQ1TkXgMGUrA28G7BlCdX0U24exaYUPW7ujl1/zupQUr+rh9F wMhw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:x-gm-message-state:content-type; bh=mGZJcFUPaNUmI3qxKIRhpuCFqSjrHG/4S4BqAEuMywM=; b=a1f7Xqzy4CSvxPBNPeejd5LBLoQBmwQJ9u/fGD+cF7Fy98PxRtxHR6hyUlqbsVK7vA LK/6zOw9Rym0oPKWp1T7vWKskhbPiy72TEa+0hSZ3xpSSkdH89w5JpqaqRkp6XTNbM8h MlIrKTxL+1xSJGZqonasBsUlR4E3hhkzZ+Ny62OZRdV8sLCSdtJwuWiZxrAnafB2h6Dw krnN4PFtwW39xgf0kB//4neLDXJQehxXL99hxTltu870I9If5xUXtEee6fgWl8gOirPd UFt/qQEA+UX13DBiYJTRl8E6+TcMQlQggsXd3NBQpT2YoEpuSGvggXXpFW30LxUGZ8qp fARg==
Received: by 10.52.27.209 with SMTP id v17mr949843vdg.113.1333120670731; Fri, 30 Mar 2012 08:17:50 -0700 (PDT)
Received: by 10.52.27.209 with SMTP id v17mr949839vdg.113.1333120670651; Fri, 30 Mar 2012 08:17:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.17.193 with HTTP; Fri, 30 Mar 2012 08:17:30 -0700 (PDT)
In-Reply-To: <003201cd0e6a$2b871e10$82955a30$@noemax.com>
References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com>  <005d01cd0ced$a8c6dd80$fa549880$@noemax.com>    <000501cd0d7a$991dca50$cb595ef0$@noemax.com>  <003201cd0e6a$2b871e10$82955a30$@noemax.com>
From: John Tamplin 
Date: Fri, 30 Mar 2012 11:17:30 -0400
Message-ID: 
To: Arman Djusupov 
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmFXjq5igqBFuD5ZSPAnd1vG0XgEY3Jbqe3sqPJRf0BU5pZ3FkOeQoAHeYhGydpQ2QlmKXYp6qHsm3p814YC6LzfCzKS7mfNYJaeuX7sxqClaeVXZ2Ix0S1Lcsl8f0eMFfx1Q0b
Content-Type: multipart/alternative; boundary=20cf307c9bb60455f104bc7758fd
Cc: hybi@ietf.org
Subject: Re: [hybi] MUC: channel ID semantics
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, 30 Mar 2012 15:17:52 -0000

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

On Fri, Mar 30, 2012 at 7:42 AM, Arman Djusupov  wrote:

> Assuming you do, I still don't think you want to expose the internals of
> mux channels to that API -- instead, the client should create a connectio=
n
> and if that happens to be muxed over an already-established connection th=
en
> great, and if not great.
>
> **
>
> ** **
>
> General purpose protocol features should be discussed even when they are
> not currently exposed by its API. There is no need for the API to provide
> all protocol capabilities right from start, more capabilities can be
> exposed by the API over time, while upgrading a deployed protocol with mo=
re
> functionality is a much harder challenge.
>

True, but that may also lead to adding features that are speculative but
turned out never to be used.  Just as in software development, it is often
better to only add functionality only when it is known to be needed rather
than in case it might be needed.

In the case of MUX, it is itself an extension to an established protocol,
so why couldn't batch channel creation be added if it becomes necessary?


> In the particular case we are discussing the JS API currently does not
> allow the allocation of logical channels in batches, but this does not
> prevent the underlying browser implementation to transparently preallocat=
e
> batches of logical channels when it can predict that more than one logica=
l
> channel will be required soon.
>

As for arguing against it now, I think it greatly complicates the protocol
(some examples: how do you represent the parameters of all the channels,
what happens when one of the channels can't be created as requested, DoS
considerations currently blocked by one creation in flight at a time,
complicates buffer space handling, etc) and provides limited benefits.

Predicting more than one logical channel will be needed soon sounds like it
reduces to the halting problem to me, so I wouldn't hold my breath on
anything better than a raw guess.


> I=E2=80=99m not sure that multiplexing should/can be kept completely tran=
sparent
> to in-browser JS applications. There could be use cases when such
> applications would require exclusive use of the WS connection. So I would
> expect the API to have a parameter that allow it to specify whether the m=
ux
> or compression extensions are desired. The use of mux and compression can
> also be enabled/disabled by the server endpoint, but I doubt that it will
> be a solution for all cases.
>

I disagree, but it doesn't matter; at hybi we are only discussing the wire
protocol -- if someone wants to build an API that exposes all of that,
fine.  We already leave it up to the client for the choice of when/how to
use MUX, so if you are building your own non-browser client you can already
do as you wish.

--=20
John A. Tamplin
Software Engineer (GWT), Google

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


On Fri, Mar 30, 2012 at 7:42 AM, Arman Djusupov =
<arman@noemax.com<=
/a>> wrote:



A=
ssuming you do, I still don't think you want to expose the internals of=
 mux channels to that API -- instead, the client should create a connection=
 and if that happens to be muxed over an already-established connection the=
n great, and if not great.



=
=C2=A0


General purpose protocol features should be disc=
ussed even when they are not currently exposed by its API. There is no need=
 for the API to provide all protocol capabilities right from start, more ca=
pabilities can be exposed by the API over time, while upgrading a deployed =
protocol with more functionality is a much harder challenge.




True, but that may also lead to addi=
ng features that are speculative but turned out never to be used. =C2=A0Jus=
t as in software development, it is often better to only add functionality =
only when it is known to be needed rather than in case it might be needed.<=
/div>



In the case of MUX, it is itself an extension to an est=
ablished protocol, so why couldn't batch channel creation be added if i=
t becomes necessary?
=C2=A0



<=
span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s=
erif";color:#1f497d">In the particular case we are discussing the JS A=
PI currently does not allow the allocation of logical channels in batches, =
but this does not prevent the underlying browser implementation to transpar=
ently preallocate batches of logical channels when it can predict that more=
 than one logical channel will be required soon.=C2=A0




As for arguing against it now, I thi=
nk it greatly complicates the protocol (some examples: how do you represent=
 the parameters of all the channels, what happens when one of the channels =
can't be created as requested, DoS considerations currently blocked by =
one creation in flight at a time, complicates buffer space handling, etc) a=
nd provides limited benefits.




Predicting more than one logical channel will be needed=
 soon sounds like it reduces to the halting problem to me, so I wouldn'=
t hold my breath on anything better than a raw guess.
=C2=A0


I=E2=80=99m not sure that multiplexin=
g should/can be kept completely transparent to in-browser JS applications. =
There could be use cases when such applications would require exclusive use=
 of the WS connection. So I would expect the API to have a parameter that a=
llow it to specify whether the mux or compression extensions are desired. T=
he use of mux and compression can also be enabled/disabled by the server en=
dpoint, but I doubt that it will be a solution for all cases.=C2=A0<=
/p>



I disagree, but it doesn't matte=
r; at hybi we are only discussing the wire protocol -- if someone wants to =
build an API that exposes all of that, fine. =C2=A0We already leave it up t=
o the client for the choice of when/how to use MUX, so if you are building =
your own non-browser client you can already do as you wish.




-- 
John A. Tamplin
Software Engineer (GWT), Goo=
gle


--20cf307c9bb60455f104bc7758fd--