From tyoshino@google.com Mon Apr 1 06:12: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 8DFBD21F9730 for ; Mon, 1 Apr 2013 06:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PxqKfZweHMKb for ; Mon, 1 Apr 2013 06:12:16 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 34B5621E812F for ; Mon, 1 Apr 2013 06:12:03 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm11so2138990wib.5 for ; Mon, 01 Apr 2013 06:12:02 -0700 (PDT) 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:cc:content-type; bh=+pycqs8VZFqKebV+7gOIhufdWs6OWe/sonM4S220HeQ=; b=W/BiG5BfeGGZWmdHa8HsETyCFLOUHwfyfh10AaHMYSLAuAgWq+XQgXypFqiNzi9P9w RHH3egUNa5HhtsLG7xebbMQ//3aV4R8ouMLjKfiyNHiwmxOMJTJE4NEZsblQ1KicWCJd /TyxN2sjnhn3atW1yVu+nsYymp633/uqPvmaJM/VOu4x8CkoFJ/D5MBMsIyXdQKpJWjQ W/D7PWqL+TVsH11X5fAV6krpo3KfBB0FSpVOdWgB1KliLwlzUP9NVaPfqvgSuifdfS6k IvFhYNN62Kr64bI/IushLlTQ7nTs/a+lxzjFupIWtQvmfDUvMQP0h/jRwqTmy43VMnAE nECw== 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:cc:content-type:x-gm-message-state; bh=+pycqs8VZFqKebV+7gOIhufdWs6OWe/sonM4S220HeQ=; b=ZaRba7JZRNNCMPthgA0vopXsmyNid9pX3AaDjfKAVMP327uUo/d9EYB0E/EBZhwfRE 8+2oKHr4BPNsWhrggxwkFFoyV6rGjhOK8CT9oGNi9AblH8yIrHplp97HnbYciqVz50NF I+pY91WPP5aezia4ku58HA/3aY5zhqbzWwZRlnQaEcZIq+7TTw3amzmJ550dRxad91r8 uXfq3ZB9DinN0leuXLwF4v5rxKHK3euZnqftsDsJQ7ARenwBSQf2FrXth5lkWCrTPk9U Ck0YM0swM8ae7v1qlYldRnoRuCYNgc3aU2JRO/tHuTMiJLXECaCyodjVT35KaB3jZEGW T73w== X-Received: by 10.180.185.176 with SMTP id fd16mr9794826wic.31.1364821922244; Mon, 01 Apr 2013 06:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.243.3 with HTTP; Mon, 1 Apr 2013 06:11:42 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130322234602.0bf66450@resistor.net> References: <6.2.5.6.2.20130223175715.094d8508@elandnews.com> <6.2.5.6.2.20130322234602.0bf66450@resistor.net> From: Takeshi Yoshino Date: Mon, 1 Apr 2013 22:11:42 +0900 Message-ID: To: SM Content-Type: multipart/alternative; boundary=001a11c26336db7df704d94c5d8d X-Gm-Message-State: ALoCoQmfeo1aiz1ZwhsIJ+j2qy4IXSJUKj9fgpo3iN+CeapZf+Xob/K6BEX9Z9w3KdEHyIk/lWYkIMTWC5sFYZR5DJn8b4fe00XDYTY2Fhi7ymOTeg29vD/sEpXS2ZnjEgOHYtnjV72foGR5PFKZ7vUflTn+vVd9GrEEb5oyCmlB1AWhfTpzOuiuAFBJW0olI/G14134Zt1T Cc: "hybi@ietf.org" Subject: Re: [hybi] Comments on draft-ietf-hybi-permessage-compression-05 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, 01 Apr 2013 13:12:17 -0000 --001a11c26336db7df704d94c5d8d Content-Type: text/plain; charset=ISO-8859-1 Hi, On Sat, Mar 23, 2013 at 4:23 PM, SM wrote: > Hi Takeshi, > >> >> Sorry I couldn't get what you mean. >> > > What I meant was not to get into all the details of how to implement. It > is better in my opinion to explain what is being sent. Please let me know > if I did not explain it well. > > OK. But since the algorithm itself is defined by showing the steps, some of examples demonstrating it would have to be step by step example and I think are still useful. I think now the examples of permessage-deflate except the first one are not getting into implementation details: - endpoint does X - the result will be frame Y, frame ... - Z in Y means blah blah, W in Y means blah blah > Which part of the sentence is bad for the RFC Editor? >> > > I don't really know how to explain this. I would say that the sentence > looks more like pseudo code instead of one written in English. I tried to eliminate such expressions, again from the examples section. > Could you please point a sentence which is considered to be making >> liberal use of the key worlds? I tried to remove inappropriate use but >> couldn't find so many. >> > > I'll comment using an example from draft-ietf-hybi-permessage-** > compression-07: > > 'A server MAY attach the "c2s_no_context_takeover" extension parameter > to disallow the client to use the LZ77 sliding window used to build > frames for the last message the client sent to build frames for the > next message to send. The "c2s_no_context_takeover" extension > parameter has no value. Clients SHOULD be able to accept the > "c2s_no_context_takeover" parameter. A client that received this > parameter MUST reset its LZ77 sliding window for sending to empty for > each message.' > > There are three RFC 2119 key words in the above, i.e. MAY, SHOULD, MUST. > The client "SHOULD be able to accept" is an assumption. Hmm. I meant it's recommended to make clients be able to accept the c2s_no_context_takeover. I'll changed it to use RECOMMENDED and separated them from requirement paragraph. > The "MUST reset" is what the client must do. Yes > I could write it in terms of what "c2s_no_context_takeover" means and > what the client must do when it receives the parameter. OK Thanks --001a11c26336db7df704d94c5d8d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Sat, Mar 23, 2013 at 4:23 PM, SM <sm@resistor.net> wrote:
Hi Takeshi,

Sorry I couldn't get what you mean.

What I meant was not to get into all the details of how to implement. =A0It= is better in my opinion to explain what is being sent. =A0Please let me kn= ow if I did not explain it well.


OK. But since the algorithm itself is defined by showi= ng the steps, some of examples demonstrating it would have to be step by st= ep example and I think are still useful.

I think now the examples of permessage-deflate except the first one are not= getting into implementation details:
- endpoint does X
- the result will be frame Y, frame ...
- Z in= Y means blah blah, W in Y means blah blah
=A0
Which part of the sentence is bad for the RFC Editor?

I don't really know how to explain this. =A0I would say that the senten= ce looks more like pseudo code instead of one written in English.

I tried to eliminate such expressions, again f= rom the examples section.
=A0
Could you please point a sentence which is considered to be making liberal = use of the key worlds? I tried to remove inappropriate use but couldn't= find so many.

I'll comment using an example from draft-ietf-hybi-permessage-co= mpression-07:

=A0 'A server MAY attach the "c2s_no_context_takeover" extens= ion parameter
=A0 =A0to disallow the client to use the LZ77 sliding window used to build<= br> =A0 =A0frames for the last message the client sent to build frames for the<= br> =A0 =A0next message to send. =A0The "c2s_no_context_takeover" ext= ension
=A0 =A0parameter has no value. =A0Clients SHOULD be able to accept the
=A0 =A0"c2s_no_context_takeover" parameter. =A0A client that rece= ived this
=A0 =A0parameter MUST reset its LZ77 sliding window for sending to empty fo= r
=A0 =A0each message.'

There are three RFC 2119 key words in the above, i.e. MAY, SHOULD, MUST. = =A0The client "SHOULD be able to accept" is an assumption.

Hmm. I meant it's recommended to make c= lients be able to accept the c2s_no_context_takeover.

I'll changed it to use RECOMMENDED and = separated them from requirement paragraph.
=A0
=A0The "MUST reset" is what the client must do.

Yes
=A0
=A0I could write it in terms of what "c2s_no_context_takeover" m= eans and what the client must do when it receives the parameter.

OK

Thanks
--001a11c26336db7df704d94c5d8d-- From tyoshino@google.com Mon Apr 1 07:41:28 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 83F7511E80A6 for ; Mon, 1 Apr 2013 07:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.677 X-Spam-Level: X-Spam-Status: No, score=-101.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuVKr7ImnayS for ; Mon, 1 Apr 2013 07:41:27 -0700 (PDT) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 31BA311E80A3 for ; Mon, 1 Apr 2013 07:41:26 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id r5so1753294wey.39 for ; Mon, 01 Apr 2013 07:41:26 -0700 (PDT) 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:cc:content-type; bh=mm6bBzPF6VbAHb8867rt2LsPuGfPAeI+c4w5HYVM2Lo=; b=fVysD3Fwwi2dARlE+XUxm/M40CEOGl5Q7S3Q2k7EOnL+xzlw9LOlgqrarkI+DUB4gi 22IPt3f+X47g44qq+TOr8aKAfSJRBwWSli1qxFTPTyssMZKbcnVuOz6oKNTzr8AX2Jib OxttxHrqrkuQRjRxmwS6y8R1lc+LSFD+V+nEVD42Bp7aaMrAZ36nL9jvUbWHAMYPRnL8 Q/7X7taZ4HqeJqPfypIsgTvLjWwgR+cG1DBapzHbNb1rfYLpYXDnDLqmAWBIzL9K7VtZ MjyyR107CIxHMcxORilP0DBTCta9gRuDif/cZvPKaeLoV9IzxoHbjItF8yRQBZQsmyLW Sr7w== 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:cc:content-type:x-gm-message-state; bh=mm6bBzPF6VbAHb8867rt2LsPuGfPAeI+c4w5HYVM2Lo=; b=CCrlmy3qCrruLFCHGLRkH5Z2J1dqXJLqgCG0IpEMn437ATq0cSHhlgHlHTZ0a86jQn Fms0h9VG2RWygDM5zMi+dEVnd3dcsXrY3QX696d1N7TWDXHlzsX13QUEWqEVCoTrqyor /KtS9UfxXo20VO0EDlMqFaC2W4bxWcJ/Jcsq/ZCmTDIvKYoFdWgwvN+qfU/Kf4T2neWv oKPVcvmWOl6AoHo/UAQBhfpgI4uLHFz+tBbM3pRMxUrRoMXqX2GHeA6zSsIbT2zDRSsk 0bAdBGNFkkkrMzajG6KCzRduV0TBPVk0ijBKPYInikhUJfGOtN7rr8Q5QLa15sfHbBMI v1Pg== X-Received: by 10.194.171.74 with SMTP id as10mr16031164wjc.0.1364827285990; Mon, 01 Apr 2013 07:41:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.243.3 with HTTP; Mon, 1 Apr 2013 07:41:05 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 1 Apr 2013 23:41:05 +0900 Message-ID: To: Dario Crivelli Content-Type: multipart/alternative; boundary=089e013c6c0e8fcc6004d94d9da6 X-Gm-Message-State: ALoCoQmQ/IfLM9q8QUi8ZJ1974p4Mx6oa7WTveQYkq2ZHJt9cdCDeoNRJhcXyT3Dro+X/gRkxykfLSvW4BP3jRsRd4bkD3u14pyWT86nB8ED6DlzgnWWeoR4Adfz8PrN6hPsBi8zi6oXjVNDi9z8V0Jux21gS/I6eIa7JQ72+cFkxN/ASy10TgGq2NdZjFQgJBoyhaIei9Av Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-07.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:41:28 -0000 --089e013c6c0e8fcc6004d94d9da6 Content-Type: text/plain; charset=ISO-8859-1 Hi Dario, Thanks for review. On Fri, Mar 29, 2013 at 1:41 AM, Dario Crivelli < dario.crivelli@lightstreamer.com> wrote: > We know from RFC4655 (and also from the permessage-deflate extension case) > that when a server accepts a PMCE offer, it can use, in the response, > parameters different from those used in the offer; > as a consequence, the extension specification should determine when the > response parameters are legal with respect to the offer. > In the description of the general negotiation mechanism, in paragraph 4, > as far as I can see, this is not restated explicitly. > I suggest restating that, though redundantly, because the description of > the offering/acceptance mechanism may be misleading. > In fact, the mechanism allows the client to include multiple offers of the > same PMCE with different parameters; > so, this may deceive one into thinking that the acceptance only consists > in the server choosing one of the offerings as is, with no further freedom > to use different parameters in the response. > Added a sentence "The element doesn't need to exactly the same as one of the received offers." and one example. > In paragraph 6.2 the following form is used several times: > "If a server accepts an offer with ..." > I think that the concept of "accepting an offer" should only pertain to > paragraph 6.1. > In paragraph 6.2 we are referring to the configuration parameters already > agreed-upon. > I see that in paragraph 4 there is a mention to > "the configuration parameters of the PMCE to use in detail" > which would be a better reference point, although it is not formally > defined. > Do you think that introducing a concept similar to the _Extensions In Use_ > of RFC6455 would be worthwhile? > > I'll introduce a term "agreed parameter" and use it there. > > I'm still concerned about how multiple extensions can coexist and how this > specification can interoperate with specifications of other extensions. > With reference to paragraph 5.1, as far as this specification is meant as > a specialization of RFC6455, it is clear how the indicated steps should > replace the corresponding base steps in RFC6455 > (even though RFC6455 was not expressed in terms of steps). > However, the specification in paragraph 5.1 replaces the base steps from > the "payload data portion of the original message" to the frames being sent. > It seems to me that this formulation excludes in advance the cooperation > with any other extension, otherwise conflicts in the two specifications > would arise and it might not be obvious how the two specifications should > merge. > > Changed the text considering the case there're other extensions next to the PMCE. Maybe still need more work but for now. > On the other hand, I think it is obvious to all of us that a PMCE should > only operate on the message payload > Yes. Added some text to state that. > and should not interfere with any extension to be applied subsequently > (operating either on the payload or on the frames), provided that it > doesn't conflict on the use of the RSV1 bit. > Yes. Except for fragmentation change. > I'm not sure if the current specification conveys this idea. > > Hmm, ... what kind of thing do you think we should say? > By the way, in paragraph 4 it is said that an extension can be "applied to > output of" another extension; > however, in RFC6455 I can only find the concept of an "order of > operations" (in 9.1), which seems to me a broader one. > > Yes. Extension specification in RFC 6455 is very brief. Shall we redefine it well here? Hmm > > Regards > Dario Crivelli > > > > > >> Message: 2 >> Date: Tue, 19 Mar 2013 17:36:48 +0900 >> From: Takeshi Yoshino >> To: "hybi@ietf.org" >> Subject: Re: [hybi] I-D Action: >> draft-ietf-hybi-permessage-compression-07.txt >> Message-ID: >> < >> CAH9hSJZCFZpvQPjVsRXDGeLD8BNSttoEHVU6PNupjv4F548a0A@mail.gmail.com> >> Content-Type: text/plain; charset="iso-8859-1" >> >> Reorganization, rephrasing, grammar correction. >> >> I'm happy if someone could take a look. >> >> Takeshi >> >> --089e013c6c0e8fcc6004d94d9da6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Dario,

Thanks for review.

On Fri, Mar 29, 2013 at 1:41 AM, Dario Criv= elli <dario.crivelli@lightstreamer.com> wrote= :
We know from RFC4655 (and also from the permessa= ge-deflate extension case) that when a server accepts a PMCE offer, it can = use, in the response, parameters different from those used in the offer;
as a consequence, the extension specification should determine when th= e response parameters are legal with respect to the offer.
In the= description of the general negotiation mechanism, in paragraph 4, as far a= s I can see, this is not restated explicitly.
I suggest restating that, though redundantly, because the description = of the offering/acceptance mechanism may be misleading.
In fact, = the mechanism allows the client to include multiple offers of the same PMCE= with different parameters;
so, this may deceive one into thinking that the acceptance only consis= ts in the server choosing one of the offerings as is, with no further freed= om to use different parameters in the response.

Added a sentence "The element doesn't ne= ed to exactly the same as one of the received offers." and one example= .
=A0
In paragraph 6.2 the following form is used several times:
"If a server accepts an offer w= ith ..."
I think that the concept of "accepting an offe= r" should only pertain to paragraph 6.1.
In paragraph 6.2 we are referring to the configuration parameters alre= ady agreed-upon.
I see that in paragraph 4 there is a mention to<= /div>
"the configurat= ion parameters of the PMCE to use in detail"
which would be a better reference point, although it is not formally d= efined.
Do you think that introducing a concept similar to the _E= xtensions In Use_ of RFC6455 would be worthwhile?


I'll introduce a term &quo= t;agreed parameter" and use it there.
=A0

I'm still concerned about how multiple extensions can co= exist and how this specification can interoperate with specifications of ot= her extensions.
With reference to paragraph 5.1, as far as this s= pecification is meant as a specialization of RFC6455, it is clear how the i= ndicated steps should replace the corresponding base steps in RFC6455
(even though RFC6455 was not expressed in terms of steps).
H= owever, the specification in paragraph 5.1 replaces the base steps from the= "payload data portion of the original message" to the frames bei= ng sent.
It seems to me that this formulation excludes in advance the cooperati= on with any other extension, otherwise conflicts in the two specifications = would arise and it might not be obvious how the two specifications should m= erge.


Changed the tex= t considering the case there're other extensions next to the PMCE.

Maybe still need more work but for now.
=A0
On the other hand, I th= ink it is obvious to all of us that a PMCE should only operate on the messa= ge payload

Yes. Added some text to state = that.
=A0
and should not interfere with any extension to be applied subsequ= ently (operating either on the payload or on the frames), provided that it = doesn't conflict on the use of the RSV1 bit.

Yes. Except for fragmentation change.
= =A0
I'm not sure if the current specification conveys this idea.
=


Hmm, ... what k= ind of thing do you think we should say?
=A0
By the way, in paragraph 4 it is said that an extensio= n can be "applied to output of" another extension;
however, in RFC6455 I can only find the concept of an "order of operat= ions" (in 9.1), which seems to me a broader one.


Yes. Extension = specification in RFC 6455 is very brief. Shall we redefine it well here? Hm= m
=A0

Regards
Dario Crivelli
<= /div>





Message: 2
Date: Tue, 19 Mar 2013 17:36:48 +0900
From: Takeshi Yoshino <tyoshino@google.com>
To: "hybi@ietf.org<= /a>" <hybi@ietf.= org>
Subject: Re: [hybi] I-D Action:
=A0 =A0 =A0 =A0 draft-ietf-hybi-permessage-compression-07.txt
Message-ID:
=A0 =A0 =A0 =A0 <CAH9hSJZCFZpvQPjVsRXDGeLD8= BNSttoEHVU6PNupjv4F548a0A@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Reorganization, rephrasing, grammar correction.

I'm happy if someone could take a look.

Takeshi


--089e013c6c0e8fcc6004d94d9da6-- From internet-drafts@ietf.org Mon Apr 1 07:44:39 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 E291311E80AE; Mon, 1 Apr 2013 07:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jc9YaqL7Oo1; Mon, 1 Apr 2013 07:44:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2161C11E80BA; Mon, 1 Apr 2013 07:44:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130401144439.25672.99712.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 07:44:39 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-08.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 14:44:40 -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 : Compression Extensions for WebSocket Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-08.txt Pages : 23 Date : 2013-04-01 Abstract: This document specifies a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of non-control WebSocket messages on per-message basis using parameters negotiated during the opening handshake. This framework provides a general method to apply a compression algorithm to the contents of WebSocket messages. For each compression algorithm, an extension is defined by specifying parameter negotiation and compression algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. 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-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Mon Apr 1 07:48: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 C374321F8BEA for ; Mon, 1 Apr 2013 07:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.827 X-Spam-Level: X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H94Bb1zKr9HO for ; Mon, 1 Apr 2013 07:48:27 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) by ietfa.amsl.com (Postfix) with ESMTP id C8E9421F88E3 for ; Mon, 1 Apr 2013 07:48:26 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id hi18so1602240wib.9 for ; Mon, 01 Apr 2013 07:48:26 -0700 (PDT) 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=WJmYL/M0YSmkqwwZ7FoXKN7IQBgYGVzI6v3eiv7fTW0=; b=YHF4wNxcgvdCPLd5lEKFAlRuCTH/qSUMaJswGL6TrQzbwz5sDcYtrVTi8OvfMHfANh TuiSNzwnM3nP7NMh3TW4qgCO717p1/ic9Byw9buu0zVjJyNVqZeWMIAY3r75BA3gjcoD 6gc+H/nCHAE6vtqepAmpNnPIfCVAUMM1RFXIQNfxgK+zjF96CFApdXTDVAMJ3Jg5OEOR ejBUqvd335rnbY5tx7eevCnQmm6LzbncGjQppmMeenIwG0+wLjs7CFtLYqMyJYSVZQxB NmBbrz4t+IP1rX42wg5jzpKBYAVLgClx5MNoWI7QBhca5g423tvN6fORCKntL54byUc5 hVkA== 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=WJmYL/M0YSmkqwwZ7FoXKN7IQBgYGVzI6v3eiv7fTW0=; b=kcUuOvVqzCkFQzJsLHNQNETBcVLCE0n+DRXNeDTqGNO7UUndWmVyd0U/aehgyYz/w7 KWDBPxHBEqipb8BzRzvgVd0rdGlzwkE88GOMU257HWdkLFwBbrm5/5XGhSEXRpylEYRT qM3zEAQcGr2CT+yXebMzlYj86r3IqzJscisz7TI2VADBKwQ+47/mnyKYi6Mv7d4eZike 5RxQISb04/ejYA9FgKCKgPPE91BAwfL52svBs62kOZ4dCvnJgKA+L3Ri+Ki/2zTp/Rg2 Ifc+hZg2feP/C9BwVRVgbwDZTa0bAiQR36UjLwdsaK+oHQ2UWyaQX/6owhBJ+q9RipoF F/5A== X-Received: by 10.180.184.67 with SMTP id es3mr10469518wic.0.1364827705948; Mon, 01 Apr 2013 07:48:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.243.3 with HTTP; Mon, 1 Apr 2013 07:48:05 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Mon, 1 Apr 2013 23:48:05 +0900 Message-ID: To: Joakim Erdfelt , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2299097d36d04d94db6e9 X-Gm-Message-State: ALoCoQn2whM7t+N8sJUb441WijcHjYMwVKwozX+0UEf5AECckPTcZuBqTJXPD2UuRZ9TVOg4lawwmF3HC2t5zalqBTlPAux6ur/Y3ZYsqgmDH1NEBpVGFkaZUvWoos0C0ph29yZU8uDLYf3sxl9PlZJzaovDV8xGZmbahi/iZZtgPnt7yeXVp0q0/pWUleHMwPG7GTuW27iz Subject: Re: [hybi] Reference Implementation of draft-ietf-hybi-permessage-compression-07 ? 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, 01 Apr 2013 14:48:27 -0000 --001a11c2299097d36d04d94db6e9 Content-Type: text/plain; charset=ISO-8859-1 We are going to implement it on pywebsocket soon, and then Chrome. I'll tell you here when they're ready. Takeshi On Fri, Mar 29, 2013 at 2:18 AM, Joakim Erdfelt wrote: > Is there a reference implementation of this draft of > permessage-compression? > I'd like to figure out what is wrong with our use of the Java built-in > deflate libraries (as we could never quite get x-deflate-frame to work with > chrome) > > -- > Joakim Erdfelt > webtide.com > Developer advice, services and support > from the Jetty & CometD experts > eclipse.org/jetty - cometd.org > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --001a11c2299097d36d04d94db6e9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We are going to implement it on pywebsocket soon, and then= Chrome. I'll tell you here when they're ready.

Takeshi


On Fri, Mar 29, 2013 at 2:18 AM, Joakim = Erdfelt <joakim@intalio.com> wrote:
Is there a reference implementation of this draft of permessage-compre= ssion?
I'd like to figure out what is wrong with our use of t= he Java built-in deflate libraries (as we could never quite get x-deflate-f= rame to work with chrome)

--
Joakim Erdfelt <joakim@intalio.com>
webtide.com
Developer advice, services and support
from the Jetty= & CometD experts

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


--001a11c2299097d36d04d94db6e9-- From dario.crivelli@lightstreamer.com Thu Apr 4 08:56:38 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 400E121F93AA for ; Thu, 4 Apr 2013 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.483 X-Spam-Level: * X-Spam-Status: No, score=1.483 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1EpXBLL4e4bP for ; Thu, 4 Apr 2013 08:56:37 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 16C0921F93C5 for ; Thu, 4 Apr 2013 08:56:36 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id o45so2145558wer.36 for ; Thu, 04 Apr 2013 08:56:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightstreamer.com; s=google; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type; bh=zUM5JeUVh5AiPPorbD8QtKp9Dw1uzHcKSj7xPDYSawY=; b=Efcrb9G0FA5Kn8zDjp+5Kk5mb5Ytu8hTF8p/mJYB6LEubtb4OI9qCvE5O4nV6PdzBR mWDvSN+dxIjZiV/aSBuuHbS5f03HA9sMHxQjItjPsXSK1MY6ikAV4eEgjo0ZBcmoE9vw WRTDVrMOIkPjQU6R5fDXcC1i3+/ZDP9ReQcAg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=zUM5JeUVh5AiPPorbD8QtKp9Dw1uzHcKSj7xPDYSawY=; b=dDaCNvPMc0T93h3DUV/SzQG2OmHWMNIP+VWqoU5b0g+PS85jNwyvHwZFrgmx1zrK/i khV7VUY1i66IrhZVLGV/56ARByZB50YLNGIFdJoOZKb52GGYvyRFQq4Y6Pr/CpOeLEzM Nk3yZKwe9nZVuw5EL8EL4/oHATfvuI8yDgrnX3TqUHRL3ThLZBXUxDI6F2VeJDPigHJZ VF57dyZeEd6+fQ3aBZ8T5FVGoWh8x7dDmEMtIYUusxhZau5sJB2/1quB6AU9DiY48NeE 2MWz5cEX2qOowZ0HVIRJHU7a1ST/oiswfrcU05W44E/zCb7uKtlTd+Du8G229m2UzNNz sxYQ== X-Received: by 10.180.188.3 with SMTP id fw3mr10149858wic.33.1365090995452; Thu, 04 Apr 2013 08:56:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.104.199 with HTTP; Thu, 4 Apr 2013 08:56:14 -0700 (PDT) X-Originating-IP: [2.238.52.66] In-Reply-To: References: From: Dario Crivelli Date: Thu, 4 Apr 2013 17:56:14 +0200 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=001a11c37cdcded6ff04d98b038c X-Gm-Message-State: ALoCoQk6HK1v2iGIbW7jj0Ybu6vmBJNowFzV2Wp3IYsO1CZTQMjRoBrFapfDJeISJihL/gDXbH0U Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-07.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, 04 Apr 2013 15:56:38 -0000 --001a11c37cdcded6ff04d98b038c Content-Type: text/plain; charset=ISO-8859-1 Hi Takeshi, >From my viewpoint, the notes added in draft 08 make things clearer. I will try to expand on some points of the previous email that don't have a clear way out. Then I will add other notes on the new draft 08 in the proper thread. >> On the other hand, I think it is obvious to all of us that a PMCE should >> only operate on the message payload >> > > Yes. Added some text to state that. > > >> and should not interfere with any extension to be applied subsequently >> (operating either on the payload or on the frames), provided that it >> doesn't conflict on the use of the RSV1 bit. >> > > Yes. Except for fragmentation change. > Consider that conflicts due to fragmentation only arise with extensions that are supposed to be applied before the PMCE. As the PMCE only operates on the payload, the incompatibility with any previous extension operating on the frames, in my opinion, should be in some way implicit (see below). > > >> >> I'm not sure if the current specification conveys this idea. >> >> > Hmm, ... what kind of thing do you think we should say? > I'm not able to propose any solution, because there is nothing to lean upon. However, I think that your reformulation of 5.1 and 5.2 in draft 08, where you explicitly refer to extension chaining, is more prone to mutual compatibility. The job would be easier if RFC 6455 had put some more restrictions. For instance, a statement that the encoding of a message is a two-phase process, where: - the first phase produces the message payload and its properties (in terms of opcode and reserved bits, due to be set in the first frame); - the second phase produces the frames, with any additional frame-level opcodes and reserved bits (along with possible extension data and custom control frames). This would provide "inputs" and "outputs" for the extensions to operate on, and also basic constraints on the chaining of extensions. Do you think that imposing a similar restriction would cause possible useful extensions to be ruled out? By the way, I admit that I haven't managed to read the sibling proposal for the Multiplexing extension yet, so maybe this restriction is already unsuitable for that one. > > >> By the way, in paragraph 4 it is said that an extension can be "applied >> to output of" another extension; >> however, in RFC6455 I can only find the concept of an "order of >> operations" (in 9.1), which seems to me a broader one. >> >> > Yes. Extension specification in RFC 6455 is very brief. Shall we redefine > it well here? Hmm > Do you think that expanding RFC 6455, in order to clarify how the extension should be allowed to operate, would still be possible? In fact, anything stated regarding extensions should have no impact on the protocol itself; moreover, since no extension has been registered yet, making changes on the matter now would pose no cross-compatibility issues. But I'm not familiar with the specification process and I acknowledge that this may be unfeasible. > >> >> Regards >> Dario Crivelli >> >> >> >> >> >>> Message: 2 >>> Date: Tue, 19 Mar 2013 17:36:48 +0900 >>> From: Takeshi Yoshino >>> To: "hybi@ietf.org" >>> Subject: Re: [hybi] I-D Action: >>> draft-ietf-hybi-permessage-compression-07.txt >>> Message-ID: >>> < >>> CAH9hSJZCFZpvQPjVsRXDGeLD8BNSttoEHVU6PNupjv4F548a0A@mail.gmail.com> >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> Reorganization, rephrasing, grammar correction. >>> >>> I'm happy if someone could take a look. >>> >>> Takeshi >>> >>> > --001a11c37cdcded6ff04d98b038c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Takeshi,

From my viewpoint, the notes adde= d in draft 08 make things clearer.
I will try to expand on some p= oints of the previous email that don't have a clear way out.
Then I will add other notes on the new draft 08 in the proper thread.
=



On the other hand, I think it is obviou= s to all of us that a PMCE should only operate on the message payload

Yes. Added some text to state that.<= /div>
=A0
and should not interfere with any extension to be applied subsequ= ently (operating either on the payload or on the frames), provided that it = doesn't conflict on the use of the RSV1 bit.

Yes. Except for fragmentation change.
=

Consider that conflicts due to fragm= entation only arise with extensions that are supposed to be applied before = the PMCE.
As the PMCE only operates on the payload, the incompatibility with any= previous extension operating on the frames, in my opinion, should be in so= me way implicit (see below).
=A0
=A0

I'm not sure if the current specification conveys t= his idea.


Hmm, ... wha= t kind of thing do you think we should say?

I'm not able to propose any solution, because there= is nothing to lean upon.
However, I think that your reformulatio= n of 5.1 and 5.2 in draft 08, where you explicitly refer to extension chain= ing, is more prone to mutual compatibility.

The job would be easier if RFC 6455 had put some more r= estrictions.
For instance, a statement that the encoding of a mes= sage is a two-phase process, where:
- the first phase produces the message payload and its properties (in = terms of opcode and reserved bits, due to be set in the first frame);
=
- the second phase produces the frames, with any additional frame-leve= l opcodes and reserved bits (along with possible extension data and custom = control frames).
This would provide "inputs" and "outputs" for the = extensions to operate on, and also basic constraints on the chaining of ext= ensions.

Do you think that imposing a similar rest= riction would cause possible useful extensions to be ruled out?
By the way, I admit that I haven't managed to read the sibling pro= posal for the Multiplexing extension yet, so maybe this restriction is alre= ady unsuitable for that one.
=A0
=A0
By the way, in paragraph 4 it is said that an extensio= n can be "applied to output of" another extension;
however, in RFC6455 I can only find the concept of an "order of operat= ions" (in 9.1), which seems to me a broader one.


Yes. Extension specif= ication in RFC 6455 is very brief. Shall we redefine it well here? Hmm

Do you think that expan= ding RFC 6455, in order to clarify how the extension should be allowed to o= perate, would still be possible?
In fact, anything stated regarding extensions should have no impact on= the protocol itself;
moreover, since no extension has been regis= tered yet, making changes on the matter now would pose no cross-compatibili= ty issues.
But I'm not familiar with the specification process and I acknowle= dge that this may be unfeasible.


=A0

Regards
Dario Crivelli
<= /div>





Message: 2
Date: Tue, 19 Mar 2013 17:36:48 +0900
From: Takeshi Yoshino <tyoshino@google.com>
To: "hybi@ietf.org<= /a>" <hybi@ietf.= org>
Subject: Re: [hybi] I-D Action:
=A0 =A0 =A0 =A0 draft-ietf-hybi-permessage-compression-07.txt
Message-ID:
=A0 =A0 =A0 =A0 <CAH9hSJZCFZpvQPjVsRXDGeLD8= BNSttoEHVU6PNupjv4F548a0A@mail.gmail.com>
Content-Type: text/plain; charset=3D"iso-8859-1"

Reorganization, rephrasing, grammar correction.

I'm happy if someone could take a look.

Takeshi



--001a11c37cdcded6ff04d98b038c-- From dario.crivelli@lightstreamer.com Thu Apr 4 09:27:24 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 B3D4B21F8CBE for ; Thu, 4 Apr 2013 09:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.483 X-Spam-Level: * X-Spam-Status: No, score=1.483 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_ILLEGAL_IP=1.908, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlSUrqWqxdt5 for ; Thu, 4 Apr 2013 09:27:23 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 74C1E21F8BEA for ; Thu, 4 Apr 2013 09:27:23 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id ez12so4892382wid.12 for ; Thu, 04 Apr 2013 09:27:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lightstreamer.com; s=google; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:cc:content-type; bh=Xq/aBIhN8NjR67KwTH0xq3XwoRZWzAGjLz2vRpP3Rz8=; b=HMt8kVJKzONT/axzwLfnLMcLsX14VftCh8im5sWouWCniPY7lmiTqJ9bCbGQy1Sfd5 gPzxvOqyxP63kRxoZmLa47Ux46X4VDqjhkM0r/ipwgITRaJ6IrbH/aNd0gAVp/E4kVAN 9SbYlg2mTK6qBN05XAy0FYrA82CPyCITzB7p0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=Xq/aBIhN8NjR67KwTH0xq3XwoRZWzAGjLz2vRpP3Rz8=; b=EmJF6djdDCTusbca+vxr/XPFaoSPb9kUb47kc0ZVQUD7APqJ+YFgBQDjcH9u9gzv44 IvTCQaRuyTNSWeFH5Np6xWPMa53CdqyLM935qIsx7Vr5gN/GPPy3yNJL2Y5umTG6mi3e +06f+1H5pTYXijpQgdMt1ntGD9Hf1A83L+agykUU6fNr9n5z6WiuuHe7LawxXY2mgVZ5 1pLJFDZV2toFnzauq50D+112jBQnfH4io3v8ComH8hj6I+INJ3Czh4bsJocPE/ZY+5yO Wkp9j+IVGohUIQS+C1HoLFYasFdGPt/3DeBM4km9lD7d3To6vjHdr2KmEHs6DcF1hQbT RnXw== X-Received: by 10.180.97.233 with SMTP id ed9mr30438157wib.32.1365092842243; Thu, 04 Apr 2013 09:27:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.104.199 with HTTP; Thu, 4 Apr 2013 09:27:02 -0700 (PDT) X-Originating-IP: [2.238.52.66] From: Dario Crivelli Date: Thu, 4 Apr 2013 18:27:02 +0200 Message-ID: To: tyoshino@google.com Content-Type: multipart/alternative; boundary=f46d044306aaf29c6204d98b71a8 X-Gm-Message-State: ALoCoQlKGhdF3QZOnekJcjsIgX19H5Jiyz1L7M/q8mtoOFag7eBIYAxLenv2ltrIZXkDde6cpN6v Cc: hybi@ietf.org Subject: [hybi] Feedback on draft-ietf-hybi-permessage-compression-08.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, 04 Apr 2013 16:27:24 -0000 --f46d044306aaf29c6204d98b71a8 Content-Type: text/plain; charset=ISO-8859-1 Hi Takeshi, Please consider the following feedback. In your changes in 6.2.3.2, upon the second occurrence of If the "agreed parameters" you should have written: "don't contain". The general matter of extension chaining also affects paragraph 6.3: If I understand correctly, you say that an intermediary may add or remove a DEFLATE extension on the fly. Do you mean that this is allowed also when other extensions follow the DEFLATE? Even if this implies unwinding those extensions first, then applying them back? By the way, I see that the note on intermediaries is expressed in terms of PMCEs, but it lies within the DEFLATE chapter. Do you confirm that it is not there by mistake? At the beginning of chapter 5, you say that PMCEs operate only on non-control messages but RFC 6455 only introduces control frames, not control messages. I see "non-control messages" also written in RFC 6455 on page 34; I suppose that even that one is a case of improper denomination. After that, in draft 08 you have added: PMCEs operate only on the payload data portion and the "Per-message Compressed" bit But the last part seems to me too strong and in contrast with what you answered me a few weeks ago; I report the relevant part below: Q: For instance: can a future extension belonging to this set [i.e. the PMCEs] also reserve the RSV2 bit? A: It may though it needs to be discussed and registered with the registry. Regards Dario Crivelli > ------------------------------ > > Message: 3 > Date: Mon, 01 Apr 2013 07:44:39 -0700 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: hybi@ietf.org > Subject: [hybi] I-D Action: > draft-ietf-hybi-permessage-compression-08.txt > Message-ID: <20130401144439.25672.99712.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the BiDirectional or Server-Initiated HTTP > Working Group of the IETF. > > Title : Compression Extensions for WebSocket > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-08.txt > Pages : 23 > Date : 2013-04-01 > > Abstract: > This document specifies a framework for creating WebSocket extensions > that add compression functionality to the WebSocket Protocol. An > extension based on this framework compresses the payload data portion > of non-control WebSocket messages on per-message basis using > parameters negotiated during the opening handshake. This framework > provides a general method to apply a compression algorithm to the > contents of WebSocket messages. For each compression algorithm, an > extension is defined by specifying parameter negotiation and > compression algorithm in detail. This document also specifies one > specific compression extension using the DEFLATE algorithm. > > 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-08 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-08 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > --f46d044306aaf29c6204d98b71a8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Takeshi,

P= lease consider the following feedback.

In your cha= nges in 6.2.3.2, upon the second occurrence of
=A0 =A0 If the &qu= ot;agreed parameters"
you should have written: "don't contain".

=
The general matter of extension chaining also affects paragraph = 6.3:
If I understand correctly, you say that an intermediary may = add or remove a DEFLATE extension on the fly.
Do you mean that this is allowed also when other extensions follow the= DEFLATE?
Even if this implies unwinding those extensions first, = then applying them back?

By the way, I see that th= e note on intermediaries is expressed in terms of PMCEs, but it lies within= the DEFLATE chapter.
Do you confirm that it is not there by mistake?

At the beginning of chapter 5, you say that
=A0 =A0 PMCEs oper= ate only on non-control messages
but RFC 6455 only introduces con= trol frames, not control messages.
I see "non-control messages" also written in RFC 6455 on pag= e 34; I suppose that even that one is a case of improper denomination.

After that, in draft 08 you have added:
=A0 =A0 PMCEs operate only on the payload data portion and the "Per-me= ssage Compressed" bit
But the last part seems to me too stro= ng and in contrast with what you answered me a few weeks ago;
I r= eport the relevant part below:
Q: For instance: can a future extension belonging to this set [i.e. th= e PMCEs] also reserve the RSV2 bit?
A: It may though it needs to = be discussed and registered with the registry.

Regards
Dario Crivelli


<= div>
=A0
------------------------------

Message: 3
Date: Mon, 01 Apr 2013 07:44:39 -0700
From: internet-drafts@ietf.org<= /a>
To: i-d-announce@ietf.org
Cc: hybi@ietf.org
Subject: [hybi] I-D Action:
=A0 =A0 =A0 =A0 draft-ietf-hybi-permessage-compression-08.txt
Message-ID: <20130401144439.25672.99712.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"


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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Compression Extensions for WebS= ocket
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-permessage-compre= ssion-08.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 23
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-01

Abstract:
=A0 =A0This document specifies a framework for creating WebSocket extension= s
=A0 =A0that add compression functionality to the WebSocket Protocol. =A0An<= br> =A0 =A0extension based on this framework compresses the payload data portio= n
=A0 =A0of non-control WebSocket messages on per-message basis using
=A0 =A0parameters negotiated during the opening handshake. =A0This framewor= k
=A0 =A0provides a general method to apply a compression algorithm to the =A0 =A0contents of WebSocket messages. =A0For each compression algorithm, a= n
=A0 =A0extension is defined by specifying parameter negotiation and
=A0 =A0compression algorithm in detail. =A0This document also specifies one=
=A0 =A0specific compression extension using the DEFLATE algorithm.

=A0 =A0Please send feedback to the hybi@ie= tf.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-permessa= ge-compression-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-hybi-permessage-compression-08


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


--f46d044306aaf29c6204d98b71a8-- From sm@resistor.net Mon Apr 8 14:21:24 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 9393721F904B for ; Mon, 8 Apr 2013 14:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GX9TvcEAomo0 for ; Mon, 8 Apr 2013 14:21:23 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B5ED21F8FC7 for ; Mon, 8 Apr 2013 14:21:19 -0700 (PDT) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r38LLCeF029686; Mon, 8 Apr 2013 14:21:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1365456076; bh=9cDOt2ogu8lBMr+KLHuqNiDvQ/j1V0cz2MB7UxC2ZhU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=Q3NJA0NiL1CbX+qrLkykVwu8ECfQg2pL+2PTjnTBUZarv6Dk4+S9fQdENg0e/zPx0 O97rkD1zpAhTei9allyTn0gX54hzpg4D8Y0rru0vkPA6Wem8KOt2pHIMNLC4ho/yzy w8T4iJdYisdFcUj3NKJ8Vt3oZw38/khneSuE44Zw= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1365456076; i=@resistor.net; bh=9cDOt2ogu8lBMr+KLHuqNiDvQ/j1V0cz2MB7UxC2ZhU=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=cN6EFQxPNkFNPhBClzUtljK/XCOZdjx5hEPE7UHCjLDO28P2xMdE9Hbr/3dPMisj2 ui+vYr4V+/1TAQTD06ZxPDul3Pe/GKRL8DoD4BSEEVQSADDpj/sxXhrQdakIVXSBsl nJ0Jukcr2UkeakQ7aC6Jt2/IQ5HaS8K+bioAzleo= Message-Id: <6.2.5.6.2.20130408140630.0b6b4868@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 08 Apr 2013 14:11:44 -0700 To: Takeshi Yoshino From: SM In-Reply-To: References: <6.2.5.6.2.20130223175715.094d8508@elandnews.com> <6.2.5.6.2.20130322234602.0bf66450@resistor.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: hybi@ietf.org Subject: Re: [hybi] Comments on draft-ietf-hybi-permessage-compression-05 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, 08 Apr 2013 21:21:24 -0000 Hi Takeshi, At 06:11 01-04-2013, Takeshi Yoshino wrote: >I think now the examples of permessage-deflate except the first one >are not getting into implementation details: >- endpoint does X >- the result will be frame Y, frame ... >- Z in Y means blah blah, W in Y means blah blah Ok. >There are three RFC 2119 key words in the above, i.e. MAY, SHOULD, >MUST. The client "SHOULD be able to accept" is an assumption. > > >Hmm. I meant it's recommended to make clients be able to accept the >c2s_no_context_takeover. In that case it could be made straight-forward by, for example, saying: Clients SHOULD accept the "c2s_no_context_takeover" parameter. >I'll changed it to use RECOMMENDED and separated them from >requirement paragraph. You could use that instead. Regards, -sm From steven.atkinson@kaazing.com Fri Apr 12 11:30:37 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 5A67121F8D14 for ; Fri, 12 Apr 2013 11:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.425 X-Spam-Level: X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhzJQF7D-UIk for ; Fri, 12 Apr 2013 11:30:36 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 30A8821F8C3C for ; Fri, 12 Apr 2013 11:30:35 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id p13so2330050vbe.7 for ; Fri, 12 Apr 2013 11:30:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=2la0dYfFKlw1SKmckkoXxDrEeJdDNFNUjWgytWZlNnQ=; b=niskjOM43uPlLZmJeqfiEMfDRQ+66K1vUi0FnkPFC8YYTV37QnYGEdsV1pvdhxdMBt WOeH3+pTi3SSwkebZaE1BOFT0HLRq3mSsAhqTqv6n/P4HXCGDAnUUIEwcWgVBvZgDz9w VtNTMd2BmDxISQn+WswMcr3v0larycUuvr9Jwwr+kwKScLHMimvW+K5Y0EXQ5HeXuh66 7kg+wxE3aI+h+ZTLJo5qL4XVCgFbZzifgGml3ZW898r+uvEo/yPeYbDYGURPFVujiC10 IBDETnd6SeHOYWdLnN46Hmk2RkEnb6KSwyra6ElR+tdKCbvLp8wSWFKw9H4PiREV+5fI h69Q== MIME-Version: 1.0 X-Received: by 10.52.232.196 with SMTP id tq4mr7928995vdc.15.1365791435169; Fri, 12 Apr 2013 11:30:35 -0700 (PDT) Received: by 10.58.209.234 with HTTP; Fri, 12 Apr 2013 11:30:35 -0700 (PDT) X-Originating-IP: [64.71.23.251] In-Reply-To: References: <5105BF2D.50104@googlemail.com> Date: Fri, 12 Apr 2013 11:30:35 -0700 Message-ID: From: Steven Atkinson To: Brian McKelvey Content-Type: multipart/alternative; boundary=089e01184abe54bb8804da2e19cb X-Gm-Message-State: ALoCoQmAhhGdddvMLURbH/eMfZBsAo48+t+5UKhOJoNpwbywlIeDRcOXR9gDWiGTsXsJbQBr+9Sx Cc: "hybi@ietf.org" , "denis.m.f.mcmahon@googlemail.com" 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: Fri, 12 Apr 2013 18:30:37 -0000 --089e01184abe54bb8804da2e19cb Content-Type: text/plain; charset=ISO-8859-1 To really boil this down to it's essentials, as far as I understand the masking, it's so that proxies cannot be confused or tricked into caching HTTP content when they are not supposed to. Consider using a WebSocket for sending HTTP request messages *within the envelope* of a WebSocket message. In this case, we would want to avoid proxies picking up the enveloped payload by mistake and caching it, otherwise an attacker could maliciously poison the cache of a proxy by sending HTTP content inside WebSocket messaging to purposefully control proxy behavior. The masking prevents/makes this harder because the payload will no longer look like HTTP and will be less likely to be misinterpreted by the proxy. One perhaps better alternative would have been to never mask, and mandate that WSS be the default, and that no plain-text WebSockets would be allowed. That way, we get "confusion" avoidance for intermediaries, but also get confidentiality and non-repudiation security properties. On Sun, Jan 27, 2013 at 5:26 PM, Brian McKelvey wrote: > The purpose of the masking has nothing to do with preventing eavesdropping > or interception. It's meant to prevent malicious javascript running in a > web browser from connecting to arbitrary non-websocket services, or from > tricking http-unaware proxies into doing the attacker's bidding, caching > malicious data, etc. > > It's about preventing browsers from initiating attacks against > unsuspecting services, not about preventing eavesdropping or securing the > privacy of data in 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 < > denis.m.f.mcmahon@googlemail.com> wrote: > > > 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 > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > -- Sincerely, Steve Atkinson Software Engineer >|< Kaazing Corporation, CA USA >|< --089e01184abe54bb8804da2e19cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To really boil this down to it's essentials, as far as= I understand the masking,=A0
it's so that proxies cannot be confus= ed or tricked into caching HTTP content when they are not supposed to.
=
Consider using a WebSocket for sending HTTP request = messages *within the envelope* of a WebSocket message.
In t= his case, we would want to avoid proxies picking up the enveloped payload b= y mistake and caching it, otherwise an attacker
could maliciously poison the cache of a proxy by sending HTTP co= ntent inside WebSocket messaging to purposefully control proxy behavior.

The masking prevents/makes this harder b= ecause the payload will no longer look like HTTP and will be less likely to= be misinterpreted by the proxy.

One perhaps better alternative would have b= een to never mask, and mandate that WSS be the default, and that no plain-t= ext WebSockets would be allowed.
That way, we get "con= fusion" avoidance for intermediaries, but also get confidentiality and= non-repudiation security properties.


On Sun,= Jan 27, 2013 at 5:26 PM, Brian McKelvey <theturtle32@gmail.com>= ; wrote:
The purpose of the masking has nothing to do= with preventing eavesdropping or interception. =A0It's meant to preven= t malicious javascript running in a web browser from connecting to arbitrar= y non-websocket services, or from tricking http-unaware proxies into doing = the attacker's bidding, caching malicious data, etc.

It's about preventing browsers from initiating attacks against unsuspec= ting services, not about preventing eavesdropping or securing the privacy o= f data in transit. =A0The use of TLS with WebSockets is required for that.<= br>
Brian

Sent from my iPhone

On Jan 27, 2013, at 3:58 PM, Denis McMahon <denis.m.f.mcmahon@googlemail.com> wrote:

> The unpredictability of the masking key is essential to prevent author= s
> 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."
>
> -=3D However =3D-
>
> 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<= br> > 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<= br> > 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 o= f
> 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<= br> > 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
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi



--
=
Sincerely,
Steve Atkinson
Software Engineer
<= div>>|<=A0 Kaazing Corporation, CA USA=A0 >|<<= /div>
--089e01184abe54bb8804da2e19cb-- From martin.thomson@gmail.com Fri Apr 12 12:33: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 943B121F8FD7 for ; Fri, 12 Apr 2013 12:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQKyL9nndAyz for ; Fri, 12 Apr 2013 12:33:40 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD1921F8FDA for ; Fri, 12 Apr 2013 12:33:40 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z2so2409332wey.1 for ; Fri, 12 Apr 2013 12:33:39 -0700 (PDT) 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=vBTgMidsPCACpmq2MsRLuVFFbwZH6KXqpOSDhv9MZ0c=; b=fPkiUVnI8cZ8p0RFRo0nF7kh38OGAWE2nUGV6XQs/tN0PQFqO94F/yXxKsJ1jPyfcc cHf/xX0e2BQ3I6qfGEkqBtTXmxeafpgQrRlV4/s3lSo5uWp8COJgFktUTnmGE1JjQep1 5i485NtRpI+TYXfrjWJfnhsErSx73NwKZU4PbGG1aDcHb7Ko6oUxeokNXgZc+yKx6oXo GmEpFPakolR9DV1A9m6+mMllx7y0xlCXd6xNTcX2CKySiwv/5iKj+cSn9T0ajQrkWxph IngCpEaXj7xDbHhjoWm4WSpvpRw1BWsYY22FwRQ8JXi5Nwtsb3SQ0EkUvoRXCUGZm/I5 i1aw== MIME-Version: 1.0 X-Received: by 10.180.94.133 with SMTP id dc5mr12955wib.1.1365795219343; Fri, 12 Apr 2013 12:33:39 -0700 (PDT) Received: by 10.194.41.35 with HTTP; Fri, 12 Apr 2013 12:33:39 -0700 (PDT) In-Reply-To: References: <5105BF2D.50104@googlemail.com> Date: Fri, 12 Apr 2013 12:33:39 -0700 Message-ID: From: Martin Thomson To: Steven Atkinson Content-Type: text/plain; charset=UTF-8 Cc: "hybi@ietf.org" , "denis.m.f.mcmahon@googlemail.com" 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: Fri, 12 Apr 2013 19:33:41 -0000 Has the working group considered an FAQ? This question (including some of the follow up) are very common. The answer hasn't changed and there is a record of the discussion leading to the specified conclusion. On 12 April 2013 11:30, Steven Atkinson wrote: > To really boil this down to it's essentials, as far as I understand the > masking, > it's so that proxies cannot be confused or tricked into caching HTTP content > when they are not supposed to. > > Consider using a WebSocket for sending HTTP request messages *within the > envelope* of a WebSocket message. > In this case, we would want to avoid proxies picking up the enveloped > payload by mistake and caching it, otherwise an attacker > could maliciously poison the cache of a proxy by sending HTTP content inside > WebSocket messaging to purposefully control proxy behavior. > > The masking prevents/makes this harder because the payload will no longer > look like HTTP and will be less likely to be misinterpreted by the proxy. > > One perhaps better alternative would have been to never mask, and mandate > that WSS be the default, and that no plain-text WebSockets would be allowed. > That way, we get "confusion" avoidance for intermediaries, but also get > confidentiality and non-repudiation security properties. > > > On Sun, Jan 27, 2013 at 5:26 PM, Brian McKelvey > wrote: >> >> The purpose of the masking has nothing to do with preventing eavesdropping >> or interception. It's meant to prevent malicious javascript running in a >> web browser from connecting to arbitrary non-websocket services, or from >> tricking http-unaware proxies into doing the attacker's bidding, caching >> malicious data, etc. >> >> It's about preventing browsers from initiating attacks against >> unsuspecting services, not about preventing eavesdropping or securing the >> privacy of data in 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. >> > >> > 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 >> > >> > _______________________________________________ >> > hybi mailing list >> > hybi@ietf.org >> > https://www.ietf.org/mailman/listinfo/hybi >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > > > > > -- > Sincerely, > Steve Atkinson > Software Engineer >>|< Kaazing Corporation, CA USA >|< > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From bruce@callenish.com Wed Apr 17 17:58: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 E151021E80E5 for ; Wed, 17 Apr 2013 17:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgNe1YQS0QdL for ; Wed, 17 Apr 2013 17:58:16 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.247.111]) by ietfa.amsl.com (Postfix) with ESMTP id 4DD0721E80E1 for ; Wed, 17 Apr 2013 17:58:16 -0700 (PDT) Received: from [96.50.69.82] (port=59587 helo=[192.168.145.102]) by biz82.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1USdAv-0001lZ-Av; Wed, 17 Apr 2013 17:58:13 -0700 Message-ID: <516F4520.1070406@callenish.com> Date: Wed, 17 Apr 2013 17:58:08 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: "hybi@ietf.org" References: <5105BF2D.50104@googlemail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz82.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - callenish.com X-Get-Message-Sender-Via: biz82.inmotionhosting.com: authenticated_id: bruce+callenish.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: 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: Thu, 18 Apr 2013 00:58:17 -0000 For a while, I worked with a few others on a FAQ at: http://trac.tools.ietf.org/wg/hybi/trac/wiki/FAQ I got discouraged, though, when it started to be used as a place to debate issues that had already been decided on the mailing list (hence the request at the top of it not to do that). Since it isn't an official document for the WG it has no status within it, and has been left in a somewhat disorganized state. If you'd like to clean it up, you are welcome to. On 13-04-12 12:33 PM, Martin Thomson wrote: > Has the working group considered an FAQ? > > This question (including some of the follow up) are very common. The > answer hasn't changed and there is a record of the discussion leading > to the specified conclusion. > > From tyoshino@google.com Thu Apr 25 03:03:39 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 6235E21F95E7 for ; Thu, 25 Apr 2013 03:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUTGF3eGgYUY for ; Thu, 25 Apr 2013 03:03:38 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 6307A21F95E5 for ; Thu, 25 Apr 2013 03:03:38 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id l13so8428789wie.4 for ; Thu, 25 Apr 2013 03:03:37 -0700 (PDT) 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:cc:content-type; bh=NmjqiWnoW+/kkokGaEFgTd48P/cBu7Zs8TZWPw/HheY=; b=di5YDqtuHszYYZUiIdgbslcgFrOP/4iYGtv3MfGuT+0I4q4ez0l41snJkD8B6RD2QB uhFGJG7iXos+oYirkE0TtmIdVPdFLjldPv+PWaIdh9NrCovdX9tX8KjrQ6kMxHagn9Vd XToGwj1bjqW6RZhnF9zKp/NuEpAILUvoGfCxg1fyFTExeLkhMdJRf02CMaBDovG0oJtG UKvJ9ZFRCZkZ6JH1sdT2M42dwtnjhXDjPzrM+kc8cT5PMqebpcHqftjH3y2Br8bb31LD kxaAMBFXU1ztBbwDkfYtyRk9BVzymSXcxz8MXldJ0PZGA8uRpMiLeDTncHtiJpjrwoQL udCQ== 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:cc:content-type:x-gm-message-state; bh=NmjqiWnoW+/kkokGaEFgTd48P/cBu7Zs8TZWPw/HheY=; b=po/kffOEd7Zzv8qyudhNG7lUseTHZ9TYw7GnxAwH4hiGwyY+kWIFaoB25wHdOAOP7p qneKkn9r4GBpdcbYveoRubPe+LykKb/ORe2Wll2RXnelJ0zMOMEAETmqvHjvT3Kqmb/y p8XnwWTtcbQbrSREzhTt2wZHhke+HcWMqALm7CLQnpQAvFVbQd8uFvqO91qHAzf+4kkN /9mxlAZo36fDH/n+2/0PfDnz0rOQumhBnoXmHgOdqaYbrOu9j23aa32Lf4B35pbJcyn1 JBKt7csSfriJ91mOjK7bU+VdOy5tZDOiC/it1ltVWuNBPJ5r/KK+4mhtMf1LHDXBKJSj baNA== X-Received: by 10.194.82.34 with SMTP id f2mr16429119wjy.25.1366884217507; Thu, 25 Apr 2013 03:03:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.167.42 with HTTP; Thu, 25 Apr 2013 03:03:17 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 25 Apr 2013 19:03:17 +0900 Message-ID: To: Dario Crivelli Content-Type: multipart/alternative; boundary=047d7beb95c03be59b04db2c8876 X-Gm-Message-State: ALoCoQmxvLx9DTnatD145kjYsMD6q63oikovQ5ARVZYSMzJskHstJKAVXtzTNArRDMszf5lskIteA3s2lplC4KRiJuOcHVu0OjPAK0H6FGr1NBkrWFXhPL7QlIXtoCtMyRfqnfdAbDOIA5zt6VxpGUh3XJ3kPzpJDQypwE6wJv5AHe6Lf2DaHTFosUyybyHHggd+Nu/mI48s Cc: "hybi@ietf.org" Subject: Re: [hybi] Feedback on draft-ietf-hybi-permessage-compression-08.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, 25 Apr 2013 10:03:39 -0000 --047d7beb95c03be59b04db2c8876 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 5, 2013 at 1:27 AM, Dario Crivelli < dario.crivelli@lightstreamer.com> wrote: > In your changes in 6.2.3.2, upon the second occurrence of > If the "agreed parameters" > you should have written: "don't contain". > Oh, right. Fixed. > The general matter of extension chaining also affects paragraph 6.3: > If I understand correctly, you say that an intermediary may add or remove > a DEFLATE extension on the fly. > Yes. Not per message but per connection. > Do you mean that this is allowed also when other extensions follow the > DEFLATE? > Even if this implies unwinding those extensions first, then applying them > back? > Yes. > By the way, I see that the note on intermediaries is expressed in terms of > PMCEs, but it lies within the DEFLATE chapter. > Do you confirm that it is not there by mistake? > Good catch. Yes, that's just my mistake. Left some note specific to permessage-deflate and added a higher level section with more general note. > At the beginning of chapter 5, you say that > PMCEs operate only on non-control messages > but RFC 6455 only introduces control frames, not control messages. > I see "non-control messages" also written in RFC 6455 on page 34; I > suppose that even that one is a case of improper denomination. > Right. Replaced with non-control frames. > After that, in draft 08 you have added: > PMCEs operate only on the payload data portion and the "Per-message > Compressed" bit > But the last part seems to me too strong and in contrast with what you > answered me a few weeks ago; > I report the relevant part below: > Q: For instance: can a future extension belonging to this set [i.e. the > PMCEs] also reserve the RSV2 bit? > A: It may though it needs to be discussed and registered with the registry. > I see. Removed the sentence and added "If the extension expects frames as input, build a frame for the message and pass it." to the paragraphs talking about connection to the subsequent extension instead. --047d7beb95c03be59b04db2c8876 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 5, 2013 at 1:27 AM, Dario Crivelli <dario.crivelli@lightstreamer.com> wrote:
In your changes in 6.2.3.2, upon the second occurrence of
=A0= =A0 If the "agreed parameters"
you should have written: "don't contain".

Oh, right. Fixed.
=A0
The general matter of exten= sion chaining also affects paragraph 6.3:
If I understand correct= ly, you say that an intermediary may add or remove a DEFLATE extension on t= he fly.

Yes. Not per message but per c= onnection.
=A0
Do you mean that this is allowed also when other extensions follow the= DEFLATE?
Even if this implies unwinding those extensions first, = then applying them back?

Yes.
=A0
By the way, I see that the note on intermediaries is expressed in term= s of PMCEs, but it lies within the DEFLATE chapter.
Do you confirm that it is not there by mistake?

Good catch. Yes, that's just my mistake. Left som= e note specific to permessage-deflate and added a higher level section with= more general note.
=A0
<= div> At the beginning of chapter 5, you say that
=A0 =A0 PMCEs operate= only on non-control messages
but RFC 6455 only introduces contro= l frames, not control messages.
I see "non-control messages" also written in RFC 6455 on pag= e 34; I suppose that even that one is a case of improper denomination.

Right. Replaced with non-cont= rol frames.
=A0
<= div> After that, in draft 08 you have added:
=A0 =A0 PMCEs operate only on the payload data portion and the "Per-me= ssage Compressed" bit
But the last part seems to me too stro= ng and in contrast with what you answered me a few weeks ago;
I r= eport the relevant part below:
Q: For instance: can a future extension belonging to this set [i.e. th= e PMCEs] also reserve the RSV2 bit?
A: It may though it needs to = be discussed and registered with the registry.

I see. Removed the sentence and added "If the exte= nsion expects frames as input, build a frame for the message and pass it.&q= uot; to the paragraphs talking about connection to the subsequent extension= instead.
=A0
--047d7beb95c03be59b04db2c8876-- From tyoshino@google.com Thu Apr 25 03:27: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 AC58C21F947C for ; Thu, 25 Apr 2013 03:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMyo5YUWDMYl for ; Thu, 25 Apr 2013 03:27:22 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7527321F9473 for ; Thu, 25 Apr 2013 03:27:22 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id z2so2479761wey.29 for ; Thu, 25 Apr 2013 03:27:21 -0700 (PDT) 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:cc:content-type; bh=O1TMcm+xoU6OSv19irJj7VpcAd5ZVGrxr+xHzcf/zHs=; b=hKca1/7ahCwOPDPcAJvZ1pCCCrZPMmGwoiUOXBl9ADiEM/9gPkqc2GrqJqDSWIXIUJ /rNYyjh+4zY17wrDjxLTM6kfOeZxbQ/wyDXboBPCWGNoVF+eHpbdCTB+K0J6B8+XJRba FM71TXndGZc6Pry2CEETGYIfl6M7HSVJMX/wE9NaVtdLUwdcCcLZGapLazEePFtmucsc a7IZbcnieRNOGyCd21gfYvGJGhbiLPbCkGhqZkXpVvh+/01eywf7TK2UXfmKROK4OZjb 9wsvl3KxUvxZQZlWepyz9LxoEecOFA6vig2aB+WZZD2JhbeFkO40/FnuNaCzbiN6fd/b GO/A== 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:cc:content-type:x-gm-message-state; bh=O1TMcm+xoU6OSv19irJj7VpcAd5ZVGrxr+xHzcf/zHs=; b=JSv2xaRS8w3p7c4ybBRBCcuhVcv01DOGM0CLOByyzkGyhEGQp2bjQclHmTI1b6WIIK qQOvk+t7jxqxhTynuwwVC1OPqlH988nTmeNlTBsNh1NexnEUDO49rdWJ/9HgjxO9+j96 PwvTdvqQVJnXV2fOz2poosGZ5jcc7Fcw7GLQnk0sqOADmuIlx+IPc5NgPtXLn+p8Mnh7 PSvQrEvlgnN/cYBo3xW2v4HeeUDb/w8POxHiRN5KY4srIqDA54xiV2kTHxcc/PhTUvGk xhri48M+vWbIisglC0O+mKmh8neGfQKxcqgS1jHiLDILnQf0Pf0k9ulKvLSRypH9jAUm 6hhA== X-Received: by 10.180.87.170 with SMTP id az10mr3222015wib.3.1366885641570; Thu, 25 Apr 2013 03:27:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.167.42 with HTTP; Thu, 25 Apr 2013 03:27:01 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 25 Apr 2013 19:27:01 +0900 Message-ID: To: Dario Crivelli Content-Type: multipart/alternative; boundary=f46d0444e97f1d5f1404db2cdd32 X-Gm-Message-State: ALoCoQk3St4DToNCfuOEgXPigdWexBbxPMCfUZOcrriSAfCpYeVAO14ViCiVqBx2juXYnprn1YZpA3ixeP6dIHJh1i5RQs8BU1HNC5ly1tuTFiUXleyW93QcWUZCOLRdakXJ9Y+QAOJ9BzMjO6duOTUsok3ZR0cN131D9vdouHAz9VmE7Qgs75uCT4Vu8LJosF7UZcxeR66B Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-07.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, 25 Apr 2013 10:27:37 -0000 --f46d0444e97f1d5f1404db2cdd32 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 5, 2013 at 12:56 AM, Dario Crivelli < dario.crivelli@lightstreamer.com> wrote: > Hi Takeshi, > > From my viewpoint, the notes added in draft 08 make things clearer. > I will try to expand on some points of the previous email that don't have > a clear way out. > Then I will add other notes on the new draft 08 in the proper thread. > > > >>> On the other hand, I think it is obvious to all of us that a PMCE should >>> only operate on the message payload >>> >> >> Yes. Added some text to state that. >> >> >>> and should not interfere with any extension to be applied subsequently >>> (operating either on the payload or on the frames), provided that it >>> doesn't conflict on the use of the RSV1 bit. >>> >> >> Yes. Except for fragmentation change. >> > > Consider that conflicts due to fragmentation only arise with extensions > that are supposed to be applied before the PMCE. > Right. > As the PMCE only operates on the payload, the incompatibility with any > previous extension operating on the frames, in my opinion, should be in > some way implicit (see below). > Yes. My rephrasing using newly defined terms clarifies that more. > > >> >> >>> >>> I'm not sure if the current specification conveys this idea. >>> >>> >> Hmm, ... what kind of thing do you think we should say? >> > > I'm not able to propose any solution, because there is nothing to lean > upon. > However, I think that your reformulation of 5.1 and 5.2 in draft 08, where > you explicitly refer to extension chaining, is more prone to mutual > compatibility. > > The job would be easier if RFC 6455 had put some more restrictions. > For instance, a statement that the encoding of a message is a two-phase > process, where: > - the first phase produces the message payload and its properties (in > terms of opcode and reserved bits, due to be set in the first frame); > - the second phase produces the frames, with any additional frame-level > opcodes and reserved bits (along with possible extension data and custom > control frames). > This would provide "inputs" and "outputs" for the extensions to operate > on, and also basic constraints on the chaining of extensions. > > Do you think that imposing a similar restriction would cause possible > useful extensions to be ruled out? > I'm basically not concerned much with having such an input/output interface between extensions. It has expressive power high enough. Old deflate-stream idea needed replacing the second phase but it's now deprecated. > By the way, I admit that I haven't managed to read the sibling proposal > for the Multiplexing extension yet, so maybe this restriction is already > unsuitable for that one. > Old one was. The latest one generates sequence of messages, not frames. So, no problem. > > >> >> >>> By the way, in paragraph 4 it is said that an extension can be "applied >>> to output of" another extension; >>> however, in RFC6455 I can only find the concept of an "order of >>> operations" (in 9.1), which seems to me a broader one. >>> >>> >> Yes. Extension specification in RFC 6455 is very brief. Shall we redefine >> it well here? Hmm >> > > Do you think that expanding RFC 6455, in order to clarify how the > extension should be allowed to operate, would still be possible? > In fact, anything stated regarding extensions should have no impact on the > protocol itself; > moreover, since no extension has been registered yet, making changes on > the matter now would pose no cross-compatibility issues. > But I'm not familiar with the specification process and I acknowledge that > this may be unfeasible. > > Useful, but... needs much work. It would bring long discussion imaging various possible extensions. I prefer doing that later. --f46d0444e97f1d5f1404db2cdd32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 5, 2013 at 12:56 AM, Dario Crivelli <dario.crivelli@lightstreamer.com> wrote:
Hi Takeshi,

=
From my viewpoint, the notes added in draft 08 make things clearer.
I will try to expand on some points of the previous email that don&= #39;t have a clear way out.
Then I will add other notes on the new draft 08 in the proper thread.
=


=

On the other hand, I think it is obviou= s to all of us that a PMCE should only operate on the message payload

Yes. Added some text to state that.<= /div>
=A0
and should not interfere with any extension to be applied subsequ= ently (operating either on the payload or on the frames), provided that it = doesn't conflict on the use of the RSV1 bit.

Yes. Except for fragmentation change.
=

Consider that conflicts due to= fragmentation only arise with extensions that are supposed to be applied b= efore the PMCE.

Right.
=A0
As the PMCE only operates on the payload, the incompatibility with any= previous extension operating on the frames, in my opinion, should be in so= me way implicit (see below).

Yes. My rephrasing using newly defined terms clarifies that more.
=A0
=A0
=A0

I'm not sure if the current specification conveys t= his idea.


Hmm, ... wha= t kind of thing do you think we should say?

I'm not able to propose any solution, because= there is nothing to lean upon.
However, I think that your reform= ulation of 5.1 and 5.2 in draft 08, where you explicitly refer to extension= chaining, is more prone to mutual compatibility.

The job would be easier if RFC 6455 had put some more r= estrictions.
For instance, a statement that the encoding of a mes= sage is a two-phase process, where:
- the first phase produces the message payload and its properties (in = terms of opcode and reserved bits, due to be set in the first frame);
=
- the second phase produces the frames, with any additional frame-leve= l opcodes and reserved bits (along with possible extension data and custom = control frames).
This would provide "inputs" and "outputs" for the = extensions to operate on, and also basic constraints on the chaining of ext= ensions.

Do you think that imposing a similar rest= riction would cause possible useful extensions to be ruled out?

I'm basically not concerne= d much with having such an input/output interface between extensions. It ha= s expressive power high enough.

Old deflate-stream idea needed replacing the second phase but it's now = deprecated.
=A0
By the way, I admit that I haven't managed to read the sibling pro= posal for the Multiplexing extension yet, so maybe this restriction is alre= ady unsuitable for that one.

Old one was. The latest one generates sequence of messages, not frames. So,= no problem.
=A0
=A0
=A0
By the way, in paragraph 4 it is said that an extensio= n can be "applied to output of" another extension;
however, in RFC6455 I can only find the concept of an "order of operat= ions" (in 9.1), which seems to me a broader one.


Yes. Extension specif= ication in RFC 6455 is very brief. Shall we redefine it well here? Hmm

Do you think that= expanding RFC 6455, in order to clarify how the extension should be allowe= d to operate, would still be possible?
In fact, anything stated regarding extensions should have no impact on= the protocol itself;
moreover, since no extension has been regis= tered yet, making changes on the matter now would pose no cross-compatibili= ty issues.
But I'm not familiar with the specification process and I acknowle= dge that this may be unfeasible.


Useful, but... needs much wo= rk. It would bring long discussion imaging various possible extensions. I p= refer doing that later.
=A0
--f46d0444e97f1d5f1404db2cdd32-- From tyoshino@google.com Thu Apr 25 03:29:00 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 4763121F9473 for ; Thu, 25 Apr 2013 03:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FyzC4nfyC9-J for ; Thu, 25 Apr 2013 03:28:59 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9D14721F93D4 for ; Thu, 25 Apr 2013 03:28:59 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id l13so8968901wie.5 for ; Thu, 25 Apr 2013 03:28:58 -0700 (PDT) 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:cc:content-type; bh=eSWeylY+2RwSOXBnKUQxXmB1DePz7XnlP3jImCs3ORw=; b=Q3unhL+si8n7k0qdQDjLx1JBDuwsGlNmjmNetLrWfnUqVEPoWSdDlO767p8DJbBonw ThGibULzsGXDqPWHIH4k6dHH67p/U8pwTQs3OC23gSh4Ch3EI3TxmyPPw6Vnb8zirqRy eAoDAUEoCM2o81mLYIIWOjeOtqJ/08k+/QjlHrK4KTypmfj1Mxr0H9mZQ5ZudoRDYQ+6 X6hVy5ebftGLYzknQljV9dYQwspkB26ksZKCuL1dD5bN+ysqfltG2Jcsd37AZbzmQYBR Lai3ZjmCJw5B/Ne5fWGS3hZRcE5AfyEflohOSpBau4X9PMxt10bP0L+BFhNYUYIC7AWE m/fw== 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:cc:content-type:x-gm-message-state; bh=eSWeylY+2RwSOXBnKUQxXmB1DePz7XnlP3jImCs3ORw=; b=biN8n4JGngilHRZi6k35l1w+MRfTSFj1rzibGN+0nSi8SUYcrkqqkEYLqu9xd8DgR+ glrzG+IqdqBWUA0DVymUEEo1YxcCZxRfKX5JCGpX1TXL7vHrwm0FVQ48+yyhfKNV6zs9 DZsfEvjqo17PYfmFNeLU48gfnyP3gVm+6beRvzOPSN5bZNhnq+VzX43yGUYYimB5qo2S rqmmUDeUFquesllqTZ/SEPlW1Ul+QAImDrdhs/9LoPhy1DNQRdX5rgA2m7039b2TPSiG BeekJYq4/uKTW8ZsygcwL/Qwnw4/44nRuxQd8KYB54Replz9w+zDXSAY/Fu4aBs0i5GA kRfg== X-Received: by 10.194.5.196 with SMTP id u4mr74828407wju.54.1366885738658; Thu, 25 Apr 2013 03:28:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.167.42 with HTTP; Thu, 25 Apr 2013 03:28:38 -0700 (PDT) In-Reply-To: <6.2.5.6.2.20130408140630.0b6b4868@resistor.net> References: <6.2.5.6.2.20130223175715.094d8508@elandnews.com> <6.2.5.6.2.20130322234602.0bf66450@resistor.net> <6.2.5.6.2.20130408140630.0b6b4868@resistor.net> From: Takeshi Yoshino Date: Thu, 25 Apr 2013 19:28:38 +0900 Message-ID: To: SM Content-Type: multipart/alternative; boundary=047d7b5d5886e6dafc04db2ce2fa X-Gm-Message-State: ALoCoQlCAOUx0q7KppFl1/iyzVe8qWFW1aTmp+3twYsD+Ocshosb4kE0bAWdy4HjtECTiO2Rsbx2ye3OS+P4VJ/tSJd/J5o1ChreNeW9FRFvUGJMqkK1eX0RfDs5zqHbsQkK/BBvaPYipgu0Kcb1bVi8W1cyf7URK9Nw8AmkucP2Zc356NqmRUY71D8MCNtTkWuXVFf8Vn0W Cc: "hybi@ietf.org" Subject: Re: [hybi] Comments on draft-ietf-hybi-permessage-compression-05 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, 25 Apr 2013 10:29:00 -0000 --047d7b5d5886e6dafc04db2ce2fa Content-Type: text/plain; charset=ISO-8859-1 On Tue, Apr 9, 2013 at 6:11 AM, SM wrote: > There are three RFC 2119 key words in the above, i.e. MAY, SHOULD, MUST. >> The client "SHOULD be able to accept" is an assumption. >> >> >> Hmm. I meant it's recommended to make clients be able to accept the >> c2s_no_context_takeover. >> > > In that case it could be made straight-forward by, for example, saying: > > Clients SHOULD accept the "c2s_no_context_takeover" parameter. > > I see. Thanks --047d7b5d5886e6dafc04db2ce2fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 9, 2013 at 6:11 AM, SM <<= a href=3D"mailto:sm@resistor.net" target=3D"_blank">sm@resistor.net>= wrote:
There are three RFC 2119 k= ey words in the above, i.e. MAY, SHOULD, MUST. =A0The client "SHOULD b= e able to accept" is an assumption.


Hmm. I meant it's recommended to make clients be able to accept the c2s= _no_context_takeover.

In that case it could be made straight-forward by, for example, saying:

=A0 Clients SHOULD accept the "c2s_no_context_takeover" parameter= .


I see. = Thanks=A0
--047d7b5d5886e6dafc04db2ce2fa-- From internet-drafts@ietf.org Thu Apr 25 07:06: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 2BB5621F93E8; Thu, 25 Apr 2013 07:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYvCCK8-c7uz; Thu, 25 Apr 2013 07:06:26 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 613C121F91D9; Thu, 25 Apr 2013 07:06:26 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2013 07:06:26 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 14:06:27 -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 : Compression Extensions for WebSocket Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-09.txt Pages : 27 Date : 2013-04-25 Abstract: This document specifies a framework for creating WebSocket extensions that add compression functionality to the WebSocket Protocol. An extension based on this framework compresses the payload data portion of non-control WebSocket messages on a per-message basis using parameters negotiated during the opening handshake. This framework provides a general method to apply a compression algorithm to the contents of WebSocket messages. For each compression algorithm, an extension is defined by specifying parameter negotiation and compression algorithm in detail. This document also specifies one specific compression extension using the DEFLATE algorithm. 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-permessage-compression-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Thu Apr 25 07:09:37 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 A86A121F8F01 for ; Thu, 25 Apr 2013 07:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPtqaUQrGBRo for ; Thu, 25 Apr 2013 07:09:37 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 854D521F8C06 for ; Thu, 25 Apr 2013 07:09:30 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id s47so1903033wey.22 for ; Thu, 25 Apr 2013 07:09:29 -0700 (PDT) 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=WOT7ylrDbsBYewqxn/z6pOLiSxCnB1NcHbCuS/Sxsqk=; b=n/fGYCXi3bQSQlhOglVlZXukbfycY8z2qe+gPXWVtyyW90AS/PZsF9i3paaQ/ZcmEB Vc56HYuGbOPDGhY7JxaaBFSRnWiXwYqPBEhIbMqNmFYYUsUzlX5eu+kkFkGmeGLf+7yI I3ZBdX1mBclZkqdMF5phtA0qIi5o8kBulwM5GnWUeoeHCfp5zmGR9uiwKfZz5pH4eaQb zHPLVcgnjJ0NzlhIKVbDk3ccV0JEATq41yTbYFNKev6L4HLWnkQtmMytyCpDD7jJ00So HKKxq265+Vbk+IncRQpUlhhNV2R5aJicJTjy4mlskB/eX9I1NwpdTb3IxqtfuJYMjTSG D2nA== 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=WOT7ylrDbsBYewqxn/z6pOLiSxCnB1NcHbCuS/Sxsqk=; b=VX4CEi2j6uDZEYQYSLPlG0xTrk/JB+3dsjrpLFHC7fBrfxpJHY9Op/21mGBG85KeS2 ocfjIOot/1HfkKKV9I+v6+LMiBygG93OAG7Htoi/K1KUchOOqaoTvNcTvoj5vfwOFmKs 79s68eyXxjYIuk6aNl5fMi0bgo55q1XVhFCa9gHAj5uiK6ZyH6LV85njZD5fq++z34fw okC9S0fKJPx+n52ws5oSX9cJHK7YHrj+UvXorO4nMvWps6I4/eLjsRWEu4WdI7F0rIDZ qvzhlMTp+vpV8dMNOyeQCMQ3hdUnG/a3rAsyXAUaxdzLq8UAxIvaXZ46C4E9luwXMJ7b xd9A== X-Received: by 10.180.149.200 with SMTP id uc8mr1223899wib.3.1366898969442; Thu, 25 Apr 2013 07:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.167.42 with HTTP; Thu, 25 Apr 2013 07:09:09 -0700 (PDT) In-Reply-To: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> References: <20130425140626.10027.9016.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 25 Apr 2013 23:09:09 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=001a11c2697e84b25404db2ff787 X-Gm-Message-State: ALoCoQkHJS1pL/DkxMcqk4aPBufBwgJxDo2Dk95lhH+1OiemdOZauFF96BqkLmjIRDJXNCyLxSnho5AM8hgbW78GGXL6aE0DYsVnfh8Dg2SHMehNxKO0hh7UZF480+Gmm0ElFx+eLpqowOA91jDYn8glnpe+j9OhK7w3OOpziWmCer+wtKM8FDQp2wpJoxjCLwz2mQy69/v3 Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-09.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2013 14:09:37 -0000 --001a11c2697e84b25404db2ff787 Content-Type: text/plain; charset=ISO-8859-1 Incorporated suggestions by Dario Crivelli and Adam Rice. Thanks. Takeshi On Thu, Apr 25, 2013 at 11:06 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the BiDirectional or Server-Initiated HTTP > Working Group of the IETF. > > Title : Compression Extensions for WebSocket > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-09.txt > Pages : 27 > Date : 2013-04-25 > > Abstract: > This document specifies a framework for creating WebSocket extensions > that add compression functionality to the WebSocket Protocol. An > extension based on this framework compresses the payload data portion > of non-control WebSocket messages on a per-message basis using > parameters negotiated during the opening handshake. This framework > provides a general method to apply a compression algorithm to the > contents of WebSocket messages. For each compression algorithm, an > extension is defined by specifying parameter negotiation and > compression algorithm in detail. This document also specifies one > specific compression extension using the DEFLATE algorithm. > > 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-09 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-hybi-permessage-compression-09 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --001a11c2697e84b25404db2ff787 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Incorporated suggestions by Dario Crivelli=A0and Adam Rice= . Thanks.

Takeshi


On Thu, Apr 25, 2013 at 11:06 PM, <internet-drafts@ietf.org> wrote:

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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Compression Extensions for WebS= ocket
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-permessage-compre= ssion-09.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 27
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-04-25

Abstract:
=A0 =A0This document specifies a framework for creating WebSocket extension= s
=A0 =A0that add compression functionality to the WebSocket Protocol. =A0An<= br> =A0 =A0extension based on this framework compresses the payload data portio= n
=A0 =A0of non-control WebSocket messages on a per-message basis using
=A0 =A0parameters negotiated during the opening handshake. =A0This framewor= k
=A0 =A0provides a general method to apply a compression algorithm to the =A0 =A0contents of WebSocket messages. =A0For each compression algorithm, a= n
=A0 =A0extension is defined by specifying parameter negotiation and
=A0 =A0compression algorithm in detail. =A0This document also specifies one=
=A0 =A0specific compression extension using the DEFLATE algorithm.

=A0 =A0Please 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-permessa= ge-compression-09

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-hybi-permessage-compression-09


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

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

--001a11c2697e84b25404db2ff787-- From tyoshino@google.com Thu Apr 25 07:16: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 1095A21F94C3 for ; Thu, 25 Apr 2013 07:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeFnAlsUNioW for ; Thu, 25 Apr 2013 07:16:35 -0700 (PDT) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0023321F8EFC for ; Thu, 25 Apr 2013 07:16:34 -0700 (PDT) Received: by mail-we0-f177.google.com with SMTP id s47so1910598wey.22 for ; Thu, 25 Apr 2013 07:16:34 -0700 (PDT) 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=UMGD9sZiOcBRF+gsuvEkIB4HBRDZXqa31KlKvpxGGrY=; b=bwBrvOkAwWECuiEa3wXe/EfGyj0vRohUYLTS0yrarFwvIaqBstHfKLD0hXFuryW3T7 IDyAIwofNGJuPI8ZqmaGIjSjL3S0QiZ3i3Bmie20+J/+O3MM9QHolzxVxFSU/UL8/U4V qmIMPzqXfvCMqpI25x1zmq/ZDU6Hj7ggmPnqZODKzZgcG4ocPeWt/T+O1VEsRt55RSOX qB3pPctBNSYtoMlr5dTXHCciJTficBYQmGlN2zRR+nfBsk26T9VgJ7oAM+KXvxUXHMpo G0MjBnTe/z3gU3+BEAX8qwkFeKgHQU09wfLWoKjnIRzZ9ZxKf0aspxITjbMAz+anhqw7 Hffg== 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=UMGD9sZiOcBRF+gsuvEkIB4HBRDZXqa31KlKvpxGGrY=; b=l+8j4TdhZy6Ry5zBx6EJdQPYekKMjHMPPM29+0R3u4JPh9xdJVaoOecPnCyZH36ncK lQQx/6xKUfamJj1DOxy+GkPLjWLbEHOqDJvu76/UnWW/fvg1NmEkWk+37z/a3a9dCdlR 6fnKguk9xAjRKCnQId3JdcoXgW7/S3HqVYDxjTYWRt6T47R7Bs9wgEiGCgPbJh4v6ZkV B25BgSjBaiV2lWuXxniUkRbnOnB0bg5LPuqZncTyVHSSx/PwCRnj57RwoaKBElBPSaz6 /0JUGp0l0kQjsPf5+kT08zcQ0aBP0XdMJGSXn/dzJJlfrtlRqQgQwJUorkHT0t2dpu2l TtVA== X-Received: by 10.194.5.196 with SMTP id u4mr76230184wju.54.1366899393281; Thu, 25 Apr 2013 07:16:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.167.42 with HTTP; Thu, 25 Apr 2013 07:16:13 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 25 Apr 2013 23:16:13 +0900 Message-ID: To: Joakim Erdfelt , "hybi@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d5886c7dcc304db301086 X-Gm-Message-State: ALoCoQleDQC7J9E7BtiD8/uCPOjPxI3fnaj12iDoC2f4SPk3bvOGniP6KiGQyqzHMwAydSkMWLioxS3v86if22vHME9UApO3u4oGAmp7CJ8lSxoR7HwqkDA39XKnUzPPUGkuSEfXCxV5A/A4nVsoyvVFx1VXL1lvNt9A7f2jdGgiKVcbWMFTbe5/2nFIJcMwqQrDocdiLXkD Subject: Re: [hybi] Reference Implementation of draft-ietf-hybi-permessage-compression-07 ? 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, 25 Apr 2013 14:16:36 -0000 --047d7b5d5886c7dcc304db301086 Content-Type: text/plain; charset=ISO-8859-1 Hi Joakim, permessage-compress is now implemented on echo_client.py of pywebsocket. You can do simple send/receive test using --use-permessage-deflate parameter. Chrome is also going to support it behind a flag soon. Takeshi On Mon, Apr 1, 2013 at 11:48 PM, Takeshi Yoshino wrote: > We are going to implement it on pywebsocket soon, and then Chrome. I'll > tell you here when they're ready. > > Takeshi > > > On Fri, Mar 29, 2013 at 2:18 AM, Joakim Erdfelt wrote: > >> Is there a reference implementation of this draft of >> permessage-compression? >> I'd like to figure out what is wrong with our use of the Java built-in >> deflate libraries (as we could never quite get x-deflate-frame to work with >> chrome) >> >> -- >> Joakim Erdfelt >> webtide.com >> Developer advice, services and support >> from the Jetty & CometD experts >> eclipse.org/jetty - cometd.org >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > --047d7b5d5886c7dcc304db301086 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Joakim,

permessage-compress is now i= mplemented on echo_client.py of pywebsocket. You can do simple send/receive= test using --use-permessage-deflate parameter.

Chrome is also going to support it behind a flag soon.

Takeshi


On Mon, Apr 1, 2013 at 11:48 PM, Takeshi= Yoshino <tyoshino@google.com> wrote:
We are going to implement it on pywebsocket soon, and then= Chrome. I'll tell you here when they're ready.

Takeshi


On Fri, Mar 29, 2= 013 at 2:18 AM, Joakim Erdfelt <joakim@intalio.com> wrote:<= br>
Is there a reference implementation of this draft of permessage-compre= ssion?
I'd like to figure out what is wrong with our use of t= he Java built-in deflate libraries (as we could never quite get x-deflate-f= rame to work with chrome)

--
Joakim Erdfelt <joakim@intalio.com>
webtide.com
Developer advice, services and support
from the Jetty= & CometD experts

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



--047d7b5d5886c7dcc304db301086-- From joakim@intalio.com Thu Apr 25 07:54: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 E69FF21F93E5 for ; Thu, 25 Apr 2013 07:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhZ1lj8DpwPm for ; Thu, 25 Apr 2013 07:54:06 -0700 (PDT) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by ietfa.amsl.com (Postfix) with ESMTP id 7F5E221F93E8 for ; Thu, 25 Apr 2013 07:53:50 -0700 (PDT) Received: by mail-ee0-f47.google.com with SMTP id b57so1283620eek.20 for ; Thu, 25 Apr 2013 07:53:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=uFRnDaoYNIdC3vqZVu9kuDrxhmtyMt18eFn+pOYwiS0=; b=PNjTVIeCUdtqf7/JQX/G8mvqA4PxruEb4bPvWXom9hlyVTWx8IdrilwNyhhJzXcEpc 0gQLl+vfvSMLw5A85zWSdRfICSJTfAWfo6UEURQ7+q25C6gO94alvejL1U8ca6kBvYgh 5/KlfPOAQT0Lif5wEn7zqq0cj0O0Aa7NS9wSct+LZMcNOfaLJ9v1Ohe0zuNxFGHyI212 ZgAcrnQM5IjfQCGo45v8Czmmtv9MKDitsjpIycRTtTQii6fMJ0ab7RMjLJ/on8zY7sLW xKt5vjI75IJ/dJq74PSsCiFZpzrvxBHhf56eThd87YFzG0PSfI0PZRyT7eP3z8+wSt/B hs6A== MIME-Version: 1.0 X-Received: by 10.14.87.199 with SMTP id y47mr76663982eee.17.1366901621529; Thu, 25 Apr 2013 07:53:41 -0700 (PDT) Received: by 10.15.108.70 with HTTP; Thu, 25 Apr 2013 07:53:41 -0700 (PDT) Date: Thu, 25 Apr 2013 07:53:41 -0700 Message-ID: From: Joakim Erdfelt To: hybi@ietf.org Content-Type: multipart/alternative; boundary=001a11c29c60997f3904db3095bb X-Gm-Message-State: ALoCoQkkw5jbFhnBgIenE1qkj4WdrZ+r4KMG9/C3YhqAYLmCwgHMJfezM2NukHsZRDRxDDQPJZ04 Subject: [hybi] permessage-compression / permessage-deflate configuration is too complex 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, 25 Apr 2013 14:54:08 -0000 --001a11c29c60997f3904db3095bb Content-Type: text/plain; charset=ISO-8859-1 How can a server side implementation respond on a the extension negotiation for this spec, using the permessage-deflate saying, "sorry, we don't support the C-library tweaks present in the spec and will only use default behavior" or to say "sorry, we don't support the C-library tweaks present in the spec and will only use the following behavior for both c2s and s2c streams" The current language in permessage-compression-09 (Section 8) says: A server MUST decline a "permessage-deflate" offer if any of the following conditions is met: o The offer has any extension parameter not defined for use in an offer. o The offer has any extension parameter with an invalid value. o The offer has multiple extension parameters with the same name. o The server doesn't support the offered configuration. That last bullet point is the crux of the problem I'm facing. How can the negotiation indicate that "yes, i support permessage-deflate, but only this specific configuration, that doesn't match up to your configuration to permessage-deflate" I'd like to propose that all of the following concepts be removed from the permessage-deflate and just standardized for specific default behavior based on a sensible set of defaults (lowest common denominator?), similar to how HTTP's content codings work (the http spec does not tweak compression algorithms) ... c2s_max_window_bits c2s_no_context_takeover s2c_max_window_bits s2c_no_context_takeover from a Java point of view these are not possible to support without re-implementing the entire java.util.zip.Deflate library in each java application. (default Deflate support, that ships with every copy of Java since 1.0, just does not support these tweaks) -- Joakim Erdfelt webtide.com Developer advice, services and support from the Jetty & CometD experts eclipse.org/jetty - cometd.org --001a11c29c60997f3904db3095bb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
How can a server side implementation respond on= a the extension negotiation for this spec, using the permessage-deflate sa= ying, "sorry, we don't support the C-library tweaks present in the= spec and will only use default behavior" or to say "sorry, we do= n't support the C-library tweaks present in the spec and will only use = the following behavior for both c2s and s2c streams"

The current language in permessage-compression-09= (Section 8) says:

=A0 =A0A serve= r MUST decline a "permessage-deflate" offer if any of the followi= ng conditions is met:
=A0 =A0 =A0 o =A0The offer has any extension paramete= r not defined for use in an offer.
=A0 =A0 =A0 o =A0The offer has= any extension parameter with an invalid value.
=A0 =A0 =A0 o =A0= The offer has multiple extension parameters with the same name.
=A0 =A0 =A0 o =A0The server doesn't support the offered configurat= ion.

That last bullet point is the crux of t= he problem I'm facing. =A0How can the negotiation indicate that "y= es, i support permessage-deflate, but only this specific configuration, tha= t doesn't match up to your configuration to permessage-deflate"

I'd like to propose that all of the fol= lowing concepts be removed from the permessage-deflate and just standardize= d for specific default behavior based on a sensible set of defaults (lowest= common denominator?), similar to how HTTP's content codings work (the = http spec does not tweak compression algorithms) ...

c2s_max_window_bits
c2s_no_context_takeover

s2c_max_window_bits
s2c_no_context_takeov= er

from a Java point of view these are not possibl= e to support without re-implementing the entire java.util.zip.Deflate libra= ry in each java application. (default Deflate support, that ships with ever= y copy of Java since 1.0, just does not support these tweaks)

--
Joakim Erdfelt <joakim@intalio.com>
webtide.com<= /div>
Developer advice, services and support
from= the Jetty & CometD experts
--001a11c29c60997f3904db3095bb-- From webmaster@zaphoyd.com Thu Apr 25 15:38:49 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 AE55B21F96E8 for ; Thu, 25 Apr 2013 15:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M+DKVy4iFVxj for ; Thu, 25 Apr 2013 15:38:49 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id D325621F96CD for ; Thu, 25 Apr 2013 15:38:48 -0700 (PDT) Received: from ranna.uchicago.edu ([128.135.45.206]:57648) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from ) id 1UVUoQ-0004UB-Rg; Thu, 25 Apr 2013 18:38:47 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_FB7D05E0-7059-47AF-B141-00481F134FBD" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Peter Thorson In-Reply-To: Date: Thu, 25 Apr 2013 17:38:43 -0500 Message-Id: <25D2499B-BC3C-4232-8697-FFDE76E06A8D@zaphoyd.com> References: To: Joakim Erdfelt X-Mailer: Apple Mail (2.1503) 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: "hybi@ietf.org" Subject: Re: [hybi] permessage-compression / permessage-deflate configuration is too complex 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, 25 Apr 2013 22:38:49 -0000 --Apple-Mail=_FB7D05E0-7059-47AF-B141-00481F134FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Apr 25, 2013, at 09:53 , Joakim Erdfelt wrote: > How can a server side implementation respond on a the extension = negotiation for this spec, using the permessage-deflate saying, "sorry, = we don't support the C-library tweaks present in the spec and will only = use default behavior" or to say "sorry, we don't support the C-library = tweaks present in the spec and will only use the following behavior for = both c2s and s2c streams" >=20 > The current language in permessage-compression-09 (Section 8) says: >=20 > A server MUST decline a "permessage-deflate" offer if any of the = following conditions is met: > o The offer has any extension parameter not defined for use in = an offer. > o The offer has any extension parameter with an invalid value. > o The offer has multiple extension parameters with the same = name. > o The server doesn't support the offered configuration. >=20 > That last bullet point is the crux of the problem I'm facing. How can = the negotiation indicate that "yes, i support permessage-deflate, but = only this specific configuration, that doesn't match up to your = configuration to permessage-deflate" >=20 > I'd like to propose that all of the following concepts be removed from = the permessage-deflate and just standardized for specific default = behavior based on a sensible set of defaults (lowest common = denominator?), similar to how HTTP's content codings work (the http spec = does not tweak compression algorithms) ... >=20 > c2s_max_window_bits > c2s_no_context_takeover >=20 > s2c_max_window_bits > s2c_no_context_takeover >=20 > from a Java point of view these are not possible to support without = re-implementing the entire java.util.zip.Deflate library in each java = application. (default Deflate support, that ships with every copy of = Java since 1.0, just does not support these tweaks) >=20 > -- > Joakim Erdfelt Section 8.1.3 explains how to handle this case: A client sending: `Sec-WebSocket-Extensions: permessage-deflate; = s2c_no_context_takeover, permessage-deflate` is asking "I would prefer = that you reset the sliding window for each message, but if you can't = then the defaults are acceptable." The server could then choose which = copy of the extension request to return based on what it supports. A client sending: `Sec-WebSocket-Extensions: permessage-deflate; = s2c_no_context_takeover` is asking "I don't have the memory to spare for = a default sliding window context per connection. We can compress if you = support window resetting, if not we can't use compression." Removing these options would not enable a Java based endpoint to = compress connections that it otherwise wouldn't have been able to. It = only removes the ability for non-Java endpoints to optimize their = resource usage. Peter= --Apple-Mail=_FB7D05E0-7059-47AF-B141-00481F134FBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 joakim@intalio.com> = wrote:

How can a server side = implementation respond on a the extension negotiation for this spec, = using the permessage-deflate saying, "sorry, we don't support the = C-library tweaks present in the spec and will only use default behavior" = or to say "sorry, we don't support the C-library tweaks present in the = spec and will only use the following behavior for both c2s and s2c = streams"

The current language in = permessage-compression-09 (Section 8) says:

   A server MUST = decline a "permessage-deflate" offer if any of the following conditions = is met:
      o  The offer has = any extension parameter not defined for use in an = offer.
      o  The offer has any = extension parameter with an invalid value.
    =   o  The offer has multiple extension parameters with the same = name.
      o  The server doesn't support the offered = configuration.

That last bullet = point is the crux of the problem I'm facing.  How can the = negotiation indicate that "yes, i support permessage-deflate, but only = this specific configuration, that doesn't match up to your configuration = to permessage-deflate"

I'd like to propose that all of the = following concepts be removed from the permessage-deflate and just = standardized for specific default behavior based on a sensible set of = defaults (lowest common denominator?), similar to how HTTP's content = codings work (the http spec does not tweak compression algorithms) = ...
=

c2s_max_window_bits
c2s_no_context_takeover<= /div>

s2c_max_window_bits
s2c_no_context_take= over

from a Java point of view these are not = possible to support without re-implementing the entire = java.util.zip.Deflate library in each java application. (default Deflate = support, that ships with every copy of Java since 1.0, just does not = support these tweaks)

--
Joakim Erdfelt <joakim@intalio.com>

Section 8.1.3 explains how = to handle this case:

A client sending: = `Sec-WebSocket-Extensions: permessage-deflate; 

A client sending: = `Sec-WebSocket-Extensions: permessage-deflate; s2c_no_context_takeover` is = asking "I don't have the = memory to spare for a default sliding window context per connection. We = can compress if you support window resetting, if not we can't use = compression."

Removing these = options would not enable a Java based endpoint to compress connections = that it otherwise wouldn't have been able to. It only removes the = ability for non-Java endpoints to optimize their resource = usage.

Peter
= --Apple-Mail=_FB7D05E0-7059-47AF-B141-00481F134FBD-- From tyoshino@google.com Thu Apr 25 20:53:48 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 2CBEB21F8EEA for ; Thu, 25 Apr 2013 20:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.977 X-Spam-Level: X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxnD4l6r0djP for ; Thu, 25 Apr 2013 20:53:47 -0700 (PDT) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id F05E921F8432 for ; Thu, 25 Apr 2013 20:53:46 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id m6so135389wiv.13 for ; Thu, 25 Apr 2013 20:53:46 -0700 (PDT) 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:cc:content-type; bh=N5edr4vTGillGI4ZqQI4yYVEVdOdGbEn8x6ASWTX3LY=; b=Z5UWrrNdYPl+UKLAYa76UrqhIOzlB53HC0Ts3fqtinF31wFU3EeRvwJr/D8opa4Koc SaYiPJE+PtGLDgX+f55qzsCqLM0vffy1LUqeUDqRVAKHQIsMgvbKdXgXY2rNHDjfe07d S5yR6jEb9nxPfQvKtQFIJeSmZosu7HpX1xr/ZlQgo5YFbe4WAIRuuZAGYB+C6HOV2iIm jzD1vFsXctkMEagzYs0yeE36qPpkUpnhLPGx4jtHePnQ3QCPjU3XCTB1XNXTkxLyi6cS Cq0ar9xOI54zEFJJHyrqSuwC8ELZlEMyrNj5DgFyElxgxeR8VA2ngKvxX1/EgODw8UR1 vkWw== 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:cc:content-type:x-gm-message-state; bh=N5edr4vTGillGI4ZqQI4yYVEVdOdGbEn8x6ASWTX3LY=; b=d6C3qrhCjwfgV1geJsX3RV90lyZUD3S6oqcK56TMrGDD0CKoL5WRqY5cLY5Wsx8WaR v0HAqU5AlXlMOBzSepvdxxYO89BzeygQVV+AzrVWsPSjj60V6fBP4JBgCIYJ6/8hczHA AMY8I0NfQfuI3b8fhlmOTW7bCQoWh6L7Pu3SDET3X4gL9KOmrAejsvPewGTQLY62m6vV 9ClikFdI+HyRFNoRu1Jkk5nw9hSg2Zq63xWU1rw170dBXXU+x1nc9w9SzfFt+vL3VF5+ Hi8+9/WEzcOyrjYb82o0scuLxf2KPwEHQNV7VdxLqGj5Ed3I1X60tp0/EOVLWyqYihIS Df2w== X-Received: by 10.194.143.50 with SMTP id sb18mr79272482wjb.44.1366948426080; Thu, 25 Apr 2013 20:53:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.167.42 with HTTP; Thu, 25 Apr 2013 20:53:26 -0700 (PDT) In-Reply-To: <25D2499B-BC3C-4232-8697-FFDE76E06A8D@zaphoyd.com> References: <25D2499B-BC3C-4232-8697-FFDE76E06A8D@zaphoyd.com> From: Takeshi Yoshino Date: Fri, 26 Apr 2013 12:53:26 +0900 Message-ID: To: Peter Thorson Content-Type: multipart/alternative; boundary=089e0115f79a5cf78804db3b7b2e X-Gm-Message-State: ALoCoQn1VTm/yccByWi57j2GIfBBaXgOMGePXNR/sZCQ+WBVydkKuWg2iBM0+/afjgEKSSVH2d11Ej/VcGnQdbx8PcG5eYjzofIbWDjrDNzAe4a1K28iXE+UnkMas8uvT5TzOpcWTFnXueikkrfriWvttPn8glAMJ+trw1jeMpN+hLBsahluIw4KY8zJ24SB+jy107OE7oCV Cc: "hybi@ietf.org" Subject: Re: [hybi] permessage-compression / permessage-deflate configuration is too complex 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, 26 Apr 2013 03:53:48 -0000 --089e0115f79a5cf78804db3b7b2e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 26, 2013 at 7:38 AM, Peter Thorson wrote: > On Apr 25, 2013, at 09:53 , Joakim Erdfelt wrote: > > How can a server side implementation respond on a the extension > negotiation for this spec, using the permessage-deflate saying, "sorry, we > don't support the C-library tweaks present in the spec and will only use > default behavior" or to say "sorry, we don't support the C-library tweaks > present in the spec and will only use the following behavior for both c2s > and s2c streams" > > The current language in permessage-compression-09 (Section 8) says: > > A server MUST decline a "permessage-deflate" offer if any of the > following conditions is met: > o The offer has any extension parameter not defined for use in an > offer. > o The offer has any extension parameter with an invalid value. > o The offer has multiple extension parameters with the same name. > o The server doesn't support the offered configuration. > > That last bullet point is the crux of the problem I'm facing. How can the > negotiation indicate that "yes, i support permessage-deflate, but only this > specific configuration, that doesn't match up to your configuration to > permessage-deflate" > > I'd like to propose that all of the following concepts be removed from the > permessage-deflate and just standardized for specific default behavior > based on a sensible set of defaults (lowest common denominator?), similar > to how HTTP's content codings work (the http spec does not tweak > compression algorithms) ... > > c2s_max_window_bits > c2s_no_context_takeover > > s2c_max_window_bits > s2c_no_context_takeover > > from a Java point of view these are not possible to support without > re-implementing the entire java.util.zip.Deflate library in each java > application. (default Deflate support, that ships with every copy of Java > since 1.0, just does not support these tweaks) > > -- > Joakim Erdfelt > > > Section 8.1.3 explains how to handle this case: > > A client sending: `Sec-WebSocket-Extensions: permessage-deflate; > s2c_no_context_takeover, permessage-deflate` is asking "I would prefer > that you reset the sliding window for each message, but if you can't then > the defaults are acceptable." The server could then choose which copy of > the extension request to return based on what it supports. > > A client sending: `Sec-WebSocket-Extensions: permessage-deflate; s2c_no_context_takeover` > is asking "I don't have the memory to spare for a default sliding window > context per connection. We can compress if you support window resetting, if > not we can't use compression." > > Removing these options would not enable a Java based endpoint to compress > connections that it otherwise wouldn't have been able to. It only removes > the ability for non-Java endpoints to optimize their resource usage. > > Peter > The minimal set of functionality necessary to conform to this spec as a server is s2c_no_context_takeover. That's all. I believe Java SE can implement it. - Compression: use java.util.zip.Deflater and append 0x00 at the end. If received s2c_no_context_takeover, just recreate Deflater instance for each message. - Decompression: add 0x00 0x00 0xff 0xff to the end of message payload, decompress it using java.util.zip.Inflater. When you see the end of DEFLATE stream, recreate Inflate object and continue processing the rest. - You don't need to care c2s_max_window_bits and c2s_no_context_takeover. Just don't send them. - You can just ignore c2s_max_window_bits capability announcement coming from the client since you don't use it. - You should just reject requests with s2c_max_window_bits. Clients should take the way Peter explained above. We're not sure if window bits is win for WebSocket or not, so I'd prefer having it in the spec now. If it turned out to be win, you might be asked to support it by users. Otherwise, everyone forgets them. Anyway, you can make your server conform to the spec by supporting only s2c_no_context_takeover. Similarly, the minimal set clients need to support is c2s_no_context_takeover. Thanks --089e0115f79a5cf78804db3b7b2e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 26, 2013 at 7:38 AM, Peter Thorson <web= master@zaphoyd.com> wrote:
On Apr 25, 2013, at 09:53 , Joakim Erdfelt <joakim@intalio.com> wrote:
How can a server side impl= ementation respond on a the extension negotiation for this spec, using the = permessage-deflate saying, "sorry, we don't support the C-library = tweaks present in the spec and will only use default behavior" or to s= ay "sorry, we don't support the C-library tweaks present in the sp= ec and will only use the following behavior for both c2s and s2c streams&qu= ot;

The current language in permessage-compression-09 (Sect= ion 8) says:

=A0 =A0A server MUST decline a &= quot;permessage-deflate" offer if any of the following conditions is m= et:
=A0 =A0 =A0 o =A0The offer has any extension parameter not = defined for use in an offer.
=A0 =A0 =A0 o =A0The offer has any e= xtension parameter with an invalid value.
=A0 =A0 =A0 o =A0The of= fer has multiple extension parameters with the same name.
=A0 =A0 =A0 o =A0The server doesn't support the offered configurat= ion.

That last bullet point is the crux of the pro= blem I'm facing. =A0How can the negotiation indicate that "yes, i = support permessage-deflate, but only this specific configuration, that does= n't match up to your configuration to permessage-deflate"

I'd like to propose that all of the following= concepts be removed from the permessage-deflate and just standardized for = specific default behavior based on a sensible set of defaults (lowest commo= n denominator?), similar to how HTTP's content codings work (the http s= pec does not tweak compression algorithms) ...

c2s_max_window_bits
c2s_no_context_takeover

s2c_max_window_bits
s2c_no_context_takeov= er

from a Java point of view these are not possibl= e to support without re-implementing the entire java.util.zip.Deflate libra= ry in each java application. (default Deflate support, that ships with ever= y copy of Java since 1.0, just does not support these tweaks)

--
Joakim Erdfelt <joakim@intalio.com>

Section 8.1.3 expl= ains how to handle this case:

A client sending: `S= ec-WebSocket-Extensions: permessage-deflate;=A0s2c_no_context_takeover,=A0permessage-deflate` is asking=A0"I= would prefer that you reset the sliding window for each message, but if yo= u can't then the defaults are acceptable." The server could then c= hoose which copy of the extension request to return based on what it suppor= ts.

A client sending: `Sec-WebSocket-Extensions: permessage= -deflate;=A0s2c_no_context_takeover` is askin= g=A0"I don't have the memory = to spare for a default sliding window context per connection. We can compre= ss if you support window resetting, if not we can't use compression.&qu= ot;

Removing these options would not enable a Java ba= sed endpoint to compress connections that it otherwise wouldn't have be= en able to. It only removes the ability for non-Java endpoints to optimize = their resource usage.

Peter

The minimal set of = functionality necessary to conform to this spec as a server is s2c_no_conte= xt_takeover. That's all. I believe Java SE can implement it.

- Compression: use java.util.zip.Deflater and append 0x= 00 at the end. If received s2c_no_context_takeover, just recreate Deflater = instance for each message.
- Decompression: add 0x00 0x00 0xff 0x= ff to the end of message payload, decompress it using java.util.zip.Inflate= r. When you see the end of DEFLATE stream, recreate Inflate object and cont= inue processing the rest.

- You don't need to care c2s_max_window_bits and c2= s_no_context_takeover. Just don't send them.
- You can just i= gnore c2s_max_window_bits capability announcement coming from the client si= nce you don't use it.
- You should just reject requests with s2c_max_window_bits. Clients sh= ould take the way Peter explained above.

We're= not sure if window bits is win for WebSocket or not, so I'd prefer hav= ing it in the spec now. If it turned out to be win, you might be asked to s= upport it by users. Otherwise, everyone forgets them. Anyway, you can make = your server conform to the spec by supporting only s2c_no_context_takeover.=

Similarly, the minimal set clients need to suppor= t is c2s_no_context_takeover.

Thanks
--089e0115f79a5cf78804db3b7b2e-- From johnsonhammond2@hushmail.com Sat Apr 27 09:57:35 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 2DABC21F9835 for ; Sat, 27 Apr 2013 09:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+oiQ7l+Tg13 for ; Sat, 27 Apr 2013 09:57:35 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by ietfa.amsl.com (Postfix) with ESMTP id 0364221F982D for ; Sat, 27 Apr 2013 09:57:35 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) by smtp2.hushmail.com (Postfix) with SMTP id B5F90E7D27 for ; Sat, 27 Apr 2013 16:57:34 +0000 (UTC) Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp2.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 16:57:34 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 7B62B14DBDE; Sat, 27 Apr 2013 16:57:34 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 12:57:34 -0400 To: hybi@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427165734.7B62B14DBDE@smtp.hushmail.com> Subject: [hybi] Biggest Fake Conference in Computer Science X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 18:20:59 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From jat@jaet.org Sat Apr 27 12:39:58 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 2146621F978E for ; Sat, 27 Apr 2013 12:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 548eeGS7y7hJ for ; Sat, 27 Apr 2013 12:39:57 -0700 (PDT) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by ietfa.amsl.com (Postfix) with ESMTP id C676E21F95DB for ; Sat, 27 Apr 2013 12:39:56 -0700 (PDT) Received: by mail-pa0-f52.google.com with SMTP id fb10so619939pad.39 for ; Sat, 27 Apr 2013 12:39:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:x-originating-ip:in-reply-to:references :from:date:message-id:subject:to:cc:content-type:x-gm-message-state; bh=HfrQupDW0x+MQ8qiJQspVhfmQmZzLqQrfTqqK03DLsc=; b=l/khQsKZF9Zr/UC5WTDd/r+wMQZ0L8qUBo1+VakfMAhcGtYOmF7WAor4JRhsIJqC6J aGs92CnrzYDqBHURcqwWnkoidacUFK9uiZ0PWYDmw8sVCl2HWWWinYrmtf6sS4JaUrOn OS1/mnAm/goUsh1eqc7WDUZcBAWaI7CHy0rXK4mHTZPAtWSWlm1xCDjp8SVjqa9EOEoc mrPhd60IqJij9u9mR0U5UED3lJAy8iPBXt44r2063R3jmxYtj/nwGpbv13rj01iuPVBe gq03umI54gJvHW7L3WrkO8iCZsx7y+0DUF0lTCTTjgxnJlvgsj8I2SI8y7Fa0j5sOHKN DtHw== X-Received: by 10.68.195.234 with SMTP id ih10mr50673286pbc.162.1367091596496; Sat, 27 Apr 2013 12:39:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.241.163 with HTTP; Sat, 27 Apr 2013 12:39:36 -0700 (PDT) X-Originating-IP: [198.49.103.3] In-Reply-To: <20130427165734.7B62B14DBDE@smtp.hushmail.com> References: <20130427165734.7B62B14DBDE@smtp.hushmail.com> From: "John A. Tamplin" Date: Sat, 27 Apr 2013 15:39:36 -0400 Message-ID: To: johnsonhammond2@hushmail.com Content-Type: multipart/alternative; boundary=047d7b10cf85fc26e504db5cd0ec X-Gm-Message-State: ALoCoQl5ZwSEGSsReEmfKChgLAA7Ulhjz0msR9li1Y7WDxJaVNSqx+NSwa11fdRtKP+k03KWvzyk Cc: "hybi@ietf.org" Subject: Re: [hybi] Biggest Fake Conference in Computer Science X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 19:39:58 -0000 --047d7b10cf85fc26e504db5cd0ec Content-Type: text/plain; charset=UTF-8 On Sat, Apr 27, 2013 at 12:57 PM, wrote: > Biggest Fake Conference in Computer Science > All very interesting, but spamming unrelated groups with your post doesn't seem any better. -- John A. Tamplin --047d7b10cf85fc26e504db5cd0ec Content-Type: text/html; charset=UTF-8
On Sat, Apr 27, 2013 at 12:57 PM, <johnsonhammond2@hushmail.com> wrote:
Biggest Fake Conference in Computer Science

All very interesting, but spamming unrelated groups with your post doesn't seem any better.

--
John A. Tamplin
--047d7b10cf85fc26e504db5cd0ec-- From sm@elandsys.com Sat Apr 27 13:19: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 3757021F9778 for ; Sat, 27 Apr 2013 13:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Mgn3Q92mK5D for ; Sat, 27 Apr 2013 13:19:19 -0700 (PDT) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7E821F96ED for ; Sat, 27 Apr 2013 13:19:18 -0700 (PDT) Received: from SUBMAN.elandsys.com ([197.224.152.148]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r3RKJ4t0022814 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 27 Apr 2013 13:19:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1367093955; bh=TdzRIx/RlvrkR1hYlxyfVw5/8Wcz447AaKlVhlJaDas=; h=Date:To:From:Subject:In-Reply-To:References; b=Eqlp53nJOzptWdt8dcvXFyDiw1jF4oRu+ua82F2U/V/Bp/XRepjbkJGPW/GjV7K8v quQZdZW/y82tBAxAA/CdRDm6pDP8R6UjQL5eOmQZmSZYuSE02O6yv29dSKeFUNZcZ1 7hM4kq2rl64nYurPQgU9Ko04HRRxhq2vgw4bFE5k= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1367093955; i=@elandsys.com; bh=TdzRIx/RlvrkR1hYlxyfVw5/8Wcz447AaKlVhlJaDas=; h=Date:To:From:Subject:In-Reply-To:References; b=r0//xpXyO0UV3qaAC8umvNiG7AS5czg0GETQGxYyh+5sL0ydHBNMZwvL2wvuX0z5q QvNMP68ZnOJrd5BuoafXN/5kdgnxLSRJxK3Lk7K7WqSbB812lGjMhcNpZ62NnKlNaF kiB05ko3aVVpkwGS3+/V7inPIiiF3XSlTLB9L9Rw= Message-Id: <6.2.5.6.2.20130427131445.0e8f73c0@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 27 Apr 2013 13:18:50 -0700 To: hybi@ietf.org From: S Moonesamy In-Reply-To: <20130427165734.7B62B14DBDE@smtp.hushmail.com> References: <20130427165734.7B62B14DBDE@smtp.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [hybi] Moderation of johnsonhammond2@hushmail.com X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2013 20:19:20 -0000 Hello, There is an off-topic message which has been posted to several IETF mailing lists ( http://www.ietf.org/mail-archive/web/hybi/current/msg10024.html ). The subscription for johnsonhammond2@hushmail.com has been set as moderated. Regards, S. Moonesamy (as HyBi WG Secretary) From tobias.oberstein@tavendo.de Mon Apr 29 07:50:00 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 C510A21F9E73 for ; Mon, 29 Apr 2013 07:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cvuhpTwE5d-9 for ; Mon, 29 Apr 2013 07:50:00 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id A968421F9E72 for ; Mon, 29 Apr 2013 07:49:59 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.160]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Mon, 29 Apr 2013 07:49:58 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Mon, 29 Apr 2013 07:49:57 -0700 Thread-Topic: AutobahnTestsuite: new server reports Thread-Index: Ac5E5xjiPPGnI6+6Ttu+fpcQ+M9JGA== Message-ID: <634914A010D0B943A035D226786325D4422AE2250B@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "autobahnws@googlegroups.com" Subject: [hybi] AutobahnTestsuite: new server reports 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, 29 Apr 2013 14:50:00 -0000 Hello, we have updated the WebSocket server test reports on http://autobahn.ws/testsuite for 5 servers: Jetty, WebSocket++, Cowboy, ws (nodejs) and Autobahn. Good news regarding protocol compliance: The tested server implementations now completely pass all 301 test cases of AutobahnTestsuite, and 4/5 pass everything "strict". Cheers, Tobias Note: we (obviously) don't claim that passing those tests is equivalent to 100% spec compliance, but it's an indicator ..