From nobody Mon Jul 6 09:03:21 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1501A90A6; Mon, 6 Jul 2015 09:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HKUlx12hSpx3; Mon, 6 Jul 2015 09:03:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1591A1A89A8; Mon, 6 Jul 2015 09:03:12 -0700 (PDT) Received: from unnumerable.local (pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t66G32c2019216 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 6 Jul 2015 11:03:03 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-71-170-237-80.dllstx.fios.verizon.net [71.170.237.80] claimed to be unnumerable.local Message-ID: <559AA6B2.3@nostrum.com> Date: Mon, 06 Jul 2015 11:02:58 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Takeshi Yoshino References: <558B1E9C.8080505@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070408070604080409070400" Archived-At: Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, hybi@ietf.org, "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [hybi] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 16:03:19 -0000 This is a multi-part message in MIME format. --------------070408070604080409070400 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit (adding the hybi list) It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate. I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood. The additions to the text you propose will certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyond the intermediary needs to be prominent. But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down? RjS On 6/30/15 3:42 AM, Takeshi Yoshino wrote: > Thank you for review, Robert. > > On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks > wrote: > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Summary: Ready with issues > > (fwiw, I also reviewed up through version -24). > > Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. > (If that's not what it's trying to set up, please clarify). > > OK. So, I'd like to change the text as follows: > > When an intermediary proxies ... Per-message Compression of messages > received from one peer, and then forward the messages to the other > peer, if the intermediary ... > > It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? > Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. > > It's not well discussed in RFC6455. Right. AFAIK, there's no such > extension defined, yet. > > I understand that this text (intermediary section in the I-D) works > just not to disallow change of compression but there's nothing in > RFC6455 that guarantees that such transformation doesn't cause any > issue with other infrastructure of the WebSocket protocol. > > I believe that unless any extension that interferes with the other > negotiated extensions (e.g. counting the number of negotiated > extensions, relying on PMCE, etc.), the core WebSocket protocol > (things defined in RFC6455) should work. If such an extension is > introduced, it would be just considered to be incompatible with PMCEs, > or that extension should describe how to coordinate with change on > PMCE in the intermediaries section of its RFC. > > I think this is more reasonable than prohibiting change on Per-message > Compression by intermediaries. > > This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? > > Ah, right. Maybe some text like: > > "It's not guaranteed that the PMCE which an endpoint has negotiated in > the opening handshake is preserved in the whole path to the peer > endpoint." > > It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. > > > As a general discussion to cover other extensions (if they want. by > referring to this to-be-RFC) like the section defining terms to > complement RFC6455 [1]? > > [1] > https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 --------------070408070604080409070400 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit (adding the hybi list)

It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate.

I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood. The additions to the text you propose will certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyond the intermediary needs to be prominent.

But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down?

RjS

On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:

When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ...
 
It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that?
Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol.

I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC.

I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries.
This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

"It's not guaranteed that the PMCE which an endpoint has negotiated in the opening handshake is preserved in the whole path to the peer endpoint."
 
It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected.

As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]?

 

--------------070408070604080409070400-- From nobody Wed Jul 8 11:47:18 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1FA1A21B3; Wed, 8 Jul 2015 11:47:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G_L_IBvQ-Sh9; Wed, 8 Jul 2015 11:47:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C5DC1A009C; Wed, 8 Jul 2015 11:47:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Spencer Dawkins" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150708184716.20298.85889.idtracker@ietfa.amsl.com> Date: Wed, 08 Jul 2015 11:47:16 -0700 Archived-At: Cc: hybi@ietf.org, draft-ietf-hybi-permessage-compression@ietf.org, hybi-chairs@ietf.org Subject: [hybi] Spencer Dawkins' No Objection on draft-ietf-hybi-permessage-compression-24: (with COMMENT) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 18:47:17 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-hybi-permessage-compression-24: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support both of Ben's comments that mention intermediaries. From nobody Thu Jul 9 05:22:44 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039871AD358; Thu, 9 Jul 2015 05:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kv5RJy0pT9d9; Thu, 9 Jul 2015 05:22:39 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF44C1AD34C; Thu, 9 Jul 2015 05:22:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Stephen Farrell" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150709122239.3065.83450.idtracker@ietfa.amsl.com> Date: Thu, 09 Jul 2015 05:22:39 -0700 Archived-At: Cc: hybi@ietf.org, draft-ietf-hybi-permessage-compression@ietf.org, hybi-chairs@ietf.org Subject: [hybi] Stephen Farrell's Discuss on draft-ietf-hybi-permessage-compression-24: (with DISCUSS) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 12:22:41 -0000 Stephen Farrell has entered the following ballot position for draft-ietf-hybi-permessage-compression-24: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- The secdir reviewer's comment about modifying the signalling seems to me to be something that the hybi WG needs to have debated. Did that happen? From nobody Tue Jul 14 01:32:46 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB5581A9094 for ; Tue, 14 Jul 2015 01:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dJlosPV0cT5A for ; Tue, 14 Jul 2015 01:32:41 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C701A9093 for ; Tue, 14 Jul 2015 01:32:39 -0700 (PDT) Received: by oige126 with SMTP id e126so1881355oig.0 for ; Tue, 14 Jul 2015 01:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0cKQrYW7Zcze47Q+t4aZtQSNrkeNnaJ2wAXSCjn1CYM=; b=SBtFAbR+Nt9SrdDDny6qDnBi98BXoyEW3s6jLxhuSYCI96EhV+b6sH5yc3LJqCUXpK o0tFMjV0vqlimT7pflddR521fVSmRz4bhz6DjFERSCS7f7YnVVNIvZGQQ3xxf550gr/l X2zxVnahJeHSzNTLT0ygXvixdRo9aGFffoAI3HcXa1r5icJI8HK4Jk5xNRdNXIr61NuW Vc7zkhCQ7AN0+eQ5APMGgL9j3mRwnPO2NqiH8otq3k6t2ob0sTHRr+WUJPXteCNXpwRf NHSWlCbfzQFgMaDuWHXign8+oCWNNRvz+9CJ2IpaAAv42lMsU9yR308sFQWShwxn5ahj uWEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0cKQrYW7Zcze47Q+t4aZtQSNrkeNnaJ2wAXSCjn1CYM=; b=WQeU84YvDPoi2TFwnfCScAG+RsZj54kycNbmRJphH4/Nytv9R1gAP6m61ehjxF7AuO 6V0Lp3YqAtvrHyeyOWEp2jyHp8Rt6E++uBsnjO1SHUO9Pw8t+2gHwE2IVl6A7nqIbd6w x0lQcHbVqvz+y5cGrCJgJPRYY1qrFXiihS8wSVgdBaSDpvMBKzF+I+BYOAreF4kE+zo1 BgGDKhjO+bZbvqRVWb3nQAqV58BnIw5ilK8tqqzKB7KSaDKDjZ2B+5Ew267Ir/yR3GNk uwaYHdDEszrZWUpngPm8N9xKaqpkKljLuoRf6cHv1aO2UvieO9FkbTngIbhPodBDITKS NIIw== X-Gm-Message-State: ALoCoQmm7L6UlDVrG4TIGc3TVMcsTkEQW69ehtd2Z1HTC2niokHI5TI2YGaByqOt+WvA9BsyTlG9 X-Received: by 10.202.57.137 with SMTP id g131mr30373347oia.122.1436862758457; Tue, 14 Jul 2015 01:32:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Tue, 14 Jul 2015 01:32:18 -0700 (PDT) In-Reply-To: <559AA6B2.3@nostrum.com> References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> From: Takeshi Yoshino Date: Tue, 14 Jul 2015 17:32:18 +0900 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=001a113cee2a4f350f051ad1ae75 Archived-At: Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, "hybi@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [hybi] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:32:45 -0000 --001a113cee2a4f350f051ad1ae75 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks wrote: > (adding the hybi list) > Hi Robert, Sorry for delay. > > It seems to me that this effectively adding an actor (the intermediary) , > and defining (not as explicitly as I think it needs to be) protocol > mechanics for that actor in ways that the base specification did not > anticipate. > > Done more archaeology... This text originates from the intermediaries section introduced on update between draft-tyoshino-hybi-websocket-perframe-deflate-06 and draft-ietf-hybi-websocket-perframe-compression-00 I couldn't find the original proposal which led to this text from my mail box. I thought someone made one on HyBi, but only found my comment on publish of -00. As far as I remember, we initially didn't intend to add any requirement, expectation, etc. to the main (RFC 6455) spec by this spec. The text now looks like an additional requirements to complement the main spec just unexpectedly (unexpectedly at least for me). I added this text just to note a fact that when one wants to change compression, handshake should be also altered appropriately, otherwise, it doesn't work. Maybe the following texts in RFC 6455 have a similar role. o As control frames cannot be fragmented, an intermediary MUST NOT ... o An intermediary MUST NOT change the fragmentation of a message if ... o An intermediary MUST NOT change the fragmentation of any message ... > I'm not comfortable that the consequences of these new mechanics > (specifically - that the intermediary can directly participate in the > extension negotiations, and change the results) are well understood. > Did you mean "not well understood"? > The additions to the text you propose will certainly help point out that > there might be some, and the message that the endpoint won't have insight > into how its messages are handled beyond the intermediary needs to be > prominent. > Yeah. But now I'm wondering if it's in the scope of protocol standardization or not. Seems the text should be changed to look like a warning (don't do this or your stack won't work) as discussed above. > > But I wonder if the mechanics of an intermediary _changing the protocol > signalling_ is something the working group should explicitly work on > writing down? > > I've been viewing the PMCE from the view point of a browser developer. Like fragmentation, permessage-deflate is also just a transport-level thing which is invisible/transparent to the final user of the communication (e.g. JavaScript using the WebSocket API). My comments are based on this idea. But with your comment, I just noticed that it's not trivial. Actually, the extensions under use is exposed to the user of the protocol via _Extensions in Use_. We should have been aware of that. > RjS > > > On 6/30/15 3:42 AM, Takeshi Yoshino wrote: > > Thank you for review, Robert. > > On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks > wrote: > >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Summary: Ready with issues >> >> (fwiw, I also reviewed up through version -24). >> >> Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. >> (If that's not what it's trying to set up, please clarify). >> >> OK. So, I'd like to change the text as follows: > > When an intermediary proxies ... Per-message Compression of messages > received from one peer, and then forward the messages to the other peer, if > the intermediary ... > > >> It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? >> Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. >> >> It's not well discussed in RFC6455. Right. AFAIK, there's no such > extension defined, yet. > > I understand that this text (intermediary section in the I-D) works just > not to disallow change of compression but there's nothing in RFC6455 that > guarantees that such transformation doesn't cause any issue with other > infrastructure of the WebSocket protocol. > > I believe that unless any extension that interferes with the other > negotiated extensions (e.g. counting the number of negotiated extensions, > relying on PMCE, etc.), the core WebSocket protocol (things defined in > RFC6455) should work. If such an extension is introduced, it would be just > considered to be incompatible with PMCEs, or that extension should describe > how to coordinate with change on PMCE in the intermediaries section of its > RFC. > > I think this is more reasonable than prohibiting change on Per-message > Compression by intermediaries. > >> This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? >> >> Ah, right. Maybe some text like: > > "It's not guaranteed that the PMCE which an endpoint has negotiated in > the opening handshake is preserved in the whole path to the peer endpoint." > > >> It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. >> >> > As a general discussion to cover other extensions (if they want. by > referring to this to-be-RFC) like the section defining terms to complement > RFC6455 [1]? > > [1] > https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 > > > > --001a113cee2a4f350f051ad1ae75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 7, 2015 at 1:02 AM, Robert Sparks <rjsparks@nostrum.com>= wrote:
=20 =20 =20
(adding the hybi list)

Hi Rob= ert,

Sorry for delay.
=C2=A0

It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate.


Done more=C2=A0archaeology..= .

This text originates from the intermediaries sec= tion introduced on update between
draft-tyoshino-hybi-websocket-p= erframe-deflate-06 and
draft-ietf-hybi-websocket-perframe-compres= sion-00

I couldn't find the original proposal = which led to this text from my mail box. I thought someone made one on HyBi= , but only found my comment on publish of -00.

As = far as I remember, we initially didn't intend to add any requirement, e= xpectation, etc. to the main (RFC 6455) spec by this spec. The text now loo= ks like an additional requirements to complement the main spec just unexpec= tedly (unexpectedly at least for me). I added this text just to note a fact= that when one wants to change compression, handshake should be also altere= d appropriately, otherwise, it doesn't work. Maybe the following texts = in RFC 6455 have a similar role.

=C2=A0 =C2= =A0o =C2=A0As control frames cannot be fragmented, an intermediary MUST NOT= ...

=C2=A0 =C2=A0o =C2=A0An intermediary MUST NOT= change the fragmentation of a message if ...

=C2= =A0 =C2=A0o =C2=A0An intermediary MUST NOT change the fragmentation of any = message ...
=C2=A0
I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood.

Did you mean "n= ot well understood"?
=C2=A0
The additions to the text you propose will = certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyon= d the intermediary needs to be prominent.
Yeah. But now I'm wondering if it's in the scope of pro= tocol standardization or not. Seems the text should be changed to look like= a warning (don't do this or your stack won't work) as discussed ab= ove.
=C2=A0

But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down?


I've been viewing the PM= CE from the view point of a browser developer. Like fragmentation, permessa= ge-deflate is also just a transport-level thing which is invisible/transpar= ent to the final user of the communication (e.g. JavaScript using the WebSo= cket API). My comments are based on this idea. But with your comment, I jus= t noticed that it's not trivial.

Actually, the= extensions under use is exposed to the user of the protocol via _Extension= s in Use_. We should have been aware of that.
=C2=A0
RjS


On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I have reviewed this document as part of the security =
directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking ab=
out an intermediary doing compression on one side and not (or doing differe=
nt compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:

When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ...
=C2=A0
It's not clear from reading RFC6455 that the idea =
of intermediaries changing the contents of the websocket extension negotiat=
ion mechanism was considered - have I missed the text in that RFC that disc=
usses that?
Are there other extensions that suggest similar behavior? It's not imme=
diately clear that the protocol mechanics do the right thing when the diffe=
rent negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol.

I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC.

I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries.
This also seems to put an endpoint in a position where=
 it has no say on what an intermediary does with the traffic on the other s=
ide of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

"It's not guaranteed that the PMCE which an endpo= int has negotiated in the opening handshake is preserved in the whole path to the peer endpoint."
=C2=A0
It would be good to point to, or provide, a discussion=
 of how the extension negotiation mechanism in WebSockets is meant to be pr=
otected.

As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]?

=C2=A0


--001a113cee2a4f350f051ad1ae75-- From nobody Tue Jul 14 01:38:47 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFADC1A90B1 for ; Tue, 14 Jul 2015 01:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPsDEjCOUeDN for ; Tue, 14 Jul 2015 01:38:40 -0700 (PDT) Received: from mail-ob0-x232.google.com (mail-ob0-x232.google.com [IPv6:2607:f8b0:4003:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE15C1A90A7 for ; Tue, 14 Jul 2015 01:38:39 -0700 (PDT) Received: by obbgp5 with SMTP id gp5so1852782obb.0 for ; Tue, 14 Jul 2015 01:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=8R7Fi5GdwtT38yYY9ZOnhjWPan+0eJTKISG68AuBu9w=; b=UT3hzbQVUVZMWwe6ezttivQsS6JvPnZuMxc7ECElQIiYgUG38q+w0FK4cQ6/M99QjR BwOUZOTAnXojS5zOD4IQZk4cVzDZXyjT4S/haz6pXcZBXeN5lvQmLDhklQkCOBeuHLPS +854PX7o0QXJ8qV19vEFIDpuoA+RmCpWQbpOWYOrPU4aICWyvbNsPTFNUY8jom7dYJUP oDB2cUJLPqQIi0EE6bkgL4ZzCPysfhqdDZl1V9QUdPenmf1dsbEXnXKYCE0UY0Sz20GX PHBpsm4Uc7U++Dnw7yV9p0fj1mDNUZ0lR8wenixxEtwg5YZMcSntsOyix0XAD4j1oU4b IPwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=8R7Fi5GdwtT38yYY9ZOnhjWPan+0eJTKISG68AuBu9w=; b=cKGvQ26gljg2o6LZepmOMypaTHrg9rsOLN5XN4JVv3yTZKm5MDB14j0OssAAaf1US+ 6nJeTnOuX+ux+F7knVgVQYpeuY00dvoBvLjq2w7oQ4aLJ3yF+vHzv0p2z1VkRCVavBOp aAwAUIIfrlrItN6P0ZMM9M7rGftE4eiZf7KKfVsGDRgE8dygfSsnpAgF6cFILa178a7Q XmBSA1nQR8jESRK+n5H2BdXwGZX4V3D462iNe5dXlpGqPXJHVCuIKUYD8VytvNKmsYYW xV9xQsyKI13CQ19sqsnZ9XcFz6DVCZiMjKwVpAXQQNJA4o4h6TZvq4P+wK9Ga/9ip+/K XxzQ== X-Gm-Message-State: ALoCoQnPtrk6wq4xHBBr1YeN+DPXJIo6+RNAy9FI9BiUBqLhsBZPqry/1srb45q/W53RSDtnjF4h X-Received: by 10.60.35.98 with SMTP id g2mr32160370oej.6.1436863117672; Tue, 14 Jul 2015 01:38:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Tue, 14 Jul 2015 01:38:18 -0700 (PDT) From: Takeshi Yoshino Date: Tue, 14 Jul 2015 17:38:18 +0900 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=089e01182c10b86aa9051ad1c318 Archived-At: Cc: "hybi@ietf.org" , draft-ietf-hybi-permessage-compression@ietf.org, The IESG , hybi-chairs@ietf.org Subject: [hybi] Stephen Farrell's Discuss on draft-ietf-hybi-permessage-compression-24: (with DISCUSS) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2015 08:38:44 -0000 --089e01182c10b86aa9051ad1c318 Content-Type: text/plain; charset=UTF-8 On Thu, Jul 9, 2015 at 9:22 PM, Stephen Farrell wrote: > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > The secdir reviewer's comment about modifying the signalling > seems to me to be something that the hybi WG needs to have > debated. Did that happen? > Just started. --089e01182c10b86aa9051ad1c318 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Jul 9, 2015 at 9:22 PM, Stephen Farrell <stephen.farrell@cs.= tcd.ie> wrote:
------------= ----------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


The secdir reviewer's comment about modifying the signalling
seems to me to be something that the hybi WG needs to have
debated. Did that happen?

Just started.=
=C2=A0
--089e01182c10b86aa9051ad1c318-- From nobody Wed Jul 22 04:51:57 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25C851B2F72 for ; Wed, 22 Jul 2015 04:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl-FWzRCWL20 for ; Wed, 22 Jul 2015 04:51:52 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65AC1B2F9D for ; Wed, 22 Jul 2015 04:51:35 -0700 (PDT) Received: by obbop1 with SMTP id op1so132439348obb.2 for ; Wed, 22 Jul 2015 04:51:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=eGLRaCucGfcLJTrb2pY/EfghQC+95y1tf/NvnbrXXRk=; b=lLS2FY7qk4dKsGoIaaDkoTwcDh9zD8kAAOtZzOmYgHwEMU5YgQWznVyNHZVBTX1TTu uAzYyVjDyop7tkq0gCtHGyflAJwsFsWNc25Y+utF2pxFSp5ascMP+qEnMYoQY6Gr060u Y4XSF3HhOAJi1FZdabcl/SSCiXYNrldK9M7NN2z2807LdXAucmQgYqBSd4oKcdSYCGwE NAqbhzJs+Qr4+RgDRAsSA32jddevyioOL4jTl1qnG0hB0dvd6JRq3ycddANubTMBY5Ur pmcOtWtf8vugeQ5NEciFC0jTZmPz6iJQBSo75ihKC1DbEonNAzARdddgjiGUXJgWLUEe XiVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=eGLRaCucGfcLJTrb2pY/EfghQC+95y1tf/NvnbrXXRk=; b=T8urLdBVoNcbCsIrx21ryQmR/BOdedMQjqzJ5s6Su/NwWYnAFXRlyhSygYpmI/Stlw 4lo8KsB+Mq3Jowk0c7ZM/OjE3xgu+GZBIyyHbieZCD/dWEnDDkcvDbLb4CAkwN4TUJ4e wd+rabJNlsBWumVgV4EsOdIKQ855qtrAVisjtKXD/FBNyOAZv5nkOCiTBetdT6n+uDc1 /G6fl8Sp4PI/MqyRcXfnshJSkH55IAuoqnjn83nz+g588tH7BTPJracGBOwP5s2EJnVv 9BnrJJKwcWr38V4Kid2nu2Bh8YEB4Yib8u3SCSz0iWLd0XmocxutQ9X/4M3x671jjyjv fopA== X-Gm-Message-State: ALoCoQngRwi4YnrEHmpOu5lwqpugByjsx4Oxk4oX/Jr7/ujp203srVQ+SARShn3CPg5ijgVGk0pA X-Received: by 10.182.199.103 with SMTP id jj7mr1982759obc.49.1437565895138; Wed, 22 Jul 2015 04:51:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Wed, 22 Jul 2015 04:51:15 -0700 (PDT) In-Reply-To: References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> From: Takeshi Yoshino Date: Wed, 22 Jul 2015 20:51:15 +0900 Message-ID: To: Robert Sparks Content-Type: multipart/alternative; boundary=e89a8ff1c9ec85962c051b756409 Archived-At: Cc: draft-ietf-hybi-permessage-compression.all@ietf.org, "hybi@ietf.org" , "ietf@ietf.org" , "secdir@ietf.org" Subject: Re: [hybi] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:51:55 -0000 --e89a8ff1c9ec85962c051b756409 Content-Type: text/plain; charset=UTF-8 HyBi people, Please respond to this thread if you want to keep the section as-is (or with some improvement. texts welcome). I plan to revise it by replacing with a warning (saying "don't change the compression unless you don't know it") unless anyone objects to it. Takeshi On Tue, Jul 14, 2015 at 5:32 PM, Takeshi Yoshino wrote: > On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks > wrote: > >> (adding the hybi list) >> > > Hi Robert, > > Sorry for delay. > > >> >> It seems to me that this effectively adding an actor (the intermediary) , >> and defining (not as explicitly as I think it needs to be) protocol >> mechanics for that actor in ways that the base specification did not >> anticipate. >> >> > Done more archaeology... > > This text originates from the intermediaries section introduced on update > between > draft-tyoshino-hybi-websocket-perframe-deflate-06 and > draft-ietf-hybi-websocket-perframe-compression-00 > > I couldn't find the original proposal which led to this text from my mail > box. I thought someone made one on HyBi, but only found my comment on > publish of -00. > > As far as I remember, we initially didn't intend to add any requirement, > expectation, etc. to the main (RFC 6455) spec by this spec. The text now > looks like an additional requirements to complement the main spec just > unexpectedly (unexpectedly at least for me). I added this text just to note > a fact that when one wants to change compression, handshake should be also > altered appropriately, otherwise, it doesn't work. Maybe the following > texts in RFC 6455 have a similar role. > > o As control frames cannot be fragmented, an intermediary MUST NOT ... > > o An intermediary MUST NOT change the fragmentation of a message if ... > > o An intermediary MUST NOT change the fragmentation of any message ... > > >> I'm not comfortable that the consequences of these new mechanics >> (specifically - that the intermediary can directly participate in the >> extension negotiations, and change the results) are well understood. >> > > Did you mean "not well understood"? > > >> The additions to the text you propose will certainly help point out that >> there might be some, and the message that the endpoint won't have insight >> into how its messages are handled beyond the intermediary needs to be >> prominent. >> > > Yeah. But now I'm wondering if it's in the scope of protocol > standardization or not. Seems the text should be changed to look like a > warning (don't do this or your stack won't work) as discussed above. > > >> >> But I wonder if the mechanics of an intermediary _changing the protocol >> signalling_ is something the working group should explicitly work on >> writing down? >> >> > I've been viewing the PMCE from the view point of a browser developer. > Like fragmentation, permessage-deflate is also just a transport-level thing > which is invisible/transparent to the final user of the communication (e.g. > JavaScript using the WebSocket API). My comments are based on this idea. > But with your comment, I just noticed that it's not trivial. > > Actually, the extensions under use is exposed to the user of the protocol > via _Extensions in Use_. We should have been aware of that. > > >> RjS >> >> >> On 6/30/15 3:42 AM, Takeshi Yoshino wrote: >> >> Thank you for review, Robert. >> >> On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks >> wrote: >> >>> I have reviewed this document as part of the security directorate's >>> ongoing effort to review all IETF documents being processed by the >>> IESG. These comments were written primarily for the benefit of the >>> security area directors. Document editors and WG chairs should treat >>> these comments just like any other last call comments. >>> >>> Summary: Ready with issues >>> >>> (fwiw, I also reviewed up through version -24). >>> >>> Section 7 (Intermediaries) should be more explicit that it's talking about an intermediary doing compression on one side and not (or doing different compression) on the other. >>> (If that's not what it's trying to set up, please clarify). >>> >>> OK. So, I'd like to change the text as follows: >> >> When an intermediary proxies ... Per-message Compression of messages >> received from one peer, and then forward the messages to the other peer, if >> the intermediary ... >> >> >>> It's not clear from reading RFC6455 that the idea of intermediaries changing the contents of the websocket extension negotiation mechanism was considered - have I missed the text in that RFC that discusses that? >>> Are there other extensions that suggest similar behavior? It's not immediately clear that the protocol mechanics do the right thing when the different negotiations on each side of the proxy fail differently. >>> >>> It's not well discussed in RFC6455. Right. AFAIK, there's no such >> extension defined, yet. >> >> I understand that this text (intermediary section in the I-D) works >> just not to disallow change of compression but there's nothing in RFC6455 >> that guarantees that such transformation doesn't cause any issue with other >> infrastructure of the WebSocket protocol. >> >> I believe that unless any extension that interferes with the other >> negotiated extensions (e.g. counting the number of negotiated extensions, >> relying on PMCE, etc.), the core WebSocket protocol (things defined in >> RFC6455) should work. If such an extension is introduced, it would be just >> considered to be incompatible with PMCEs, or that extension should describe >> how to coordinate with change on PMCE in the intermediaries section of its >> RFC. >> >> I think this is more reasonable than prohibiting change on Per-message >> Compression by intermediaries. >> >>> This also seems to put an endpoint in a position where it has no say on what an intermediary does with the traffic on the other side of it. Is that worth discussing in the document? >>> >>> Ah, right. Maybe some text like: >> >> "It's not guaranteed that the PMCE which an endpoint has negotiated in >> the opening handshake is preserved in the whole path to the peer endpoint." >> >> >>> It would be good to point to, or provide, a discussion of how the extension negotiation mechanism in WebSockets is meant to be protected. >>> >>> >> As a general discussion to cover other extensions (if they want. by >> referring to this to-be-RFC) like the section defining terms to complement >> RFC6455 [1]? >> >> [1] >> https://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-24#section-3 >> >> >> >> > --e89a8ff1c9ec85962c051b756409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
HyBi people,

Please respond to this thr= ead if you want to keep the section as-is (or with some improvement. texts = welcome).

I plan to revise it by replacing with a = warning (saying "don't change the compression unless you don't= know it") unless anyone objects to it.

Takeshi
=

On Tue, Jul 14, 2015 at 5:32 PM, Takeshi Yos= hino <tyoshino@google.com> wrote:
On Tue, Jul 7, 2015 at 1:02 AM, Robert Sparks <<= a href=3D"mailto:rjsparks@nostrum.com" target=3D"_blank">rjsparks@nostrum.c= om> wrote:
=20 =20 =20
(adding the hybi list)

Hi Rob= ert,

Sorry for delay.
= =C2=A0

It seems to me that this effectively adding an actor (the intermediary) , and defining (not as explicitly as I think it needs to be) protocol mechanics for that actor in ways that the base specification did not anticipate.


Done more=C2=A0archae= ology...

This text originates from the intermediar= ies section introduced on update between
draft-tyoshino-hybi-webs= ocket-perframe-deflate-06 and
draft-ietf-hybi-websocket-perframe-= compression-00

I couldn't find the original pr= oposal which led to this text from my mail box. I thought someone made one = on HyBi, but only found my comment on publish of -00.

<= div>As far as I remember, we initially didn't intend to add any require= ment, expectation, etc. to the main (RFC 6455) spec by this spec. The text = now looks like an additional requirements to complement the main spec just = unexpectedly (unexpectedly at least for me). I added this text just to note= a fact that when one wants to change compression, handshake should be also= altered appropriately, otherwise, it doesn't work. Maybe the following= texts in RFC 6455 have a similar role.

=C2= =A0 =C2=A0o =C2=A0As control frames cannot be fragmented, an intermediary M= UST NOT ...

=C2=A0 =C2=A0o =C2=A0An intermediary M= UST NOT change the fragmentation of a message if ...

=C2=A0 =C2=A0o =C2=A0An intermediary MUST NOT change the fragmentation o= f any message ...
=C2=A0
I'm not comfortable that the consequences of these new mechanics (specifically - that the intermediary can directly participate in the extension negotiations, and change the results) are well understood.

Did you mean = "not well understood"?
=C2=A0
The additions to th= e text you propose will certainly help point out that there might be some, and the message that the endpoint won't have insight into how its messages are handled beyon= d the intermediary needs to be prominent.
Yeah. But now I'm wondering if it's in the scope= of protocol standardization or not. Seems the text should be changed to lo= ok like a warning (don't do this or your stack won't work) as discu= ssed above.
=C2=A0

But I wonder if the mechanics of an intermediary _changing the protocol signalling_ is something the working group should explicitly work on writing down?


I've been viewing= the PMCE from the view point of a browser developer. Like fragmentation, p= ermessage-deflate is also just a transport-level thing which is invisible/t= ransparent to the final user of the communication (e.g. JavaScript using th= e WebSocket API). My comments are based on this idea. But with your comment= , I just noticed that it's not trivial.

Actual= ly, the extensions under use is exposed to the user of the protocol via _Ex= tensions in Use_. We should have been aware of that.
=C2=A0
RjS


On 6/30/15 3:42 AM, Takeshi Yoshino wrote:
Thank you for review, Robert.

On Thu, Jun 25, 2015 at 6:18 AM, Robert Sparks <rjsparks@nostrum.com> wrote:
I have reviewed this document as part of the security =
directorate's=20
ongoing effort to review all IETF documents being processed by the=20
IESG.  These comments were written primarily for the benefit of the=20
security area directors.  Document editors and WG chairs should treat=20
these comments just like any other last call comments.

Summary: Ready with issues

(fwiw, I also reviewed up through version -24).

Section 7 (Intermediaries) should be more explicit that it's talking ab=
out an intermediary doing compression on one side and not (or doing differe=
nt compression) on the other.
(If that's not what it's trying to set up, please clarify).
OK. So, I'd like to change the text as follows:

When an intermediary proxies ... Per-message Compression of messages received from one peer, and then forward the messages to the other peer, if the intermediary ...
=C2=A0
It's not clear from reading RFC6455 that the idea =
of intermediaries changing the contents of the websocket extension negotiat=
ion mechanism was considered - have I missed the text in that RFC that disc=
usses that?
Are there other extensions that suggest similar behavior? It's not imme=
diately clear that the protocol mechanics do the right thing when the diffe=
rent negotiations on each side of the proxy fail differently.
It's not well discussed in RFC6455. Right. AFAIK, there's no such extension defined, yet.

I understand that this text (intermediary section in the I-D) works just not to disallow change of compression but there's nothing in RFC6455 that guarantees that such transformation doesn't cause any issue with other infrastructure of the WebSocket protocol.

I believe that unless any extension that interferes with the other negotiated extensions (e.g. counting the number of negotiated extensions, relying on PMCE, etc.), the core WebSocket protocol (things defined in RFC6455) should work. If such an extension is introduced, it would be just considered to be incompatible with PMCEs, or that extension should describe how to coordinate with change on PMCE in the intermediaries section of its RFC.

I think this is more reasonable than prohibiting change on Per-message Compression by intermediaries.
This also seems to put an endpoint in a position where=
 it has no say on what an intermediary does with the traffic on the other s=
ide of it. Is that worth discussing in the document?
Ah, right. Maybe some text like:

"It's not guaranteed that the PMCE which an endpo= int has negotiated in the opening handshake is preserved in the whole path to the peer endpoint."
=C2=A0
It would be good to point to, or provide, a discussion=
 of how the extension negotiation mechanism in WebSockets is meant to be pr=
otected.

As a general discussion to cover other extensions (if they want. by referring to this to-be-RFC) like the section defining terms to complement RFC6455 [1]?

=C2=A0



--e89a8ff1c9ec85962c051b756409-- From nobody Wed Jul 29 05:09:15 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52BE91A8902 for ; Wed, 29 Jul 2015 05:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEO_PHb0s943 for ; Wed, 29 Jul 2015 05:09:14 -0700 (PDT) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75A111A88F9 for ; Wed, 29 Jul 2015 05:09:14 -0700 (PDT) Received: by ioeg141 with SMTP id g141so19071454ioe.3 for ; Wed, 29 Jul 2015 05:09:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=o3wBPYbOshkyQ5yyfhMFUkO00FME2/P6DdQM6p2olYY=; b=IKbryHc+cGG+v2OIip2ymCj/XPkJCj4TWZjnK4X6oXFDZs6CIFGWCZWUOp0K9xHgP9 AF5nAn8TNXHCo29ODESiCn8NVibz4K8Jlj75VQHZfk/qWKZVkd2pG44kBI+HwQY5Davm /U2iCaIhB3HCXqS2Yf4URa+q+yhJytXxa304YVaVO61kppLo4V+R6Pi5MDVkvLdJLdLT ZhZJU7h9f94FkKp6cq/E5pvBEPhnQzIQtP4+e4me2JehWlaghUqHtIOEKnODjbjesHRd tE1wItKx7fbdPdOxgtv45ywDlq922+0HXw+V2l6/P6HR1ybilLC/+B8yGrx1AwcTr5nA KnDQ== MIME-Version: 1.0 X-Received: by 10.107.8.17 with SMTP id 17mr945693ioi.15.1438171753818; Wed, 29 Jul 2015 05:09:13 -0700 (PDT) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.133.95 with HTTP; Wed, 29 Jul 2015 05:09:13 -0700 (PDT) In-Reply-To: References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> Date: Wed, 29 Jul 2015 14:09:13 +0200 X-Google-Sender-Auth: st_LDG_-00NmjJyFgFOBzUfeY_Y Message-ID: From: Barry Leiba To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "hybi@ietf.org" , Stephen Farrell , Robert Sparks Subject: Re: [hybi] [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 12:09:15 -0000 (Trimming CC list...) > HyBi people, > > Please respond to this thread if you want to keep the section as-is (or with > some improvement. texts welcome). > > I plan to revise it by replacing with a warning (saying "don't change the > compression unless you don't know it") unless anyone objects to it. Takeshi, the energy level of the HyBi group is so low at this point that I think you should work out suitable text with Robert and Stephen, post it as a revised I-D, and then call for reviews -- with silence taken as agreement at this point. Can you do that quickly, and have it resolved before, say, 12 August? Barry From nobody Wed Jul 29 07:49:37 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2261D1A87CD for ; Wed, 29 Jul 2015 07:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wif6XAMoQrk4 for ; Wed, 29 Jul 2015 07:49:21 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765111A87CE for ; Wed, 29 Jul 2015 07:48:16 -0700 (PDT) Received: by oibn4 with SMTP id n4so6203162oib.3 for ; Wed, 29 Jul 2015 07:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k9eplF3fjio2QmoF7S5cH3bu28aGi+obBt319RYIyso=; b=gq792PbGyGMjnwZKRBI3/Q0QlF/fRUgxk9J/Sx7EH6dgsUQ7AikY0BjdIZ4fOiwRG0 Jm10xCqJMKI5Q5FnIcKFiwZbAxDEc7qv5cz7rZVnPdOUhu9J70m8B4In1AKnaST6gIq0 i+F2UBkXwxBLJmijXzc6glL8zpfJYhYJ7qgSd5b/1OMW1g/PCKqzlaCEL93Kq1P3d+3d sJh2rESE2CG6CeegScIrwj09wg9qjNTaWPK5Z3VxjN0OmlgMI2ifjoZD+17OjFfRNIsb bA5rrkNlsgu3d0537h16yf6ZG/2da6tlXydhSa9eUJ2qaZe8yeJGK2uS8Dl4t3wmpLJv YfhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=k9eplF3fjio2QmoF7S5cH3bu28aGi+obBt319RYIyso=; b=eoOz5PUsGm7yA4I2NMVeDfDDpkaVrW2uShpR57vwDdiaEBFtVgrNElr4hLX74X0xBS /qWl4mh5EhOlCUkLjWMBrteRovuuEG5Zvc2ZoLMpLAcGlopyZwcyExTEx5Ce5wT/omDS V7+s9aehH+X+cp1yH+oruYw2abHgGwI7chPYLQ/ERfn9TNUmeTevvvYQ3hnnwYQA6QcY aDdCVmE6qI0/SAJHvu37oDL12LYMjFoU5OaqbX+E5cxjMu6FVvI89rUglpcGp/2gRYq6 S+76cnGAJYa3/xbS3T+vo+5PNQ+4Qtjyd3nSS8EYSZEF3uOwnd2R/eFvN35sSoz08jvi ePrA== X-Gm-Message-State: ALoCoQlscCEJFvnGaZI3JqhU2mn6/PazD6yegwP4C5fRME5cuugBCzhYN8Adnq18OiOHeMEzPfQH X-Received: by 10.202.196.18 with SMTP id u18mr35887510oif.58.1438181296146; Wed, 29 Jul 2015 07:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Wed, 29 Jul 2015 07:47:56 -0700 (PDT) In-Reply-To: References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> From: Takeshi Yoshino Date: Wed, 29 Jul 2015 23:47:56 +0900 Message-ID: To: Barry Leiba Content-Type: multipart/alternative; boundary=001a113e385047c1ef051c04ad6f Archived-At: Cc: "hybi@ietf.org" , Stephen Farrell , Robert Sparks Subject: Re: [hybi] [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 14:49:22 -0000 --001a113e385047c1ef051c04ad6f Content-Type: text/plain; charset=UTF-8 On Wed, Jul 29, 2015 at 9:09 PM, Barry Leiba wrote: > (Trimming CC list...) > > > HyBi people, > > > > Please respond to this thread if you want to keep the section as-is (or > with > > some improvement. texts welcome). > > > > I plan to revise it by replacing with a warning (saying "don't change the > > compression unless you don't know it") unless anyone objects to it. > > Takeshi, the energy level of the HyBi group is so low at this point > that I think you should work out suitable text with Robert and > Stephen, post it as a revised I-D, and then call for reviews -- with > silence taken as agreement at this point. > > Can you do that quickly, and have it resolved before, say, 12 August? > Got it, Barry. I'll do so. > > Barry > --001a113e385047c1ef051c04ad6f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113e385047c1ef051c04ad6f-- From nobody Wed Jul 29 09:23:06 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBA041ACC82 for ; Wed, 29 Jul 2015 09:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZZYYFjvy1RS for ; Wed, 29 Jul 2015 09:23:03 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [188.40.63.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88E41AC40A for ; Wed, 29 Jul 2015 09:22:47 -0700 (PDT) DKIM-Signature: a=rsa-sha1; t=1438186965; x=1438791765; s=m2048; d=noemax.com; c=relaxed/relaxed; v=1; bh=oOo22YBM5vncbWyQJdDBj6JtL+c=; h=From:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; b=wF3dtacMRsEAmnV3N63D1GXZlZRbqrweNP+bGgKMFwGpQbdtCXqz57BhDV8PGmbANcGsNeJqEkyn7Dh9AP7VVffMvXRHSpnWdMjmSyCGiHJUXmTOnNIidxBNbErkR5+KYRRD7Cocto57yzTxLWDhujFDirv3xowtz533n5+wKBQgxcG3RaKnMG7OIsPg1aBrHdTED8Em2V5pPXMn614Ui8Z59iW27ssSEGbzzLI+gDu1JpmGotRTm6tiwTaoczSA8twEJvFYDNTNEs1Qd5ASFeCsr6zGENfzKL46skrowYq8WmYcevQJHUh+TotYTL59Dy8zm9/N7szHuGmlIVTGeQ== Received: from AlexLaptop by mail.noemax.com (Noemax Mail Server) with ASMTP (SSL) id 0201507291922446218; Wed, 29 Jul 2015 19:22:44 +0300 From: "Alexander Philippou" To: "'Barry Leiba'" , "'Takeshi Yoshino'" References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> In-Reply-To: Date: Wed, 29 Jul 2015 19:22:32 +0300 Message-ID: <00cc01d0ca1a$c74e43e0$55eacba0$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 15.0 thread-index: AQFHpPSdLVygQSGgKVCN1xW8L1viNAL8TesRAjfy/8oBnGOyKALJaHPRAcmiF/6eqc07cA== Content-Language: en-us Archived-At: Cc: hybi@ietf.org, 'Robert Sparks' , 'Stephen Farrell' Subject: Re: [hybi] [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 16:23:05 -0000 +1 Alexander > -----Original Message----- > From: hybi [mailto:hybi-bounces@ietf.org] On Behalf Of Barry Leiba > Sent: Wednesday 29 July 2015 15:09 > To: Takeshi Yoshino > Cc: hybi@ietf.org; Stephen Farrell ; Robert = Sparks > > Subject: Re: [hybi] [secdir] Secdir review of = draft-ietf-hybi-permessage- > compression-22 >=20 > (Trimming CC list...) >=20 > > HyBi people, > > > > Please respond to this thread if you want to keep the section as-is = (or with > > some improvement. texts welcome). > > > > I plan to revise it by replacing with a warning (saying "don't = change the > > compression unless you don't know it") unless anyone objects to it. >=20 > Takeshi, the energy level of the HyBi group is so low at this point > that I think you should work out suitable text with Robert and > Stephen, post it as a revised I-D, and then call for reviews -- with > silence taken as agreement at this point. >=20 > Can you do that quickly, and have it resolved before, say, 12 August? >=20 > Barry >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From nobody Wed Jul 29 09:49:02 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04781ACDA6 for ; Wed, 29 Jul 2015 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.788 X-Spam-Level: X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0He9ENXr-ySq for ; Wed, 29 Jul 2015 09:48:58 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88A51ACD97 for ; Wed, 29 Jul 2015 09:48:57 -0700 (PDT) Received: by obre1 with SMTP id e1so11634898obr.1 for ; Wed, 29 Jul 2015 09:48:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=gyQZnRZPor45rZ5VqLau5G1Sgz+e4RpkzSLcNNxJxjg=; b=OoxowdEi9HBOGMDxZtAhmniM/2b0419eGhrdE4AjWPOdExpNkvuDdmBIAbkos7WJQc /UrQXzUPeJjnGJ38aISPsaCsOFN49VfkHI9bxu7RDh/MI1KaREcrihc3Oa1vJ0URg2G+ tQBiPHz5jcNSzuH0YD4pelt/0g1IJ3yBCdC9k+QW5tASQnGTPfSfY5SUn2KrV2K2LBEM 3N+PltWbzPHv01t/EtivoaF9Xa9ETbO/RsPSO2JWiumLVWOq09HlXWjjXcBHbUhWAQLG DL1dpEOZeoaHcl56kCezC4NHCKPyzLxvDdX5Urucq+SyLM/MNc1J6M1thtp31rDpDyNl N9cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-type; bh=gyQZnRZPor45rZ5VqLau5G1Sgz+e4RpkzSLcNNxJxjg=; b=jytXePXlrgybVaRO9iawhuZ0FnSnJhul/G931JG13NfH+Rve3gJagaIIIzhGNl0pCh +Ytsr/oydj/CfGq1JT/4KbNOd/MQVY75Xjrz+12heD6Qh/g2UQB/06dScxdWHTP+q/Vq arxIt5uuVDMOVluKulxJTUXhBrrcKEfQbq4N/Ep/CO4jyOl6m7ytZbvOkjpukqXUvOab 6OdUeGNZ3ICZqagEeaapgZ12kBahEcNNcjGaZIQRFY6Mo115K0QH7DGccBL0/1iP0PqR 7igC+aJq+JSXa6Of8HuCY4vvWz6RXGb3swQwISSCZT5Q2R7Q1msOry7QnFXBtlgGMcFt wXHQ== X-Gm-Message-State: ALoCoQlZ4ngkXyLAvxy4y9zByJ37jmotsqX4C21QGlVjAhh1eDCq4p6tp92ezzUkHCJaRMIPiVOA X-Received: by 10.60.35.98 with SMTP id g2mr40842226oej.6.1438188536477; Wed, 29 Jul 2015 09:48:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Wed, 29 Jul 2015 09:48:36 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 30 Jul 2015 01:48:36 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=089e01182c10d66e34051c065c33 Archived-At: Cc: "hybi@ietf.org" Subject: [hybi] Implementing permessage-deflate with Java (was: Re: Restarting IESG review on permessage-deflate) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 16:49:00 -0000 --089e01182c10d66e34051c065c33 Content-Type: text/plain; charset=UTF-8 Hi Joakim, On Sat, Oct 5, 2013 at 4:17 AM, Takeshi Yoshino wrote: > On Fri, Oct 4, 2013 at 11:24 PM, Joakim Erdfelt > wrote: > >> There is also Eclipse Jetty 9.1 (currently in RC releases) support >> (server and client) >> >> We cannot support some of the spec, as written. >> Our experiences implementing it, and using chromium + pywebsocket for >> testing both the server or client implementation. >> >> The following configuration parameters are not supported, nor can/will be. >> >> s2c_no_context_takeover >> c2s_no_context_takeover >> s2c_max_window_bits >> c2s_max_window_bits >> >> > Sorry, why? s2c_no_context_takeover requests the server to reset context. > The server just need to throw away current deflater, create a new one and > use it. > > I appreciate if you explain why this doesn't work in detail if you have time. Regarding, server_max_window_bits in an offer, I think the choice would be just rejecting such offers. Regarding, client_max_window_bits with a value in an offer, you can just ignore it. Or, do you think that without supporting these parameters permessage-deflate won't be useful enough to work on? There're still many clients that can benefit from permessage-deflate. For example, Chrome never sends server_max_window_bits in an offer. > If the client didn't send s2c_no_context_takeover, you can still do the > same. You don't have to carry over compression context. > > The problem is that your server cannot decompress incoming data if the > client carries over compression context. So, you can just reply with > c2s_no_context_takeover. In > http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-12#section-8.1.1.2, > a client is required to implement c2s_no_context_takeover. I made this > mandatory since it's doable. So, you don't have to worry about clients > coming without c2s_no_context_takeover capability. > > >> This level of control of the deflate algorithm is just not possible in >> Java, sorry. >> >> > Again, please explain why you can't support no_context_takeover family > parameter. > > --089e01182c10d66e34051c065c33 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joakim,

=
=
On Fri, Oct 4, 2013 at 11:24 PM= , Joakim Erdfelt <joakim@intalio.com> wrote:
There is also = Eclipse Jetty 9.1 (currently in RC releases) support (server and client)
We cannot support some of the spec, as written.
Ou= r experiences implementing it, and using chromium + pywebsocket for testing= both the server or client implementation.

The following configuration parameters are not supporte= d, nor can/will be.

s2c_no_context_takeover
<= div>c2s_no_context_takeover
s2c_max_window_bits
c2s_max= _window_bits


Sorry, w= hy? s2c_no_context_takeover requests the server to reset context. The serve= r just need to throw away current deflater, create a new one and use it.


I appreci= ate if you explain why this doesn't work in detail if you have time.

Regarding, server_max_window_bits in an offer, I thi= nk the choice would be just rejecting such offers.

Regarding, client_max_window_bits with a value in an offer, you can just i= gnore it.

Or, do you think that without supporting= these parameters permessage-deflate won't be useful enough to work on?= There're still many clients that can benefit from permessage-deflate. = For example, Chrome never sends server_max_window_bits in an offer.
=C2=A0
If the client d= idn't send s2c_no_context_takeover, you can still do the same. You don&= #39;t have to carry over compression context.

The = problem is that your server cannot decompress incoming data if the client c= arries over compression context. So, you can just reply with c2s_no_context= _takeover. In=C2=A0http://tools.iet= f.org/html/draft-ietf-hybi-permessage-compression-12#section-8.1.1.2, a= client is required to implement c2s_no_context_takeover. I made this manda= tory since it's doable. So, you don't have to worry about clients c= oming without c2s_no_context_takeover capability.
=C2=A0
This level of control of the deflate algorithm is just not possible in= Java, sorry.


<= /span>
Again, please explain why you can't support no_context_takeo= ver family parameter.
=C2=A0

--089e01182c10d66e34051c065c33-- From nobody Wed Jul 29 09:49:49 2015 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70F221ACD61 for ; Wed, 29 Jul 2015 09:49:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.388 X-Spam-Level: X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3HYYc1u2v6Q for ; Wed, 29 Jul 2015 09:49:47 -0700 (PDT) Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FD171ACD88 for ; Wed, 29 Jul 2015 09:49:45 -0700 (PDT) Received: by obdeg2 with SMTP id eg2so11657290obd.0 for ; Wed, 29 Jul 2015 09:49:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=C7GhnZHbRRXigmc79HxLpEFzghe4AM7Huh3IFf9vF3A=; b=XvKaQp04NWHDRgtb9lPpk9h12u50sUa0K9U5NkCgU6d8skNjuoje2Fx2wgxaZSQRDX t24SlyWSS5Fjy6f+SkP7jUk9IZHJzZnxRTyQrmxYlToAzDNum9nS4OGZa7CLIi9egQoK hpqESc2uxqxPLrg6RkWVWLNOxHxtQ0wwU3I81KJU/lGD2u0hTZir5Wy55iRy/SxGM6Ul EwvGUOc1XjAH7OvV0/+d74DJvssP+kzE7bIko3PwbnXlV2PtD50Nq7KPcAXELo7JyVx8 AmAAVKkRO5ME881wHKP3xflrhsnVHIDx9VI+AeIxFv1HUOd8DRhHqvPVbtnXuxkh+Ukb 7f/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=C7GhnZHbRRXigmc79HxLpEFzghe4AM7Huh3IFf9vF3A=; b=O7NMFU0Tnny4FBL4QE4AmChncQu8/+mOdTnilgDpozI2ZxGdM+jS+ROM2c8VTMIqGM BrxFWZ/eVxLd+jTG3EYQS9mKomZZvByhs11VYdT5mwQndtwUEXBTLlNFQvLqELAJccYm geKgKeIA/tchqVFro1X38Ipt0BdpD0uFo4W7O3OhBannHeg6h6cnrtckGqZIoqh1jxZD UzDMCnBQG3Is8cIVH1kcEJ0EmND36ru18N+ys7HR++HQxoZLatpFcUEmP3S7eLTx4UaI 1whmCQsn24AmewmH+/mCzsqCmxqtL/ZC9JXTq8zuN1Z7Gi3qW12/uyS27mIoNbrEvnA1 C/Lg== X-Gm-Message-State: ALoCoQnjRXhhC4xED/P7XFqYx2wU8aFF5pHpn+zX0dqZY2UOVf2wx+59FxxCk3FrGUYStvnVpJYw X-Received: by 10.182.210.165 with SMTP id mv5mr40946174obc.82.1438188584719; Wed, 29 Jul 2015 09:49:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.66.130 with HTTP; Wed, 29 Jul 2015 09:49:24 -0700 (PDT) In-Reply-To: References: <558B1E9C.8080505@nostrum.com> <559AA6B2.3@nostrum.com> From: Takeshi Yoshino Date: Thu, 30 Jul 2015 01:49:24 +0900 Message-ID: To: Joakim Erdfelt Content-Type: multipart/alternative; boundary=001a11c24894b68ee3051c065fd3 Archived-At: Cc: "hybi@ietf.org" , Barry Leiba , Robert Sparks , Stephen Farrell Subject: Re: [hybi] [secdir] Secdir review of draft-ietf-hybi-permessage-compression-22 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 16:49:48 -0000 --001a11c24894b68ee3051c065fd3 Content-Type: text/plain; charset=UTF-8 Hi Joakim, On Thu, Jul 30, 2015 at 12:24 AM, Joakim Erdfelt wrote: > Speaking on behalf of Eclipse Jetty ... > > We do not yet have a working permessage-deflate, we have determined that > the existing spec (as currently written) is hostile towards the built-in > (native) deflate apis in Java (based on evidence collected during autobahn > testsuite for permessage-deflate) > Is the issue what you've described in https://www.ietf.org/mail-archive/web/hybi/current/msg10179.html ? > > To fix this, our current solution would be to implement this as a custom, > 100% java, deflate algorithm (which is *very* undesirable) > > We don't say much about the permessage-deflate, because we cannot > participate with others that have it implemented. > We briefly experimented with JNI layer to zlib directly, but our own > experiments showed that not using this layer we got better performance. > Interest from our community on permessage-deflate is very low as well. > > > Joakim Erdfelt / joakim@webtide.com > > On Wed, Jul 29, 2015 at 7:47 AM, Takeshi Yoshino > wrote: > >> On Wed, Jul 29, 2015 at 9:09 PM, Barry Leiba >> wrote: >> >>> (Trimming CC list...) >>> >>> > HyBi people, >>> > >>> > Please respond to this thread if you want to keep the section as-is >>> (or with >>> > some improvement. texts welcome). >>> > >>> > I plan to revise it by replacing with a warning (saying "don't change >>> the >>> > compression unless you don't know it") unless anyone objects to it. >>> >>> Takeshi, the energy level of the HyBi group is so low at this point >>> that I think you should work out suitable text with Robert and >>> Stephen, post it as a revised I-D, and then call for reviews -- with >>> silence taken as agreement at this point. >>> >>> Can you do that quickly, and have it resolved before, say, 12 August? >>> >> >> Got it, Barry. I'll do so. >> >> >>> >>> Barry >>> >> >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> >> > --001a11c24894b68ee3051c065fd3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Joakim,

On Thu, Ju= l 30, 2015 at 12:24 AM, Joakim Erdfelt <joakim@webtide.com>= wrote:
Speaking on beha= lf of Eclipse Jetty ...

We do not yet have a working per= message-deflate, we have determined that the existing spec (as currently wr= itten) is hostile towards the built-in (native) deflate apis in Java (based= on evidence collected during autobahn testsuite for permessage-deflate)

Is the issue what you've desc= ribed in=C2=A0https://www.ietf.org/mail-archive/web/hybi/current/msg10179= .html ?
=C2=A0

To fix this, our current solution would be t= o implement this as a custom, 100% java, deflate algorithm (which is *very*= undesirable)

We don't say much about the perm= essage-deflate, because we cannot participate with others that have it impl= emented.
We briefly experimented with JNI layer to zlib directly,= but our own experiments showed that not using this layer we got better per= formance.
Interest from our community on permessage-deflate is ve= ry low as well.


Joakim Erdfelt / joakim@webtide.com

On Wed, Jul 29, 2015 = at 7:47 AM, Takeshi Yoshino <tyoshino@google.com> wrote:
On We= d, Jul 29, 2015 at 9:09 PM, Barry Leiba <barryleiba@computer.org= > wrote:
(Trimming CC list...)<= br>
> HyBi people,
>
> Please respond to this thread if you want to keep the section as-is (o= r with
> some improvement. texts welcome).
>
> I plan to revise it by replacing with a warning (saying "don'= t change the
> compression unless you don't know it") unless anyone objects = to it.

Takeshi, the energy level of the HyBi group is so low at this point<= br> that I think you should work out suitable text with Robert and
Stephen, post it as a revised I-D, and then call for reviews -- with
silence taken as agreement at this point.

Can you do that quickly, and have it resolved before, say, 12 August?

Got it, Barry. I'll do so.
<= div>=C2=A0

Barry


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



--001a11c24894b68ee3051c065fd3--