From julian.reschke@gmx.de Fri Jan 4 05:26:44 2013 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 8F8AC21F8550 for ; Fri, 4 Jan 2013 05:26:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-4.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6NuzrZrrzLb for ; Fri, 4 Jan 2013 05:26:44 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id C627321F854C for ; Fri, 4 Jan 2013 05:26:43 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.33]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0MWMYG-1TWi6N34EU-00XYjD for ; Fri, 04 Jan 2013 14:26:41 +0100 Received: (qmail invoked by alias); 04 Jan 2013 13:26:41 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.104]) [217.91.35.233] by mail.gmx.net (mp033) with SMTP; 04 Jan 2013 14:26:41 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18SUMoWZMISoJkTtURcs1tjOqvzFcbmPx95u6e9/T kAyHj3Smgq2m8U Message-ID: <50E6D88E.7030100@gmx.de> Date: Fri, 04 Jan 2013 14:26:38 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Takeshi Yoshino References: In-Reply-To: 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] Resolutions for the issues of the compression spec reported during WGLC X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 13:26:44 -0000 On 2012-12-17 05:28, Takeshi Yoshino wrote: > ... > ==== Open issue ==== > > - Conflict between "method" extension parameter spec and RFC 6455 > -- http://www.ietf.org/mail-archive/web/hybi/current/msg09904.html > > Possible solutions are: > > a) revise RFC 6455 by replacing constraint on quoted-string from "token" > to CHAR - CTL > pros: > - human readable > cons: > - needs very strong justification to change 6455 > -- existing implementations strictly conform to 6455 will "Fail" when > method parameter including space, semicolon, etc. instead of just > rejecting the extension > -- there might be any private-use extension that manipulates extensions > header assuming extension parameters conform to token after unquote > > b) move the method parameter into a new separate handshake header entry > pros: > - human readable > cons: > - introduces a new header not defined in 6455 > > c) use hex-encoding to token-ize the method parameter string (for > compatibility, use method_hex as the extension parameter name) > pros: > - just addition of well-known simple encoding. no change outside of > Sec-WebSocket-Extensions header > cons: > - not human readable > > My thought: > > I think it can be considered to be a bug that the token constraint is > making extension header hard to carry structured data. But as listed > above, there're difficulties to adopt (a). > > (c) sounds like the most feasible interim solution. > ... I haven't followed the discussions that led to the current design, but this smells a bit like a case of an over-engineered extension point. Do you *really* expect that negotiation will have to happen on *paramaters*? If this is not the case, it would be *much* simpler to simply define different tokens for the different schemes and be done. So, for instance: Sec-WebSocket-Extensions: permessage-compress-deflate instead of Sec-WebSocket-Extensions: permessage-compress; method=deflate Keep in mind that if you extend quoted-string to essentially wrap other name/parameter pairs, you may end up with having to escape double quotes; and this is asking for trouble for something that really should be easy. Best regards, Julian From tyoshino@google.com Sun Jan 6 20:51:17 2013 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 9723B21F8581 for ; Sun, 6 Jan 2013 20:51:17 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jumD6tb0y59N for ; Sun, 6 Jan 2013 20:51:17 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id CEDDB21F853C for ; Sun, 6 Jan 2013 20:51:16 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so19033789vbn.28 for ; Sun, 06 Jan 2013 20:51:16 -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; bh=ClV8iXOrTA8IWVysR2aRi4ig7nE3H2XEBXK2oE/jQvg=; b=J0MmycPPWKBquJqaUdYkBRWDV1X8hqXT7UwrUrbr8ClyRAzuRcQYrs4htLV5WLIk6X Wkv5YhAKM7NBu2gq/W5+2b3Q2SGSTe4FHqxsJyfqwYROz5nziVw1HjTpzhi02K/CpD0N ZIPGAXt/drFkESoOXg9oKPuXSKh30LFrmutCpikc/9V9O0HKPIUqXju2jLMTad4hWVaU 9PEJ/rcwje8CPCVLjhrtjzGpNAvVPGfTT9TXgJRFGN3xjm2HhBpV3oOHLK4OONEoQeuu J6pB9kMiX7Rt4LMexgSa4c99EOzSeQpaiVEbKJ7Q0ScWHIHzGBm8gljdH411yad7SIBr VIgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=ClV8iXOrTA8IWVysR2aRi4ig7nE3H2XEBXK2oE/jQvg=; b=mzDpxW7HQkOVqmzH5LQsVo1l17kmjjUPAOBM729+1Wfluj0ZUlJ/TwEn21+OUIDR3Z L/YiPPLFEuEWziUIGfAaBLGKIBb2xk5ncLpiRC3Jt4XuSToegzu8QVoIXyl0zIji00mZ yAElXQJ8EGKofwHDiQOZcXuP/WEmW3xreCfpzusQfANrCxphbYxZnM2fO/Yj42XajiOd kax9qCTiFN9VzjxGrPFrnounj7aRLvmRlAvM104HpQ4nR3XU7ilmaPDySPdn7Ymzrsmu 8ru18uPDwkMeeO6KeO7mSTjscCD3NBny8SQA4In4EfUp6CNgtwM0Ystk891VoGa58kqC oTew== Received: by 10.52.16.17 with SMTP id b17mr71325202vdd.86.1357534276022; Sun, 06 Jan 2013 20:51:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.255.226 with HTTP; Sun, 6 Jan 2013 20:50:55 -0800 (PST) In-Reply-To: <50E6D88E.7030100@gmx.de> References: <50E6D88E.7030100@gmx.de> From: Takeshi Yoshino Date: Mon, 7 Jan 2013 13:50:55 +0900 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=bcaec50408e84aefe604d2ab9452 X-Gm-Message-State: ALoCoQlNFklc1oE/8goYnABSrKBxTLeeZE59Dm50AWbl9lbC/+WnKJEx2pnMACZg1gs8cp0xhbaC9rpaww+mRu6qyCyp3rss1gVds/2JC2hVFMb+SBV2wR7CUV1r43GwA7SH4TtxCdLUkRibx01ZhfzrrP5Yz20y2MY5vgTD6x12k8lg25qiPtZi4jcztFot+FOcENnLuK7y Cc: "hybi@ietf.org" Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC 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, 07 Jan 2013 04:51:17 -0000 --bcaec50408e84aefe604d2ab9452 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Julian. On Fri, Jan 4, 2013 at 10:26 PM, Julian Reschke wrote: > I haven't followed the discussions that led to the current design, but > this smells a bit like a case of an over-engineered extension point. Do you > *really* expect that negotiation will have to happen on *paramaters*? No. But see below, please. > If this is not the case, it would be *much* simpler to simply define > different tokens for the different schemes and be done. So, for instance: > > Sec-WebSocket-Extensions: permessage-compress-deflate > > instead of > > Sec-WebSocket-Extensions: permessage-compress; method=deflate > > We've discussed that in this thread. http://www.ietf.org/mail-archive/web/hybi/current/msg09605.html and made a decision as announced in http://www.ietf.org/mail-archive/web/hybi/current/msg09618.html There was no strong opinion on either of them. We chose the current design because: - to simplify correspondence between a RSV bit and an ext. - to ease extension list processing by grouping compression method candidates into one ext. Shall we go back to the old approach? I'm ok with it. Comment please everyone. > Keep in mind that if you extend quoted-string to essentially wrap other > name/parameter pairs, you may end up with having to escape double quotes; > and this is asking for trouble for something that really should be easy. --bcaec50408e84aefe604d2ab9452 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Julian.

On Fri, Jan 4, 2013 at 10:26 PM, Julian Reschke <julian.reschke@gmx= .de> wrote:
I haven't followed the discussions that led to the current design, bu= t this smells a bit like a case of an over-engineered extension point. Do y= ou *really* expect that negotiation will have to happen on *paramaters*?

No. But see below, please.
=A0
If this is not the case, it would be *much* simpler to simply define diffe= rent tokens for the different schemes and be done. So, for instance:

=A0 Sec-WebSocket-Extensions: permessage-compress-deflate

instead of

=A0 Sec-WebSocket-Extensions: permessage-compress; method=3Ddeflate



There was no strong opinion on either of them. We chose the current design = because:
- to simplify correspondence between a RSV bit and= an ext.
- to ease extension list processing by grouping co= mpression method candidates into one ext.

Shall we go back to the old approach? I'= ;m ok with it.

Comment please everyone= .
=A0
Keep in mind that if you extend quoted-string to essentially wrap other nam= e/parameter pairs, you may end up with having to escape double quotes; and = this is asking for trouble for something that really should be easy.
=A0
--bcaec50408e84aefe604d2ab9452-- From tyoshino@google.com Sun Jan 6 20:59:20 2013 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 DA04421F8618 for ; Sun, 6 Jan 2013 20:59:20 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryLraOCdrFYK for ; Sun, 6 Jan 2013 20:59:20 -0800 (PST) Received: from mail-vb0-f43.google.com (mail-vb0-f43.google.com [209.85.212.43]) by ietfa.amsl.com (Postfix) with ESMTP id 7D29721F85DA for ; Sun, 6 Jan 2013 20:59:16 -0800 (PST) Received: by mail-vb0-f43.google.com with SMTP id fs19so18699645vbb.2 for ; Sun, 06 Jan 2013 20:59:15 -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 :content-type; bh=W8pPTFy9k3q+RBQ8aC/xUaT0zhjKT/6/bhxPRt1zf7Y=; b=Dis3ru8g1S/14bGozBkZAplclKfZbnGuQ4J+NpmuKlrGh60PCl40Xl+ICFN8UBQm5f WfXeBfU0vxT6IPAAEelJqEO0GAjKRHKmcCss0xaU+84lNnluz5Y6wIVym6KtxdyCqrO5 CdV9HH/Zw2kZUw4dPKodf/AeOmHaw45m7t05CGjCT+LfrZEEgNGRoDP74rTZWkrcji/8 LaZr4JIZYzPMn247FxqWjFvC5Fth+wdd/H6i7ykWdpCQB6PGH2nuOpo0ZNt9nLH5HRus /HNHzIyKZNNcBVfcD+gP/biyvCvb2VUk3OZ9aY8XBXLK6KeAg9LWoUZBXqmRWZmgaaCz HwsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=W8pPTFy9k3q+RBQ8aC/xUaT0zhjKT/6/bhxPRt1zf7Y=; b=nt+uT92s57K03dBUUnWGVsqxWh/iwk2+d3W3pfq25aHRj9M4bLmdeLyjhIjksngUL/ Y0vSyY9BAkF3+T2jydycwu89e83qyX0QoGN1XFsyNAIp6IL3+QMPAUl4fZtYnE5d3x2b iepPwv1I+IEpmyRNkYxJkSQGDGZswhs7LlhodkA5M/1+ICcpi2gc5bXYXfxkw9FX/I+A +12hSvRi2uRdI7tdhfQ5fd8wN89FYIhieLnSYSwiS8Q1zehE+LUyF6Zv0UlAekFy4AXW k4diM6KbCeDPb070nZSrM5SyChLbue9D8VE0it2t50c5bqFILkKAUOgemXv3NhcRi6mf tnpg== Received: by 10.52.16.17 with SMTP id b17mr71332041vdd.86.1357534755791; Sun, 06 Jan 2013 20:59:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.255.226 with HTTP; Sun, 6 Jan 2013 20:58:55 -0800 (PST) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 7 Jan 2013 13:58:55 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=bcaec50408e8e3a28204d2abb0b3 X-Gm-Message-State: ALoCoQltJOZPKeBr7X4jG1VWJfxFfvg8ze7D2yVgQ/YJQmQzkqF6UkJjRKfOKSszmkXXa5nVb5YAuRY+02G5yuXmt3moc3bLq9GYeTB9NrezfhGIrWy3M32TKJ0k+rcLMbP5/Z6P8npmIW73Wn/dAhRW3AdZ0do/zNs5ShfmkmE/sKbkJpPKbMfy+AvNP3BDNiMsn+CY7sDL Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC 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, 07 Jan 2013 04:59:21 -0000 --bcaec50408e8e3a28204d2abb0b3 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Dec 17, 2012 at 1:28 PM, Takeshi Yoshino wrote: > b) move the method parameter into a new separate handshake header entry > pros: > - human readable > cons: > - introduces a new header not defined in 6455 > I got a request from chairs to elaborate why I considered this to be a disadvantage. Here are my thoughts about this. 1) To keep it able to use the same extension multiple times, we have to associate entries in the Sec-WebSocket-Compression-Spec header with entries in the Sec-WebSocket-Extensions header by adding ID for each of them. Sec-WebSocket-Extensions: permessage-compress; id=0, bar-ext, permessage-compress; id=1 Sec-WebSocket-Compression-Spec: id=0; max_win... Sec-WebSocket-Compression-Spec: id=1; max_win... This complicates the spec more than putting everything together in the Sec-WebSocket-Extensions. 2) Everyone knows Sec-WebSocket-Extensions, but not Sec-WebSocket-Compression-Spec. It's possible that headers not defined in RFC 6455 are filtered out by some firewall, proxy, etc. For these two extensions, it's ok since they're going to be well-known. But this approach misguides everyone that extension configuration that doesn't fit should go outside of Sec-WebSocket-Extensions. In the future, there'll be lots of headers that intermediary developers must take care of. --bcaec50408e8e3a28204d2abb0b3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 17, 2012 at= 1:28 PM, Takeshi Yoshino <tyoshino@google.com> wrote:
=
b) move the method parameter into a new= separate handshake header entry
pros:
- human readable
cons:
- introduce= s a new header not defined in 6455

<= div>I got a request from chairs to elaborate why I considered this to be a = disadvantage. Here are my thoughts about this.

1) To keep it able to use the sa= me extension multiple times, we have to associate entries in the Sec-WebSoc= ket-Compression-Spec header with entries in the Sec-WebSocket-Extensions he= ader by adding ID for each of them.

Sec-WebSocket-Extensions: permessage-compress; id=3D0, = bar-ext, permessage-compress; id=3D1
Sec-WebSocket-Compression-Sp= ec: id=3D0; max_win...
Sec-WebSocket-Compression-Spec: id=3D1; ma= x_win...

This complicates the spec more than putting everything = together in the Sec-WebSocket-Extensions.

2) Every= one knows Sec-WebSocket-Extensions, but not Sec-WebSocket-Compression-Spec.= It's possible that headers not defined in RFC 6455 are filtered out by= some firewall, proxy, etc. For these two extensions, it's ok since the= y're going to be well-known. But this approach misguides everyone that = extension configuration that doesn't fit should go outside of Sec-WebSo= cket-Extensions. In the future, there'll be lots of headers that interm= ediary developers must take care of.

--bcaec50408e8e3a28204d2abb0b3-- From SRS0+3ea0fdae24b2ad8a=LD=noemax.com=arman@noemax.com Thu Jan 10 06:12:16 2013 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 417F721F849A for ; Thu, 10 Jan 2013 06:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfrAGQXEsMsK for ; Thu, 10 Jan 2013 06:12:13 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 114FD21F845A for ; Thu, 10 Jan 2013 06:12:12 -0800 (PST) DKIM-Signature: a=rsa-sha1; t=1357827132; x=1358431932; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=lD0o1g6ENq+fBovzdK/TphJRFvw=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=kh2KtgXr+kD4rTTfwQlFDjv5k126zog+fnQCvV1ZtfHN1P8nmS+d4ukS42Igb4Gc+gKqsEBsFm4VzQb44yk+uNfzuJWQpbFS1IzTkSWmtOeR5oJghKvMpIPQnhQu08vl5W1hSSp2gVnlquDXFHfzH3ttTAsnfhAQol1bhfnqFfU= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.3) with ASMTP (SSL) id VPW57410; Thu, 10 Jan 2013 16:12:10 +0200 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , "'Julian Reschke'" References: <50E6D88E.7030100@gmx.de> In-Reply-To: Date: Thu, 10 Jan 2013 16:12:02 +0200 Message-ID: <000c01cdef3c$79b2ce50$6d186af0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CDEF4D.3D3B9E50" X-Mailer: Microsoft Outlook 14.0 thread-index: AQJZ+5S3sJWLaGhJEwxhlbOtpQum6AESZVQ1AqAyEUuXDOySMA== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 15:36:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01CDEF4D.3D3B9E50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit For me it doesn't make a big difference, I'm OK with going back to the old way, but we have to remember the reason why we ended up with method parameter. We did so in order to make compression extensions mutually exclusive. Plus, the current specification defines the DEFLATE method as just one of several possible methods, theoretically there can be multiple methods . If we change to permessage-compress-deflate then the specification would have to define how the extension name is formed based on the format it uses. I personally don't mind going back to old way, but AFAIR Tobias was working on Autobahn's test suite for permessage-compress interoperability. If his work is already done then reverting the spec again will require re-testing interop once again. With best regards, Arman From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino Sent: Monday, January 07, 2013 6:51 AM To: Julian Reschke Cc: hybi@ietf.org Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC Thanks, Julian. On Fri, Jan 4, 2013 at 10:26 PM, Julian Reschke wrote: I haven't followed the discussions that led to the current design, but this smells a bit like a case of an over-engineered extension point. Do you *really* expect that negotiation will have to happen on *paramaters*? No. But see below, please. If this is not the case, it would be *much* simpler to simply define different tokens for the different schemes and be done. So, for instance: Sec-WebSocket-Extensions: permessage-compress-deflate instead of Sec-WebSocket-Extensions: permessage-compress; method=deflate We've discussed that in this thread. http://www.ietf.org/mail-archive/web/hybi/current/msg09605.html and made a decision as announced in http://www.ietf.org/mail-archive/web/hybi/current/msg09618.html There was no strong opinion on either of them. We chose the current design because: - to simplify correspondence between a RSV bit and an ext. - to ease extension list processing by grouping compression method candidates into one ext. Shall we go back to the old approach? I'm ok with it. Comment please everyone. Keep in mind that if you extend quoted-string to essentially wrap other name/parameter pairs, you may end up with having to escape double quotes; and this is asking for trouble for something that really should be easy. ------=_NextPart_000_000D_01CDEF4D.3D3B9E50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

For me it doesn’t make a big difference, I’m OK with = going back to the old way, but we have to remember the reason why we = ended up with method parameter. We did so in order to make compression = extensions mutually exclusive. Plus, the current specification defines = the DEFLATE method as just one of several possible methods, = theoretically there can be multiple methods . If we change to = permessage-compress-deflate then the specification would have to define = how the extension name is formed based on the format it = uses.

 

I personally don’t mind going back to old way, but AFAIR Tobias = was working on Autobahn’s test suite for permessage-compress = interoperability. If his work is already done then reverting the spec = again will require re-testing interop once = again.

 

With best regards,

Arman

 

 

From:= = hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Takeshi Yoshino
Sent: Monday, January 07, 2013 6:51 = AM
To: Julian Reschke
Cc: = hybi@ietf.org
Subject: Re: [hybi] Resolutions for the issues = of the compression spec reported during WGLC

 

Thanks, Julian.

 

On Fri, Jan 4, 2013 at 10:26 PM, Julian Reschke <julian.reschke@gmx.de> = wrote:

I haven't = followed the discussions that led to the current design, but this smells = a bit like a case of an over-engineered extension point. Do you *really* = expect that negotiation will have to happen on = *paramaters*?

 

No. But see below, please.

 

If this is not the case, it would be = *much* simpler to simply define different tokens for the different = schemes and be done. So, for instance:

  = Sec-WebSocket-Extensions: permessage-compress-deflate

instead = of

  Sec-WebSocket-Extensions: permessage-compress; = method=3Ddeflate

 

We've discussed that in this = thread.

and made a decision as = announced in

 

There was no strong opinion on either of them. We = chose the current design because:

- to simplify correspondence between a RSV bit and an = ext.

- to ease extension = list processing by grouping compression method candidates into one = ext.

 

Shall we go back to the old approach? I'm ok with = it.

 

Comment please everyone.

 

Keep in = mind that if you extend quoted-string to essentially wrap other = name/parameter pairs, you may end up with having to escape double = quotes; and this is asking for trouble for something that really should = be easy.

 

------=_NextPart_000_000D_01CDEF4D.3D3B9E50-- From Gabriel.Montenegro@microsoft.com Thu Jan 10 13:24:20 2013 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 63A1621F87AC for ; Thu, 10 Jan 2013 13:24:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dSYsVCykyjEa for ; Thu, 10 Jan 2013 13:24:19 -0800 (PST) Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.30]) by ietfa.amsl.com (Postfix) with ESMTP id 61CF421F8632 for ; Thu, 10 Jan 2013 13:24:18 -0800 (PST) Received: from BY2FFO11FD016.protection.gbl (10.1.15.203) by BY2FFO11HUB004.protection.gbl (10.1.14.157) with Microsoft SMTP Server (TLS) id 15.0.596.13; Thu, 10 Jan 2013 21:24:14 +0000 Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD016.mail.protection.outlook.com (10.1.14.132) with Microsoft SMTP Server (TLS) id 15.0.596.13 via Frontend Transport; Thu, 10 Jan 2013 21:24:14 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 10 Jan 2013 21:23:54 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 10 Jan 2013 13:23:53 -0800 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.168]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0328.011; Thu, 10 Jan 2013 13:23:53 -0800 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: Meet in Orlando for IETF 86? Thread-Index: Ac3veICPQNTNc6TiRJu9ZbFVfciEEA== Date: Thu, 10 Jan 2013 21:23:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11638DBD7CTK5EX14MBXW603w_" MIME-Version: 1.0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(44976002)(54356001)(50986001)(47736001)(49866001)(31966008)(16406001)(79102001)(56776001)(4396001)(74662001)(55846006)(47976001)(16236675001)(15202345001)(77982001)(512954001)(46102001)(56816002)(5343635001)(33656001)(5343655001)(51856001)(16796002)(59766001)(76482001)(47446002)(54316002)(74502001)(53806001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB004; H:TK5EX14HUBC101.redmond.corp.microsoft.com; LANG:en; X-OriginatorOrg: microsoft.onmicrosoft.com X-Forefront-PRVS: 0722981D2A Subject: [hybi] Meet in Orlando for IETF 86? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 21:24:20 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11638DBD7CTK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, It's time to decide whether we need to meet in Orlando. We have till Monday= to request a slot at the meeting. It doesn't strike me that we have an urg= ent need to meet, but please let Salvatore and I know what your thoughts ar= e. Thanks, Gabriel --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11638DBD7CTK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

It’s time to decide whether we need to meet in= Orlando. We have till Monday to request a slot at the meeting. It doesn= 217;t strike me that we have an urgent need to meet, but please let Salvato= re and I know what your thoughts are.

 

Thanks,

 

Gabriel

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11638DBD7CTK5EX14MBXW603w_-- From tyoshino@google.com Mon Jan 14 18:50:21 2013 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 9FBCE11E809B for ; Mon, 14 Jan 2013 18:50:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TQOnxDE2pwo for ; Mon, 14 Jan 2013 18:50:20 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id BF3DE11E8099 for ; Mon, 14 Jan 2013 18:50:20 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id fy27so4248702vcb.41 for ; Mon, 14 Jan 2013 18:50:20 -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; bh=lEGYcCohMTxNimniS4GxRIUnDU7MSuBgrmF/MEerhTc=; b=PvegWqGZYinsNk4HXy9Ckg8WbAaIHy7/SHynw6f4oPnnFXCp3dZuxzYzFaMKvovu+O cR0kl3EgY8oGOMqlxu5GxIqw8WzHxmSb70YqQi+bFNz74NqmSq94+XPV6MdF6YZTCskU UrXBA1OKsBtocqMWDVdLcaKWYpwyK906Ed/5RF46RU34Gp/1fxjI+IsjE8JgB3L+tuMa p0apWAFm9MU7So2u7qBQr8ZqPbn8+alxqKLmT+ZnISLK/ELMgwl8JxKO61YgPVfIodD0 MnBQub3CVriY9QJvyh8S4U0BamevXShQAqHYfmzk4letI0BAkZd1969AJDCJqH8zm+v9 rYdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=lEGYcCohMTxNimniS4GxRIUnDU7MSuBgrmF/MEerhTc=; b=PD46xllUTQoz5YAhzde+D7qnuChzv4VAX0olCim7JEEw3NCJ85EXDRE/TTWg7Fu7cv 2IhPBUEifFsPWkafe/AWzyDxgRDDJ92Bx5vAnj7dl7MK6h/CZlKcVcMkcfxwIn8fofIM LsTazkHQHVApHOEoPlRkgJ6330Ki70bzwzR7PmXVrmG1iwT49Y7awCmfJV9AZrdrAZJy RYh9K9B8p+LRVHcWiXFlFmleQLh2dZtnijcpZzO6tO3SaLcGHv0OzaapKAh/kw5y5kqR s83mtf5DMeQGVSVa/fR/sdgQTMoybn3xjiH+Yz9YKfNw/5OELfdLHKKygOZ5tHTG/fut CstA== Received: by 10.52.178.225 with SMTP id db1mr92503427vdc.10.1358218220016; Mon, 14 Jan 2013 18:50:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.49.198 with HTTP; Mon, 14 Jan 2013 18:49:59 -0800 (PST) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 15 Jan 2013 11:49:59 +0900 Message-ID: To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=bcaec5196d7188146604d34ad203 X-Gm-Message-State: ALoCoQmSGYJAk6NvNqjb22P31PgMT7X+qUoN/LVFRvnE49i6uIddsHK+KEa+iWhlac6pfxn+XLuEjT9g9gvZBe4s313VMcn/rM8pai2eAQ6cOk/Y73K0ka5cZOfMvEXtiRVOqbCeaaBSJItRYgbETmqDmwyqzeJ/hBEzJMx5cu5kgXVrZEnh+HZcVcmx11dZhgm5HErGel1Z Cc: "hybi@ietf.org" Subject: Re: [hybi] Meet in Orlando for IETF 86? 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, 15 Jan 2013 02:50:21 -0000 --bcaec5196d7188146604d34ad203 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I'm ok with it. Let's continue to polish the specs online. Takeshi On Fri, Jan 11, 2013 at 6:23 AM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > Folks,**** > > ** ** > > It=92s time to decide whether we need to meet in Orlando. We have till > Monday to request a slot at the meeting. It doesn=92t strike me that we h= ave > an urgent need to meet, but please let Salvatore and I know what your > thoughts are. **** > > ** ** > > Thanks,**** > > ** ** > > Gabriel**** > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --bcaec5196d7188146604d34ad203 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
I'm ok with it. Let's continue to polish the specs= online.

Takeshi

On Fri, Jan 11, 2013 at 6:23 AM, Gabriel= Montenegro <Gabriel.Montenegro@microsoft.com> wrote:

Folks,

=A0

It=92s time to decide whether we need to meet in Orl= ando. We have till Monday to request a slot at the meeting. It doesn=92t st= rike me that we have an urgent need to meet, but please let Salvatore and I= know what your thoughts are.

=A0

Thanks,

=A0

Gabriel


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


--bcaec5196d7188146604d34ad203-- From tyoshino@google.com Mon Jan 14 20:30:27 2013 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 8209321F8799 for ; Mon, 14 Jan 2013 20:30:27 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMr8LMJzqFJg for ; Mon, 14 Jan 2013 20:30:26 -0800 (PST) Received: from mail-vb0-f41.google.com (mail-vb0-f41.google.com [209.85.212.41]) by ietfa.amsl.com (Postfix) with ESMTP id B407B21F8798 for ; Mon, 14 Jan 2013 20:30:26 -0800 (PST) Received: by mail-vb0-f41.google.com with SMTP id l22so4410328vbn.0 for ; Mon, 14 Jan 2013 20:30:26 -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; bh=L97ejNGq5mOmLachBrcV699R+BF17uw35Ghu5uic454=; b=WTze9vD7xVKTMXHMVxRfG9YnvBwKgYAVVlWpMx00j4Va1je4QdpTyMH72fq+CejylL 4/u8Hiek1hUENvSbFV3GqXBQoJ+lyAhek7QLWufjwD0ZcrzvLjMHkWu22eGB0ktk3zNm hJoBds+l8L6WYCw0Fey+MruuCkCtEzQe0aXJRwmI0riexL2nP15Yw/RgzVi/sNjPA67o F2TR2nmlZwkMnoxPQxtKSg1WN2x7dVy3ODbGvbMnn4ZRv3w0E1EDNJOUTvRfFMQPw6mS DUyZjXDnnaNnuGbQTJA5wlKLw8d38P4aKxROlZcCSxr8FFVWh4553GvxBRrlCwfcnLV2 hB6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=L97ejNGq5mOmLachBrcV699R+BF17uw35Ghu5uic454=; b=Bl7U1ZTwF1FBqHaSNW/ZtHo6OPtiDXpA7gzYZ1nySMMOo5Q8OBJdKe3oWItzzYl5X6 kqpjliAQJ7VKUozPsT9PrwL+Ncul1Jexn0wHsLEcAgbPZrCngrHmm4KrUL3VXdfPB/j4 FmYouUPbq/GzQhmIg/TPdWLYRQTE5kgi+TRJhISm34f6rDnRas62F721UlcJUG6nAGd1 gu9nKHIDml03ggme1PA9rlNEL728wuH7/ZNU9aFlK0h76OZOfTzzR/JxTtS4tyJneL23 8/Nc2a4HnMLOj7DwxwBFvPokrCkU2lbT+T6M/m2nR7vZ19mDp7ODTkMa9fsuEaVAlLMC kjfQ== Received: by 10.220.228.138 with SMTP id je10mr62087745vcb.67.1358224226093; Mon, 14 Jan 2013 20:30:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.49.198 with HTTP; Mon, 14 Jan 2013 20:30:04 -0800 (PST) In-Reply-To: <000c01cdef3c$79b2ce50$6d186af0$@noemax.com> References: <50E6D88E.7030100@gmx.de> <000c01cdef3c$79b2ce50$6d186af0$@noemax.com> From: Takeshi Yoshino Date: Tue, 15 Jan 2013 13:30:04 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae9cdc0f3858ac204d34c388e X-Gm-Message-State: ALoCoQnCdaD9OeSTbrzIvwxsDkpVzq15+lg14Vq/R/mZDZir38DBl0zL1sPQ/mQ5eNxu+Gpm5FfnFv7/uW+2hKEGIsRfHYI3IoKBcqtdf0rYy9dZRiVhyS+fDjw3Lw+ngBfuJq4rq0TnCmLWh7I/rQfUD6QtYPCXZZPX8eO50iJ+GFX2FE7eJEX83SSi5ChYUMuC8Ee2wRCt Cc: Julian Reschke , "hybi@ietf.org" Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC 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, 15 Jan 2013 04:30:27 -0000 --14dae9cdc0f3858ac204d34c388e Content-Type: text/plain; charset=ISO-8859-1 Thanks, Arman. It passed 1 week since my post calling for comments. Based on: - Julian and Arman's comment - the fact that we didn't have strong objection to 1 extension per 1 algorithm approach I'd like to - revert the spec (1 extension per 1 algorithm) - but keep text for general compression extension and deflate specific text separate (John Tamplin's opinion) - keep the spec name - keep framing detail unchanged I'll publish it as -05 in a few days. Tell me if you have any objection. Best Takeshi --14dae9cdc0f3858ac204d34c388e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks, Arman.

It passed 1 we= ek since my post calling for comments. Based on:
- Julian and Arman's comment
- the fact that we didn't have strong object= ion to 1 extension per 1 algorithm approach
I'd like to
- revert t= he spec (1 extension per 1 algorithm)
- but keep text for general compression ex= tension and deflate specific text separate (John Tamplin's opinion)
- keep the spec name
- keep framing detail unchanged

<= div class=3D"gmail_extra" style>I'll publish it as -05 in a few days. T= ell me if you have any objection.

Best
Takeshi

--14dae9cdc0f3858ac204d34c388e-- From SRS0+fa57565000a1b679=LI=noemax.com=arman@noemax.com Tue Jan 15 03:01:08 2013 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 7267021F866E for ; Tue, 15 Jan 2013 03:01:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uKBWKg-a9X5 for ; Tue, 15 Jan 2013 03:01:07 -0800 (PST) Received: from mail.noemax.com (mail.noemax.com [74.208.113.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB6B21F8645 for ; Tue, 15 Jan 2013 03:01:07 -0800 (PST) DKIM-Signature: a=rsa-sha1; t=1358247667; x=1358852467; s=m1024; d=noemax.com; c=relaxed/relaxed; v=1; bh=1Nxgz8/LIvo2B3cWWiJ+LLA0r0U=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:In-Reply-To:References; b=rKwVrJ9R3Fggd+0mRj23tRMBA/R4Hs8cJqLrMo9AWBGiGgyNTEawnMHrnWhs9xQ/z6bui73TsVNJQoaX8k1d+qgC+KEJErQAfcpzN+mXM2uS54evrPSpekg5+coJuJBj85i3gS9zzY5g285PZAG89HqYr4tsYumeQ87wJ+vz7YY= Received: from mail.noemax.com by mail.noemax.com (IceWarp 10.4.4) with ASMTP (SSL) id AMQ03706; Tue, 15 Jan 2013 13:01:06 +0200 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <50E6D88E.7030100@gmx.de> <000c01cdef3c$79b2ce50$6d186af0$@noemax.com> In-Reply-To: Date: Tue, 15 Jan 2013 13:00:55 +0200 Message-ID: <0b5f01cdf30f$9bb51f90$d31f5eb0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B60_01CDF320.5F3DEF90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJZ+5S3sJWLaGhJEwxhlbOtpQum6AESZVQ1AqAyEUsCIWm/XgMjcwTPluprctA= Content-Language: en-us Cc: 'Julian Reschke' , hybi@ietf.org Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC 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, 15 Jan 2013 12:04:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B60_01CDF320.5F3DEF90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Takeshi, That's fine with me. But will the specification define the rules for naming extensions that use other algorithms, and a general guideline on how to serialize compressed data into frames? Or from now on this specification will cover only deflate compression ? With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Tuesday, January 15, 2013 6:30 AM To: Arman Djusupov Cc: Julian Reschke; hybi@ietf.org Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC Thanks, Arman. It passed 1 week since my post calling for comments. Based on: - Julian and Arman's comment - the fact that we didn't have strong objection to 1 extension per 1 algorithm approach I'd like to - revert the spec (1 extension per 1 algorithm) - but keep text for general compression extension and deflate specific text separate (John Tamplin's opinion) - keep the spec name - keep framing detail unchanged I'll publish it as -05 in a few days. Tell me if you have any objection. Best Takeshi ------=_NextPart_000_0B60_01CDF320.5F3DEF90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello = Takeshi,

 

That’s = fine with = me.

 

But will the specification define the rules for naming = extensions that use other algorithms, and a = general guideline on how to = serialize = compressed data into frames? Or from now on this specification will = cover only deflate compression ?

 

With best regards,

Arman

 

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Tuesday, = January 15, 2013 6:30 AM
To: Arman Djusupov
Cc: = Julian Reschke; hybi@ietf.org
Subject: Re: [hybi] Resolutions = for the issues of the compression spec reported during = WGLC

 

Thanks, Arman.

 

It passed 1 week since my post calling for comments. = Based on:

- Julian and = Arman's comment

- the fact = that we didn't have strong objection to 1 extension per 1 algorithm = approach

I'd like = to

- revert the spec (1 = extension per 1 algorithm)

- but keep text for general compression extension and = deflate specific text separate (John Tamplin's = opinion)

- keep the spec = name

- keep framing detail = unchanged

 

I'll publish it as -05 in a few days. Tell me if you = have any objection.

 

Best

Takeshi

 

------=_NextPart_000_0B60_01CDF320.5F3DEF90-- From webmaster@zaphoyd.com Tue Jan 15 04:05:46 2013 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 6498221F88CC for ; Tue, 15 Jan 2013 04:05:46 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id docvn0OCvyfX for ; Tue, 15 Jan 2013 04:05:43 -0800 (PST) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8E52D21F88D1 for ; Tue, 15 Jan 2013 04:05:42 -0800 (PST) Received: from c-68-51-76-178.hsd1.il.comcast.net ([68.51.76.178]:41811 helo=[10.0.1.88]) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1Tv5Gv-0008Vl-8p; Tue, 15 Jan 2013 07:05:41 -0500 Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Peter Thorson In-Reply-To: Date: Tue, 15 Jan 2013 06:05:40 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1E570FA0-35CA-472B-9796-B0855A3043BB@zaphoyd.com> References: <50E6D88E.7030100@gmx.de> <000c01cdef3c$79b2ce50$6d186af0$@noemax.com> To: Takeshi Yoshino X-Mailer: Apple Mail (2.1499) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Get-Message-Sender-Via: sh78.surpasshosting.com: authenticated_id: webmaster@zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: Julian Reschke , "hybi@ietf.org" Subject: Re: [hybi] Resolutions for the issues of the compression spec reported during WGLC 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, 15 Jan 2013 12:05:46 -0000 Hi Takeshi, I have implemented extension negotiation per the 04 draft and I can say = that the parsing is definitely more complicated and error prone than = anything else previously used in the WebSocket protocol, thought not = necessarily in the deep corners of HTTP itself. This change should = simplify that considerably. I previously didn't have strong feelings = either way. The 04 method was more complicated but cleaner and more = expressive. The new method was a lot simpler but more messy and verbose = at the extension header level. Looking more closely at my extension negotiation code this morning I = think the 1 extension per algorithm is a good idea. Specifically, I = noticed that at the extension level I already have a system for = evaluating and choosing which extensions to use. Batching multiple sets = of extension parameters into the parameter list of a single extension = requires a second stage of parameter negotiation that while very = similar, is just different enough to need separate per extension = parameter negotiation code. Assuming multiple extension values with the = same name are still allowed (RFC6455 doesn't seem to forbid it) and the = rules about mutual exclusivity between different extensions in the same = family are clearly laid out, I don't see any functionality loss.=20 For this extension I think this is a good choice. One last question I = have though.. will this set a precedent towards simpler extension = options that will be a problem for any future extensions that might need = it for something other than parameter negotiation? Peter On Jan 14, 2013, at 22:30 , Takeshi Yoshino wrote: > Thanks, Arman. >=20 > It passed 1 week since my post calling for comments. Based on: > - Julian and Arman's comment > - the fact that we didn't have strong objection to 1 extension per 1 = algorithm approach > I'd like to > - revert the spec (1 extension per 1 algorithm) > - but keep text for general compression extension and deflate specific = text separate (John Tamplin's opinion) > - keep the spec name > - keep framing detail unchanged >=20 > I'll publish it as -05 in a few days. Tell me if you have any = objection. >=20 > Best > Takeshi >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ricea@google.com Wed Jan 23 01:30:59 2013 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 82FC821F86A3 for ; Wed, 23 Jan 2013 01:30:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.974 X-Spam-Level: X-Spam-Status: No, score=-102.974 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xaKjXBr0dk9 for ; Wed, 23 Jan 2013 01:30:58 -0800 (PST) Received: from mail-bk0-f52.google.com (mail-bk0-f52.google.com [209.85.214.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4300521F844E for ; Wed, 23 Jan 2013 01:30:57 -0800 (PST) Received: by mail-bk0-f52.google.com with SMTP id y7so1483067bkt.11 for ; Wed, 23 Jan 2013 01:30:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=GqtPu29wkU90Igp+KHhVPUeOqRbW+yRbXEK0CUCkffk=; b=YKS1wfnqDrkRG9evn/pqjjP9yUrWP//qQGv/s0QOB2xB8DIZ1knbCA4+GHVfLv2EkB VoUHHvPlNgp28qok88S47/PB6ORaLf1y4J8lr9AHtgMJZFpx728UqkN7fP+58zc9PBbB MKptOrrJrCppDjG9F6c89vdi8AoNh+NE4TzRBZW7ci9HQvmNpVhxHV2q1SE/Wnc+TO/w HFTAEyN/UP61DCcWSP8eoRbfjmkbRogoheofCcGvvton7fENfSN8/u5iR2MKZy6wEnUs ojC1+Ou50il86ePhNfsRu3fYA0Q3BmQp1PvAEXPE3oa0Prz8OJQFLYAxINVGY7YLVVGR 4FnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=GqtPu29wkU90Igp+KHhVPUeOqRbW+yRbXEK0CUCkffk=; b=ZcW+m4ZMtKJPDtLtzs8sZ+rAxiYDteYZA1xfJCT/o+rVfHc4TvvAUBCak8IkHjnVcT TSDSKcfjCVuEPAzP/3Ia3Tk/g5bOfT+Cc8Gakm1+gzPyPqZFBXjmrmzUHHRXl9UFg7Ri ZkKfTk5FfFkFlK5Rp/g+NbG2CWkdhLadgidPE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type:x-gm-message-state; bh=GqtPu29wkU90Igp+KHhVPUeOqRbW+yRbXEK0CUCkffk=; b=iL6gyRlO0fEncnPbz6aVEUzS9d9sczTY78CWDHiQUPqvbLZoTKmnRweou9l7HE3jrI u/ifb7pymHYRsucox1Ts4ayvZHm1izu/3tkVFaIP42Y628A6nbEZkNbHxNbnVoS/SfN3 fsvUpnTupNsHD1YR3wNhjekK+1vUYu6hvyKWm484b3cQ4HVN01IP84z8mR2d6chIDO+v UANoz58sizBJp6y7A1b9XLiCnZif0NW6zKzZLJv4EqEkk5QtWT1fbkYD7W0sEK6156fD m1tIb9rj4wUrR0HtvqapDcR/AoPvjVG30nCp3/90MmdZsfT81A2Z/q+DLRuwUubRWQ7c T00A== MIME-Version: 1.0 X-Received: by 10.204.9.23 with SMTP id j23mr182432bkj.2.1358933457008; Wed, 23 Jan 2013 01:30:57 -0800 (PST) Sender: ricea@google.com Received: by 10.204.114.19 with HTTP; Wed, 23 Jan 2013 01:30:56 -0800 (PST) Date: Wed, 23 Jan 2013 18:30:56 +0900 X-Google-Sender-Auth: urcDu3Bq5BJQJ88df9Xyh3JAe5g Message-ID: From: Adam Rice To: hybi@ietf.org Content-Type: multipart/alternative; boundary=00151758a602fa781604d3f1596b X-Gm-Message-State: ALoCoQnyu7F5RuRPHSJkpd8+vfEStSdIUr48gMxfLlthjbT/W4zICw9e3iyKN9idqBRt1d+h7kYf8349MJe8Fs0/9eAinCp7dAUbKoiAu6L7xJLng504YDYD5Fwvkfnr1l4EN18bp/A9nREFwq8P2GS+7Omqx5bNE+MytgJCc6PDXXnP6kVBAttPB5daU63iRvKGlnAOu6rX Subject: [hybi] WebSocket connection throttling clarification requested 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, 23 Jan 2013 09:32:28 -0000 --00151758a602fa781604d3f1596b Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to ask for clarification on section 4.1 item 2 of WebSocket RFC 6455. It reads (emphasis mine): 2. If the client already has a WebSocket connection to the remote host (IP address) *identified by /host/ and port /port/ pair,* even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. If multiple connections *to the same IP address* are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps. The first sentence seems to imply that connections should be throttled on the basis of (host, port) pairs, ie. that ws://192.0.2.1:80/ and ws:// 192.0.2.1:81/ should be considered independent for the purposes of connection throttling. The last sentence seems to imply that connections should be throttled on the basis of IP address only, so connections ws:// 192.0.2.1:80/ and ws://192.0.2.1:81/ should be placed in the same bucket for throttling purposes. Which interpretation is correct? Thank you, Adam Rice --00151758a602fa781604d3f1596b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I would like to ask for clari= fication on section 4.1 item 2 of WebSocket RFC 6455. It reads (emphasis mi= ne):

2. If the client already has a WebSocket connection to the remote host= (IP address) identified by /host/ and port /port/ pair, even if the= remote host is known by another name, the client MUST wait until that conn= ection has been established or for that connection to have failed. There MU= ST be no more than one connection in a CONNECTING state. If multiple connec= tions to the same IP address are attempted simultaneously, the clien= t MUST serialize them so that there is no more than one connection at a tim= e running through the following steps.

The first sente= nce seems to imply that connections should be throttled on the basis of (ho= st, port) pairs, ie. that ws://192.0.2.1:8= 0/ and ws://192.0.2.1:81/ should b= e considered=A0independent=A0for the purposes of connection throttling. The= last sentence seems to imply that connections should be throttled on the b= asis of IP address only, so connections ws://192.0.2.1:80/ and ws://192.0.2.1:81= / should be placed in the same bucket for throttling purposes.

Which interpretation is correct?

Thank you,
Adam Rice
--00151758a602fa781604d3f1596b-- From derhoermi@gmx.net Wed Jan 23 13:02:12 2013 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 3261F21F874F for ; Wed, 23 Jan 2013 13:02:12 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdFtv-10h89P for ; Wed, 23 Jan 2013 13:02:11 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0DBE521F8694 for ; Wed, 23 Jan 2013 13:02:10 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.4]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M0vtR-1Ut5nZ0WgZ-00v7FF for ; Wed, 23 Jan 2013 22:02:10 +0100 Received: (qmail invoked by alias); 23 Jan 2013 21:02:09 -0000 Received: from pD9538B97.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [217.83.139.151] by mail.gmx.net (mp004) with SMTP; 23 Jan 2013 22:02:09 +0100 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/nC5UhpBLnn89tq2Q3qzEk3aIP0tu736Aw/TsSdz SA7j3NyNEWxxcn From: Bjoern Hoehrmann To: Adam Rice Date: Wed, 23 Jan 2013 22:02:11 +0100 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket connection throttling clarification requested 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, 23 Jan 2013 21:02:12 -0000 * Adam Rice wrote: >I would like to ask for clarification on section 4.1 item 2 of WebSocket >RFC 6455. It reads (emphasis mine): > >2. If the client already has a WebSocket connection to the remote host (IP >address) *identified by /host/ and port /port/ pair,* even if the remote >host is known by another name, the client MUST wait until that connection >has been established or for that connection to have failed. There MUST be >no more than one connection in a CONNECTING state. If multiple connections *to >the same IP address* are attempted simultaneously, the client MUST >serialize them so that there is no more than one connection at a time >running through the following steps. > >The first sentence seems to imply that connections should be throttled on >the basis of (host, port) pairs, ie. that ws://192.0.2.1:80/ and ws:// >192.0.2.1:81/ should be considered independent for the purposes of >connection throttling. The last sentence seems to imply that connections >should be throttled on the basis of IP address only, so connections ws:// >192.0.2.1:80/ and ws://192.0.2.1:81/ should be placed in the same bucket >for throttling purposes. It seems pretty clear to me that the more conservative interpretation is the intended one. One reason is that there would otherwise be no limit on the simultaneous attempts to connect with a single IP address using different port numbers. It seems "identified by /host/ and port /port/ pair" can safely be removed without replacement through errata. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From internet-drafts@ietf.org Wed Jan 23 23:49:42 2013 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 B712D21F87FE; Wed, 23 Jan 2013 23:49:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4T3fAX1Nlxjh; Wed, 23 Jan 2013 23:49:42 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392C221F857D; Wed, 23 Jan 2013 23:49:42 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130124074942.29406.8064.idtracker@ietfa.amsl.com> Date: Wed, 23 Jan 2013 23:49:42 -0800 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-05.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 07:49:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTTP Wo= rking Group of the IETF. Title : WebSocket Per-message Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-05.txt Pages : 20 Date : 2013-01-23 Abstract: This document specifies a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. Extensions based on this framework compress the payload of non- control WebSocket messages using a specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each message. This document also specifies one specific compression extension using DEFLATE. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Wed Jan 23 23:55:09 2013 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 F194221F89AA for ; Wed, 23 Jan 2013 23:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.976 X-Spam-Level: X-Spam-Status: No, score=-101.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1k86WORYckxO for ; Wed, 23 Jan 2013 23:55:08 -0800 (PST) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by ietfa.amsl.com (Postfix) with ESMTP id 291DD21F89A4 for ; Wed, 23 Jan 2013 23:55:07 -0800 (PST) Received: by mail-ve0-f171.google.com with SMTP id 14so1349362vea.2 for ; Wed, 23 Jan 2013 23:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=d7OqLA+oSRil+m5svzOJtFlorE6BI7sTQDRIoqbS2TY=; b=mVZaLQ3Ao1D1+FWjubwaYNrZUGfzyNQjR/4x8m6wWdPQvYbhiLNY0aKDCdSE9Mj+jc ZbONbe2xw+obBSJQ3P5A8FLbJk9RRRyT5DWLdXmu7ieqTBEItoisyagzqqYBV3bjIHwI OHV0jkkoYfFaQ3UYiIcwUg257/4Ln2iv6dABTHirVHKB3Wv0+EtBBZX9g1xb9wbcV7ch /FLO5xHXFHM2S6PoegYQqigsm3fqoc3SOaviwsMhuPAKZEBC8oQEwSY/f2ljHf90K9nS mOPrXtXLkNnSq/pIONtg+vflrhlsK9wSafQOnrG7ycxJkUVU66S0vg8mOvF15IkVCYtH ulzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=d7OqLA+oSRil+m5svzOJtFlorE6BI7sTQDRIoqbS2TY=; b=nLJ571xllMg0Nchs0nbgkVd9JpMcB1Dcx5JXHW2gqTYzWJL/C7mqkWDo4giuEBXNrg HpVaEJ37xsmEKzEWjfBhfq+Ozw/oK3CrL4BiaUX8ZMZ2tu0lev/bqTJLu6MOA13Vd9Cq sZetE36Rccg32CbQgZEhacLVNu3JvTsXiNJEs+qw0YV5Tv1JGsAoBG+7eljjtlJduIyt b6embu6TGesWOLb7J323+hAlz8ZhfIaRJ5YtzX4mxQSb9u/tiD7F1cY117qJ8TI7+YtR MRWdTXKF7jXPx1MvfLEbeeWUDkFjieiIhbHkjJB7yLKj5agWuspuXOg90byWBfpjj3rl VVdQ== X-Received: by 10.52.156.7 with SMTP id wa7mr869246vdb.46.1359014107273; Wed, 23 Jan 2013 23:55:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.207.231 with HTTP; Wed, 23 Jan 2013 23:54:47 -0800 (PST) In-Reply-To: <20130124074942.29406.8064.idtracker@ietfa.amsl.com> References: <20130124074942.29406.8064.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 24 Jan 2013 16:54:47 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=bcaec53aec041bd89a04d40421b8 X-Gm-Message-State: ALoCoQlrtFewntlBeEsUJylc015nvt1ZFq4QIyeaC2TA6OIeJaq0Yq92GGJhOJdagdPLCQfHntpd12NWw6rvyUwliMs+0H9rjyhKgZu0vgWt3QeT8CTABb/BWWWNB5pJhsWirORUHnWKok3S/kbXqYbcdb1hJPWkdeFAJc2NBiWpVtpltanF5BJQDY1rRp1TJf+UHdzOgbFV Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-05.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 07:55:09 -0000 --bcaec53aec041bd89a04d40421b8 Content-Type: text/plain; charset=ISO-8859-1 See also: http://www.ietf.org/mail-archive/web/hybi/current/msg09938.html Addressed issues reported during WGLC (ended 2012/Nov/14) - Conflict between "method" extension parameter spec and RFC 6455 -- http://www.ietf.org/mail-archive/web/hybi/current/msg09904.html -- FIXED: Changed the spec back to adopt 1 extension / algorithm approach - English grammar issues -- http://www.ietf.org/mail-archive/web/hybi/current/msg09902.html -- FIXED - Add an option to suppress compression on client-to-server data -- http://www.ietf.org/mail-archive/web/hybi/current/msg09922.html -- WONT FIX: Didn't receive much support/justification. - Clarified that the condition lists defining bad parameters are OR list --bcaec53aec041bd89a04d40421b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Ad= dressed issues reported during WGLC (ended 2012/Nov/14)

- Conflict between "method" extension parameter spec and RFC = 6455
-- FIXED: Changed the spec back to ado= pt 1 extension / algorithm approach
- English grammar issues
-- FIXED
- Add an option to suppress compression on client-to-ser= ver data
-- WONT FIX: Didn't receive much support/justification.
= - Clarified that the condition lists defining bad parameters are OR list

--bcaec53aec041bd89a04d40421b8-- From simone.bordet@gmail.com Thu Jan 24 01:48:33 2013 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 3DA2E21F8503 for ; Thu, 24 Jan 2013 01:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzyZvekerJUt for ; Thu, 24 Jan 2013 01:48:32 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id BA68D21F84F0 for ; Thu, 24 Jan 2013 01:48:32 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id x6so4160429dac.26 for ; Thu, 24 Jan 2013 01:48:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uK/9bTQtAqp62n8BcrXZq0QgW5C9yN5WI4pafFbGIsU=; b=CgZnbiSVUe5Kg3V8JehvnBuy2VNbGB4pBQO6mzkvQnUIYkLZdF+tDPljq3ssLKhTzZ rw84phltKW7Iv43dx8Fg9WpNO1lfPUEqOas/OLVmnY/DBDMvu/81ONsOGbg8yqGcEWko 9EbwSmvpKynlcYkXnGbvc9Ojfru0bbc3AtRRQXI/PK4CLuczaxPc3Wtzs0I232a0QIJA ig8RhYVEkrPX/vuz6stC3pMW7cY0vdFn/Osh+SMruULMRn9jfkrLELUdnFZY5sXPhj+e AvvEFC2sZAyo/kPMmZs1+iGua2D2cEgFRHFJmU3UsIVnyjogbcvuglyiQVd+75ETA2Vr YFZw== MIME-Version: 1.0 X-Received: by 10.66.87.67 with SMTP id v3mr3062357paz.63.1359020912469; Thu, 24 Jan 2013 01:48:32 -0800 (PST) Received: by 10.68.209.228 with HTTP; Thu, 24 Jan 2013 01:48:32 -0800 (PST) In-Reply-To: References: Date: Thu, 24 Jan 2013 10:48:32 +0100 Message-ID: From: Simone Bordet To: Adam Rice Content-Type: text/plain; charset=UTF-8 Cc: Hybi Subject: Re: [hybi] WebSocket connection throttling clarification requested X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 09:48:33 -0000 Hi, On Wed, Jan 23, 2013 at 10:30 AM, Adam Rice wrote: > Hi, > > I would like to ask for clarification on section 4.1 item 2 of WebSocket RFC > 6455. It reads (emphasis mine): > > 2. If the client already has a WebSocket connection to the remote host (IP > address) identified by /host/ and port /port/ pair, even if the remote host > is known by another name, the client MUST wait until that connection has > been established or for that connection to have failed. There MUST be no > more than one connection in a CONNECTING state. If multiple connections to > the same IP address are attempted simultaneously, the client MUST serialize > them so that there is no more than one connection at a time running through > the following steps. May I ask the reason for this requirement ? It seems to me that a protocol should not limit in this way concurrent connects to a host. This look more like a recommendation for implementers, but not something that should be mandated in a protocol. For example, this would be sub-optimal for client WebSocket libraries that can be used to perform load testing, or server-to-server communication, etc. Not all clients or use cases are browsers. I'd like to propose to remove this requirement and changing it a non-normative section as a suggestion for browser implementations. Thanks ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz From denis.m.f.mcmahon@googlemail.com Sun Jan 27 15:58:43 2013 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 9BD0B21F87F7 for ; Sun, 27 Jan 2013 15:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.539 X-Spam-Level: X-Spam-Status: No, score=-0.539 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_UK=1.749, HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFehww6KRjKg for ; Sun, 27 Jan 2013 15:58:42 -0800 (PST) Received: from smtp.demon.co.uk (mdfmta009.mxout.tbr.inty.net [91.221.168.50]) by ietfa.amsl.com (Postfix) with ESMTP id 8740E21F86EA for ; Sun, 27 Jan 2013 15:58:42 -0800 (PST) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id D52FC38407C for ; Sun, 27 Jan 2013 23:58:40 +0000 (GMT) Received: from mdfmta009.tbr.inty.net (unknown [127.0.0.1]) by mdfmta009.tbr.inty.net (Postfix) with ESMTP id B60F838406F for ; Sun, 27 Jan 2013 23:58:40 +0000 (GMT) Received-SPF: neutral (mdfmta009.tbr.inty.net: 62.49.24.171 is neither permitted nor denied by domain of googlemail.com) client-ip=62.49.24.171; envelope-from=denis.m.f.mcmahon@googlemail.com; helo=[192.168.1.65]; Received: from [192.168.1.65] (unknown [62.49.24.171]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mdfmta009.tbr.inty.net (Postfix) with ESMTP for ; Sun, 27 Jan 2013 23:58:39 +0000 (GMT) Message-ID: <5105BF2D.50104@googlemail.com> Date: Sun, 27 Jan 2013 23:58:37 +0000 From: Denis McMahon Organization: Denis McMahon User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: hybi@ietf.org X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-MDF-HostID: 4 X-Mailman-Approved-At: Sun, 27 Jan 2013 16:54:03 -0800 Subject: [hybi] RFC 6455 Client-Server Masking X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: denis.m.f.mcmahon@googlemail.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 00:29:26 -0000 The unpredictability of the masking key is essential to prevent authors of malicious applications from selecting the bytes that appear on the wire. >From this statement, I assume that the purpose of masking is "to prevent authors of malicious applications from selecting the bytes that appear on the wire." -= However =- The masking key is transmitted as part of the packet, and appears as 4 bytes ABCD. This is like sending data inside a locked casket for security, WITH THE KEY SAFELY TIED TO THE CASKET! It follows from the protocol description that to detect any arbitrary sequence of n bytes in length, it is merely necessary to determine the four possible bit sequences that those bytes might represent, and monitor for all four of those bit sequences. The masking sequence for any N bytes of data will be one of four sequences, based on the mask bytes ABCD: 012345678.....n ABCDABCDA...... BCDABCDAB...... CDABCDABC...... DABCDABCD...... Given any sequence b1 ... bn which the attacker wishes to detect, the attacker simply has to combine, for each frame, b1 ... bn with each of the 4 possible sequences of n bytes in length of masking bytes, and listen for all 4 sequences. Computationally this is a trivial exercise! This mechanism does nothing to significantly increase the difficulty of a malicious application listening to the bytes on the wire with the intention of detecting specific patterns. It would be much better if the protocol dropped the masking concept, stated that it makes no attempt to protect data from eavesdropping or interception, and made the recommendation that if data security is desired, then appropriate transport layer security eg RFC 5246 TLS1.2 / RFC 6101 SSL3.0 should be employed. Denis McMahon From theturtle32@gmail.com Sun Jan 27 17:26:12 2013 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 6B42921F86CA for ; Sun, 27 Jan 2013 17:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u15wtLgdVGju for ; Sun, 27 Jan 2013 17:26:11 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id BD5A521F8573 for ; Sun, 27 Jan 2013 17:26:11 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz10so1196297pad.37 for ; Sun, 27 Jan 2013 17:26:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=p3ykf3Rs5/DXVpsSAPv7JCBvMsiM2yujRkZ1ikL/fTc=; b=h3KXrvdTnktlRlu5myUaI/9epx8FxQPRG8ALiw4OsSfv0mS8B1KMXil9nZxAZuOY+6 X66OVVUoJgRbokQoSNEzZyBBHOnOUTP1njUm7vmWcWYNZdTT1Tupbr07iRVTZLiDssjL FSl1smbAnYWh0X0MyS39j0U74269ChApLZnUOhaHV3cdWKPLbwTXv5k0mb3oUZqClFgp CI9ybEK5a07wP1LAj+1JDkG7uv36uoDPqyi3ZgGLeWIT+w4+s63iWlI/qS1+I/yDRdMJ TpPsFkLVA2/jRKKVw5O7MfJ4KL2NVC65iPzt5LwetYRsVFhhvFbjDEhHveRYhxHhl6On 7wPw== X-Received: by 10.66.74.98 with SMTP id s2mr31907264pav.64.1359336371518; Sun, 27 Jan 2013 17:26:11 -0800 (PST) Received: from [192.168.0.101] (75-142-117-193.static.mtpk.ca.charter.com. [75.142.117.193]) by mx.google.com with ESMTPS id kp4sm5222597pbc.52.2013.01.27.17.26.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 27 Jan 2013 17:26:10 -0800 (PST) References: <5105BF2D.50104@googlemail.com> Mime-Version: 1.0 (1.0) In-Reply-To: <5105BF2D.50104@googlemail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10A525) From: Brian McKelvey Date: Sun, 27 Jan 2013 17:26:07 -0800 To: "denis.m.f.mcmahon@googlemail.com" Cc: "hybi@ietf.org" Subject: Re: [hybi] RFC 6455 Client-Server Masking 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, 28 Jan 2013 01:26:12 -0000 The purpose of the masking has nothing to do with preventing eavesdropping o= r interception. It's meant to prevent malicious javascript running in a web= browser from connecting to arbitrary non-websocket services, or from tricki= ng http-unaware proxies into doing the attacker's bidding, caching malicious= data, etc. It's about preventing browsers from initiating attacks against unsuspecting s= ervices, not about preventing eavesdropping or securing the privacy of data i= n transit. The use of TLS with WebSockets is required for that. Brian Sent from my iPhone On Jan 27, 2013, at 3:58 PM, Denis McMahon wrote: > The unpredictability of the masking key is essential to prevent authors > of malicious applications from selecting the bytes that appear on the wire= . >=20 > =46rom this statement, I assume that the purpose of masking is "to prevent= > authors of malicious applications from selecting the bytes that appear > on the wire." >=20 > -=3D However =3D- >=20 > The masking key is transmitted as part of the packet, and appears as 4 > bytes ABCD. This is like sending data inside a locked casket for > security, WITH THE KEY SAFELY TIED TO THE CASKET! >=20 > It follows from the protocol description that to detect any arbitrary > sequence of n bytes in length, it is merely necessary to determine the > four possible bit sequences that those bytes might represent, and > monitor for all four of those bit sequences. >=20 > The masking sequence for any N bytes of data will be one of four > sequences, based on the mask bytes ABCD: >=20 > 012345678.....n > ABCDABCDA...... > BCDABCDAB...... > CDABCDABC...... > DABCDABCD...... >=20 > Given any sequence b1 ... bn which the attacker wishes to detect, the > attacker simply has to combine, for each frame, b1 ... bn with each of > the 4 possible sequences of n bytes in length of masking bytes, and > listen for all 4 sequences. Computationally this is a trivial exercise! >=20 > This mechanism does nothing to significantly increase the difficulty of > a malicious application listening to the bytes on the wire with the > intention of detecting specific patterns. >=20 > It would be much better if the protocol dropped the masking concept, > stated that it makes no attempt to protect data from eavesdropping or > interception, and made the recommendation that if data security is > desired, then appropriate transport layer security eg RFC 5246 TLS1.2 / > RFC 6101 SSL3.0 should be employed. >=20 > Denis McMahon >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ricea@google.com Sun Jan 27 21:23:36 2013 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 2D18F21F851E for ; Sun, 27 Jan 2013 21:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqyMCuhkN7DU for ; Sun, 27 Jan 2013 21:23:35 -0800 (PST) Received: from mail-vb0-f51.google.com (mail-vb0-f51.google.com [209.85.212.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6A21F84CA for ; Sun, 27 Jan 2013 21:23:34 -0800 (PST) Received: by mail-vb0-f51.google.com with SMTP id fq11so1641619vbb.10 for ; Sun, 27 Jan 2013 21:23:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6a49gQlqa0MQqNMXdJliDqBaWaH9W7ROEJF4VEBCKhs=; b=XZ6EsXI5ig6/E/ge8QTRVfXYzYMha8wRm5MlHAXytmlKZdJbAtRE/SfbVH0eqviDJ1 kZwRqYhB/66NGH0a0l2kCC39Y6DQxFZBuF7dsNu/JyFwn5YluS0RoWESEwN65Os5Wkmu 5eEPA1O0JQwwY57xRwEYaZNUPFk+BKxBv0Ing4yGrr6T/YRiQzBiG7HkeI6KZpHPKEQ+ 8w401LOAdQMYMcw3ZKtDQfosuX53Y0eVrmyUU6w2+hGKwq0hFt92Wk01pyouyRpWeAJ/ y93JkZM3v/mCpdoEO4hKZ/uwZ7UPrxm33iJLqMouinJaRmm93tHOxmATped0x8Ff8xSY LmDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=6a49gQlqa0MQqNMXdJliDqBaWaH9W7ROEJF4VEBCKhs=; b=psHy38L23w+PkMwKW3GlTwhQY9ZQa1JOxTpTTW4sTtrtbURpimFcZ9D4QTwAaFy07w vvHzYSTTRUL7Tey92JlNytDKg5Wutzxr4ralhAcAOGIZMgjhOWvKtmsjoKhaOAUZP38Z XBP7Zp4pBJcc0/JcEEhL2BPz3Dip2UDWwUDKJFZK0Qp2dtcdCkLf+DoBEgtrNrHGgC1L t2PA4wccg1HimD9xxuJe1IbTv7q7KMxshC2VBMtbNRMrb6T5TyJC3bHMhwhlvF2+VJhw Bskr6kCFF7hwMM+Ei2PNfnhCtBfm3BM2NRzO7p3aZ4heR1ZPlBW+V+wB/JPvCCDX3kAt 1AGw== MIME-Version: 1.0 X-Received: by 10.221.9.144 with SMTP id ow16mr1251499vcb.29.1359350613231; Sun, 27 Jan 2013 21:23:33 -0800 (PST) Received: by 10.58.96.6 with HTTP; Sun, 27 Jan 2013 21:23:33 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 14:23:33 +0900 Message-ID: From: Adam Rice To: Bjoern Hoehrmann Content-Type: multipart/alternative; boundary=bcaec54a38006d499304d4527a03 X-Gm-Message-State: ALoCoQlCV3fiNvD9x+ol4TDiLvSdalY18KiTsqn2CmSN1sfanEuqIi1sLgOtHS2lDesZcbc+j5GWPJgCuUkmG1JIm5Kprx4sykk0djJ55OZNdfDpbjWI6UZxQb5bxKhi75Jp64K67MJwq+K4uAFLTcOIHxeEZMARGZmFn0ZcJCP0wV8IlzcOgDobujSjULUMtFWtD3JejMQm X-Mailman-Approved-At: Sun, 27 Jan 2013 21:40:14 -0800 Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket connection throttling clarification requested 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, 28 Jan 2013 05:23:36 -0000 --bcaec54a38006d499304d4527a03 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am concerned that the "throttling is per IP address (regardless of port)" interpretation allows for a denial of service against any host which uses web sockets and also has a firewall policy to drop SYN packets to unused ports. Example: 1. attacker opens a socket to ws://google.com:81/ 2. since there is no response to the TCP/IP SYN packet, the connection hangs until it times out on the client-side. 3. The user attempts navigates to google.com in another tab, which attempts to open a connection to ws://google.com:80/ 4. If we consider port 81 and port 80 to be in the same bucket for connection throttling, the user's legitimate connection will hang waiting for the attacker's connection to finish. Obviously a single connection will not hang for more than a few minutes at most, but the attacker can open hundreds of connections, essentially completely blocking google.com from using WebSockets for as long as the user doesn't close the attacker's page. Since the browser is not doing a lot of work (only sending a SYN packet every few seconds), it remains completely responsive and from the user's point of view it appears that google.com is simply not working. SYN-dropping firewalls are ubiquitous among major commercial websites, and it seems unlikely that this policy will change. I think there is a risk that this will hurt WebSocket adoption. I would therefore like to propose that the wording of the third paragraph is changed from "to the same IP address" to "to the same /host/ and /port/ pair", so that this interpretation will be unambiguously endorsed. On 24 January 2013 06:02, Bjoern Hoehrmann wrote: > * Adam Rice wrote: > >I would like to ask for clarification on section 4.1 item 2 of WebSocket > >RFC 6455. It reads (emphasis mine): > > > >2. If the client already has a WebSocket connection to the remote host (= IP > >address) *identified by /host/ and port /port/ pair,* even if the remote > >host is known by another name, the client MUST wait until that connectio= n > >has been established or for that connection to have failed. There MUST b= e > >no more than one connection in a CONNECTING state. If multiple > connections *to > >the same IP address* are attempted simultaneously, the client MUST > >serialize them so that there is no more than one connection at a time > >running through the following steps. > > > >The first sentence seems to imply that connections should be throttled o= n > >the basis of (host, port) pairs, ie. that ws://192.0.2.1:80/ and ws:// > >192.0.2.1:81/ should be considered independent for the purposes of > >connection throttling. The last sentence seems to imply that connections > >should be throttled on the basis of IP address only, so connections ws:/= / > >192.0.2.1:80/ and ws://192.0.2.1:81/ should be placed in the same bucket > >for throttling purposes. > > It seems pretty clear to me that the more conservative interpretation is > the intended one. One reason is that there would otherwise be no limit > on the simultaneous attempts to connect with a single IP address using > different port numbers. It seems "identified by /host/ and port /port/ > pair" can safely be removed without replacement through errata. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ > --bcaec54a38006d499304d4527a03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I am concerned that the "throttling is per IP address= (regardless of port)" interpretation allows for a denial of service a= gainst any host which uses web sockets and also has a firewall policy to dr= op SYN packets to unused ports.

Example:

1. attac= ker opens a socket to ws://google.com:81/=
2. since there is no response to the TCP/IP SYN packet= , the connection hangs until it times out on the client-side.
3. The user attempts navigates to = google.com in another tab, which attempts to open a connection to ws://= google.com:80/
4. If = we consider port 81 and port 80 to be in the same bucket for connection thr= ottling, the user's legitimate connection will hang waiting for the att= acker's connection to finish.

Obviously a single connection will not hang= for more than a few minutes at most, but the attacker can open hundreds of= connections, essentially completely blocking google.com from using WebSockets for as long as the user doesn't c= lose the attacker's page.

Since the browser is not doing a lot of wor= k (only sending a SYN packet every few seconds), it remains completely resp= onsive and from the user's point of view it appears that google.com is simply not working.

SYN-dropping firewalls are ubiquitous among= major commercial websites, and it seems unlikely that this policy will cha= nge. I think there is a risk that this will hurt WebSocket adoption.

I would therefore like to propose that the = wording of the third paragraph is changed from "to the same IP address= " to "to the same /host/ and /port/ pair", so that this inte= rpretation will be unambiguously endorsed.



<= br>




On 24 January 2013 06:02, Bjoer= n Hoehrmann <derhoermi@gmx.net> wrote:
* Adam Rice wrote:
>I would like to ask for clarification on section 4.1 item 2 of WebSocke= t
>RFC 6455. It reads (emphasis mine):
>
>2. If the client already has a WebSocket connection to the remote host = (IP
>address) *identified by /host/ and port /port/ pair,* even if the= remote
>host is known by another name, the client MUST wait u= ntil that connection
>has been established or for that connection to have failed. There MUST = be
>no more than one connection in a CONNECTING state. If multiple co= nnections *to
>the same IP address* are attempted simultaneously, the client MUST
>serialize them so that there is no more than one conn= ection at a time
>running through the following steps.
>
>The first sentence seems to imply that connections should be throttled = on
>the basis of (host, port) pairs, ie. that ws://192.0.2.1:80/ and ws://
>192.0.2.1:81/ sh= ould be considered independent for the purposes of
>connection throttling. The last sentence seems to imply that connection= s
>should be throttled on the basis of IP address only, so connections ws:= //
>192.0.2.1:80/ an= d ws://192.0.2.1:81/= should be placed in the same bucket
>for throttling purposes.

It seems pretty clear to me that the more conservative interpretation= is
the intended one. One reason is that there would otherwise be no limit
on the simultaneous attempts to connect with a single IP address using
different port numbers. It seems "identified by /host/ and port /port/=
pair" can safely be removed without replacement through errata.
--
Bj=F6rn H=F6hrmann =B7 mailto:bjoern= @hoehrmann.de =B7 http://bjoern.hoehrmann.de
Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld.de
25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev.de/

--bcaec54a38006d499304d4527a03-- From wwwrun@rfc-editor.org Thu Jan 31 23:39:41 2013 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 1A9FF21F87D9 for ; Thu, 31 Jan 2013 23:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.382 X-Spam-Level: X-Spam-Status: No, score=-102.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLmyC4J+6b64 for ; Thu, 31 Jan 2013 23:39:40 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 927A121F87D7 for ; Thu, 31 Jan 2013 23:39:40 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 78956B1E003; Thu, 31 Jan 2013 23:38:46 -0800 (PST) To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, presnick@qti.qualcomm.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com From: RFC Errata System Message-Id: <20130201073846.78956B1E003@rfc-editor.org> Date: Thu, 31 Jan 2013 23:38:46 -0800 (PST) Cc: hybi@ietf.org, rfc-editor@rfc-editor.org Subject: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 07:39:41 -0000 The following errata report has been submitted for RFC6455, "The WebSocket Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6455&eid=3473 -------------------------------------- Type: Editorial Reported by: Adam Rice Section: 4.1 Original Text ------------- 2. If the client already has a WebSocket connection to the remote host (IP address) identified by /host/ and port /port/ pair, even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same IP address are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps. Corrected Text -------------- 2. If the client already has a WebSocket connection to the remote host (IP address) identified by /host/ and port /port/ pair, even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same /host/ and /port/ pair are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps. Notes ----- The original wording makes it ambiguous whether distinct ports on the same host are considered distinct for throttling purposes. The first sentence implies that the throttling should be applied per (host,port) pair, whereas the final sentence implies it is only based on IP address. Implementations of both interpretations appear to exist in the wild. I propose disambiguating in favour of the (host,port) interpretation, because the host-only interpretation allows for a potential denial-of-service attack targeted against hosts which drop packets to unused ports. For example, an attacker from a different origin can create several hundred WebSockets to "wss://google.com:81/". Each one will attempt to connect in serial, and take tens of seconds to time out. If the user then attempts to use an application which legitimately uses a WebSocket to "wss://google.com:443/", then due to the throttling to google.com it will not be able to connect until all of the attacker's connections have timed out. The user will perceive that the legitimate application is malfunctioning, since there is no visible sign that they are being attacked. From the server end, the attack is only apparent in the firewall logs. The actual rate of SYN packets dropped will be small and unlikely to trigger an alert. On the other hand, with the (host,port) interpretation, connections to google.com:81 do not block connections to google.com:443, and this attack is completely ineffective. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) -------------------------------------- Title : The WebSocket Protocol Publication Date : December 2011 Author(s) : I. Fette, A. Melnikov Category : PROPOSED STANDARD Source : BiDirectional or Server-Initiated HTTP Area : Applications Stream : IETF Verifying Party : IESG