- style

-- normalize terms of RFC 6455

-- shorter IPR boilerplate
Thanks

--20cf303f6a341675ac04b7f55384-- From arman@noemax.com Mon Feb 6 01:26: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 5D4AA21F85F8 for ; Mon, 6 Feb 2012 01:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZSA66lqxxa0 for ; Mon, 6 Feb 2012 01:26:39 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id A27A721F85FD for ; Mon, 6 Feb 2012 01:26:39 -0800 (PST) Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id QLG12332; Mon, 06 Feb 2012 11:26:32 +0200 From: "Arman Djusupov" To: "'Martin Sustrik'" , "'Willy Tarreau'" References: <4F224ACB.60602@250bpm.com> <20120130061007.GL28091@1wt.eu> <4F263BC7.70400@250bpm.com> In-Reply-To: <4F263BC7.70400@250bpm.com> Date: Mon, 6 Feb 2012 11:26:31 +0200 Message-ID: <004701cce4b1$6d9cf910$48d6eb30$@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: AQIMSD5dcOm3ueTsAYFu+3PNSqZozAMypsFUAcQyJ0sCRweHhgLvIfNBlV9pbKA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 06 Feb 2012 09:26:40 -0000 Hello, The peer is able to refuse creating a new channel in real-time. Asking the user to specify a maximum number of channels will impose a static limit which is not flexible when adaptive scaling is required. Each side should be able limit the number of sub-channels depending on the current load (idle threads in thread pool etc.) When the peer rejects creating a new sub-channel there are still 2 options (a) stop creating new channels or (b) create a new connection and try to allocate new channels within that one. With best regards, Arman -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Martin Sustrik Sent: Monday, January 30, 2012 8:42 AM To: Willy Tarreau Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 On 01/30/2012 03:10 PM, Willy Tarreau wrote: > This means the endpoint should be smart enough not to announce the > whole buffer for a single channel, and always announce less than what > remains divided by the number of channels, in order to be able to > infinitely divide it. That's suboptimal but offers equal space to everyone. This way one overloaded channel can starve out other channels, although it'll happen in multiple iterations. In case of 2 channels, one idle, the other one overloaded the overloaded channel would first advertise 1/2 of the rx buffer, then 1/2 of the remaining part of the buffer (1/4 of the whole buffer) then 1/2 of that etc. The whole algorithm asymptotically approaches the entire buffer size. Once it is full, both channels are stuck, even the innocent one that was sending no data. The only way to ensure that one channel won't starve another one is to allocate separate buffer for each channel. That in turn means that you can DoS your peer by simply asking for inordinate number of channels and running it out of memory that way. SCTP which is another protocol with multiplexing built in solves this problem by asking user to specify the max number of channels when the endpoint is established. Martin _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From arman@noemax.com Mon Feb 6 01:28: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 12C5A21F85C7 for ; Mon, 6 Feb 2012 01:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, 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 Wgs2AxEiTOfB for ; Mon, 6 Feb 2012 01:28:44 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8FD7421F85C0 for ; Mon, 6 Feb 2012 01:28:44 -0800 (PST) Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id QLI45137; Mon, 06 Feb 2012 11:28:37 +0200 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , References: In-Reply-To: Date: Mon, 6 Feb 2012 11:28:36 +0200 Message-ID: <004801cce4b1$b8534130$28f9c390$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CCE4C2.7BDC1130" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMSD5dcOm3ueTsAYFu+3PNSqZozJWw0hFg Content-Language: en-us Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 06 Feb 2012 09:28:46 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0049_01CCE4C2.7BDC1130 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Takeshi, "Any compression extensions negotiated apply only to the channel they are negotiated on -- therefore, any compression extension in the initial handshake applies only to logical channel 1. If WebSocket payload data is masked by a per-frame key, such masking is applied to frames for each logical channel separately." Providing the ability to specify a compression extension per sub-channel greatly increases the complexity of the implementation. I believe it would be simpler if the compressed logical channels were grouped in a compressed connection, while the logical channels that do not need compression were grouped in a separate non-compressed connection. Maintaining a DEFLATE window per sub-channel is very expensive, doing so could eliminate all the benefits of multiplexing. But if you believe that there is a strong use case for per channel compression, then we could support both options (common compression and per channel) by having logical channel 1 perform its own handshake rather than using the initial handshake for it. With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Friday, January 27, 2012 6:55 AM To: hybi@ietf.org Subject: [hybi] Multiplexing extension spec draft 02 http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-02 Diff http://tools.ietf.org/rfcdiff?url2=draft-tamplin-hybi-google-mux-02.txt No semantic change. - some typo fixes - named "control channel" explicitly - updated reference to point RFC - added some vertical space for readability ------=_NextPart_000_0049_01CCE4C2.7BDC1130 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Takeshi,

“Any compression extensions negotiated apply = only to the channel they are negotiated on -- therefore, any compression = extension in the initial handshake applies only to logical channel = 1. If WebSocket payload data is masked by a per-frame key, such = masking is applied to frames for each logical channel = separately.”

Providing the ability to specify a compression = extension per sub-channel greatly increases the complexity of the = implementation. I believe it would be simpler if the compressed logical = channels were grouped in a compressed connection, while the logical = channels that do not need compression were grouped in a separate = non-compressed connection. Maintaining a DEFLATE window per sub-channel = is very expensive, doing so could eliminate all the benefits of = multiplexing.

But if = you believe that there is a strong use case for per channel compression, = then we could support both options (common compression and per channel) = by having logical channel 1 perform its own handshake rather than using = the initial handshake for it.

With = best regards,

Arman

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Friday, January 27, 2012 6:55 = AM
To: hybi@ietf.org
Subject: [hybi] Multiplexing = extension spec draft 02

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

Diff http://tools.ietf.org/rfcdiff?url2=3Ddraft-tamplin-hybi-google-= mux-02.txt

No semantic change.

- = some typo fixes

- named = "control channel" explicitly

- updated reference to point = RFC

- added some vertical = space for readability

------=_NextPart_000_0049_01CCE4C2.7BDC1130-- From sustrik@250bpm.com Mon Feb 6 13:06: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 6C8C121F876C for ; Mon, 6 Feb 2012 13:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 jfiIF0-imNev for ; Mon, 6 Feb 2012 13:06:25 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9F7D121F8771 for ; Mon, 6 Feb 2012 13:06:24 -0800 (PST) Received: from [192.168.0.57] (unknown [118.131.79.167]) by mail.moloch.sk (Postfix) with ESMTPSA id 1D6041800F68; Mon, 6 Feb 2012 22:06:21 +0100 (CET) Message-ID: <4F3040CA.7090002@250bpm.com> Date: Mon, 06 Feb 2012 22:06:18 +0100 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Arman Djusupov References: <4F224ACB.60602@250bpm.com> <20120130061007.GL28091@1wt.eu> <4F263BC7.70400@250bpm.com> <004701cce4b1$6d9cf910$48d6eb30$@noemax.com> In-Reply-To: <004701cce4b1$6d9cf910$48d6eb30$@noemax.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 06 Feb 2012 21:06:25 -0000 Hi Arman, > The peer is able to refuse creating a new channel in real-time. Asking the > user to specify a maximum number of channels will impose a static limit > which is not flexible when adaptive scaling is required. Each side should be > able limit the number of sub-channels depending on the current load (idle > threads in thread pool etc.) Agreed. The max-channel parameter is an API concern, not the protocol concern. Martin From sustrik@250bpm.com Mon Feb 6 13:09: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 6CAE521F873A for ; Mon, 6 Feb 2012 13:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.694 X-Spam-Level: X-Spam-Status: No, score=-0.694 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] 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 ulRg5t4Qrtzu for ; Mon, 6 Feb 2012 13:09:59 -0800 (PST) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3A421F8738 for ; Mon, 6 Feb 2012 13:09:58 -0800 (PST) Received: from [192.168.0.57] (unknown [118.131.79.167]) by mail.moloch.sk (Postfix) with ESMTPSA id 864A21800F68; Mon, 6 Feb 2012 22:09:56 +0100 (CET) Message-ID: <4F3041A1.7020902@250bpm.com> Date: Mon, 06 Feb 2012 22:09:53 +0100 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111109 Thunderbird/3.1.16 MIME-Version: 1.0 To: Takeshi Yoshino References: <4F224ACB.60602@250bpm.com> <4F26332F.20806@250bpm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 06 Feb 2012 21:09:59 -0000 On 30/01/12 08:00, Takeshi Yoshino wrote: > On Mon, Jan 30, 2012 at 15:05, Martin Sustrik > wrote: > > The scenario that I was referring to looks like this: > > 1. Receiver on channel 1 has 100 bytes in rx buffer free. > 2. Despite of that it announces quota of 200 bytes. > > ...snip... > > My original proposition was meant to explicitly prevent this kind of > situation. > > > Yes, I imagined similar example from your original post, and proposed > the generalized text. Ok. Sorry for not getting it straight away. Still, even if we don't want to use MUST, so that the spec allows for exotic mutliplexing algorithms that may be ok with one channel blocking other channels for arbitrary amount of time, it still may be a good idea to use SHOULD. IIRC "SHOULD" is defined as "do so unless you have a very good reason not to" which fits the bill here. Martin From tyoshino@google.com Mon Feb 6 23:34: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 2907F21F8718 for ; Mon, 6 Feb 2012 23:34:16 -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 ZDs7WYuEzlls for ; Mon, 6 Feb 2012 23:34:15 -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 50D5221F870F for ; Mon, 6 Feb 2012 23:34:15 -0800 (PST) Received: by obbwd15 with SMTP id wd15so9610085obb.31 for ; Mon, 06 Feb 2012 23:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=8bXEt9bAsk2RvHgGSFrq1aTridk65Ixdj4GXuRwH69s=; b=W/DZJYPsCzCSROoEfdfqWn57RI8cVIQ5uddzJjPjFIWD0J/a8ANU+V5SIM7DvmG3XJ slFLTURKsVOEubqyNI3JCnXETKE57g1oQDi73GxnZM+qHZ1hdSqboeKcM96TJv0KIMAc /Ma3ajvkDQ7W9TFavj9+TdtP4P6HxkR9UEvtk= Received: by 10.50.159.161 with SMTP id xd1mr14367646igb.15.1328600054447; Mon, 06 Feb 2012 23:34:14 -0800 (PST) Received: by 10.50.159.161 with SMTP id xd1mr14367637igb.15.1328600054365; Mon, 06 Feb 2012 23:34:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.164.201 with HTTP; Mon, 6 Feb 2012 23:33:54 -0800 (PST) In-Reply-To: <004801cce4b1$b8534130$28f9c390$@noemax.com> References: <004801cce4b1$b8534130$28f9c390$@noemax.com> From: Takeshi Yoshino Date: Tue, 7 Feb 2012 16:33:54 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9340b9349ff6d04b85ace6f X-System-Of-Record: true X-Gm-Message-State: ALoCoQnebK6r3sLztUwAvqVfdFvlWb4SWlqBcS973upM2ysmRnSPoDqtTSDWk7aO9YHlM+32PK3p8IGVTXF2LAAEsRPwiDgFZCkpWYaMaW9mDNYS8yzgz0Q2N9KBdJPIPMq30RbYzchW Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 07 Feb 2012 07:34:16 -0000 --14dae9340b9349ff6d04b85ace6f Content-Type: text/plain; charset=ISO-8859-1 Hello Arman, On Mon, Feb 6, 2012 at 18:28, Arman Djusupov wrote: > Providing the ability to specify a compression extension per sub-channel > greatly increases the complexity of the implementation. I believe it would > be simpler if the compressed logical channels were grouped in a compressed > connection, while the logical channels that do not need compression were > grouped in a separate non-compressed connection. Maintaining a DEFLATE > window per sub-channel is very expensive, > Good point. It's not so good idea to have compression contexts for each logical channel from the perspective of memory consumption. > doing so could eliminate all the benefits of multiplexing. > We still can reduce TCP's portion of memory pressure. WS + compression memory pressure = big flexibility = big WS + mux + channel-wise compression memory pressure = middle flexibility = big WS + mux + grouped compression memory pressure = small flexibility = small > But if you believe that there is a strong use case for per channel > compression, then we could support both options (common compression and per > channel) > The original assumption because of which we chose this approach is that each stream might have very different characteristics (one is text, another is compressed binary, ... different compressibility/redundancy pattern) and so it would be better to make it able to switch compression on/off for each stream. I still think it's useful. > by having logical channel 1 perform its own handshake rather than using > the initial handshake for it. > We shouldn't add any more latency for opening handshake. So, we cannot take the way to do handshake for the logical channel 1 using a mux control message (since we need to wait until we receive server's opening handshake). I'd suggest a) just give "Sec-WebSocket-Extensions: mux, deflate-frame" and "Sec-WebSocket-Extensions: deflate-frame, mux" different meanings as RFC 6455 says order is significant. I.e. "mux, deflate-frame" means deflate-frame is applied to logical channel 1 while "deflate-frame, mux" means deflate-frame is applied to physical channel. When received an AddChannel mux control with R=1 (delta-encoded), Sec-WebSocket-Extensions header for the new logical channel is computed from extension entries after mux. b) change mux extension parameter spec to be able to carry compression settings for physical channel c) change mux extension parameter spec so that it holds compression settings for the logical channel 1 in it I prefer a). Problem here is that we need to set client's default behavior. If a browser sends "deflate-frame, mux, deflate-frame", the server can choose physical/channel-wise by rejecting either of deflate-frame tokens to show its preference. The browser can still insist on use of physical channel (or logical channel-wise) compression by sending "deflate-frame, mux" (or "mux, deflate-frame"). Thanks --14dae9340b9349ff6d04b85ace6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hello Arman,

On Mon, Feb 6, 2012 at 18:28, Arman Djusu= pov <arman@noemax.= com> wrote:

Providing the ability to specify a compression extension per= sub-channel greatly increases the complexity of the implementation. I beli= eve it would be simpler if the compressed logical channels were grouped in = a compressed connection, while the logical channels that do not need compre= ssion were grouped in a separate non-compressed connection. Maintaining a D= EFLATE window per sub-channel is very expensive,

Good point. It's not so good idea to have= compression contexts for each logical channel from the perspective of memo= ry consumption.

doing so could = eliminate all the benefits of multiplexing.=A0

We still can reduce TCP's portion of memory pressure.

WS + compression

=A0 memory pressure =3D big

=A0 f= lexibility =3D big

WS + mux + channel-wise compression

= =A0 memory pressure =3D middle

=A0 flexibility =3D big

= WS + mux + grouped compression

=A0 memory pressure =3D small

=A0 flexibility =3D small

But if you believe that there is a strong use case for per channel compress= ion, then we could support both options (common compression and per channel= )

The original assumption because of which= we chose this approach is that each stream might have very different chara= cteristics (one is text, another is compressed binary, ... different compre= ssibility/redundancy pattern) and so it would be better to make it able to = switch compression on/off for each stream. I still think it's useful.

by having logical channel 1 perform its own handshake rather= than using the initial handshake for it.

We shouldn't add any more latency for ope= ning handshake. So, we cannot take the way to do handshake for the logical = channel 1 using a mux control message (since we need to wait until we recei= ve server's opening handshake).

I'd suggest

a) just give "Sec-WebSoc= ket-Extensions: mux, deflate-frame" and "Sec-WebSocket-Extensions= : deflate-frame, mux" different meanings as RFC 6455 says order is sig= nificant. I.e. "mux, deflate-frame" means deflate-frame is applie= d to logical channel 1 while "deflate-frame, mux" means deflate-f= rame is applied to physical channel. When received an AddChannel mux contro= l with R=3D1 (delta-encoded), Sec-WebSocket-Extensions header for the=A0new= logical channel is computed from extension entries after mux.

b) change mux extension parameter spec to be able to carry compre= ssion settings for physical channel

c) change mux extension param= eter spec so that it holds compression settings for the logical channel 1 i= n it

I prefer a).

<= br>

Problem here is that we need to set client's=A0default be= havior. If a browser sends "deflate-frame, mux, deflate-frame", t= he server can choose physical/channel-wise by rejecting either of deflate-f= rame tokens to show its preference. The browser can still insist on use of = physical channel (or logical channel-wise) compression by sending "def= late-frame, mux" (or "mux, deflate-frame").

Thanks

--14dae9340b9349ff6d04b85ace6f-- From arman@noemax.com Tue Feb 7 02:05: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 9347121F87B8 for ; Tue, 7 Feb 2012 02:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.464, 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 LJ48PExPvosm for ; Tue, 7 Feb 2012 02:05:48 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id BC0BD21F87B6 for ; Tue, 7 Feb 2012 02:05:47 -0800 (PST) Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id RMM96838; Tue, 07 Feb 2012 12:05:38 +0200 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <004801cce4b1$b8534130$28f9c390$@noemax.com> In-Reply-To: Date: Tue, 7 Feb 2012 12:05:43 +0200 Message-ID: <003c01cce580$11bdae80$35390b80$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01CCE590.D5467E80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMSD5dcOm3ueTsAYFu+3PNSqZozAESfUVlAdqvK9SVmwVIYA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 07 Feb 2012 10:05:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003D_01CCE590.D5467E80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Takeshi, >a) just give "Sec-WebSocket-Extensions: mux, deflate-frame" and "Sec-WebSocket-Extensions: deflate-frame, mux" different meanings as RFC 6455 says order is significant. I.e. "mux, deflate-frame" means deflate-frame is applied to logical channel 1 while "deflate-frame, mux" means deflate-frame is applied to physical channel. When received an AddChannel mux control with R=1 (delta-encoded), Sec-WebSocket-Extensions header for the new logical channel is computed from extension entries after mux. >b) change mux extension parameter spec to be able to carry compression settings for physical channel >c) change mux extension parameter spec so that it holds compression settings for the logical channel 1 in it >I prefer a). >Problem here is that we need to set client's default behavior. If a browser sends "deflate-frame, mux, deflate-frame", the server can choose physical/channel-wise by rejecting either of deflate-frame tokens to show its preference. The browser can still insist on use of physical channel (or logical channel-wise) compression by sending "deflate-frame, mux" (or "mux, deflate-frame"). I also prefer a), unless we find a better solution in the future. I think that the specification can prohibit or at least discourage using both physical channel compression and logical channel compression. This simply doesn't make sense and does not give any benefits. Even if the specification does not prohibit this than the server still can refuse such a mixture of extensions. Normally when a client sends "deflate-frame, mux, deflate-frame", the server can always reply with "deflate-frame, mux " or "mux, deflate-frame" depending what it supports or what is preferable to this particular server. Using the Sec-WebSocket-Extensions header in such a manner also looks logically consistent since the order in which the extensions are applied in this case indeed does make a meaningful difference. With best regards, Arman ------=_NextPart_000_003D_01CCE590.D5467E80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Takeshi,

>a) = just give "Sec-WebSocket-Extensions: mux, deflate-frame" and = "Sec-WebSocket-Extensions: deflate-frame, mux" different = meanings as RFC 6455 says order is significant. I.e. "mux, = deflate-frame" means deflate-frame is applied to logical channel 1 = while "deflate-frame, mux" means deflate-frame is applied to = physical channel. When received an AddChannel mux control with R=3D1 = (delta-encoded), Sec-WebSocket-Extensions header for the new logical = channel is computed from extension entries after mux.

>b) change mux extension parameter spec to be = able to carry compression settings for physical channel

>c) change mux extension parameter spec so that = it holds compression settings for the logical channel 1 in = it

>I prefer a).

>Problem here is that we need to set client's = default behavior. If a browser sends "deflate-frame, mux, = deflate-frame", the server can choose physical/channel-wise = by rejecting either of deflate-frame tokens to show its preference. The = browser can still insist on use of physical channel (or logical = channel-wise) compression by sending "deflate-frame, mux" (or = "mux, deflate-frame").

I also = prefer a), unless we find a better solution in the future. I think that = the specification can prohibit or at least discourage using both = physical channel compression and logical channel compression. This = simply doesn't make sense and does not give any benefits. Even if the = specification does not prohibit this than the server still can refuse = such a mixture of extensions. Normally when a client sends = "deflate-frame, mux, deflate-frame", the server can always = reply with "deflate-frame, mux " or "mux, = deflate-frame" depending what it supports or what is preferable to = this particular server. Using the Sec-WebSocket-Extensions header in = such a manner also looks logically consistent since the order in which = the extensions are applied in this case indeed does make a meaningful = difference.

With = best regards,

Arman

------=_NextPart_000_003D_01CCE590.D5467E80-- From wwwrun@ietfa.amsl.com Tue Feb 7 09:43:02 2012 Return-Path: X-Original-To: hybi@ietf.org Delivered-To: hybi@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id ADD8F21F8870; Tue, 7 Feb 2012 09:43:02 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120207174302.ADD8F21F8870@ietfa.amsl.com> Date: Tue, 7 Feb 2012 09:43:02 -0800 (PST) Cc: hybi@ietf.org Subject: [hybi] WG Review: Recharter of BiDirectional or Server-Initiated HTTP (hybi) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: iesg@ietf.org List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2012 17:43:03 -0000 A modified charter has been submitted for the BiDirectional or Server- Initiated HTTP (hybi) working group in the Applications Area of the IETF. The IESG has not made any determination as yet. The modified charter is provided below for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, February 14, 2012. BiDirectional or Server-Initiated HTTP (hybi) ----------------------------------------- Status: Active Working Group Last Updated: 2012-02-02 Chairs: Salvatore Loreto Gabriel Montenegro Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Secretary: S Moonesamy Mailing Lists: Address: hybi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hybi Archive: http://www.ietf.org/mail-archive/web/hybi/ Description of Working Group: The BiDirectional or Server-Initiated HTTP (HyBi) working group defines the WebSocket Protocol, a technology for bidirectional communication between an HTTP client and an HTTP server that provides greater efficiency than previous approaches (e.g., use of hanging requests or long polling). Having completed work on the core protocol (RFC 6455), the group continues to define extensions for use by WebSocket implementations. The following extensions and optimizations are currently in scope: 1. A per-frame compression extension to improve bandwidth usage (draft-tyoshino-hybi-websocket-perframe-deflate is a likely starting point). 2. A multiplexing extension to improve the scalability of the WebSocket protocol (draft-tamplin-hybi-google-mux is a likely starting point). 3. Timeout-handling capabilities to reduce the chattiness of the protocol (draft-thomson-hybi-http-timeout is a likely starting point). The working group will also serve as a discussion venue for subprotocols. However, no subprotocol is currently chartered as a deliverable, and the WG must be rechartered to work on any subprotocols. The group will not work on an updated version of the WebSocket protocol, unless it is specifically rechartered to do so. 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. The group will also continue coordinating with other working groups within the IETF (e.g., HTTPBIS) as appropriate. Goal and Milestones: Feb 2012 - Adopt a WG item for the per-frame compression extension May 2012 - Issue WG last call on the per-frame compression extension Jun 2012 - Send per-frame compression extension to IESG for consideration as a Proposed Standard Jun 2012 - Adopt a WG item for timeout handling Jul 2012 - Adopt a WG for the multiplexing extension Aug 2012 - Issue WG last call on timeout handling Sep 2012 - Issue WG last call on the multiplexing extension Oct 2012 - Send timeout handling to IESG for consideration as a Proposed Standard Nov 2012 - Send multiplexing extension to IESG for consideration as a Proposed Standard From tyoshino@google.com Tue Feb 7 21:23: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 BBB5811E8094 for ; Tue, 7 Feb 2012 21:23:04 -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 nkcGmHSvt3Ks for ; Tue, 7 Feb 2012 21:23:04 -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 2699311E8088 for ; Tue, 7 Feb 2012 21:23:04 -0800 (PST) Received: by ghbg16 with SMTP id g16so62211ghb.31 for ; Tue, 07 Feb 2012 21:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=nVOufB9s1O3+BlVfhwKAoW0ngN9Iefi3IuVHGnHV5V8=; b=fRgx3qdqFCOKehGV+s06drslsH8MAZ3LEtZxY42rzsJYMqO55ZsOVQzd0TdbIM6F0t 7PZLqeXvsqVg+HFsKjDVpFaFx21lFGn0Byed0niF7ZjHhGbmYTYkssOWvL7JABvltp2S 46of0DgikqLE9auVOKtEF4JnvBFUnHWPn/8cA= Received: by 10.236.124.2 with SMTP id w2mr35623898yhh.83.1328678583727; Tue, 07 Feb 2012 21:23:03 -0800 (PST) Received: by 10.236.124.2 with SMTP id w2mr35623891yhh.83.1328678583652; Tue, 07 Feb 2012 21:23:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Tue, 7 Feb 2012 21:22:43 -0800 (PST) In-Reply-To: <4F3041A1.7020902@250bpm.com> References: <4F224ACB.60602@250bpm.com> <4F26332F.20806@250bpm.com> <4F3041A1.7020902@250bpm.com> From: Takeshi Yoshino Date: Wed, 8 Feb 2012 14:22:43 +0900 Message-ID: To: Martin Sustrik X-System-Of-Record: true Content-Type: multipart/alternative; boundary=20cf300e50b7ffd1e104b86d164a Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 08 Feb 2012 05:23:04 -0000 --20cf300e50b7ffd1e104b86d164a Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 7, 2012 at 06:09, Martin Sustrik wrote: > Still, even if we don't want to use MUST, so that the spec allows for > exotic mutliplexing algorithms that may be ok with one channel blocking > other channels for arbitrary amount of time, it still may be a good idea to > use SHOULD. > > IIRC "SHOULD" is defined as "do so unless you have a very good reason not > to" which fits the bill here. OK. I'll try to take in your suggestion. --20cf300e50b7ffd1e104b86d164a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 7, 2012 at 06:09, Martin Sustrik <sustrik@250bpm.com= > wrote:

Still, even if we don't want to use MUST, so that the= spec allows for exotic mutliplexing algorithms that may be ok with one cha= nnel blocking other channels for arbitrary amount of time, it still may be = a good idea to use SHOULD.

IIRC "SHOULD" is defined as "do so unless you have a very go= od reason not to" which fits the bill here.

OK. I'll try to take in your suggestion.=A0

=A0<= /div>

--20cf300e50b7ffd1e104b86d164a-- From tyoshino@google.com Tue Feb 7 21:27: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 81AB511E80A0 for ; Tue, 7 Feb 2012 21:27: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=[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 pDeDrEyZcdYw for ; Tue, 7 Feb 2012 21:27:10 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id BA3AC11E80A6 for ; Tue, 7 Feb 2012 21:27:03 -0800 (PST) Received: by ggnq2 with SMTP id q2so63900ggn.31 for ; Tue, 07 Feb 2012 21:27:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=B7dgRdZ37FG68j2U1Ms34/rNVZEJtjxyGT0dKoqK7Qc=; b=DZuwkaXg4FBk1jHwbOLbhEfC+tp6ExW/LX+nFJfFklbK+t/Bd4hNioX1OPzMqqd62c oFFwET0iqM3dG9eIQjwIiMxQ7IbeJL9AaEmBumvXMpKnncZ8vKkAl9524yyiFVAA7j30 d/0aB8An57I3uIY85P7GZAgYIIhdkK/i7WQP8= Received: by 10.101.144.27 with SMTP id w27mr10136737ann.72.1328678823349; Tue, 07 Feb 2012 21:27:03 -0800 (PST) Received: by 10.101.144.27 with SMTP id w27mr10136733ann.72.1328678823252; Tue, 07 Feb 2012 21:27:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Tue, 7 Feb 2012 21:26:43 -0800 (PST) In-Reply-To: <003c01cce580$11bdae80$35390b80$@noemax.com> References: <004801cce4b1$b8534130$28f9c390$@noemax.com> <003c01cce580$11bdae80$35390b80$@noemax.com> From: Takeshi Yoshino Date: Wed, 8 Feb 2012 14:26:43 +0900 Message-ID: To: Arman Djusupov X-System-Of-Record: true Content-Type: multipart/alternative; boundary=0016e6d2629547d56304b86d257e Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 08 Feb 2012 05:27:10 -0000 --0016e6d2629547d56304b86d257e Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 7, 2012 at 19:05, Arman Djusupov wrote: > I also prefer a), unless we find a better solution in the future. I think > that the specification can prohibit or at least discourage using both > physical channel compression and logical channel compression. > Agreed > This simply doesn't make sense and does not give any benefits. Even if the > specification does not prohibit this than the server still can refuse such > a mixture of extensions. Normally when a client sends "deflate-frame, mux, > deflate-frame", the server can always reply with "deflate-frame, mux " or > "mux, deflate-frame" depending what it supports or what is preferable to > this particular server. > Yes. > Using the Sec-WebSocket-Extensions header in such a manner also looks > logically consistent since the order in which the extensions are applied in > this case indeed does make a meaningful difference. > Yes. Thanks. I'll reflect this idea in the next version. --0016e6d2629547d56304b86d257e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 7, 2012 at 19:05, Arman Djusupov <arman@noemax.com= > wrote:

I also= prefer a), unless we find a better solution in the future. I think that th= e specification can prohibit or at least discourage using both physical cha= nnel compression and logical channel compression.

Agreed

This simply doesn't make sense and does not give any benefits. Eve= n if the specification does not prohibit this than the server still can ref= use such a mixture of extensions. Normally when a client sends "deflat= e-frame, mux, deflate-frame", the server can always reply with "d= eflate-frame, mux " or "mux, deflate-frame" depending what i= t supports or what is preferable to this particular server.

Yes.=A0

Using the Sec-WebSocket-Extensions header in such a manner also looks= logically consistent since the order in which the extensions are applied i= n this case indeed does make a meaningful difference.

Yes.

Tha= nks. I'll reflect this idea in the next version.

--0016e6d2629547d56304b86d257e-- From arman@noemax.com Tue Feb 7 23:50: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 C1A3A21F84D1 for ; Tue, 7 Feb 2012 23:50:02 -0800 (PST) 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 c0Y5NNh2w3og for ; Tue, 7 Feb 2012 23:50:02 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id CFF7121F84E6 for ; Tue, 7 Feb 2012 23:50:01 -0800 (PST) Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id SJG63007; Wed, 08 Feb 2012 09:50:07 +0200 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <004801cce4b1$b8534130$28f9c390$@noemax.com> <003c01cce580$11bdae80$35390b80$@noemax.com> In-Reply-To: Date: Wed, 8 Feb 2012 09:50:00 +0200 Message-ID: <001201cce636$46a1c0d0$d3e54270$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01CCE647.0A2F72D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMSD5dcOm3ueTsAYFu+3PNSqZozAESfUVlAdqvK9QAkjhKZgFiRAdslYzN+TA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 08 Feb 2012 07:50:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0013_01CCE647.0A2F72D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Great! Thank you. From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, February 08, 2012 7:27 AM To: Arman Djusupov Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 On Tue, Feb 7, 2012 at 19:05, Arman Djusupov wrote: I also prefer a), unless we find a better solution in the future. I think that the specification can prohibit or at least discourage using both physical channel compression and logical channel compression. Agreed This simply doesn't make sense and does not give any benefits. Even if the specification does not prohibit this than the server still can refuse such a mixture of extensions. Normally when a client sends "deflate-frame, mux, deflate-frame", the server can always reply with "deflate-frame, mux " or "mux, deflate-frame" depending what it supports or what is preferable to this particular server. Yes. Using the Sec-WebSocket-Extensions header in such a manner also looks logically consistent since the order in which the extensions are applied in this case indeed does make a meaningful difference. Yes. Thanks. I'll reflect this idea in the next version. ------=_NextPart_000_0013_01CCE647.0A2F72D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Great! Thank you.

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, = February 08, 2012 7:27 AM
To: Arman Djusupov
Cc: = hybi@ietf.org
Subject: Re: [hybi] Multiplexing extension spec = draft 02

On Tue, = Feb 7, 2012 at 19:05, Arman Djusupov <arman@noemax.com> = wrote:

I also prefer a), unless we = find a better solution in the future. I think that the specification can = prohibit or at least discourage using both physical channel compression = and logical channel = compression.

Agreed

This = simply doesn't make sense and does not give any benefits. Even if the = specification does not prohibit this than the server still can refuse = such a mixture of extensions. Normally when a client sends = "deflate-frame, mux, deflate-frame", the server can always = reply with "deflate-frame, mux " or "mux, = deflate-frame" depending what it supports or what is preferable to = this particular = server.

Yes.

Using = the Sec-WebSocket-Extensions header in such a manner also looks = logically consistent since the order in which the extensions are applied = in this case indeed does make a meaningful = difference.

Yes.

Thanks. I'll reflect this idea in the next = version.

------=_NextPart_000_0013_01CCE647.0A2F72D0-- From jat@google.com Wed Feb 8 10:35:15 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 2379A21F858E for ; Wed, 8 Feb 2012 10:35:15 -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 MPkLKkyHVRst for ; Wed, 8 Feb 2012 10:35:13 -0800 (PST) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id BEFFF21F855B for ; Wed, 8 Feb 2012 10:35:13 -0800 (PST) Received: by qcsg13 with SMTP id g13so566020qcs.31 for ; Wed, 08 Feb 2012 10:35:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:x-system-of-record:content-type; bh=f3C401FJbH2Y8N7Mza4AwTK8Oh1u0mj6QgBHWO2VDlQ=; b=unTDjZeQQpI7nivVLiymAAfDsrD4PmFdsP6doMe1uLMdznQlJChEUPkWoLtKHYcidA 9ZiwyRXRrPrbCodl9HiZi2AnE//3/cfQLu9r0SMdsy2jyH8zf0VoJkcl1wcUzxTVujdt Rhq6o3jHH+g07PETxqKk38ueuK/QGNx2qm9ik= Received: by 10.229.102.75 with SMTP id f11mr11561822qco.49.1328726113287; Wed, 08 Feb 2012 10:35:13 -0800 (PST) Received: by 10.229.102.75 with SMTP id f11mr11561813qco.49.1328726113187; Wed, 08 Feb 2012 10:35:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.134.72 with HTTP; Wed, 8 Feb 2012 10:34:53 -0800 (PST) In-Reply-To: <004801cce4b1$b8534130$28f9c390$@noemax.com> References: <004801cce4b1$b8534130$28f9c390$@noemax.com> From: John Tamplin Date: Wed, 8 Feb 2012 13:34:53 -0500 Message-ID: To: Arman Djusupov X-System-Of-Record: true Content-Type: multipart/alternative; boundary=002354470c70faf81f04b8782708 Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing extension spec draft 02 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, 08 Feb 2012 18:35:15 -0000 --002354470c70faf81f04b8782708 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 6, 2012 at 4:28 AM, Arman Djusupov wrote: > =E2=80=9CAny compression extensions negotiated apply only to the channel = they are > negotiated on -- therefore, any compression extension in the initial > handshake applies only to logical channel 1. If WebSocket payload data i= s > masked by a per-frame key, such masking is applied to frames for each > logical channel separately.=E2=80=9D > > ** > > ** ** > > Providing the ability to specify a compression extension per sub-channel > greatly increases the complexity of the implementation. I believe it woul= d > be simpler if the compressed logical channels were grouped in a compresse= d > connection, while the logical channels that do not need compression were > grouped in a separate non-compressed connection. Maintaining a DEFLATE > window per sub-channel is very expensive, doing so could eliminate all th= e > benefits of multiplexing. > > ** > > But if you believe that there is a strong use case for per channel > compression, then we could support both options (common compression and p= er > channel) by having logical channel 1 perform its own handshake rather tha= n > using the initial handshake for it. > The rationale was that an intermediate MUX would otherwise have to decompress inbound channels and recompress the combined channel, which seems a waste. I agree that in the browser case, where the individual channels never exist separately, it would be better to do compression only on the physical channel. So, it seems like we need to have options for either behavior. --=20 John A. Tamplin Software Engineer (GWT), Google --002354470c70faf81f04b8782708 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 6, 2012 at 4:28 AM, Arman Djusupov <= span dir=3D"ltr"><arman@noemax.com> wrote:

=E2=80=9CAny compress= ion extensions negotiated apply only to the channel they are negotiated on = -- therefore, any compression extension in the initial handshake applies on= ly to logical channel 1.=C2=A0 If WebSocket payload data is masked by a per= -frame key, such masking is applied to frames for each logical channel sepa= rately.=E2=80=9D

=C2=A0
Providing the ability to specif= y a compression extension per sub-channel greatly increases the complexity = of the implementation. I believe it would be simpler if the compressed logi= cal channels were grouped in a compressed connection, while the logical cha= nnels that do not need compression were grouped in a separate non-compresse= d connection. Maintaining a DEFLATE window per sub-channel is very expensiv= e, doing so could eliminate all the benefits of multiplexing.=C2=A0

But if you believe that there is a strong use case for per= channel compression, then we could support both options (common compressio= n and per channel) by having logical channel 1 perform its own handshake ra= ther than using the initial handshake for it.

The rationale was that an intermediate MUX would ot= herwise have to decompress inbound channels and recompress the combined cha= nnel, which seems a waste. =C2=A0I agree that in the browser case, where th= e individual channels never exist separately, it would be better to do comp= ression only on the physical channel.

So, it seems like we need to have options for either be= havior.=C2=A0

--
John A. Tamplin
Software = Engineer (GWT), Google
--002354470c70faf81f04b8782708-- From ruoqiu.lee@gmail.com Wed Feb 15 07:23: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 6695321F879A for ; Wed, 15 Feb 2012 07:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, 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 WZ+bqZ9J6PtN for ; Wed, 15 Feb 2012 07:23:49 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id D473221F8517 for ; Wed, 15 Feb 2012 07:23:49 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so1586509pbc.31 for ; Wed, 15 Feb 2012 07:23:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=nhYrfa8YwzuoyI7CIVfQg1OyFHCoEq6qetl22Gv5n0w=; b=gthJVkQctYfdOPiE7dS0IGq2IfNzAfhvGFOi9CVboEmuhp2cy21Dk8X82g6fHBagFQ 05+qHesXaIy2WtzY9B+98MjHnEnMEYl3Kh4VZdhLGYPYZLrD8lR4iB4VooAN279adxbV PHW7x/ag5jAMGABk1umkxR/WG/U1XV2i6oJ50= MIME-Version: 1.0 Received: by 10.68.234.7 with SMTP id ua7mr4583689pbc.76.1329319429658; Wed, 15 Feb 2012 07:23:49 -0800 (PST) Received: by 10.68.62.106 with HTTP; Wed, 15 Feb 2012 07:23:49 -0800 (PST) Date: Wed, 15 Feb 2012 23:23:49 +0800 Message-ID: From: juan li To: hybi@ietf.org Content-Type: multipart/alternative; boundary=047d7b33d6d665d79104b9024c58 X-Mailman-Approved-At: Wed, 15 Feb 2012 07:28:06 -0800 Subject: [hybi] a question about the redirect of websocket 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, 15 Feb 2012 15:23:50 -0000 --047d7b33d6d665d79104b9024c58 Content-Type: text/plain; charset=ISO-8859-1 Hi, On page 20 of rfc6455, I find this sentence "A data center might have a server that responds to WebSocket requests with an appropriate handshake and then passes the connection to another server to actually process the data frames". How to do this(A server has completed the handshake and then passes the connection to another server)? Thanks. --047d7b33d6d665d79104b9024c58 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

=A0 =A0On page 20 of rfc6455, I find this sentence "A= data center might
have a server that responds to WebSocket =A0requests = with an appropriate
handshake and then passes the connection to another = server to actually
process the data frames". How to do this(A server has completed thehandshake and then passes the connection to another server)?

Thanks= . --047d7b33d6d665d79104b9024c58-- From ruoqiu.lee@gmail.com Sun Feb 19 01:38: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 AAA3B21F8549 for ; Sun, 19 Feb 2012 01:38:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.224 X-Spam-Level: X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=0.374, 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 0FIyNOGsmn1n for ; Sun, 19 Feb 2012 01:38:08 -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 BA7B921F851B for ; Sun, 19 Feb 2012 01:38:08 -0800 (PST) Received: by ghbg16 with SMTP id g16so2653524ghb.31 for ; Sun, 19 Feb 2012 01:38:08 -0800 (PST) Received-SPF: pass (google.com: domain of ruoqiu.lee@gmail.com designates 10.101.133.10 as permitted sender) client-ip=10.101.133.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ruoqiu.lee@gmail.com designates 10.101.133.10 as permitted sender) smtp.mail=ruoqiu.lee@gmail.com; dkim=pass header.i=ruoqiu.lee@gmail.com Received: from mr.google.com ([10.101.133.10]) by 10.101.133.10 with SMTP id k10mr6921043ann.23.1329644288392 (num_hops = 1); Sun, 19 Feb 2012 01:38:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=ri5dRBVyOInV2YJD/yLDeD7A7HCTz1Zym1rwzeVIWTQ=; b=FE3uOfETBKua0980RxuFf69323y//5oDqGApvhg9vW81h+hpSspqeCo1/HIUQTdrg+ zEr3n5N6+BwE6LNTO7Ic/9FqOqA1OPtsnr02+BqDtqPccJSNaJWuWFLYrlFDoipyZJ0j C3fbFUeGUHIicxXCoS7MKB3W/Nsiyw4HfbeMw= MIME-Version: 1.0 Received: by 10.101.133.10 with SMTP id k10mr5304017ann.23.1329644288349; Sun, 19 Feb 2012 01:38:08 -0800 (PST) Received: by 10.236.209.227 with HTTP; Sun, 19 Feb 2012 01:38:08 -0800 (PST) Date: Sun, 19 Feb 2012 17:38:08 +0800 Message-ID: From: juan li To: hybi@ietf.org Content-Type: multipart/alternative; boundary=0016e6d27cca7c157f04b94def96 Subject: [hybi] why did rfc6455 choose the 16-byte sec_websocket_key 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, 19 Feb 2012 09:38:09 -0000 --0016e6d27cca7c157f04b94def96 Content-Type: text/plain; charset=ISO-8859-1 Hi, Why does rfc6455 choose the 16-byte sec_websocket_key? When encoded, it occupies 24 bytes. The sec_websocket_accept occupies 28 bytes. They are so long. Why not choose a shorter key? Thanks for your reply. --0016e6d27cca7c157f04b94def96 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

=A0 =A0 =A0 =A0Why does rfc6455 choose the 16-byte s= ec_websocket_key? =A0When encoded, it occupies 24 bytes. The sec_websocket_= accept occupies 28 bytes. They are so long.=A0

Why not choose a s= horter key?

Thanks for your reply.

On Sun, Feb 19, 2012 at 4:38 AM, juan li <ruoqiu.lee@gmail.com= > wrote:

=C2=A0=C2=A0 =C2=A0 =C2=A0 Why does rfc6455 choose the 16-byte sec_web= socket_key? =C2=A0When encoded, it occupies 24 bytes. The sec_websocket_acc= ept occupies 28 bytes. They are so long.=C2=A0
Why not choose a s= horter key?

A shorter key has security implications, and since this= happens once per handshake the cost is negligible.=C2=A0

<= br>

--
John A. Tamplin
Software Engineer (GWT), Google
--bcaec51d20d81b4c1c04b95b4a34-- From tyoshino@google.com Sun Feb 19 22: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 1A7A921F85D7 for ; Sun, 19 Feb 2012 22:14:01 -0800 (PST) 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_41=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 HgjlAobedzsb for ; Sun, 19 Feb 2012 22:14:00 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id B7A8021F84B5 for ; Sun, 19 Feb 2012 22:13:57 -0800 (PST) Received: by yhkk25 with SMTP id k25so2816636yhk.31 for ; Sun, 19 Feb 2012 22:13:57 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.236.78.231 as permitted sender) client-ip=10.236.78.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.236.78.231 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.236.78.231]) by 10.236.78.231 with SMTP id g67mr25872391yhe.117.1329718437413 (num_hops = 1); Sun, 19 Feb 2012 22:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=EmWGB0mu3SUteE/RKLTOEsF/nxeiGD8BmJlzOteTIR8=; b=GXiBabss7uXHfeZHmN/pnph5mC5bSno0f6bR2y4QwT2ox9esG1zmxUU2TAPv0zuirJ z/xKJW5oJ2TnzAA1kwzSmwlnedn16R5wr9ENQtPIn2Z0QernZJgan9DHOKsfGcu7lzIL vUC8MqvFG+n44ckNu+xuKMYxVPD+M8Ks1QV/k= Received: by 10.236.78.231 with SMTP id g67mr19881869yhe.117.1329718437368; Sun, 19 Feb 2012 22:13:57 -0800 (PST) Received: by 10.236.78.231 with SMTP id g67mr19881858yhe.117.1329718437284; Sun, 19 Feb 2012 22:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Sun, 19 Feb 2012 22:13:37 -0800 (PST) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 20 Feb 2012 15:13:37 +0900 Message-ID: To: juan li Content-Type: multipart/alternative; boundary=20cf300fb1a51b0a2804b95f3346 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkg8ae8NF/0VOQiX0ziWI8tE+mTXn6C7SzL2DoeIMLpFrDY0tEAkVE8RQP1+2s25qtgTyZ19eFN+bb/hc5o4Yw0OVADgEdmbkd8nB+80M8CmKhvOk6UoLB9Q6jsiGIzbJ47Kz6h Cc: hybi@ietf.org Subject: Re: [hybi] a question about the redirect of websocket 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, 20 Feb 2012 06:14:01 -0000 --20cf300fb1a51b0a2804b95f3346 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Feb 16, 2012 at 00:23, juan li wrote: snip. > process the data frames". How to do this(A server has completed the > handshake and then passes the connection to another server)? > I think "pass the connection" in the sentence means forwarding everything following the opening handshake to backends (possibly converted into some in-data-center protocol) and forwarding data returned from backends to the client. --20cf300fb1a51b0a2804b95f3346 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thu, Feb 16, 2012 at 00:23, juan li <ruoqiu.lee@gmail.com> wrote:

snip.

process the data frames". How to do this(A server has completed = the
handshake and then passes the connection to another server)?

I think "pass the connection"= in the sentence means=A0forwarding everything following the opening handsh= ake to backends (possibly=A0converted into some in-data-center protocol) an= d forwarding data returned from backends to the client.

--20cf300fb1a51b0a2804b95f3346-- From wwwrun@ietfa.amsl.com Tue Feb 21 10:27:58 2012 Return-Path: X-Original-To: hybi@ietf.org Delivered-To: hybi@ietfa.amsl.com Received: by ietfa.amsl.com (Postfix, from userid 30) id A4B3D21F88E6; Tue, 21 Feb 2012 10:27:58 -0800 (PST) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20120221182758.A4B3D21F88E6@ietfa.amsl.com> Date: Tue, 21 Feb 2012 10:27:58 -0800 (PST) Cc: hybi@ietf.org, Gabriel.Montenegro@microsoft.com Subject: [hybi] WG Action: RECHARTER: BiDirectional or Server-Initiated HTTP (hybi) 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, 21 Feb 2012 18:27:58 -0000 The BiDirectional or Server-Initiated HTTP (hybi) working group in the Applications Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. BiDirectional or Server-Initiated HTTP (hybi) ----------------------------------------- Status: Active Working Group Last Updated: 2012-02-02 Chairs: Salvatore Loreto Gabriel Montenegro Applications Area Director(s): Pete Resnick Peter Saint-Andre Applications Area Advisor: Peter Saint-Andre Secretary: S Moonesamy Mailing Lists: Address: hybi@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/hybi Archive: http://www.ietf.org/mail-archive/web/hybi/ Description of Working Group: The BiDirectional or Server-Initiated HTTP (HyBi) working group defines the WebSocket Protocol, a technology for bidirectional communication between an HTTP client and an HTTP server that provides greater efficiency than previous approaches (e.g., use of hanging requests or long polling). Having completed work on the core protocol (RFC 6455), the group continues to define extensions for use by WebSocket implementations. The following extensions and optimizations are currently in scope: 1. A per-frame compression extension to improve bandwidth usage (draft-tyoshino-hybi-websocket-perframe-deflate is a likely starting point). 2. A multiplexing extension to improve the scalability of the WebSocket protocol (draft-tamplin-hybi-google-mux is a likely starting point). 3. Timeout-handling capabilities to reduce the chattiness of the protocol (draft-thomson-hybi-http-timeout is a likely starting point). The working group will also serve as a discussion venue for subprotocols. However, no subprotocol is currently chartered as a deliverable, and the WG must be rechartered to work on any subprotocols. The group will not work on an updated version of the WebSocket protocol, unless it is specifically rechartered to do so. 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. The group will also continue coordinating with other working groups within the IETF (e.g., HTTPBIS) as appropriate. Goal and Milestones: Feb 2012 - Adopt a WG item for the per-frame compression extension May 2012 - Issue WG last call on the per-frame compression extension Jun 2012 - Send per-frame compression extension to IESG for consideration as a Proposed Standard Jun 2012 - Adopt a WG item for timeout handling Jul 2012 - Adopt a WG for the multiplexing extension Aug 2012 - Issue WG last call on timeout handling Sep 2012 - Issue WG last call on the multiplexing extension Oct 2012 - Send timeout handling to IESG for consideration as a Proposed Standard Nov 2012 - Send multiplexing extension to IESG for consideration as a Proposed Standard From salvatore.loreto@ericsson.com Tue Feb 21 23:20: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 4C6B821F8757 for ; Tue, 21 Feb 2012 23:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.641 X-Spam-Level: X-Spam-Status: No, score=-109.641 tagged_above=-999 required=5 tests=[AWL=0.957, 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 52z55ZIM96Id for ; Tue, 21 Feb 2012 23:20:21 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 9903E21F8717 for ; Tue, 21 Feb 2012 23:20:18 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-24-4f44973060d5 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id A0.B6.27041.037944F4; Wed, 22 Feb 2012 08:20:16 +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; Wed, 22 Feb 2012 08:20:16 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 323F12321 for ; Wed, 22 Feb 2012 09:20:16 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 136E952172 for ; Wed, 22 Feb 2012 09:20:16 +0200 (EET) Received: from n106.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C4B665212C for ; Wed, 22 Feb 2012 09:20:15 +0200 (EET) Message-ID: <4F44972F.6060003@ericsson.com> Date: Wed, 22 Feb 2012 09:20:15 +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" References: <20120222071449.GO31337@sideshowbarker> In-Reply-To: <20120222071449.GO31337@sideshowbarker> X-Forwarded-Message-Id: <20120222071449.GO31337@sideshowbarker> Content-Type: multipart/alternative; boundary="------------070505090203020005090401" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Fwd: [testsuites] WebSocket support on w3c-test.org 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, 22 Feb 2012 07:20:22 -0000 --------------070505090203020005090401 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit FYI -------- Original Message -------- Subject: [testsuites] WebSocket support on w3c-test.org Date: Wed, 22 Feb 2012 08:14:50 +0100 From: Michael[tm] Smith To: public-webapps@w3.org We now have initial WebSocket server support set up on w3c-test.org. Simple demo here: http://w3c-test.org/demo/console.html The server support uses pywebsocket, so if you have server components of WebSocket test cases written in Python, we can host them under http://www.w3c-test.org/ws/ If anybody's interested in actually trying that right now, and you have *_wsh.py handlers you'd like to have installed, we can work on getting something set up to facilitate it. --Mike -- Michael[tm] Smith http://people.w3.org/mike/+ --------------070505090203020005090401 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit FYI

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

Subject:	[testsuites] WebSocket support on w3c-test.org
Date:	Wed, 22 Feb 2012 08:14:50 +0100
From:	Michael[tm] Smith <mike@w3.org>
To:	public-webapps@w3.org <public-webapps@w3.org>

We now have initial WebSocket server support set up on w3c-test.org. Simple
demo here:

  http://w3c-test.org/demo/console.html

The server support uses pywebsocket, so if you have server components of
WebSocket test cases written in Python, we can host them under
http://www.w3c-test.org/ws/

If anybody's interested in actually trying that right now, and you have
*_wsh.py handlers you'd like to have installed, we can work on getting
something set up to facilitate it.

  --Mike

-- 
Michael[tm] Smith http://people.w3.org/mike/+

--------------070505090203020005090401-- From salvatore.loreto@ericsson.com Fri Feb 24 22:25: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 68AAB21F85EC for ; Fri, 24 Feb 2012 22:25:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.72 X-Spam-Level: X-Spam-Status: No, score=-109.72 tagged_above=-999 required=5 tests=[AWL=0.878, 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 IRGmApP+vfvd for ; Fri, 24 Feb 2012 22:25:25 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 914F521F85ED for ; Fri, 24 Feb 2012 22:25:23 -0800 (PST) X-AuditID: c1b4fb39-b7bf2ae0000069a1-17-4f487ed1eb63 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B0.17.27041.1DE784F4; Sat, 25 Feb 2012 07:25:22 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Sat, 25 Feb 2012 07:25:21 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 9A7962319 for ; Sat, 25 Feb 2012 08:25:21 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 870B55218C for ; Sat, 25 Feb 2012 08:25:21 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3C82052161 for ; Sat, 25 Feb 2012 08:25:21 +0200 (EET) Message-ID: <4F487ED0.5010502@ericsson.com> Date: Sat, 25 Feb 2012 08:25:20 +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" References: <20120223203026.9020.19689.idtracker@ietfa.amsl.com> In-Reply-To: <20120223203026.9020.19689.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120223203026.9020.19689.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------080002030002040204070706" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Fwd: hybi - Requested session has been scheduled for IETF 83 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, 25 Feb 2012 06:25:26 -0000 --------------080002030002040204070706 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit FYI on HyBi meeting time at IETF 83 - note this is *draft* schedule and may change. hybi Session 1 (2 hours) Wednesday, Afternoon Session I 1300-1500 Room Name: 252B --------------080002030002040204070706 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 7bit FYI on HyBi meeting time at IETF 83 - note this is *draft* schedule and may change.

hybi Session 1 (2 hours)
    Wednesday, Afternoon Session I 1300-1500
    Room Name: 252B

--------------080002030002040204070706-- From ruoqiu.lee@gmail.com Mon Feb 27 06:38: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 3CA9F21F8737 for ; Mon, 27 Feb 2012 06:38:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.299, 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 BXAftC1nauyq for ; Mon, 27 Feb 2012 06:38:57 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3A2421F8734 for ; Mon, 27 Feb 2012 06:38:57 -0800 (PST) Received: by dakl33 with SMTP id l33so883283dak.31 for ; Mon, 27 Feb 2012 06:38:57 -0800 (PST) Received-SPF: pass (google.com: domain of ruoqiu.lee@gmail.com designates 10.68.218.231 as permitted sender) client-ip=10.68.218.231; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ruoqiu.lee@gmail.com designates 10.68.218.231 as permitted sender) smtp.mail=ruoqiu.lee@gmail.com; dkim=pass header.i=ruoqiu.lee@gmail.com Received: from mr.google.com ([10.68.218.231]) by 10.68.218.231 with SMTP id pj7mr41326133pbc.63.1330353537015 (num_hops = 1); Mon, 27 Feb 2012 06:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7wmNx5TmteB5DqIL330oWVrMeNCdyUptiwIT7/3S1So=; b=AWpeO7WFg64FMBrCiHpcAYGJXVZLgLdbEWj0Gje/JQ5Yhb7w8MeS8prxCWyjQdv4R3 VW2Be0eZri26XBIeVPDUBvpuZuSZHYFLkNNLzgGRjlpu5xAqMIw/H+7SA7xj0GEnuYAF ku3yhs99ekEv1Of14k3mYOmFAv4hxnS8gq0UM= MIME-Version: 1.0 Received: by 10.68.218.231 with SMTP id pj7mr35149069pbc.63.1330353536838; Mon, 27 Feb 2012 06:38:56 -0800 (PST) Received: by 10.68.223.36 with HTTP; Mon, 27 Feb 2012 06:38:56 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 22:38:56 +0800 Message-ID: From: Juan Li To: John Tamplin Content-Type: multipart/alternative; boundary=047d7b2ed26dfd2bc404b9f311cb Cc: hybi@ietf.org Subject: Re: [hybi] why did rfc6455 choose the 16-byte sec_websocket_key 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, 27 Feb 2012 14:38:59 -0000 --047d7b2ed26dfd2bc404b9f311cb Content-Type: text/plain; charset=ISO-8859-1 What kind of security implications? eg., how do that kind of security problems happen? Thanks, juanzi. 2012/2/20 John Tamplin > On Sun, Feb 19, 2012 at 4:38 AM, juan li wrote: > >> Why does rfc6455 choose the 16-byte sec_websocket_key? When >> encoded, it occupies 24 bytes. The sec_websocket_accept occupies 28 bytes. >> They are so long. >> Why not choose a shorter key? >> > > A shorter key has security implications, and since this happens once per > handshake the cost is negligible. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --047d7b2ed26dfd2bc404b9f311cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

What kind of security implications? eg., how do that kind of security = problems happen?

=A0

Thanks,

juanzi.

2012/2/20 John Tamplin <jat@google.com>

On Sun, Feb 19, 2012 at 4:38 AM, juan li <ruoqiu.lee@= gmail.com> wrote:

=A0=A0 =A0 =A0 Why does rfc6455 choose the 16-byte sec_websocket_key? = =A0When encoded, it occupies 24 bytes. The sec_websocket_accept occupies 28= bytes. They are so long.=A0

Why not choose a shorter key?

A shorter key has security implications, and since this happens once p= er handshake the cost is negligible.=A0
<= font color=3D"#888888">

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

--047d7b2ed26dfd2bc404b9f311cb-- From ruoqiu.lee@gmail.com Mon Feb 27 06:47: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 8F75521F873B for ; Mon, 27 Feb 2012 06:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.049 X-Spam-Level: X-Spam-Status: No, score=-3.049 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, 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 lGaujgSjajN3 for ; Mon, 27 Feb 2012 06:47:22 -0800 (PST) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id A36BA21F873A for ; Mon, 27 Feb 2012 06:47:22 -0800 (PST) Received: by dakl33 with SMTP id l33so891062dak.31 for ; Mon, 27 Feb 2012 06:47:22 -0800 (PST) Received-SPF: pass (google.com: domain of ruoqiu.lee@gmail.com designates 10.68.134.198 as permitted sender) client-ip=10.68.134.198; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ruoqiu.lee@gmail.com designates 10.68.134.198 as permitted sender) smtp.mail=ruoqiu.lee@gmail.com; dkim=pass header.i=ruoqiu.lee@gmail.com Received: from mr.google.com ([10.68.134.198]) by 10.68.134.198 with SMTP id pm6mr38984194pbb.147.1330354042533 (num_hops = 1); Mon, 27 Feb 2012 06:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U7eSVd/HsUYYLlg7EtsCbN01OBHad63vYUBH+EccOSA=; b=BAycW74A/jtu13Vvmf6sq5yz3xU5pWasZ8MJAHc87XtiVzjntX9De2lLH2HRMh6tg7 kECWJLGaH7fkSNZoMolR3wRutJJ+w4hadLos9kUx8LyXEqWHiK9Ph7NAy90mdfZAaMk4 gq0snzetVlR2mIexAC7r1PuPlJJnNdFb45s44= MIME-Version: 1.0 Received: by 10.68.134.198 with SMTP id pm6mr33266586pbb.147.1330354042364; Mon, 27 Feb 2012 06:47:22 -0800 (PST) Received: by 10.68.223.36 with HTTP; Mon, 27 Feb 2012 06:47:22 -0800 (PST) In-Reply-To: References: Date: Mon, 27 Feb 2012 22:47:22 +0800 Message-ID: From: Juan Li To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=047d7b10cb291ee39a04b9f33031 Cc: hybi@ietf.org Subject: Re: [hybi] a question about the redirect of websocket 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, 27 Feb 2012 14:47:23 -0000 --047d7b10cb291ee39a04b9f33031 Content-Type: text/plain; charset=ISO-8859-1 Do you mean that the server processing the handshake just acts as the reverse proxy of the backends? But that still occupies the resources of the server.It is not the real redirect during data framing. 2012/2/20 Takeshi Yoshino > On Thu, Feb 16, 2012 at 00:23, juan li wrote: > snip. > >> process the data frames". How to do this(A server has completed the >> handshake and then passes the connection to another server)? >> > > I think "pass the connection" in the sentence means forwarding everything > following the opening handshake to backends (possibly converted into some > in-data-center protocol) and forwarding data returned from backends to the > client. > > --047d7b10cb291ee39a04b9f33031 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Do you mean that the server processing the handshake just acts as the = reverse proxy of the backends?

But that still occupies the resources of the server.It is not the real= redirect during data framing.

2012/2/20 Takeshi Yoshino <= tyoshino@google.com>

On Thu, Feb 16, 2012 at 00:23, juan li <ruoq= iu.lee@gmail.com> wrote:

snip.

process the data frames". = How to do this(A server has completed the
handshake and then passes the = connection to another server)?

I think "pass the connection" in the sentence means=A0forwar= ding everything following the opening handshake to backends (possibly=A0con= verted into some in-data-center protocol) and forwarding data returned from= backends to the client.

--047d7b10cb291ee39a04b9f33031-- From jat@google.com Mon Feb 27 06:59: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 2C60C21F8429 for ; Mon, 27 Feb 2012 06:59:41 -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 w-M0+M-WxHbb for ; Mon, 27 Feb 2012 06:59:40 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0D021F842C for ; Mon, 27 Feb 2012 06:59:23 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1204718vbb.31 for ; Mon, 27 Feb 2012 06:59:23 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.220.232.10 as permitted sender) client-ip=10.220.232.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.220.232.10 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.220.232.10]) by 10.220.232.10 with SMTP id js10mr8256232vcb.53.1330354763580 (num_hops = 1); Mon, 27 Feb 2012 06:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=SmT2LQJeLkllMIBZeShKQn82of5PHT3FEME+AAIXiy4=; b=2iYRA7QHzczlgnFaT2ktPdZ3fUhjJbT0bA26Uon8ywIbziIzQc8W44WzRCR9Cvx+iE 9g/Q67/oxFUjZEuNBjluovOA34VKaAD3i+8PNrzqEmpRwu7GNFTsPM+HolZzzmeBOr7H RlJZME5aZ5+mQf0FjG7IxR/VVS5ln7wymwQuI= Received: by 10.220.232.10 with SMTP id js10mr6612703vcb.53.1330354763499; Mon, 27 Feb 2012 06:59:23 -0800 (PST) Received: by 10.220.232.10 with SMTP id js10mr6612680vcb.53.1330354763320; Mon, 27 Feb 2012 06:59:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Mon, 27 Feb 2012 06:59:03 -0800 (PST) In-Reply-To: References:

From: John Tamplin Date: Mon, 27 Feb 2012 09:59:03 -0500 Message-ID: To: Juan Li Content-Type: multipart/alternative; boundary=14dae9ccd4ec17cdec04b9f35b5b X-System-Of-Record: true X-Gm-Message-State: ALoCoQnf+BR6M+X7nV3t1OALQjWaNzXK37vQ2+CGT3tkT4kciQGhNODSMrRfDdkKNCVEZ23Vcv3CLDUQuhZr4NqbbqTT7gTH8nYNt6t0FMcauBSqoeWHkCWhbfgtGhebEvtJM5Oh3Lul Cc: hybi@ietf.org Subject: Re: [hybi] a question about the redirect of websocket 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, 27 Feb 2012 14:59:41 -0000 --14dae9ccd4ec17cdec04b9f35b5b Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2012 at 9:47 AM, Juan Li wrote: > Do you mean that the server processing the handshake just acts as the > reverse proxy of the backends? > But that still occupies the resources of the server.It is not the real > redirect during data framing. > The point is that such things are outside the scope of the WebSocket protocol. A large serving environment will likely have some sort of front-end loadbalancer, which chooses the appropriate server to handle the connection, handles failover, etc. That frontend might decompress, decrypt, and/or demux incoming data (perhaps in specialized hardware) before passing on the data to the ultimate endpoint. Regarding "resources of the server", it could be just like a router -- the packets continue to pass through the router, with it performing some operation on them, before continuing to the ultimate destination. That paragraph you refer to just says if the functions of a WebSocket server is split across machines, the set of physical machines implementing the WebSocket server protocol is considered the server for the purposes of the spec. -- John A. Tamplin Software Engineer (GWT), Google --14dae9ccd4ec17cdec04b9f35b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 27, 2012 at 9:47 AM, Juan Li <ruoqiu.lee@gmail.com= > wrote:

Do you mean that the server processing the handshake just acts as the = reverse proxy of the backends?

But that still occupies the resources of the server.It is not the real= redirect during data framing.

The p= oint is that such things are outside the scope of the WebSocket protocol.

A large serving environment will likely have some sort of fr= ont-end loadbalancer, which chooses the appropriate server to handle the co= nnection, handles failover, etc. =C2=A0That frontend might decompress, decr= ypt, and/or demux incoming data (perhaps in specialized hardware) before pa= ssing on the data to the ultimate endpoint.

Regarding "resources of the server", it could= be just like a router -- the packets continue to pass through the router, = with it performing some operation on them, before continuing to the ultimat= e destination.

That paragraph you refer to just says if the functions = of a WebSocket server is split across machines, the set of physical machine= s implementing the WebSocket server protocol is considered the server for t= he purposes of the spec.

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

--14dae9ccd4ec17cdec04b9f35b5b-- From jat@google.com Mon Feb 27 07:04: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 7D42121F86DF for ; Mon, 27 Feb 2012 07:04:58 -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 a0DiaBfpycbJ for ; Mon, 27 Feb 2012 07:04:58 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D65A221F86C4 for ; Mon, 27 Feb 2012 07:04:57 -0800 (PST) Received: by vbbez10 with SMTP id ez10so1210995vbb.31 for ; Mon, 27 Feb 2012 07:04:57 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.220.157.83 as permitted sender) client-ip=10.220.157.83; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.220.157.83 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.220.157.83]) by 10.220.157.83 with SMTP id a19mr9151010vcx.54.1330355097489 (num_hops = 1); Mon, 27 Feb 2012 07:04:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=g+LCclZGYukkpLurW+z+rUY/jvdY+TM2iZtgJ1tKcc4=; b=bKgTybKgtSKEZ3gzEigvR3/KbbdAwId7Ci3zjrpt/WfrWymL+fE58dveO19YLj75Mt NxjcQicnd0Zc2UyHrYK7QfDdPA40F2IbmbO8VQEuRc48m/qodEG6evx6eFlP4BslYw+H JVQLEOik72FzSZgFiMMbhpQbtJ3dBMt/75ZNI= Received: by 10.220.157.83 with SMTP id a19mr7350215vcx.54.1330355097426; Mon, 27 Feb 2012 07:04:57 -0800 (PST) Received: by 10.220.157.83 with SMTP id a19mr7350190vcx.54.1330355097285; Mon, 27 Feb 2012 07:04:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Mon, 27 Feb 2012 07:04:37 -0800 (PST) In-Reply-To: References: From: John Tamplin Date: Mon, 27 Feb 2012 10:04:37 -0500 Message-ID: To: Juan Li Content-Type: multipart/alternative; boundary=f46d043c07beffb44004b9f36ea8 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmB/vmSGA34vYLzGI6pee4WqyoR6fw/iq0aTtxVMD74tapohJWlEXHjtvFM/rTB+HJStyJNgEWWuCCCc6qIrQiw/vMfCch0A3HR1S9Xqg/oF2UjsFzGFIQjQq/zMSf0BJ/KNlq+ Cc: hybi@ietf.org Subject: Re: [hybi] why did rfc6455 choose the 16-byte sec_websocket_key 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, 27 Feb 2012 15:04:58 -0000 --f46d043c07beffb44004b9f36ea8 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2012 at 9:38 AM, Juan Li wrote: > What kind of security implications? eg., how do that kind of security > problems happen? > The probability of guessing the key is inversely proportional to the number of possible keys. The primary point is to make sure that the server actually speaks the WebSocket protocol, so the security implication would be allowing an attacker to use a WebSocket client (which will run in every browser and be able to connect to any server, since it is not subject to same-origin policy) to attack a non-WebSocket server if he can somehow trick the client into thinking it is a WebSocket server. A smaller key would increase the probability of generating a collision in the Sec-WebSocket-Accept, which means a server that can be made to echo back attacker-controlled values but which does not implement the WebSocket handshake could be made to pass the handshake anyway. Again, this happens once per connection, so the size isn't a significant concern. -- John A. Tamplin Software Engineer (GWT), Google --f46d043c07beffb44004b9f36ea8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Feb 27, 2012 at 9:38 AM, Juan Li <ru= oqiu.lee@gmail.com> wrote:

What kind of security implications? eg., how do that kind of security = problems happen?

The probability of g= uessing the key is inversely proportional to the number of possible keys.

The primary point is to make sure that the server actua= lly speaks the WebSocket protocol, so the security implication would be all= owing an attacker to use a WebSocket client (which will run in every browse= r and be able to connect to any server, since it is not subject to same-ori= gin policy) to attack a non-WebSocket server if he can somehow trick the cl= ient into thinking it is a WebSocket server. =C2=A0A smaller key would incr= ease the probability of generating a collision in the Sec-WebSocket-Accept,= which means a server that can be made to echo back attacker-controlled val= ues but which does not implement the WebSocket handshake could be made to p= ass the handshake anyway.

Again, this happens once per connection, so the size is= n't a significant concern.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--f46d043c07beffb44004b9f36ea8-- From salvatore.loreto@ericsson.com Mon Feb 27 23:42: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 5F67E21F8673 for ; Mon, 27 Feb 2012 23:42:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.77 X-Spam-Level: X-Spam-Status: No, score=-109.77 tagged_above=-999 required=5 tests=[AWL=0.828, 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 F7rbBi9VHkag for ; Mon, 27 Feb 2012 23:42:36 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2720821F866D for ; Mon, 27 Feb 2012 23:42:35 -0800 (PST) X-AuditID: c1b4fb3d-b7bb7ae0000007b2-33-4f4c856af05c Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 96.0C.01970.A658C4F4; Tue, 28 Feb 2012 08:42:34 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Tue, 28 Feb 2012 08:42:33 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B2ADD2306; Tue, 28 Feb 2012 09:42:33 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A47BB5219B; Tue, 28 Feb 2012 09:42:33 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 48A035206D; Tue, 28 Feb 2012 09:42:33 +0200 (EET) Message-ID: <4F4C8568.7070403@ericsson.com> Date: Tue, 28 Feb 2012 09:42:32 +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="------------080506060801000205000203" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Gabriel Montenegro , SM Subject: [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, 28 Feb 2012 07:42:37 -0000 --------------080506060801000205000203 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit 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 --------------080506060801000205000203 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit 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

--------------080506060801000205000203-- From jat@google.com Tue Feb 28 06:06: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 5710121F8664 for ; Tue, 28 Feb 2012 06:06:24 -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 cJGyGLO4VTzk for ; Tue, 28 Feb 2012 06:06:18 -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 182BA21F85C5 for ; Tue, 28 Feb 2012 06:06:13 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so1766261vcb.31 for ; Tue, 28 Feb 2012 06:06:13 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.52.38.102 as permitted sender) client-ip=10.52.38.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.52.38.102 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.52.38.102]) by 10.52.38.102 with SMTP id f6mr13036571vdk.70.1330437973466 (num_hops = 1); Tue, 28 Feb 2012 06:06:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=Hq329QE/RKBqO4YotanVGQ1/Rfw9PqDGS/DsLVOTbVQ=; b=OeOKprCTF1qLEQTih0AEse1ihOLjQ9YicAhX/wMfJ0g4pxVQ5I5dX4lfIzlk6SMjY+ Y9b+25br/Dk0YVJAnz+qKsAi6snIK1cDNZhXkz65PMo6buxc+WTvi4PX6fgdWBjHoIWc BPEgNAeJuJOc3bsc7z0u4Ms0n3sipg1ey0woo= Received: by 10.52.38.102 with SMTP id f6mr10758321vdk.70.1330437973418; Tue, 28 Feb 2012 06:06:13 -0800 (PST) Received: by 10.52.38.102 with SMTP id f6mr10758304vdk.70.1330437973305; Tue, 28 Feb 2012 06:06:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Tue, 28 Feb 2012 06:05:53 -0800 (PST) In-Reply-To: <4F4C8568.7070403@ericsson.com> References: <4F4C8568.7070403@ericsson.com> From: John Tamplin Date: Tue, 28 Feb 2012 09:05:53 -0500 Message-ID: To: Salvatore Loreto Content-Type: multipart/alternative; boundary=bcaec51d20d8cb6a4204ba06babd X-System-Of-Record: true X-Gm-Message-State: ALoCoQnU56WG1FYOGAbOKkeFUqVaVoaNpRnjFDKT1waMAStAA40v+pGTsknmFUpq5ZVYlRq+y23KazWq45JJjx546BCfY5+8XgdrFI6kACy4lxk8cTkijeDmU4rhm+MkjkhnY4UuWiri 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: Tue, 28 Feb 2012 14:06:24 -0000 --bcaec51d20d8cb6a4204ba06babd Content-Type: text/plain; charset=UTF-8 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. -- John A. Tamplin Software Engineer (GWT), Google --bcaec51d20d8cb6a4204ba06babd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2012 at 2:42 AM, Salvatore Loret= o <sa= lvatore.loreto@ericsson.com> wrote:

=20 =20 =20
the first optimization/extensio= n (or milestone if you prefer)
in the new approved HyBi charter (see ht= tp://tools.ietf.org/wg/hybi/charters )
is about:
=20
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=C2=A0 has already received comments, suggestions and feedback;
and=C2=A0 Takeshi has produced several new versions to address the rais= ed 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 extensi=
on

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

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--bcaec51d20d8cb6a4204ba06babd-- From tyoshino@google.com Tue Feb 28 08:47: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 CA3A721F8698 for ; Tue, 28 Feb 2012 08:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.033, 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 UvQdtCZV2cBs for ; Tue, 28 Feb 2012 08:47:02 -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 D788E21F867A for ; Tue, 28 Feb 2012 08:47:01 -0800 (PST) Received: by yenm5 with SMTP id m5so1012070yen.31 for ; Tue, 28 Feb 2012 08:47:01 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.236.185.97 as permitted sender) client-ip=10.236.185.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.236.185.97 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.236.185.97]) by 10.236.185.97 with SMTP id t61mr29822831yhm.100.1330447621477 (num_hops = 1); Tue, 28 Feb 2012 08:47:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=TSnVKyYAkaZUvT54n5O3Zok7T9gUzleR++QNNy09dOU=; b=oMKm1pbS8ri1+7snS/1ICmtlRXamweTXLAqrbUK1tHJEylsYFivq/rPi6kNdRn8el+ CHWytOstpQpbNilhIhNpXJfwo7NaLbtl37L1+3+4tXUrgl6WF1qyPrfjbNPSSl3v6Tph M30vUxghDt/Vzxd2zSl449ZaL/e1grPzNeHhw= Received: by 10.236.185.97 with SMTP id t61mr22518746yhm.100.1330447621296; Tue, 28 Feb 2012 08:47:01 -0800 (PST) Received: by 10.236.185.97 with SMTP id t61mr22518714yhm.100.1330447620985; Tue, 28 Feb 2012 08:47:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.236.35 with HTTP; Tue, 28 Feb 2012 08:46:40 -0800 (PST) From: Takeshi Yoshino Date: Tue, 28 Feb 2012 11:46:40 -0500 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf305e2497d7525204ba08f94b X-System-Of-Record: true X-Gm-Message-State: ALoCoQlxFnOJK2Lf9UxhTE2ljjsjqfK69VT8Qp6F0p5kmzGs5xE/s85BOk356GWGY8/DyIiClSx310l61JtWDNX8BIj8PRTjVT9v8wCYQGSEYY3iHJRDteF6KJ3R08h9l/3POCSmAxeH Subject: [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, 28 Feb 2012 16:47:02 -0000 --20cf305e2497d7525204ba08f94b Content-Type: text/plain; charset=ISO-8859-1 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 --20cf305e2497d7525204ba08f94b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable htt= p://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03

Diff=A0http://tools.ietf.org/rfcdiff?url2=3Ddraft-tamplin-h= ybi-google-mux-03.txt

- Added a section to describe terms "physica= l channel" and "logical channel"

- Now the order o= f 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=A0http://www.ietf.org/mail-archive/web/hybi/current= /msg09410.html

- Added note discussing how implementors should design quota assignmen= t to avoid starvation, etc.

-- based on=A0http://www.ietf.org/ma= il-archive/web/hybi/current/msg09402.html

- Defined operation identifiers such as _Fail the Physical Channel_

- Clarified how events, operations on logical/physical channels mus= t be handled

- Revised layout of section 7 for readability

- Added DropChannel command to handle logical channel level errors

- Added "Timeout" section

--20cf305e2497d7525204ba08f94b-- From tobias.oberstein@tavendo.de Tue Feb 28 09:41: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 485ED21F8613 for ; Tue, 28 Feb 2012 09:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMK7BLDn4ysA for ; Tue, 28 Feb 2012 09:41:09 -0800 (PST) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4B09421F85F6 for ; Tue, 28 Feb 2012 09:41:09 -0800 (PST) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.228]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Tue, 28 Feb 2012 09:41:08 -0800 From: Tobias Oberstein To: "hybi@ietf.org" Date: Tue, 28 Feb 2012 09:41:05 -0800 Thread-Topic: [hybi] Multiplexing extension spec draft 03 Thread-Index: Acz2OJ1dqU9DQLZbQBqArGB9riMPzAABoNYw Message-ID: <634914A010D0B943A035D226786325D42D5992F76E@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 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, 28 Feb 2012 17:41:10 -0000 >>- Now the order of extensions in Sec-WebSocket-Extensions determines wher= e those extensions are applied to frames (before or after (de)multiplexing) Huh. _Order is significant_ ?? Is that even supported by the WS base spec? If so, is there precedence with= other HTTP headers introducing order sign.? Somehow I feel uncomfortable with introducing order sign. in a header ..=20 And what if Sec-WebSocket-Extensions header appears more than once (don't r= emember right now if thats allowed for that specific header)? If so, aren't intermediaries al= lowed to reorder headers? From tyoshino@google.com Tue Feb 28 11:01:20 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 5DBE221F86C7 for ; Tue, 28 Feb 2012 11:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.946 X-Spam-Level: X-Spam-Status: No, score=-102.946 tagged_above=-999 required=5 tests=[AWL=0.030, 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 zcA1hjl4gLmg for ; Tue, 28 Feb 2012 11:01:19 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 180DC21F86AD for ; Tue, 28 Feb 2012 11:01:18 -0800 (PST) Received: by yhpp34 with SMTP id p34so1243683yhp.31 for ; Tue, 28 Feb 2012 11:01:18 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.236.174.106 as permitted sender) client-ip=10.236.174.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.236.174.106 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.236.174.106]) by 10.236.174.106 with SMTP id w70mr30111747yhl.68.1330455678709 (num_hops = 1); Tue, 28 Feb 2012 11:01:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=xX+EDLTfCEkOsSobGMBaq2VBXabOF0OH1GTvUjluzdw=; b=1BE4IjJytzhd2VjPK+9Y9c4VUQYesyDmFgda0gWSorHmIdglUkDKB/uzOx75EqPcpU f7fnjMLQF+iTlzAWZ9iHX+thpf7kkoiLH4lJZUCvRZDdsFqiqXe8HmgjZsn5dagvq+2j W7TxRoVtF97TqL+IvuVfN2gT0DChWBiuI9Ncg= Received: by 10.236.174.106 with SMTP id w70mr22834205yhl.68.1330455678590; Tue, 28 Feb 2012 11:01:18 -0800 (PST) Received: by 10.236.174.106 with SMTP id w70mr22834187yhl.68.1330455678436; Tue, 28 Feb 2012 11:01:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Tue, 28 Feb 2012 11:00:58 -0800 (PST) In-Reply-To: <634914A010D0B943A035D226786325D42D5992F76E@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D5992F76E@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Tue, 28 Feb 2012 14:00:58 -0500 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=20cf3040e3bc1a48b104ba0ada7c X-System-Of-Record: true X-Gm-Message-State: ALoCoQkQUvV+GnF7H+bcpF9yIhPweuRsIG1SVzb4Rvo1hMWaJy0by2Plmxx/wqpKhPXF43PVfZRb3EsImBiZW2L2A4z62Ue4IAzg7DSWmHKnsxz6vlsKXvvzRdom/QEndmbeufi3WnnG 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, 28 Feb 2012 19:01:20 -0000 --20cf3040e3bc1a48b104ba0ada7c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 28, 2012 at 12:41, Tobias Oberstein wrote: > >>- Now the order of extensions in Sec-WebSocket-Extensions determines > where those extensions are applied to frames (before or after > (de)multiplexing) > > Huh. _Order is significant_ ?? > > Is that even supported by the WS base spec? Yes, as noted in http://tools.ietf.org/html/rfc6455#section-9.1 > If so, is there precedence with other HTTP headers introducing order sign.? > What kind of HTTP headers are you worrying about? > > Somehow I feel uncomfortable with introducing order sign. in a header .. > > And what if Sec-WebSocket-Extensions header appears more than once (don't > remember right now > if thats allowed for that specific header)? If so, aren't intermediaries > allowed to reorder headers? > > As described in RFC 6455 p48. HTTP (RFC 2616) also prohibits reordering such multiple header entries. See the section 4.2 Message Headers. --20cf3040e3bc1a48b104ba0ada7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2012 at 12:41, Tobias Oberstein = <tobias= .oberstein@tavendo.de> wrote:

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

Huh. _Order is significant_ ??

Is that even supported by the WS base spec?

Yes, as noted in=A0http://tools.ietf.org/html/rfc6455#section-9.1

=A0

If so, is there precede= nce with other HTTP headers introducing order sign.?

<= br>

What kind of HTTP headers are you worrying about?=A0

= =A0

Somehow I feel uncomfortable with introducing order sign. in a header ..

And what if Sec-WebSocket-Extensions header appears more than once (don'= ;t remember right now
if thats allowed for that specific header)? If so, aren't intermediarie= s allowed to reorder headers?

As described in RFC 6455 p48.

HTTP (RFC 2616) also prohibits reordering such multiple he= ader entries. See the section 4.2 Message Headers.

--20cf3040e3bc1a48b104ba0ada7c-- From tobias.oberstein@tavendo.de Tue Feb 28 11:52: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 2485C11E8072 for ; Tue, 28 Feb 2012 11:52:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rSwHvhh7csK for ; Tue, 28 Feb 2012 11:52:38 -0800 (PST) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB5E21F86DE for ; Tue, 28 Feb 2012 11:52:38 -0800 (PST) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.228]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Tue, 28 Feb 2012 11:52:37 -0800 From: Tobias Oberstein To: Takeshi Yoshino Date: Tue, 28 Feb 2012 11:52:35 -0800 Thread-Topic: [hybi] Multiplexing extension spec draft 03 Thread-Index: Acz2S1ttb++0kWhaQNyIE6e7v7PWpwABkS6g Message-ID: <634914A010D0B943A035D226786325D42D5992F87A@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D5992F76E@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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, 28 Feb 2012 19:52:41 -0000 >>>- Now the order of extensions in Sec-WebSocket-Extensions determines whe= re those extensions are applied to frames (before or after (de)multiplexing= ) >>Huh. _Order is significant_ ?? >> >>Is that even supported by the WS base spec? > >Yes, as noted in=A0http://tools.ietf.org/html/rfc6455#section-9.1=20 Ok. Sorry. Thanks for pointing out! =A0 >>If so, is there precedence with other HTTP headers introducing order sign= .? > >What kind of HTTP headers are you worrying about?=A0 I was wondering whether _outside_ of WS, there is a case with HTTP headers where order is significant. Or is this order significance of that particular header a exotic "specialit= y" of WS? From jat@google.com Tue Feb 28 12: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 0CDD121E8051 for ; Tue, 28 Feb 2012 12:00: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=[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 Po378Mp9upbw for ; Tue, 28 Feb 2012 12:00:52 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 085A221E8063 for ; Tue, 28 Feb 2012 12:00:49 -0800 (PST) Received: by vbbez10 with SMTP id ez10so2667177vbb.31 for ; Tue, 28 Feb 2012 12:00:49 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.52.19.196 as permitted sender) client-ip=10.52.19.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.52.19.196 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.52.19.196]) by 10.52.19.196 with SMTP id h4mr14175037vde.91.1330459249085 (num_hops = 1); Tue, 28 Feb 2012 12:00:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=ZVb0DrCt6sV0J0Upo+mTNOlGTI1UVB/oHELuqqaZg4U=; b=OC/qP313FWfoMAH7URIj2f9PtFPas9zxO/oSbG41KRhMWF0abP+HnzHEG5INFlzrMI pr8kZM3XDiv28Uy8CW7xze68qyvLqL0YB7vtDcv96nB9TGvOEWWtLzPw/S9KYc9B+d25 HpKDMHBKS87ZBt4tC5BCBJU07+oUcK2ayPdIQ= Received: by 10.52.19.196 with SMTP id h4mr11784262vde.91.1330459248764; Tue, 28 Feb 2012 12:00:48 -0800 (PST) Received: by 10.52.19.196 with SMTP id h4mr11784251vde.91.1330459248670; Tue, 28 Feb 2012 12:00:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Tue, 28 Feb 2012 12:00:28 -0800 (PST) In-Reply-To: <634914A010D0B943A035D226786325D42D5992F87A@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D5992F76E@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D42D5992F87A@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Tue, 28 Feb 2012 15:00:28 -0500 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=20cf307ca01ae7b93604ba0bae14 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlDeS4v9XbfH+zfikextXKlJllc8rajqumEaEExavzZpFLnZt6GWzimzA+6O5rQgxmUPsClZb4YPMRQw2wLanB+tDNhsPinDuQZsfz7lUXkJ+6Rjd3KFkMumgwjPKdi96CjySDm 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, 28 Feb 2012 20:00:54 -0000 --20cf307ca01ae7b93604ba0bae14 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2012 at 2:52 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > I was wondering whether _outside_ of WS, there is a case with HTTP headers > where order is significant. > Isn't Accept-Encoding/etc sensitive to the order (in the case of equal q values)? -- John A. Tamplin Software Engineer (GWT), Google --20cf307ca01ae7b93604ba0bae14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 28, 2012 at 2:52 PM, Tobias Oberstei= n <tobi= as.oberstein@tavendo.de> wrote:

I was wondering whether _outside_ of WS, there is a case = with HTTP headers
where order is significant.

Isn't A= ccept-Encoding/etc sensitive to the order (in the case of equal q values)?<= /div>

--
John A. Tamplin
Software Engineer (GWT)= , Google
--20cf307ca01ae7b93604ba0bae14-- From tobias.oberstein@tavendo.de Tue Feb 28 14:58: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 29FF321E8044 for ; Tue, 28 Feb 2012 14:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yr1PKAp+u1lN for ; Tue, 28 Feb 2012 14:58:43 -0800 (PST) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 98B8A21E8035 for ; Tue, 28 Feb 2012 14:58:43 -0800 (PST) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.228]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Tue, 28 Feb 2012 14:58:42 -0800 From: Tobias Oberstein To: John Tamplin Date: Tue, 28 Feb 2012 14:58:39 -0800 Thread-Topic: [hybi] Multiplexing extension spec draft 03 Thread-Index: Acz2U669iuteRcdxRnmMCwyoesCi6QAGGRBg Message-ID: <634914A010D0B943A035D226786325D42D5992F9C6@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D5992F76E@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D42D5992F87A@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" 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, 28 Feb 2012 22:58:44 -0000 Pj5JIHdhcyB3b25kZXJpbmcgd2hldGhlciBfb3V0c2lkZV8gb2YgV1MsIHRoZXJlIGlzIGEgY2Fz ZSB3aXRoIEhUVFAgaGVhZGVycw0KPj53aGVyZSBvcmRlciBpcyBzaWduaWZpY2FudC4NCj4NCj5J c24ndCBBY2NlcHQtRW5jb2RpbmcvZXRjIHNlbnNpdGl2ZSB0byB0aGUgb3JkZXIgKGluIHRoZSBj YXNlIG9mIGVxdWFsIHEgdmFsdWVzKT8NCg0KRG9uJ3Qga25vdyBmb3Igc3VyZSwgYnV0IHRoYXQg d291bGQgbWFrZSBzZW5zZS4gSWYgc28sIHRoZW4gdGhlcmUgaXMgYSB3aWRlLXNwcmVhZA0KInBy ZWNlZGVuY2UgY2FzZSIgZm9yIG9yZGVyIHNpZ25pZmljYW5jZSBpbiBIVFRQIGhlYWRlci4gU28g SSByZXRyYWN0IHRoaXMgcG9pbnQgLS0NCg== From gregw@intalio.com Tue Feb 28 15:10: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 9971421F851A for ; Tue, 28 Feb 2012 15:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.649, 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 FF0vDUK29j1d for ; Tue, 28 Feb 2012 15:10:26 -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 37D7E21F8518 for ; Tue, 28 Feb 2012 15:10:26 -0800 (PST) Received: by obbeh20 with SMTP id eh20so3902360obb.31 for ; Tue, 28 Feb 2012 15:10:25 -0800 (PST) Received-SPF: pass (google.com: domain of gregw@intalio.com designates 10.60.22.40 as permitted sender) client-ip=10.60.22.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gregw@intalio.com designates 10.60.22.40 as permitted sender) smtp.mail=gregw@intalio.com Received: from mr.google.com ([10.60.22.40]) by 10.60.22.40 with SMTP id a8mr7086688oef.59.1330470625794 (num_hops = 1); Tue, 28 Feb 2012 15:10:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.22.40 with SMTP id a8mr6291865oef.59.1330470625244; Tue, 28 Feb 2012 15:10:25 -0800 (PST) Received: by 10.60.55.166 with HTTP; Tue, 28 Feb 2012 15:10:25 -0800 (PST) In-Reply-To: <4F4C8568.7070403@ericsson.com> References: <4F4C8568.7070403@ericsson.com> Date: Wed, 29 Feb 2012 10:10:25 +1100 Message-ID: From: Greg Wilkins To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=e89a8fb205d200756804ba0e5566 X-Gm-Message-State: ALoCoQkEBIShUh9FCkrVCEDqstzE85Sz6d6/JuQhT27rB3bwwDcZNI0qsmUujsPQNmKwqhv/ex9J 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, 28 Feb 2012 23:10:27 -0000 --e89a8fb205d200756804ba0e5566 Content-Type: text/plain; charset=ISO-8859-1 +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. cheers On 28 February 2012 18:42, 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 Loretowww.sloreto.com > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --e89a8fb205d200756804ba0e5566 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

+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

cheers

On 28 February 2012 18:42,= Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:
=20 =20 =20

Hi there,

the first optimization/extension (or milestone if you prefer)
in the new approved HyBi charter (see ht= tp://tools.ietf.org/wg/hybi/charters )
is about:
=20

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=A0 has already received comments, suggestions and feedback;
and=A0 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 extensi=
on

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

Ciao
Salvatore and Gabriel

--=20
Salvatore Loreto
www.sloreto.com

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

--e89a8fb205d200756804ba0e5566-- From julian.reschke@gmx.de Tue Feb 28 15:11: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 3BB0C21F8518 for ; Tue, 28 Feb 2012 15:11:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.305 X-Spam-Level: X-Spam-Status: No, score=-104.305 tagged_above=-999 required=5 tests=[AWL=-1.706, 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 oNg0evqmV+t4 for ; Tue, 28 Feb 2012 15:11:29 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B4F9821E8035 for ; Tue, 28 Feb 2012 15:11:28 -0800 (PST) Received: (qmail invoked by alias); 28 Feb 2012 23:11:27 -0000 Received: from p3EE2676A.dip.t-dialin.net (EHLO [192.168.178.36]) [62.226.103.106] by mail.gmx.net (mp002) with SMTP; 29 Feb 2012 00:11:27 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+2uHV+yiy2fBZ/6IergOV+56Ja4jmh5Grb1SnDbe 7Rf6LPg8cHjJHV Message-ID: <4F4D5F1C.8080607@gmx.de> Date: Wed, 29 Feb 2012 00:11:24 +0100 From: Julian Reschke 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: Tobias Oberstein References: <634914A010D0B943A035D226786325D42D5992F76E@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D42D5992F76E@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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, 28 Feb 2012 23:11:36 -0000 On 2012-02-28 18:41, Tobias Oberstein wrote: >>> - Now the order of extensions in Sec-WebSocket-Extensions determines where those extensions are applied to frames (before or after (de)multiplexing) > > Huh. _Order is significant_ ?? > > Is that even supported by the WS base spec? If so, is there precedence with other HTTP headers introducing order sign.? > > Somehow I feel uncomfortable with introducing order sign. in a header .. > > And what if Sec-WebSocket-Extensions header appears more than once (don't remember right now > if thats allowed for that specific header)? If so, aren't intermediaries allowed to reorder headers? "Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded." But that doesn't necessarily mean it's a good idea. Best regards, Julian From w@1wt.eu Tue Feb 28 15:53: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 8431121E8073 for ; Tue, 28 Feb 2012 15:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.582 X-Spam-Level: X-Spam-Status: No, score=-5.582 tagged_above=-999 required=5 tests=[AWL=-3.539, 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 SweVXhbZ6hDH for ; Tue, 28 Feb 2012 15:53:34 -0800 (PST) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id B010C21E806C for ; Tue, 28 Feb 2012 15:53:33 -0800 (PST) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id q1SNrU78030569; Wed, 29 Feb 2012 00:53:30 +0100 Date: Wed, 29 Feb 2012 00:53:30 +0100 From: Willy Tarreau To: Greg Wilkins Message-ID: <20120228235330.GC29361@1wt.eu> References: <4F4C8568.7070403@ericsson.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] 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, 28 Feb 2012 23:53:34 -0000 On Wed, Feb 29, 2012 at 10:10:25AM +1100, 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. +1, same here :-) Willy From gregw@intalio.com Tue Feb 28 16:03: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 73B5221E806F for ; Tue, 28 Feb 2012 16:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Y0km2jn4INqQ for ; Tue, 28 Feb 2012 16:03:20 -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 7CA4C21E8051 for ; Tue, 28 Feb 2012 16:03:20 -0800 (PST) Received: by obbeh20 with SMTP id eh20so3958632obb.31 for ; Tue, 28 Feb 2012 16:03:20 -0800 (PST) Received-SPF: pass (google.com: domain of gregw@intalio.com designates 10.60.5.138 as permitted sender) client-ip=10.60.5.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gregw@intalio.com designates 10.60.5.138 as permitted sender) smtp.mail=gregw@intalio.com Received: from mr.google.com ([10.60.5.138]) by 10.60.5.138 with SMTP id s10mr2537349oes.66.1330473800211 (num_hops = 1); Tue, 28 Feb 2012 16:03:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.5.138 with SMTP id s10mr2209728oes.66.1330473800107; Tue, 28 Feb 2012 16:03:20 -0800 (PST) Received: by 10.60.55.166 with HTTP; Tue, 28 Feb 2012 16:03:20 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 11:03:20 +1100 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=e89a8ff252ce3d075804ba0f120d X-Gm-Message-State: ALoCoQk1+I9tit3JhFav02CUj+niK2KpMmHJwHCcg99gysgBrZZdCFa+6sT3SqE6ZxO2UW3YvKdC 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, 29 Feb 2012 00:03:21 -0000 --e89a8ff252ce3d075804ba0f120d Content-Type: text/plain; charset=ISO-8859-1 Some comments 3. If WebSocket payload data is masked by a per-frame key, such masking is applied to frames for each logical channel separately. I'm not sure what it means to apply masking to a logical channel separately? Surely a mask is applied to the frame that carries it before the MUX extension interprets the payload? 5. Flow Control Each logical channel, including the implicitly created channel 1, is initially given a quota of bytes that may be transmitted in each direction without acknowledgement. It is illegal to send more bytes than the remaining send quota, and the receiver MUST _Fail the Logical Channel_ for any sender that does so. Should this not be a failure of the physical channel as it indicates a failure of the other ends MUX implementation? This send quota is replenished via control frames as the receiver processes the data. s/This/The/ 7. Multiplex Control Frames nice clarifications in this section! - specifically "Objectve channel ID" Is the text diagram a standard? I find the + - - - - - + lines confusing and would prefer to see: 0 1 2 3 4 5 6 7 +---------------+ | Objective | : channel ID : | (8-32) | +-----+---------+ | Opc | Opcdata | +-----+---------+ | Additional | : data : | (0-? | +---------------+ 7.1. Multiplex Control Opcodes 0 - AddChannel request (only from client) Create a new logical channel, exactly as if a new connection were received on a separate transport connection, s/exactly // s/a new logical channel/the objective channel/ probably need to state somewhere that it is an error to add and already added channel. 0 - uncompressed This is a bad name for this encoding scheme as it implies there is a compressed scheme (OK delta encoding is a compression... but you know what I mean). How about calling this "absolute" or "complete" or "plain" ? The initial quota for the new logical channel is 0, so the client may not send any data for this connection until the AddChannel response is received. Does this mean that control frames can be sent for a channel before the add channel response is received? 3 - DropChannel Can a dropped channel be readded later? 11. Fairness A multiplexing implementation MUST ensure reasonable fairness among the logical channels. This is accomplished in several ways: Receiver side o The receiver MAY limit the other peer's send quota of a logical channel by not replenishing the send quota to make sure that any logical channel cannot dominate its buffer space on the sender. s/on the sender// as it is the buffer space on the receiver that is of concern Also we should say that the receiver does not need to process frames from different logical channels serially. ie the processing of a message from a logical channel should not defer the processing of messages on other logical channels. o The sender MUST fragment a message into smaller frames when it's too big so that that logical channel will occupy the connection and the other logical channels get stuck for long time. Cumbersome. How about: The sender MUST fragment a large message into smaller frames to prevent a large message in a logical channel occupying the physical channel and thus delaying messages in other logical channels. o Logical channel frames that are sent SHOULD be limited in size (such as by refragmenting) when there is contention for the physical channel to minimize head-of-line blocking How is this different from the previous? 13. Nesting I think we should disallow nesting. Any intermediary that wants to MUX channels understands MUX, so it can flatten. cheers --e89a8ff252ce3d075804ba0f120d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Some comments

3.

   If WebSocket p=
ayload data is masked by a per-frame key, such masking
   is applied to frames for each logical channel separately.

I'm not sure what it means to apply masking to a logical chan= nel separately?=A0 Surely a mask is applied to the frame that carries it be= fore the MUX extension interprets the payload?

5.  Flow Control   Each logical channel, including the implicitly created channel 1, is
   initially given a quota of bytes that may be transmitted in each
   direction without acknowledgement.  It is illegal to send more bytes
   than the remaining send quota, and the receiver MUST _Fail the
   Logical Channel_ for any sender that does so.

Should this not be a= failure of the physical channel as it indicates a failure of the other end= s MUX implementation?

   This send quota is
   replenished via control frames as the receiver processes the data.

s/This/The/

7.  Multiplex Control Frames

nice cl= arifications in this section! - specifically "Objectve channel ID"= ;

Is the text diagram a standard?=A0 I find the + - - - - - + lines confu= sing and would prefer to see:

      0 1 2 3 4=
 5 6 7
     +---------------+
     | Objective     |
     : channel ID    :
     | (8-32)        |
     +-----+---------+
     | Opc | Opcdata |
     +-----+---------+
     | Additional    |
     : data          :
     | (0-?          |
     +---------------+

<=
h3>7.1.  Multiplex Control Opcodes =
  0 - AddChannel request (only from client)
      Create a new logical channel, exactly as if a new connection were
      received on a separate transport connection,

s/exactly //
s/a new logical channel/the objective channel/
probably need to state somewhere that it is an error to add and already ad= ded channel.



      0 - uncompressed
=

This is a bad name for this encoding scheme as it implies = there is a compressed scheme (OK delta encoding is a compression... but you= know what I mean).=A0=A0 How about calling this "absolute" or &q= uot;complete" or "plain" ?

      The initial quota for the new logical chan=
nel is 0, so the client
      may not send any data for this connection until the AddChannel
      response is received.

Does this mean that control frames can= be sent for a channel before the add channel response is received?

=

   3 - DropChannel

Can a dropped channel be rea= dded later?

11=
.  Fairness

   A multiplexing implementation MUST ensure reasonable fairness among
   the logical channels.  This is accomplished in several ways:

   Receiver side

   o  The receiver MAY limit the other peer's send quota of a logical
      channel by not replenishing the send quota to make sure that any
      logical channel cannot dominate its buffer space on the sender.

s/on the sender//=A0=A0 as it is the buffer space on the receiver= that is of concern

Also we should say that the receiver does not ne= ed to process frames from different logical channels serially.=A0 ie the pr= ocessing of a message from a logical channel should not defer the processin= g of messages on other logical channels.

   o  The sender MUST fragment a message into sm=
aller frames when it's
      too big so that that logical channel will occupy the connection
      and the other logical channels get stuck for long time.

Cumbersome.=A0 How about: The sender MUST fragment a large message in= to smaller frames to prevent a large message in a logical channel occupying= the physical channel and thus delaying messages in other logical channels.=

   o  Logical channel frames that are sent SHOUL=
D be limited in size
      (such as by refragmenting) when there is contention for the
      physical channel to minimize head-of-line blocking

How is this d= ifferent from the previous?

13.  Nesting

I th= ink we should disallow nesting.=A0 Any intermediary that wants to MUX chann= els understands MUX, so it can flatten.

cheers

--e89a8ff252ce3d075804ba0f120d-- From theturtle32@gmail.com Tue Feb 28 16:23: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 9E5CD21F85EC for ; Tue, 28 Feb 2012 16:23:23 -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 Uh19ULQCA2WE for ; Tue, 28 Feb 2012 16:23:22 -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 9CA6221F8589 for ; Tue, 28 Feb 2012 16:23:22 -0800 (PST) Received: by obbeh20 with SMTP id eh20so3981219obb.31 for ; Tue, 28 Feb 2012 16:23:22 -0800 (PST) Received-SPF: pass (google.com: domain of theturtle32@gmail.com designates 10.60.7.102 as permitted sender) client-ip=10.60.7.102; Authentication-Results: mr.google.com; spf=pass (google.com: domain of theturtle32@gmail.com designates 10.60.7.102 as permitted sender) smtp.mail=theturtle32@gmail.com; dkim=pass header.i=theturtle32@gmail.com Received: from mr.google.com ([10.60.7.102]) by 10.60.7.102 with SMTP id i6mr7757309oea.9.1330475002348 (num_hops = 1); Tue, 28 Feb 2012 16:23:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RX8YpML13HgDIV3iS8MKMtcoklKmpz4XaTEa77q08bs=; b=b85U3TME/+pwZzN0KodsGAZuPAndfZRrHV52fC6dLBsnpF7kAseZ+AuuSGaRt1LtJ9 ZeWFS7ZIRXgsVoWGHRHFEEpyd5vOfir0Qhg06LsJ2WWZN3Kj+YLZgWtfn7PG0RuGJz8Q 6H0Mt2bKStIl9Ja/c5cvvOnYa/+iM7/xyyJaQ= MIME-Version: 1.0 Received: by 10.60.7.102 with SMTP id i6mr6876697oea.9.1330475002102; Tue, 28 Feb 2012 16:23:22 -0800 (PST) Received: by 10.182.89.74 with HTTP; Tue, 28 Feb 2012 16:23:22 -0800 (PST) In-Reply-To: References: <4F4C8568.7070403@ericsson.com> Date: Tue, 28 Feb 2012 16:23:22 -0800 Message-ID: From: Brian To: Greg Wilkins Content-Type: multipart/alternative; boundary=e89a8fb2050ae2042804ba0f5960 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: Wed, 29 Feb 2012 00:23:23 -0000 --e89a8fb2050ae2042804ba0f5960 Content-Type: text/plain; charset=ISO-8859-1 +1 :-D Brian On Tue, Feb 28, 2012 at 3:10 PM, 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. > > cheers > > > On 28 February 2012 18:42, 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 Loretowww.sloreto.com >> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --e89a8fb2050ae2042804ba0f5960 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 =A0:-D

Brian

On Tue= , Feb 28, 2012 at 3:10 PM, 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

cheers

On = 28 February 2012 18:42, Salvatore Loreto <salvatore.loreto@eri= csson.com> wrote:

=20 =20 =20
Hi there,

the first optimization/extension (or milestone if you prefer)
in the new approved HyBi charter (see ht= tp://tools.ietf.org/wg/hybi/charters )
is about:
=20
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=A0 has already received comments, suggestions and feedback;
and=A0 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 extensi=
on
This consensus call will run until Monday March 12th, 2012.

Ciao
Salvatore and Gabriel

--=20 Salvatore Loreto www.sloreto.com
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

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

--e89a8fb2050ae2042804ba0f5960-- From joakim@intalio.com Wed Feb 29 10:44: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 9B6F321F8598 for ; Wed, 29 Feb 2012 10:44:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ysGZaDsuHTbx for ; Wed, 29 Feb 2012 10:44: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 0E27F21F8585 for ; Wed, 29 Feb 2012 10:44:48 -0800 (PST) Received: by obbeh20 with SMTP id eh20so5209621obb.31 for ; Wed, 29 Feb 2012 10:44:48 -0800 (PST) Received-SPF: pass (google.com: domain of joakim@intalio.com designates 10.60.3.72 as permitted sender) client-ip=10.60.3.72; Authentication-Results: mr.google.com; spf=pass (google.com: domain of joakim@intalio.com designates 10.60.3.72 as permitted sender) smtp.mail=joakim@intalio.com Received: from mr.google.com ([10.60.3.72]) by 10.60.3.72 with SMTP id a8mr604351oea.19.1330541088689 (num_hops = 1); Wed, 29 Feb 2012 10:44:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.3.72 with SMTP id a8mr519539oea.19.1330541088607; Wed, 29 Feb 2012 10:44:48 -0800 (PST) Received: by 10.182.52.3 with HTTP; Wed, 29 Feb 2012 10:44:48 -0800 (PST) In-Reply-To: References: Date: Wed, 29 Feb 2012 11:44:48 -0700 Message-ID: From: Joakim Erdfelt To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=e89a8fb1ee2af20d2a04ba1ebc3e X-Gm-Message-State: ALoCoQl5p8KNv1mAc4EfwKwPPWBhYndnZXs/Fe/IjEVVCWSlqnqlC23lat3c76UBODmPickZDysQ 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, 29 Feb 2012 18:44:49 -0000 --e89a8fb1ee2af20d2a04ba1ebc3e Content-Type: text/plain; charset=ISO-8859-1 Would it be appropriate to reference RFC6455 Sec 1.3 Opening Handshake in the section explaining the mux AddChannel request (mux Sec 7.1) headers? Similar in the way that RFC6455 Sec 1.3 references RFC2616? -- Joakim Erdfelt joakim@intalio.com --e89a8fb1ee2af20d2a04ba1ebc3e Content-Type: text/html; charset=ISO-8859-1 Would it be appropriate to reference RFC6455 Sec 1.3 Opening Handshake in the section explaining the mux AddChannel request (mux Sec 7.1) headers?

Similar in the way that RFC6455 Sec 1.3 references RFC2616?

Joakim Erdfelt

joakim@intalio.com

--e89a8fb1ee2af20d2a04ba1ebc3e-- From jat@google.com Wed Feb 29 12:03: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 381EC21E807D for ; Wed, 29 Feb 2012 12:03:33 -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 jYzu0hzsMWmm for ; Wed, 29 Feb 2012 12:03:32 -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 2F42721E805C for ; Wed, 29 Feb 2012 12:03:31 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so3172907vcb.31 for ; Wed, 29 Feb 2012 12:03:30 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.52.25.107 as permitted sender) client-ip=10.52.25.107; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.52.25.107 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.52.25.107]) by 10.52.25.107 with SMTP id b11mr2343680vdg.37.1330545810589 (num_hops = 1); Wed, 29 Feb 2012 12:03:30 -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=ERgqwh2/WJJahisbPW2Kx2LzjvMb7pZjuOwfGcXHK+o=; b=jg/dF6WeFeM7CVvGgTfFm9aUzrKf7TI6Dpg+dK5LILT6XhLkbvCnyKDwjAqER8DTPc bNHnR0xKYnmOP3MlV5LWOgE1JCt8KG2NxZUL5G7U2E9PMM+zh3TG2Ii6RV4qlIrzTw6j +behhoG4VUq10nYq1Luwt04DNnO9GPRNs0CWDKn3hqWvxhrIJ3dKmXLFw3qpSJ/rr3KO VmZ5j/+xXo8KjQ5Ai45/bKfy3nedkUeyCFsW0a82B3VZW/1DR8tpMNSAnXI7ddLzZHRy ITvCsbgIPBGkV/vbK8AZVvWDLTSVuAuKqkZR5hn0jfB5mTt7ev6D9W0kdB5gQh0VsADy GgZw== Received: by 10.52.25.107 with SMTP id b11mr2006167vdg.37.1330545810498; Wed, 29 Feb 2012 12:03:30 -0800 (PST) Received: by 10.52.25.107 with SMTP id b11mr2006147vdg.37.1330545810352; Wed, 29 Feb 2012 12:03:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Wed, 29 Feb 2012 12:03:09 -0800 (PST) In-Reply-To: References:

From: John Tamplin Date: Wed, 29 Feb 2012 15:03:09 -0500 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=20cf307d0416622a2904ba1fd6b3 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkChCYNTgmSZEn7tXBJdlV2fhG/KNfohdktxaQkySyN3VUkZ7xqNnqdYCd7owz1gfNGnaASPmRlyhIcXF61eAU3jKTEbJ5XAvLASGaZK4qlRVw3hm8JzKaK4UqAXf0NsgvFaISZ 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, 29 Feb 2012 20:03:33 -0000 --20cf307d0416622a2904ba1fd6b3 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 29, 2012 at 1:44 PM, Joakim Erdfelt wrote: > Would it be appropriate to reference RFC6455 Sec 1.3 Opening Handshake in > the section explaining the mux AddChannel request (mux Sec 7.1) headers? > > Similar in the way that RFC6455 Sec 1.3 references RFC2616? > Sounds good. -- John A. Tamplin Software Engineer (GWT), Google --20cf307d0416622a2904ba1fd6b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 29, 2012 at 1:44 PM, Joakim Erdfelt = <joakim@intalio.= com> wrote:

Would it be appropriate to reference RFC6455 Sec 1.3 Opening Handshake in t= he section explaining the mux AddChannel request (mux Sec 7.1) headers?

Similar in the way that RFC6455 Sec 1.3 references RFC2616?=

Sounds good.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--20cf307d0416622a2904ba1fd6b3-- From tyoshino@google.com Wed Feb 29 12:11: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 77BAA21F86F8 for ; Wed, 29 Feb 2012 12:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.949 X-Spam-Level: X-Spam-Status: No, score=-102.949 tagged_above=-999 required=5 tests=[AWL=0.027, 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 DTfSiB9yQ6lH for ; Wed, 29 Feb 2012 12:11:44 -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 062A421F8691 for ; Wed, 29 Feb 2012 12:11:43 -0800 (PST) Received: by ghbg16 with SMTP id g16so419086ghb.31 for ; Wed, 29 Feb 2012 12:11:43 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.101.135.32 as permitted sender) client-ip=10.101.135.32; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.101.135.32 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.101.135.32]) by 10.101.135.32 with SMTP id m32mr813562ann.84.1330546303630 (num_hops = 1); Wed, 29 Feb 2012 12:11: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=uq0ImyeSHWI1OJJjC0jQs+13Igoy4FtfQF6g3sGSeng=; b=NR7PiTyJEpT/esX0g5Fy1Ce8/huxjg6JCUtvt9RFtfJCfc/T2Y8K+pArClTnR3lKjE gG1bqWgyPfv4+2l26nUt6fUWWOwkb8c3DrhDOig+4Ttgu9ORl70b6i7tHIhc3Je4bw/T DMANRyqEvo+72DcI2aVXeyc/SVKCHRrfCwciDNjsUQZ6TQsG3O7IMWgJzJT2tlIdv5Ep qsQouhy8hvThwpJYpZsnqYu9wu91UNFE88Rc8Qn+zqHtrDCrPtjPiGKrrjkofvWaU96S ABcc2BRdxI63gP8Xv4v+1+xnX5cuVmW9KYw9Ops9m/njXryjqyC+gKvp+inl5ikA8NXI Hs9g== Received: by 10.101.135.32 with SMTP id m32mr642688ann.84.1330546303466; Wed, 29 Feb 2012 12:11:43 -0800 (PST) Received: by 10.101.135.32 with SMTP id m32mr642680ann.84.1330546303322; Wed, 29 Feb 2012 12:11:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Wed, 29 Feb 2012 12:11:23 -0800 (PST) In-Reply-To: References:

From: Takeshi Yoshino Date: Wed, 29 Feb 2012 15:11:23 -0500 Message-ID: To: Greg Wilkins , John Tamplin Content-Type: multipart/alternative; boundary=0016369fa141c44c3c04ba1ff3d7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQniOHVYhKVOXg5SIbmN9Pza78DY/YmDhwlZdef9WpuJEzBA9oTS1pCgdUiwmOpgw21XOWtoS5U7VQUvFGnrUrjKhuikyo1P0VXPDKYcSXe6eSuTm4onJC9FIc8VnJEM24HHbtk5 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, 29 Feb 2012 20:11:45 -0000 --0016369fa141c44c3c04ba1ff3d7 Content-Type: text/plain; charset=ISO-8859-1 Hi Greg, Thanks for commenting throughout. On Tue, Feb 28, 2012 at 19:03, Greg Wilkins wrote: > > Some comments > > > 3. > > If WebSocket payload data is masked by a per-frame key, such masking > is applied to frames for each logical channel separately. > > > I'm not sure what it means to apply masking to a logical channel > separately? Surely a mask is applied to the frame that carries it before > the MUX extension interprets the payload? > > John, may I confirm what this text is intended to mean? > 5. Flow Control Each logical channel, including the implicitly created channel 1, is > initially given a quota of bytes that may be transmitted in each > direction without acknowledgement. It is illegal to send more bytes > than the remaining send quota, and the receiver MUST _Fail the > Logical Channel_ for any sender that does so. > > Should this not be a failure of the physical channel as it indicates a > failure of the other ends MUX implementation? > > I wondered if it's useful if there's a choice to drop only one logical channel. As quota is independent among logical channels, we don't have to close the physical channel. But yes, as you said, this means there's bug in the sender's multiplexing. If no one opposes, I'll change this to _Fail the Physical Channel_ from the next version. > This send quota is > replenished via control frames as the receiver processes the data. > > s/This/The/ > Thanks > > 7. Multiplex Control Frames > > nice clarifications in this section! - specifically "Objectve channel ID" > > Is the text diagram a standard? I find the + - - - - - + lines confusing > and would prefer to see: > > Just used the same formatting as RFC 6455. But yes... for this case, it's just making it ugly. I'll remove them. > 0 1 2 3 4 5 6 7 > +---------------+ > | Objective | > : channel ID : > | (8-32) | > +-----+---------+ > | Opc | Opcdata | > +-----+---------+ > | Additional | > : data : > | (0-? | > +---------------+ > > > 7.1. Multiplex Control Opcodes 0 - AddChannel request (only from client) > Create a new logical channel, exactly as if a new connection were > received on a separate transport connection, > > s/exactly // > ok > s/a new logical channel/the objective channel/ > ok > > probably need to state somewhere that it is an error to add and already > added channel. > > > good point. > 0 - uncompressed > > This is a bad name for this encoding scheme as it implies there is a > compressed scheme (OK delta encoding is a compression... but you know what > I mean). How about calling this "absolute" or "complete" or "plain" ? > > "plain" sounds good. how about identity as like content-encoding of HTTP? > The initial quota for the new logical channel is 0, so the client > may not send any data for this connection until the AddChannel > response is received. > > Does this mean that control frames can be sent for a channel before the > add channel response is received? > > ok. it might be misleading to say this within the context of quota. We should just say "any frame MUST not be sent over the logical channel until AddChannel response is received" somewhere else. I'll try to fix this. > 3 - DropChannel > > Can a dropped channel be readded later? > > Hmm. One case we need to consider is: - S sends a frame(ID=1, body="blah") - C issues a DropChannel(ID=1) - C issues a AddChannelReq(ID=1) We need to be able to determine if the data frame should be dropped or not when these three happen at almost same time. But I think this is not a problem. C should drop any frame received after issue of DropChannel but before AddChannel response. 11. Fairness > > A multiplexing implementation MUST ensure reasonable fairness among > the logical channels. This is accomplished in several ways: > > Receiver side > > o The receiver MAY limit the other peer's send quota of a logical > channel by not replenishing the send quota to make sure that any > logical channel cannot dominate its buffer space on the sender. > > s/on the sender// as it is the buffer space on the receiver that is of > concern > This text is intended to note that a receiver can try to maintain fairness of inbound traffic between logical channels even if the sender doesn't employ good algorithm to assign transmission slot to each logical channel. That's why there's "on the sender". Hmm, but maybe I should revise this like... The receiver MAY limit the send quota of a logical channel by not replenishing it to make sure that any logical channel doesn't dominate the connection. > > Also we should say that the receiver does not need to process frames from > different logical channels serially. ie the processing of a message from a > logical channel should not defer the processing of messages on other > logical channels. > > OK. Let's add some text to note that point. > o The sender MUST fragment a message into smaller frames when it's > too big so that that logical channel will occupy the connection > and the other logical channels get stuck for long time. > > Cumbersome. How about: The sender MUST fragment a large message into > smaller frames to prevent a large message in a logical channel occupying > the physical channel and thus delaying messages in other logical channels. > Great. I'll take it. > > o Logical channel frames that are sent SHOULD be limited in size > (such as by refragmenting) when there is contention for the > physical channel to minimize head-of-line blocking > > How is this different from the previous? > > Ah,... maybe I've duplicated. > > > 13. Nesting > > I think we should disallow nesting. Any intermediary that wants to MUX > channels understands MUX, so it can flatten. > > Thanks for opinion. --0016369fa141c44c3c04ba1ff3d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Greg,

Thanks for commenting throughout.

On Tue, Feb 28, 2012 at 19:03, Greg Wilkins <gregw@intalio.com>= wrote:

Some comments

3.
   I=
f WebSocket payload data is masked by a per-frame key, such masking
   is applied to frames for each logical channel separately.
I'm not sure what it means to apply masking to a logical chan= nel separately?=A0 Surely a mask is applied to the frame that carries it be= fore the MUX extension interprets the payload?

John, may I confirm what this text is intended to mean?

=A0

5.  Flow Control

   Each logical channel, including the implicitly created channel 1,=
 is
   initially given a quota of bytes that may be transmitted in each
   direction without acknowledgement.  It is illegal to send more bytes
   than the remaining send quota, and the receiver MUST _Fail the
   Logical Channel_ for any sender that does so.

Should this not be a= failure of the physical channel as it indicates a failure of the other end= s MUX implementation?

I wondered if= it's useful if there's a choice to drop only one logical channel. = As quota is independent among logical channels, we don't have to close = the physical channel.

But yes, as you said, this means there's bug in the= sender's multiplexing. If no one opposes, I'll change this to _Fai= l the Physical Channel_ from the next version.

   This send quota is
   replenished via control frames as the receiver processes the data.

s/This/The/

Thanks

=A0<= /div>

7.  Multiplex Control Frames
nice clarifications in this section! - specifically "Obje= ctve channel ID"

Is the text diagram a standard?=A0 I find the + - - - - - + lines confu= sing and would prefer to see:

Just = used the same formatting as RFC 6455. But yes... for this case, it's ju= st making it ugly. I'll remove them.

=A0

      0 1 2 3 4 5 6 7
     +---------------+
     | Objective     |
     : channel ID    :
     | (8-32)        |
     +-----+---------+
     | Opc | Opcdata |
     +-----+---------+
     | Additional    |
     : data          :
     | (0-?          |
     +---------------+

7.1.  Multiplex Control Opcodes   0 - AddChann=
el request (only from client)
      Create a new logical channel, exactly as if a new connection were
      received on a separate transport connection,

s/exactly //

=A0

s/a new logical channel/the objective chan= nel/

=A0

probably need to state somewhere that it is an error to add = and already added channel.
good point.=A0
0 - uncompressed
=
This is a bad name for this encoding scheme as it implies = there is a compressed scheme (OK delta encoding is a compression... but you= know what I mean).=A0=A0 How about calling this "absolute" or &q= uot;complete" or "plain" ?

"plain" sounds good. how abo= ut identity as like content-encoding of HTTP?
=A0

The initial quota for the new logical channel is 0, so the clien= t may not send any data for this connection until the AddChannel response is received.
Does this mean that control frames can= be sent for a channel before the add channel response is received?

=

ok. it might be misleading to say this=A0w= ithin the context of quota. We should just say "any frame MUST not be = sent over the logical channel until AddChannel response is received" s= omewhere else. I'll try to fix this.

=A0

   3 - DropChannel
C= an a dropped channel be readded later?

Hmm. One case we need to consider is:<= /div>

- S sends a frame(ID=3D1, body=3D"blah")=

- C issues a DropChannel(ID=3D1)

- C issues a AddChann= elReq(ID=3D1)

We need to be able to determine if the data frame shoul= d be dropped or not when these three happen at almost same time.

But I think this is not a problem. C should drop any frame r= eceived after issue of DropChannel but before AddChannel response.

11.  Fairness

   A multiplexing implementation MUST ensure reasonable fairness among
   the logical channels.  This is accomplished in several ways:

   Receiver side

   o  The receiver MAY limit the other peer's send quota of a logical
      channel by not replenishing the send quota to make sure that any
      logical channel cannot dominate its buffer space on the sender.

s/on the sender//=A0=A0 as it is the buffer space on the receiver= that is of concern

This text is intend= ed to note that a receiver can try to maintain fairness of inbound traffic = between logical channels even if the sender doesn't employ good algorit= hm to assign transmission slot to each logical channel. That's why ther= e's "on the sender".

Hmm, but maybe I should revise this like...

<= br>

The receiver MAY limit the send quota of a logical channel by= not replenishing it to make sure that any logical channel doesn't domi= nate the connection.

=A0

Also we should say that th= e receiver does not need to process frames from different logical channels = serially.=A0 ie the processing of a message from a logical channel should n= ot defer the processing of messages on other logical channels.

OK. Let's add some text to note th= at point.

=A0

   o  The =
sender MUST fragment a message into smaller frames when it's
      too big so that that logical channel will occupy the connection
      and the other logical channels get stuck for long time.
Cumbersome.=A0 How about: The sender MUST fragment a large message in= to smaller frames to prevent a large message in a logical channel occupying= the physical channel and thus delaying messages in other logical channels.=

Great. I'll take it.

=A0

   o  Logical channel frames that are sent SHOULD be limited in si=
ze
      (such as by refragmenting) when there is contention for the
      physical channel to minimize head-of-line blocking

How is this d= ifferent from the previous?

Ah,... = maybe I've duplicated.

=A0

13. Nes= tingI think we should disallow nesting.=A0 Any intermedia= ry that wants to MUX channels understands MUX, so it can flatten.

Thanks for opinion.

--0016369fa141c44c3c04ba1ff3d7-- From tyoshino@google.com Wed Feb 29 12:13: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 8DD9321E8091 for ; Wed, 29 Feb 2012 12:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.951 X-Spam-Level: X-Spam-Status: No, score=-102.951 tagged_above=-999 required=5 tests=[AWL=0.025, 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 atssh1+O6h8v for ; Wed, 29 Feb 2012 12:13:37 -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 B813921E8017 for ; Wed, 29 Feb 2012 12:13:37 -0800 (PST) Received: by yenm5 with SMTP id m5so1814605yen.31 for ; Wed, 29 Feb 2012 12:13:37 -0800 (PST) Received-SPF: pass (google.com: domain of tyoshino@google.com designates 10.236.185.97 as permitted sender) client-ip=10.236.185.97; Authentication-Results: mr.google.com; spf=pass (google.com: domain of tyoshino@google.com designates 10.236.185.97 as permitted sender) smtp.mail=tyoshino@google.com; dkim=pass header.i=tyoshino@google.com Received: from mr.google.com ([10.236.185.97]) by 10.236.185.97 with SMTP id t61mr2727009yhm.100.1330546417424 (num_hops = 1); Wed, 29 Feb 2012 12:13:37 -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=ybrfNfQVgOg1QCdZ7fiiHPSmlIM7hO4WuRhtZMfApu0=; b=H0rk6X/sIlnVU2VjqhxJCj1oOe5hSey6jMgnDAu9bHk8Sn28iio6CQF1OquWFu3qXz IbUZgJkLzWStOQ1JNkFvjHGT+SdZ+/Itr5WIKy/MB5z6dMWnEIJ2x0umgqabaG5BFaxw sRIjSH7Eqc/ivDCb4gui7HopYCr3jdm7mhMUY5GmM3V/M2Agu38orPBkRsFX3fe4to6z LuZtHKkiiCAQpLU6t3r5cV/hq9d2X/xJtspyRqspDhHr4GSxMZoQe8Cf5ZlK1VEx8ESO sap1bailUwh3TpEUDk9DuQCrjPXibML0GJ9tI+hjvmOPrCE+2l56uZicdy9xLoiEAUtK hqIQ== Received: by 10.236.185.97 with SMTP id t61mr2152686yhm.100.1330546417364; Wed, 29 Feb 2012 12:13:37 -0800 (PST) Received: by 10.236.185.97 with SMTP id t61mr2152679yhm.100.1330546417278; Wed, 29 Feb 2012 12:13:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Wed, 29 Feb 2012 12:13:17 -0800 (PST) In-Reply-To: References:

From: Takeshi Yoshino Date: Wed, 29 Feb 2012 15:13:17 -0500 Message-ID: To: John Tamplin Content-Type: multipart/alternative; boundary=20cf305e24978f1e5504ba1ffa23 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkoAecNXku93FYS/byMCGYrvMklAYxtkBvxrXDaATKTqTaA2bEQnKau/m+95uGAKO6AlFgpOfSj2Qb9B86E8AkyJqbfRusbFXfia9BLHu/Ty0S2Xjw3t9kmHMZC26VtZ05wsJJs 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, 29 Feb 2012 20:13:38 -0000 --20cf305e24978f1e5504ba1ffa23 Content-Type: text/plain; charset=ISO-8859-1 Thanks. I'll do so in the next version. On Wed, Feb 29, 2012 at 15:03, John Tamplin wrote: > On Wed, Feb 29, 2012 at 1:44 PM, Joakim Erdfelt wrote: > >> Would it be appropriate to reference RFC6455 Sec 1.3 Opening Handshake in >> the section explaining the mux AddChannel request (mux Sec 7.1) headers? >> >> Similar in the way that RFC6455 Sec 1.3 references RFC2616? >> > > Sounds good. > > -- > John A. Tamplin > Software Engineer (GWT), Google > --20cf305e24978f1e5504ba1ffa23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. I'll do so in the next version.

On Wed, Feb 29, 2012 at 15:03, John Tamplin <jat@google.com> wrote:

On Wed, Feb 29, 2012 at 1:44 P= M, Joakim Erdfelt <joakim@intalio.com> wrote:
Would it be appropriate to reference RFC6455 Sec 1.3 Opening Handshake in t= he section explaining the mux AddChannel request (mux Sec 7.1) headers?

Similar in the way that RFC6455 Sec 1.3 references RFC2616?=

Sounds good.=A0

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

--20cf305e24978f1e5504ba1ffa23-- From jat@google.com Wed Feb 29 12: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 36FF521E801C for ; Wed, 29 Feb 2012 12:34:08 -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 MSQn6sXb3Xd5 for ; Wed, 29 Feb 2012 12:34:07 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id ECFB321E8017 for ; Wed, 29 Feb 2012 12:34:06 -0800 (PST) Received: by vbbez10 with SMTP id ez10so3743598vbb.31 for ; Wed, 29 Feb 2012 12:34:06 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.52.25.107 as permitted sender) client-ip=10.52.25.107; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.52.25.107 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.52.25.107]) by 10.52.25.107 with SMTP id b11mr2564540vdg.37.1330547646444 (num_hops = 1); Wed, 29 Feb 2012 12:34:06 -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=SUvltSmEEDsrLhXGhFmM3BgDxqf4WeQFVZ/wNp/yFO8=; b=ioLqYgAVYBjn/RuOMMX3oMqw+TnSOiu/rYyfQ2h9ZytfasDcFwPVAp/rklwA4z2OZ2 CEGJvwF5QWewoBVDiD4bKHY9uP2W3eFwGR4gRigpvH3e6ofM6yOnOWck8TodI0YbwnDJ gIatZautN8XVargXtGVEQXFExRezlZGyIyGp+Qgt8IhqlMlZThvbt3Yd01dvcyNCAt58 MWJOKzyyU5bAFk/5+0B4HTrxKr1LAhc2JaTckZgbdZnQ1kzHH+D/i5LdBMe09PQiKeO5 pyko9DFl5MjiAnBOvP7p4QGGNhrLHu6pU8/1tPTPaSkCuGqwJXdgWhsnKRlQJNwqd4p6 Y/aw== Received: by 10.52.25.107 with SMTP id b11mr2195720vdg.37.1330547646388; Wed, 29 Feb 2012 12:34:06 -0800 (PST) Received: by 10.52.25.107 with SMTP id b11mr2195701vdg.37.1330547646303; Wed, 29 Feb 2012 12:34:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Wed, 29 Feb 2012 12:33:46 -0800 (PST) In-Reply-To: References:

From: John Tamplin Date: Wed, 29 Feb 2012 15:33:46 -0500 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf307d0416d08edc04ba2043bf X-System-Of-Record: true X-Gm-Message-State: ALoCoQkXev5BXobPXOZJIOqmPnhwakpgnP+ViW9QRlP9m7UFgxT24gnl7UEbQVc4TxvDEpkeXNz2blxX5IxVGHrSYDOw1fVmjTRw5X/SkXCeBRFysGTPKirNW6c3GuA9YAGLptOSs0kP 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, 29 Feb 2012 20:34:08 -0000 --20cf307d0416d08edc04ba2043bf Content-Type: text/plain; charset=UTF-8 On Wed, Feb 29, 2012 at 3:11 PM, Takeshi Yoshino wrote: > On Tue, Feb 28, 2012 at 19:03, Greg Wilkins wrote: > >> 3. >> >> If WebSocket payload data is masked by a per-frame key, such masking >> is applied to frames for each logical channel separately. >> >> >> I'm not sure what it means to apply masking to a logical channel >> separately? Surely a mask is applied to the frame that carries it before >> the MUX extension interprets the payload? >> >> > John, may I confirm what this text is intended to mean? > This is similar to the idea of compressing logical channels vs. the physical channel. If masking is only applied to the physical channel, then an intermediary mux will have to unmask the input stream and remask it as part of the output stream. Also, it keeps separate of layers cleaner. I am open to changing this, but I think there are issues to consider both ways. > 5. Flow Control >> Each logical channel, including the implicitly created channel 1, is >> initially given a quota of bytes that may be transmitted in each >> direction without acknowledgement. It is illegal to send more bytes >> than the remaining send quota, and the receiver MUST _Fail the >> Logical Channel_ for any sender that does so. >> >> Should this not be a failure of the physical channel as it indicates a >> failure of the other ends MUX implementation? >> >> > I wondered if it's useful if there's a choice to drop only one logical > channel. As quota is independent among logical channels, we don't have to > close the physical channel. > > But yes, as you said, this means there's bug in the sender's multiplexing. > If no one opposes, I'll change this to _Fail the Physical Channel_ from the > next version. > The physical channel may bundle unrelated connections, and dropping them all because one sender failed seems excessive. I could imagine a WS mux that uses some non-WS protocol with flow control support, and simply relied on the sender respecting the flow control. Still, I won't object strongly. > 3 - DropChannel >> >> Can a dropped channel be readded later? >> >> > Hmm. One case we need to consider is: > > - S sends a frame(ID=1, body="blah") > - C issues a DropChannel(ID=1) > - C issues a AddChannelReq(ID=1) > > We need to be able to determine if the data frame should be dropped or not > when these three happen at almost same time. > > But I think this is not a problem. C should drop any frame received after > issue of DropChannel but before AddChannel response. > The intent was that the client could not reuse the channel ID until it receives a response to the DropChannel request (which isn't actually present in the doc). > 13. Nesting >> >> I think we should disallow nesting. Any intermediary that wants to MUX >> channels understands MUX, so it can flatten. >> >> > Thanks for opinion. > Again, the point of this is to allow an intermediary to pass frames along with minimal effort, rather than having to demux and remux. -- John A. Tamplin Software Engineer (GWT), Google --20cf307d0416d08edc04ba2043bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 29, 2012 at 3:11 PM, Takeshi Yoshino= <tyoshino@goog= le.com> wrote:

On Tue, Feb 28, 2012 at 19:03,= Greg Wilkins <gregw@intalio.com> wrote:
3.
   If WebSocket payload data is m=
asked by a per-frame key, such masking
   is applied to frames for each logical channel separately.
I'm not sure what it means to apply masking to a logical chan= nel separately?=C2=A0 Surely a mask is applied to the frame that carries it= before the MUX extension interprets the payload?
John, may I confirm what this text is intended to mean= ?

This is similar to the idea o= f compressing logical channels vs. the physical channel. =C2=A0If masking i= s only applied to the physical channel, then an intermediary mux will have = to unmask the input stream and remask it as part of the output stream. =C2= =A0Also, it keeps separate of layers cleaner.

I am open to changing this, but I think there are issue= s to consider both ways.

5.  Flow Control

   Each logical channel, including the implicitly created channel 1,=
 is
   initially given a quota of bytes that may be transmitted in each
   direction without acknowledgement.  It is illegal to send more bytes
   than the remaining send quota, and the receiver MUST _Fail the
   Logical Channel_ for any sender that does so. 
Should this not be a= failure of the physical channel as it indicates a failure of the other end= s MUX implementation?
I wonde= red if it's useful if there's a choice to drop only one logical cha= nnel. As quota is independent among logical channels, we don't have to = close the physical channel.

But yes, as you said, this means there's bug in the= sender's multiplexing. If no one opposes, I'll change this to _Fai= l the Physical Channel_ from the next version.
The physical channel may bundle unrelated connections, = and dropping them all because one sender failed seems excessive. =C2=A0I co= uld imagine a WS mux that uses some non-WS protocol with flow control suppo= rt, and simply relied on the sender respecting the flow control.

Still, I won't object strongly.=C2=A0

3 - DropChannel

Can a dropped channel be readded later?

Hmm. One case we need to conside= r is:

- S sends a frame(ID=3D1, body=3D"blah&= quot;)

- C issues a DropChannel(ID=3D1)

- C issues a Ad= dChannelReq(ID=3D1)

We need to be able to determine if the data frame shoul= d be dropped or not when these three happen at almost same time.

But I think this is not a problem. C should drop any frame r= eceived after issue of DropChannel but before AddChannel response.

=C2=A0

The intent was that the clie= nt could not reuse the channel ID until it receives a response to the DropC= hannel request (which isn't actually present in the doc).

13.  Nesting

I think we should disallow nesting.=C2=A0 Any intermediary that wants= to MUX channels understands MUX, so it can flatten.

Thanks for opinion.

<= /div>

Again, the point of this is to allow an intermediary= to pass frames along with minimal effort, rather than having to demux and = remux.

--
John A. Tamplin
Software E= ngineer (GWT), Google
--20cf307d0416d08edc04ba2043bf-- From gregw@intalio.com Wed Feb 29 14:03: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 1E67E21F864E for ; Wed, 29 Feb 2012 14:03:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.325, 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 B2XH+OwQ8K4u for ; Wed, 29 Feb 2012 14:03:47 -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 2E8BA21F864D for ; Wed, 29 Feb 2012 14:03:47 -0800 (PST) Received: by obbeh20 with SMTP id eh20so5441281obb.31 for ; Wed, 29 Feb 2012 14:03:46 -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 9mr791281oey.49.1330553026863 (num_hops = 1); Wed, 29 Feb 2012 14:03:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.3.9 with SMTP id 9mr684320oey.49.1330553026751; Wed, 29 Feb 2012 14:03:46 -0800 (PST) Received: by 10.60.55.166 with HTTP; Wed, 29 Feb 2012 14:03:46 -0800 (PST) In-Reply-To: References:

Date: Thu, 1 Mar 2012 09:03:46 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=e89a8f83ae2b83ac8504ba21845b X-Gm-Message-State: ALoCoQnSMF++bSjGGfvb1vBJCZf1+FwhjV4dZNtAQ/Mz/aqdo+IcetfgSVj32UIChH73yNPQTksw 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, 29 Feb 2012 22:03:48 -0000 --e89a8f83ae2b83ac8504ba21845b Content-Type: text/plain; charset=ISO-8859-1 On 1 March 2012 07:33, John Tamplin wrote: > On Wed, Feb 29, 2012 at 3:11 PM, Takeshi Yoshino wrote: > >> On Tue, Feb 28, 2012 at 19:03, Greg Wilkins wrote: >> >>> 3. >>> >>> If WebSocket payload data is masked by a per-frame key, such masking >>> is applied to frames for each logical channel separately. >>> >>> >>> I'm not sure what it means to apply masking to a logical channel >>> separately? Surely a mask is applied to the frame that carries it before >>> the MUX extension interprets the payload? >>> >>> >> John, may I confirm what this text is intended to mean? >> > > This is similar to the idea of compressing logical channels vs. the > physical channel. If masking is only applied to the physical channel, then > an intermediary mux will have to unmask the input stream and remask it as > part of the output stream. Also, it keeps separate of layers cleaner. > > I am open to changing this, but I think there are issues to consider both > ways. > John, Sorry, but I'm not understanding either choice you are implying exists. Can you expand with examples? Masking is a per frame operation, so I don't understand how it can be applied to a logical channel? > 5. Flow Control >>> Each logical channel, including the implicitly created channel 1, is >>> initially given a quota of bytes that may be transmitted in each >>> direction without acknowledgement. It is illegal to send more bytes >>> than the remaining send quota, and the receiver MUST _Fail the >>> Logical Channel_ for any sender that does so. >>> >>> Should this not be a failure of the physical channel as it indicates a >>> failure of the other ends MUX implementation? >>> >>> >> I wondered if it's useful if there's a choice to drop only one logical >> channel. As quota is independent among logical channels, we don't have to >> close the physical channel. >> >> But yes, as you said, this means there's bug in the sender's >> multiplexing. If no one opposes, I'll change this to _Fail the Physical >> Channel_ from the next version. >> > > The physical channel may bundle unrelated connections, and dropping them > all because one sender failed seems excessive. I could imagine a WS mux > that uses some non-WS protocol with flow control support, and simply relied > on the sender respecting the flow control. > > Still, I won't object strongly. > I see a flow control violation not as a failure of one sender, but of the mux implementation of the sender. But hopefully this violation will rarely occur, so I guess it does not really matter what the error response is, so long as there is one. > 13. Nesting >> >> I think we should disallow nesting. Any intermediary that wants to MUX >> channels understands MUX, so it can flatten. >> >> > Thanks for opinion. > > Again, the point of this is to allow an intermediary to pass frames along > with minimal effort, rather than having to demux and remux. > True, but the cost is passing on extra complexity and work to the server and tools. One of the purposes of having intermediaries is to offload work from the servers, so if they can do the extra work to flatten multiple multiplexed layers into a single channel space, then that will be of great assistance to the servers. Requiring muxing multiplexers to demux any incoming muxed streams feels like a lot less work and complexity rather than requiring all servers and tools to support an arbitrary depth of nesting. (So says the server developer.... shat say the intermediary developers?). cheers --e89a8f83ae2b83ac8504ba21845b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 1 March 2012 07:33, John Tamplin <jat@google.com><= /span> wrote:

On Wed, Feb 29, 2012 at 3:11 P= M, Takeshi Yoshino <tyoshino@google.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Tue, Feb 28, 2012 at 1= 9:03, Greg Wilkins <gregw@intalio.com> wrote:
3.
   If Web=
Socket payload data is masked by a per-frame key, such masking
   is applied to frames for each logical channel separately.
I'm not sure what it means to apply masking to a logical chan= nel separately?=A0 Surely a mask is applied to the frame that carries it be= fore the MUX extension interprets the payload?
John, may I confirm what this = text is intended to mean?

This is similar to the idea of compressing logical channels vs. the physic= al channel. =A0If masking is only applied to the physical channel, then an = intermediary mux will have to unmask the input stream and remask it as part= of the output stream. =A0Also, it keeps separate of layers cleaner.

I am open to changing this, but I think there are issue= s to consider both ways.

John,

Sorr= y, but I'm not understanding either choice you are implying exists.=A0= =A0 Can you expand with examples?

Masking is a per frame operation, so I don't understand how it can = be applied to a logical channel?

=A0

5.  Flow Control

   Each logical channel, including the implicitly created channel 1,=
 is
   initially given a quota of bytes that may be transmitted in each
   direction without acknowledgement.  It is illegal to send more bytes
   than the remaining send quota, and the receiver MUST _Fail the
   Logical Channel_ for any sender that does so. 
Should this not be a= failure of the physical channel as it indicates a failure of the other end= s MUX implementation?
I wonde= red if it's useful if there's a choice to drop only one logical cha= nnel. As quota is independent among logical channels, we don't have to = close the physical channel.

But yes, as you said, this means there's bug in the= sender's multiplexing. If no one opposes, I'll change this to _Fai= l the Physical Channel_ from the next version.
The physical channel may bundle unrelated connect= ions, and dropping them all because one sender failed seems excessive. =A0I= could imagine a WS mux that uses some non-WS protocol with flow control su= pport, and simply relied on the sender respecting the flow control.

Still, I won't object strongly.=A0
I see a flow control violation not a= s a failure of one sender, but of the mux implementation of the sender. But= hopefully this violation will rarely occur, so I guess it does not really = matter what the error response is, so long as there is one.

=A0
13.  Nesting
I think= we should disallow nesting.=A0 Any intermediary that wants to MUX channels= understands MUX, so it can flatten.

Thanks for opinion.
<= /div>
=
Again, the point of this is to allow an intermediary to pass frames alo= ng with minimal effort, rather than having to demux and remux.

True, but the cost is passing on extra complexity and= work to the server and tools.=A0 One of the purposes of having intermediar= ies is to offload work from the servers, so if they can do the extra work t= o flatten multiple multiplexed layers into a single channel space, then tha= t will be of great assistance to the servers.=A0=A0 Requiring muxing multip= lexers to demux any incoming muxed streams feels like a lot less work and c= omplexity rather than requiring all servers and tools to support an arbitra= ry depth of nesting. (So says the server developer.... =A0 shat say the int= ermediary developers?).

cheers

=A0

--e89a8f83ae2b83ac8504ba21845b-- From jat@google.com Wed Feb 29 14:35: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 253D421F8618 for ; Wed, 29 Feb 2012 14:35:22 -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 ojoVrXP9A+4j for ; Wed, 29 Feb 2012 14:35:21 -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 C206521F85C9 for ; Wed, 29 Feb 2012 14:35:03 -0800 (PST) Received: by vcbfk13 with SMTP id fk13so3318162vcb.31 for ; Wed, 29 Feb 2012 14:35:03 -0800 (PST) Received-SPF: pass (google.com: domain of jat@google.com designates 10.52.19.196 as permitted sender) client-ip=10.52.19.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of jat@google.com designates 10.52.19.196 as permitted sender) smtp.mail=jat@google.com; dkim=pass header.i=jat@google.com Received: from mr.google.com ([10.52.19.196]) by 10.52.19.196 with SMTP id h4mr3239570vde.91.1330554903375 (num_hops = 1); Wed, 29 Feb 2012 14:35:03 -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=ANFrRTwX5uhVP2/rYnzZoeJQEz3mt5CG4+i7YFLzslA=; b=eTfYjIlWc6YNa7WaFDCjrj7wtcO3MJ8cnp7dQqeEOel34oowQLqetWMSTaSBhBTJyW Fit9Gp+RWFgjVnJaS4+qtx5MOQRGJCCNLQAiVQ8B2tAYCwCl/VeSrutI5SYIvIz6oIwx Q3ULPIsRfM2HVGoK9Q2gDvrXZozQ9CKop+ky9wuLE2RZnKAGjR40iMCGIrrjjXNPVOLk sWxnFGV9w0DWBLj7njNBrKXZCx+GAUrPS9pzK4V/3EqKhHFrIM+YnlYGCQ3m4cSXURDu Mb+Pc6K9xVliyPXAbnEAU5HHk3D6Gv3z8jJ1QNuw7iCL7hLRzJPNLrDvRnjtPQaRvcLx nvOw== Received: by 10.52.19.196 with SMTP id h4mr2771714vde.91.1330554903328; Wed, 29 Feb 2012 14:35:03 -0800 (PST) Received: by 10.52.19.196 with SMTP id h4mr2771706vde.91.1330554903261; Wed, 29 Feb 2012 14:35:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.117.132 with HTTP; Wed, 29 Feb 2012 14:34:43 -0800 (PST) In-Reply-To: References:

From: John Tamplin Date: Wed, 29 Feb 2012 17:34:43 -0500 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=20cf307ca01a5cf21f04ba21f4c1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnrsncuMsKXylaZXq8eRV4vuytH3DPAZHS6B55XtWhqmRpKIOwGJSlijOmfpfsXXmStCUcxP+RKR9H01vDe6V68XaD07jJMUbiua8jWFqhUsTQNVk0HrWImqcjR5I0I4AVTBceh 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, 29 Feb 2012 22:35:22 -0000 --20cf307ca01a5cf21f04ba21f4c1 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 29, 2012 at 5:03 PM, Greg Wilkins wrote: > Sorry, but I'm not understanding either choice you are implying exists. > Can you expand with examples? > > Masking is a per frame operation, so I don't understand how it can be > applied to a logical channel? > You're right -- that was left over from when masking had a per-connection key and maintained state. > True, but the cost is passing on extra complexity and work to the server > and tools. One of the purposes of having intermediaries is to offload work > from the servers, so if they can do the extra work to flatten multiple > multiplexed layers into a single channel space, then that will be of great > assistance to the servers. Requiring muxing multiplexers to demux any > incoming muxed streams feels like a lot less work and complexity rather > than requiring all servers and tools to support an arbitrary depth of > nesting. (So says the server developer.... shat say the intermediary > developers?). > I think of a router or switch where you want to minimize the processing as you pass bits from an input to an output. A WS mux intermediary is likely to be higher level than that, probably about the same as a load balancer so it doesn't necessarily apply at that level. I can see the argument both ways, and I think we need to discuss the relative merits of both before deciding. -- John A. Tamplin Software Engineer (GWT), Google --20cf307ca01a5cf21f04ba21f4c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 29, 2012 at 5:03 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:

Sorry, but I'm not understanding either= choice you are implying exists.=C2=A0=C2=A0 Can you expand with examples?<= br>
Masking is a per frame operation, so I don't understand how it can = be applied to a logical channel?

You're right -- that was left over from when masking had a per-co= nnection key and maintained state.

=C2=A0

=
True, but the cost is passing on extra complexity and work to the serv= er and tools.=C2=A0 One of the purposes of having intermediaries is to offl= oad work from the servers, so if they can do the extra work to flatten mult= iple multiplexed layers into a single channel space, then that will be of g= reat assistance to the servers.=C2=A0=C2=A0 Requiring muxing multiplexers t= o demux any incoming muxed streams feels like a lot less work and complexit= y rather than requiring all servers and tools to support an arbitrary depth= of nesting. (So says the server developer.... =C2=A0 shat say the intermed= iary developers?).

I think of a router or switch where = you want to minimize the processing as you pass bits from an input to an ou= tput. =C2=A0A WS mux intermediary is likely to be higher level than that, p= robably about the same as a load balancer so it doesn't necessarily app= ly at that level. =C2=A0I can see the argument both ways, and I think we ne= ed to discuss the relative merits of both before deciding.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--20cf307ca01a5cf21f04ba21f4c1-- From gregw@intalio.com Wed Feb 29 14:42: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 4A45421E801F for ; Wed, 29 Feb 2012 14:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.716 X-Spam-Level: X-Spam-Status: No, score=-2.716 tagged_above=-999 required=5 tests=[AWL=0.260, 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 CrDrSilVg+dG for ; Wed, 29 Feb 2012 14:42:39 -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 B60A021E800E for ; Wed, 29 Feb 2012 14:42:39 -0800 (PST) Received: by obbeh20 with SMTP id eh20so5484092obb.31 for ; Wed, 29 Feb 2012 14:42:39 -0800 (PST) Received-SPF: pass (google.com: domain of gregw@intalio.com designates 10.60.7.40 as permitted sender) client-ip=10.60.7.40; Authentication-Results: mr.google.com; spf=pass (google.com: domain of gregw@intalio.com designates 10.60.7.40 as permitted sender) smtp.mail=gregw@intalio.com Received: from mr.google.com ([10.60.7.40]) by 10.60.7.40 with SMTP id g8mr823400oea.69.1330555359454 (num_hops = 1); Wed, 29 Feb 2012 14:42:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.7.40 with SMTP id g8mr706828oea.69.1330555359323; Wed, 29 Feb 2012 14:42:39 -0800 (PST) Received: by 10.60.55.166 with HTTP; Wed, 29 Feb 2012 14:42:39 -0800 (PST) In-Reply-To: References:

Date: Thu, 1 Mar 2012 09:42:39 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: multipart/alternative; boundary=e89a8fb1ef488be59d04ba220fef X-Gm-Message-State: ALoCoQkYecP3UTKCvL8zmq5VIjdzENKL2pXKQb46kuivT8ORn7Uw/wUneYRqA5Di4MCikRVz3O0J 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, 29 Feb 2012 22:42:40 -0000 --e89a8fb1ef488be59d04ba220fef Content-Type: text/plain; charset=ISO-8859-1 On 1 March 2012 09:34, John Tamplin wrote: > > I think of a router or switch where you want to minimize the processing as > you pass bits from an input to an output. A WS mux intermediary is likely > to be higher level than that, probably about the same as a load balancer so > it doesn't necessarily apply at that level. I can see the argument both > ways, and I think we need to discuss the relative merits of both before > deciding. > Sure - just advocating one side of it, but can live with nested if we determine an advantage. Note that an intermediary that is demuxing/remuxing will have little work to do on the average data packet - it will simply need to maintain a mapping of inbound channelId to outbound channelID and update the channel ID in the packets as it forwards them (this may be an argument for fixed length channelID encoding). This like flow control wont need to be fully implemented, as the intermediary can just pass back quotas to the source. cheers --e89a8fb1ef488be59d04ba220fef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On 1 March 2012 09:34, John Tamplin <jat@google.com><= /span> wrote:

I think of a router or switch where you wan= t to minimize the processing as you pass bits from an input to an output. = =A0A WS mux intermediary is likely to be higher level than that, probably a= bout the same as a load balancer so it doesn't necessarily apply at tha= t level. =A0I can see the argument both ways, and I think we need to discus= s the relative merits of both before deciding.

Sure - just advocating one side of it, but can = live with nested if we determine an advantage.

Note that an intermed= iary that is demuxing/remuxing will have little work to do on the average d= ata packet - it will simply need to maintain a mapping of inbound channelId= to outbound channelID and update the channel ID in the packets as it forwa= rds them (this may be an argument for fixed length channelID encoding).=A0 = This like flow control wont need to be fully implemented, as the intermedia= ry can just pass back quotas to the source.

cheers

--e89a8fb1ef488be59d04ba220fef--

5. Flow Control

7. Multiplex Control Frames

11= . Fairness

13. Nesting

5. Flow Control

7. Multiplex Control Frames

7.1. Multiplex Control Opcodes

11. Fairness

5. Flow Control

13. Nesting

5. Flow Control

13. Nesting