From magnus.westerlund@ericsson.com Mon May 2 01:14:37 2011 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 92AC3E06F2; Mon, 2 May 2011 01:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.546 X-Spam-Level: X-Spam-Status: No, score=-106.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hyd24ZVTWss8; Mon, 2 May 2011 01:14:33 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9FDE062A; Mon, 2 May 2011 01:14:32 -0700 (PDT) X-AuditID: c1b4fb3d-b7bd5ae000002ba3-7f-4dbe67e7074f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E6.29.11171.7E76EBD4; Mon, 2 May 2011 10:14:32 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Mon, 2 May 2011 10:14:31 +0200 Message-ID: <4DBE67E7.3090601@ericsson.com> Date: Mon, 2 May 2011 10:14:31 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Willy Tarreau References: <4DBAEEC0.8050409@ericsson.com> <20110430152133.GD10529@1wt.eu> In-Reply-To: <20110430152133.GD10529@1wt.eu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 02 May 2011 08:14:37 -0000 Willy Tarreau skrev 2011-04-30 17:21: > On Sat, Apr 30, 2011 at 05:18:43PM +0200, Iñaki Baz Castillo wrote: >> 2011/4/29 Magnus Westerlund : >>> 41. Section 9. >>> >>> The security consideration section does not discuss client >>> authentication. Is that because this is supposed to happen in the HTTP >>> GET with the upgrade headers. there is some reference to cookies etc. >>> But shouldn't there be more on this? So that a server can ensure the >>> client identity? >> >> Cookies are retrieved from a web page, so if we assume that the >> websocket server will be able to validate the client provided cookie >> then we are wrong (the websocket server could be a separate server). > > Not only that, but cookies are used by infrastructure components too > in order to maintain persistence (association between a client and a > server). This is far from my area of real expertise, however I think the specification are going to need to point to the client authentication mechanism that can be used for websocket. This as authentication is one of these security mechanisms that one very commonly need. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From w@1wt.eu Mon May 2 01:55:46 2011 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 6EC35E0655; Mon, 2 May 2011 01:55:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.338 X-Spam-Level: X-Spam-Status: No, score=-3.338 tagged_above=-999 required=5 tests=[AWL=-1.295, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjCFJHa6TvwI; Mon, 2 May 2011 01:55:45 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96DE062A; Mon, 2 May 2011 01:55:43 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p428tYHv017933; Mon, 2 May 2011 10:55:34 +0200 Date: Mon, 2 May 2011 10:55:34 +0200 From: Willy Tarreau To: Magnus Westerlund Message-ID: <20110502085534.GO10529@1wt.eu> References: <4DBAEEC0.8050409@ericsson.com> <20110429183447.GD4085@1wt.eu> <4DBE66C3.4010805@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DBE66C3.4010805@ericsson.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 02 May 2011 08:55:46 -0000 Hi, On Mon, May 02, 2011 at 10:09:39AM +0200, Magnus Westerlund wrote: > >>From memory, it's because XHR can't set a Sec- header so we're certain > > that evil code running in browsers will not fake WS handshakes. We don't > > want to prevent any non-browser from establishing a connection (that is > > neither possible nor desired), but to ensure that owned browsers won't > > do that. > > I agree that the web-application running in the browser can't fake this > if you trust the browser. However, a server has no way of knowing if > this header comes from a browser doing all correct or if it the > websocket establishment is from do-no-good implementation. Thus, I fail > to see the security value of it. The idea was that the risk comes from browsers. Those are the only ones that can remotely be massively controlled by visiting an evil site. Other tools require an access on the system. Now that said, I'm not certain there is more risk in letting javascript fake a WS connection and letting javascript send a valid POST request somewhere. > >> 22. Section 4.3: > >> If I understand the masking correctly it for one particular frame it > >> uses the same mask over and over again over each 32-bits. As the frame > >> format supports message of size up to 2^63 I think I can perform a cache > >> poisining attack anyway. > > > > There was a very lengthy debate on this several months ago and it was hard > > to reach a rough consensus. I invite you to consult the archives. In short, > > we're certain products exist with a risk for the first bytes, we're not > > aware of any product which present this risk past whatever bytes break > > HTTP parsing, and the way to write such a vulnerable product appears very > > difficult to several developers, though it can't be demonstrated that none > > exists. The resulting proposal was accepted as a trade-off between a very > > low risk and some serious performance hits in some specific usages, and > > still provides good protection against the known issues. > > Ok, long discussion has happened and you have a rough consensus. From my > perspective I think you are going to need to defend the trade-off in two > ways. First, make it clear in the security consideration that the attack > is still possible to some degree. Secondly include some of the reasoning > behind it. Otherwise people will continue to comment on it. And it will > be discussed on IESG level I am pretty certain. One of the points was that the 32-bit "GET\n" is already a valid request for Apache, so anyway whatever the size of the key you use, it will still appear there once every 4 GB. However, Apache, just as any other known HTTP server supporting keep-alive, does not randomly look into a stream looking for what looks like a request. If you want my personal opinion, if the IESG could rely on deeper HTTP knowledge and conclude that the masking would need to protect better the first few bytes and does not need to be applied later, we'd be able to make it optional and simplify the spec. I mean that in my opinion, the masking is too much for an imagined risk, and possibly limited if the risky component was carefully designed to fail on this. > >From personal view I do think the WG is taking the wrong trade-off to > leave a evident security vulnerability in the protocol. By not securing > this sufficiently the effect is going to be that people write firewall > rules that block websocket. I do understand that there will be a > performance hit. But from the perspective of a somewhat slower protocol > that can be used and a protocol that can't I know what I pick. Well, as I explained above, the risk has been "imagined" from scratch. Whoever has already had to deal with developing a server-side HTTP stack knows that it's useless and almost impossible to scan a stream trying to parse an HTTP request where there is none. Basically we're talking about looking for "GET\n" in /dev/random. So any such method always comes down to statistics in the end. Considering the performance hit, we showed that the only way to safely try to crypt the traffic was by putting the key at the end of a frame, which forces every intermediary to buffer everything until they got the key to decode the frame. And that still does not stop the 32-bit pattern above from appearing. There were valid alternative suggestions such as prepending a fake request between the payload to force the non-compliant intermediaries to process this fake request instead of parsing the payload. Other ones consisted in using a masking with the 7th bit always set so that a valid request could never be encoded in the stream. > >> 29. Section 4.5.2: > >> An endpoint MAY send a Ping message any time after the connection is > >> established and before the connection is closed. NOTE: A ping > >> message may serve either as a keepalive, or to verify that the remote > >> endpoint is still responsive. > >> > >> So one allows to have multiple outstanding PING messages? That sounds a > >> bit strange over a reliable in-order delivery channel such as TCP. And > >> if one does allow it should there be any rules for answering pings in > >> order one receives them? > > > > Indeed, we should possibly remind implementors that it's useless to send > > a new ping as long as one is still pending. > > I think there is two possible ways. Allow it and simply include a note > that it is mostly useless. Or make it clear that one is not allowed to > send new pings until one have received the pong. Good point. > >> 36. Section 7.1.1. > >> This section should recommend that the client is the one that performs > >> the TCP close so that it holds the TIME_WAIT state and not the server. > > > > If we recommend something, we should recommend that the server does it, as > > only the client is impacted by holding a time_wait, as it prevents it from > > re-opening the connection for 2 MSL, while on the server it has no impact > > as reopining a time_wait connection is immediate upon a new SYN with a > > higher seq number. Do not forget that there will be quite a number of > > intermediaries in the whole chain and we don't want to cause basic networking > > issues between server-side proxies and the servers themselves. > > Ok, I haven't thought of it from this perspective. That makes sense as > long as you have no real issues with potential build up of TIME_WAIT > states on the server. I guess the main issue would be the sheer number > of connection states TIME_WAIT states are always very cheap. My record was 35 million on a 4-GB core2duo machine :-) And internet-exposed HTTP servers are already tuned to support large numbers. BTW, there will likely be many more TW from HTTP than from WS because the former leads to far many open/close events. Cheers, Willy From gregw@intalio.com Mon May 2 02:27:33 2011 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 CB0F0E070D for ; Mon, 2 May 2011 02:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.918 X-Spam-Level: X-Spam-Status: No, score=-2.918 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SKRH3mmYRSQj for ; Mon, 2 May 2011 02:27:33 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 42BDBE0680 for ; Mon, 2 May 2011 02:27:32 -0700 (PDT) Received: by vxg33 with SMTP id 33so4795044vxg.31 for ; Mon, 02 May 2011 02:27:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.236 with SMTP id 12mr8251645vdh.223.1304328451889; Mon, 02 May 2011 02:27:31 -0700 (PDT) Received: by 10.52.116.102 with HTTP; Mon, 2 May 2011 02:27:31 -0700 (PDT) In-Reply-To: <4DB8D3B2.8090002@mozilla.com> References: <4DB8D3B2.8090002@mozilla.com> Date: Mon, 2 May 2011 19:27:31 +1000 Message-ID: From: Greg Wilkins To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Payload only compression extension, again 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, 02 May 2011 09:27:33 -0000 In jetty trunk I have an implementation of an extension I've called x-deflate-frame for now. It uses 1 reserve bit to indicate if the payload is compressed. If the payload is compressed, then it is sent as: uncompressed-length deflated-data The uncompressed-length is encoded in the same format as the websocket frame length. The uncompressed length is sent so that a buffer may be allocated before starting to inflate the data. The extension supports a minLength parameter (default 64) and will not attempt to compress payloads that are smaller than that length. When compressing the data, if the combined uncompressed-length and deflated-data is longer than the original data, then the original data frame is sent instead. Currently I'm just using the standard java Inflater/Deflater gzip classes with a reset between frames. Not exactly sure what that means with regards to the algorithm details that Takeshi has specified, but I think they are close. cheers From magnus.westerlund@ericsson.com Mon May 2 01:09:43 2011 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 37E47E06F7; Mon, 2 May 2011 01:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.544 X-Spam-Level: X-Spam-Status: No, score=-106.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o1BhnAP20fI8; Mon, 2 May 2011 01:09:42 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id B4ECBE06F8; Mon, 2 May 2011 01:09:41 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-19-4dbe66c40369 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 9D.92.28525.4C66EBD4; Mon, 2 May 2011 10:09:40 +0200 (CEST) Received: from [147.214.183.89] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Mon, 2 May 2011 10:09:39 +0200 Message-ID: <4DBE66C3.4010805@ericsson.com> Date: Mon, 2 May 2011 10:09:39 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; sv-SE; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Willy Tarreau References: <4DBAEEC0.8050409@ericsson.com> <20110429183447.GD4085@1wt.eu> In-Reply-To: <20110429183447.GD4085@1wt.eu> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Mon, 02 May 2011 03:42:04 -0700 Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 02 May 2011 08:09:43 -0000 Hi, Please see inline for comments on your answers. I have dropped the ones that are fine. Willy Tarreau skrev 2011-04-29 20:34: > Hi Magnus, > > thank you for this deep review. I can't spend enough time to comment on > many of your points (in part because many are the results of very long > discussions), but there are a few short ones that can already be easily > addressed. > > On Fri, Apr 29, 2011 at 07:00:48PM +0200, Magnus Westerlund wrote: >> 2. Section 1.3 and 9. I really don't see how the Sec-WebSocket-Origin >> header provides any security without additional mechanisms. Yes, a >> trusted browser implementation will set it correctly. However, as non >> browser or hacked browser can fake this header the server has no direct >> trust in this value. To me it appears that one would need to make >> additional bindings to some other contexts to be able to trust the value >> of this header. Or am I missing some important part here? > >>From memory, it's because XHR can't set a Sec- header so we're certain > that evil code running in browsers will not fake WS handshakes. We don't > want to prevent any non-browser from establishing a connection (that is > neither possible nor desired), but to ensure that owned browsers won't > do that. I agree that the web-application running in the browser can't fake this if you trust the browser. However, a server has no way of knowing if this header comes from a browser doing all correct or if it the websocket establishment is from do-no-good implementation. Thus, I fail to see the security value of it. > >> 22. Section 4.3: >> If I understand the masking correctly it for one particular frame it >> uses the same mask over and over again over each 32-bits. As the frame >> format supports message of size up to 2^63 I think I can perform a cache >> poisining attack anyway. > > There was a very lengthy debate on this several months ago and it was hard > to reach a rough consensus. I invite you to consult the archives. In short, > we're certain products exist with a risk for the first bytes, we're not > aware of any product which present this risk past whatever bytes break > HTTP parsing, and the way to write such a vulnerable product appears very > difficult to several developers, though it can't be demonstrated that none > exists. The resulting proposal was accepted as a trade-off between a very > low risk and some serious performance hits in some specific usages, and > still provides good protection against the known issues. Ok, long discussion has happened and you have a rough consensus. From my perspective I think you are going to need to defend the trade-off in two ways. First, make it clear in the security consideration that the attack is still possible to some degree. Secondly include some of the reasoning behind it. Otherwise people will continue to comment on it. And it will be discussed on IESG level I am pretty certain. >From personal view I do think the WG is taking the wrong trade-off to leave a evident security vulnerability in the protocol. By not securing this sufficiently the effect is going to be that people write firewall rules that block websocket. I do understand that there will be a performance hit. But from the perspective of a somewhat slower protocol that can be used and a protocol that can't I know what I pick. > >> 27. Section 4.5.1: >> After both sending and receiving a close message, an endpoint >> considers the websocket connection closed, and SHOULD close the >> underlying TCP connection. >> >> What is the alternative to actually closing the TCP connection? Can one >> actually start a new websocket over the existing TCP connection? If >> there is no alternative, why not change SHOULD to MUST or at least will. > > Agreed (same as point 5 above BTW). Yes, but in a different place. > >> 29. Section 4.5.2: >> An endpoint MAY send a Ping message any time after the connection is >> established and before the connection is closed. NOTE: A ping >> message may serve either as a keepalive, or to verify that the remote >> endpoint is still responsive. >> >> So one allows to have multiple outstanding PING messages? That sounds a >> bit strange over a reliable in-order delivery channel such as TCP. And >> if one does allow it should there be any rules for answering pings in >> order one receives them? > > Indeed, we should possibly remind implementors that it's useless to send > a new ping as long as one is still pending. I think there is two possible ways. Allow it and simply include a note that it is mostly useless. Or make it clear that one is not allowed to send new pings until one have received the pong. > >> 32. Section 5.1, page 29: >> Once a connection to the server has been established (including a >> connection via a proxy or over a TLS-encrypted tunnel), the client >> MUST send a handshake to the server. The handshake consists of an >> HTTP upgrade request, along with a list of required and optional >> headers. The requirements for this handshake are as follows. >> >> >> Considering the cache poising and the security issue, why isn't >> websocket specified to always run in a TLS tunnel? Why is the non-secure >> mode existing at all? > > TLS + NPN was evocated as a possible later upgrade. Still there is a real > need for cleartext traffic so that communications can be analysed and > filtered in schools or other places where it is mandatory to filter > contents and/or to protect people. Ok, explanation provided. I have my view of that design. I do prefer that one would find a solution allowing for per leg protection. > >> 36. Section 7.1.1. >> This section should recommend that the client is the one that performs >> the TCP close so that it holds the TIME_WAIT state and not the server. > > If we recommend something, we should recommend that the server does it, as > only the client is impacted by holding a time_wait, as it prevents it from > re-opening the connection for 2 MSL, while on the server it has no impact > as reopining a time_wait connection is immediate upon a new SYN with a > higher seq number. Do not forget that there will be quite a number of > intermediaries in the whole chain and we don't want to cause basic networking > issues between server-side proxies and the servers themselves. Ok, I haven't thought of it from this perspective. That makes sense as long as you have no real issues with potential build up of TIME_WAIT states on the server. I guess the main issue would be the sheer number of connection states Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From jat@google.com Mon May 2 07:51:40 2011 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 4F553E06C5 for ; Mon, 2 May 2011 07:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.635 X-Spam-Level: X-Spam-Status: No, score=-107.635 tagged_above=-999 required=5 tests=[AWL=-1.659, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLb-C7N0kAxf for ; Mon, 2 May 2011 07:51:39 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9D0E0675 for ; Mon, 2 May 2011 07:51:39 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p42EpcLu008565 for ; Mon, 2 May 2011 07:51:38 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304347898; bh=4ZUy6JHgZ2axxCkT+svOtBa3GK8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Pv9tFmwJQQkNiEK7C5qGNC3caTWSKCYWnzSd9T17z7MzL/eQyrPuYSdjHIhYlEqG/ 1pfPukNc+dIKH6IyjDq9Q== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by hpaq7.eem.corp.google.com with ESMTP id p42EpUrf025975 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 07:51:36 -0700 Received: by gyg4 with SMTP id 4so2330698gyg.4 for ; Mon, 02 May 2011 07:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nvicSxS/pwDo755Zbsr/DWXhD2lH4vM/seJ8d2+T630=; b=TEXzEvTcqsB9kJUPsh0IxkvOe3Tprw+UtPQT/+cARPH9tNnot2onvrLYLibx6LCGAX 0NtilJPl3Ly62oVjwbuQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=ByTHHwX2MSDjWk9Fp8/hoLvm2qSjqPTkzr6rqgyRc/JZNk63ZWQ/HDVr4jscbmP8Mp J+5/FU7H4bif1RFXJMlw== Received: by 10.150.241.3 with SMTP id o3mr6673849ybh.2.1304347896214; Mon, 02 May 2011 07:51:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.199.16 with HTTP; Mon, 2 May 2011 07:51:16 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: John Tamplin Date: Mon, 2 May 2011 10:51:16 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd5162e04763604a24c2925 X-System-Of-Record: true Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] Payload only compression extension, again 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, 02 May 2011 14:51:40 -0000 --000e0cd5162e04763604a24c2925 Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2011 at 5:27 AM, Greg Wilkins wrote: > In jetty trunk I have an implementation of an extension I've called > x-deflate-frame for now. > > It uses 1 reserve bit to indicate if the payload is compressed. > If the payload is compressed, then it is sent as: > > uncompressed-length deflated-data > > The uncompressed-length is encoded in the same format as the websocket > frame length. The uncompressed length is sent so that a buffer may be > allocated before starting to inflate the data. > Is sufficient value gained by this to justify the cost? The extension supports a minLength parameter (default 64) and will not > attempt to compress payloads that are smaller than that length. > What is the value of making this configurable on a per-connection basis? Will this be exposed to the JS API? If not, how will the browser come up with a value here? > When compressing the data, if the combined uncompressed-length and > deflated-data is longer than the original data, then the original data > frame is sent instead. > Maintaining compression state across frames (which I think is required for this to be useful) and doing this requires either being able to save/restore the compression state or saying that even the case of the compressed data growing in size and being sent uncompressed, it still affects the compression state. The former imposes some constraints on the implementation, and the latter imposes a performance penalty on the receiver (and the sender when it decides for other reasons, such as knowing the type of data being sent, not to compress the data). > Currently I'm just using the standard java Inflater/Deflater gzip > classes with a reset between frames. Not exactly sure what that means > with regards to the algorithm details that Takeshi has specified, but > I think they are close. > See the compression experiments I posted last May - if you don't maintain compression state between frames, then you lose most of the benefit of compression. Being able to send uncompressed frames cheaply avoids the cost of this, but doesn't fix not getting the benefit of compression. Unfortunately, Java's default deflate implementation doesn't allow this, as you need to flush out the compressed bits at the end of a frame (though you can play tricks with changing the compression level to 0 and back, but that seems non-portable). I believe you can do it with jzlib though. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5162e04763604a24c2925 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2011 at 5:27 AM, Greg Wilkins <gregw@intalio.com> wrote:
In jetty trunk I have an implementation of an extension I've called
x-deflate-frame for now.

It uses 1 reserve bit to indicate if the payload is compressed.
If the payload is compressed, then it is sent as:

=C2=A0 =C2=A0uncompressed-length =C2=A0deflated-data

The uncompressed-length is encoded in the same format as the websocket
frame length. =C2=A0The uncompressed length is sent so that a buffer may be=
allocated before starting to inflate the data.

=C2=A0Is sufficient value gained by this to justify the cost?
=

The extension supports a minLength parameter (default 64) and will not
attempt to compress payloads that are smaller than that length.

What is the value of making this configurable on a per-connec= tion basis? =C2=A0Will this be exposed to the JS API? =C2=A0If not, how wil= l the browser come up with a value here?
=C2=A0
When compressing the data, if the combined uncompressed-length and
deflated-data is longer than the original data, then the original data
frame is sent instead.

Maintaining comp= ression state across frames (which I think is required for this to be usefu= l) and doing this requires either being able to save/restore the compressio= n state or saying that even the case of the compressed data growing in size= and being sent uncompressed, it still affects the compression state. =C2= =A0The former imposes some constraints on the implementation, and the latte= r imposes a performance penalty on the receiver (and the sender when it dec= ides for other reasons, such as knowing the type of data being sent, not to= compress the data).
=C2=A0
Currently I'm just using the standard java Inflater/Deflater =C2=A0gzip=
classes with a reset between frames. =C2=A0Not exactly sure what that means=
with regards to the algorithm details that Takeshi has specified, but
I think they are close.

See the compre= ssion experiments I posted last May - if you don't maintain compression= state between frames, then you lose most of the benefit of compression. = =C2=A0Being able to send uncompressed frames cheaply avoids the cost of thi= s, but doesn't fix not getting the benefit of compression.

Unfortunately, Java's default deflate implementation doe= sn't allow this, as you need to flush out the compressed bits at the en= d of a frame (though you can play tricks with changing the compression leve= l to 0 and back, but that seems non-portable). =C2=A0I believe you can do i= t with jzlib though.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd5162e04763604a24c2925-- From gregw@intalio.com Mon May 2 14:59:40 2011 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 4221FE07D3 for ; Mon, 2 May 2011 14:59:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hv+2JjDiEIcn for ; Mon, 2 May 2011 14:59:38 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id A5AF3E0797 for ; Mon, 2 May 2011 14:59:37 -0700 (PDT) Received: by qyk29 with SMTP id 29so1637586qyk.10 for ; Mon, 02 May 2011 14:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.77.142 with SMTP id g14mr993822qck.10.1304373576059; Mon, 02 May 2011 14:59:36 -0700 (PDT) Received: by 10.229.73.147 with HTTP; Mon, 2 May 2011 14:59:36 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> Date: Tue, 3 May 2011 07:59:36 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] Payload only compression extension, again 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, 02 May 2011 21:59:40 -0000 On 3 May 2011 00:51, John Tamplin wrote: > On Mon, May 2, 2011 at 5:27 AM, Greg Wilkins wrote: >> >> In jetty trunk I have an implementation of an extension I've called >> x-deflate-frame for now. >> >> It uses 1 reserve bit to indicate if the payload is compressed. >> If the payload is compressed, then it is sent as: >> >> =A0 =A0uncompressed-length =A0deflated-data >> >> The uncompressed-length is encoded in the same format as the websocket >> frame length. =A0The uncompressed length is sent so that a buffer may be >> allocated before starting to inflate the data. > > =A0Is sufficient value gained by this to justify the cost? The cost is trivial. The benefit is to be able to inflate into an allocated buffer of the correct size. Without knowing the size, then you will either over allocate, or will need a growing buffer, which involves data copies. As the inflated size may be many many times larger than the deflated size, I think that it is worth investing 1,3 or 9 bytes to avoid another arbitrary limit or extra copying. I started prototyping without this length and it was a good simplification to the code when I decided to try it. Sure there are libraries that will hide the variable/unknown length better than the java libraries, but they are just smoothing over significant costs in allocation and data copying. >> The extension supports a minLength parameter (default 64) and will not >> attempt to compress payloads that are smaller than that length. > > What is the value of making this configurable on a per-connection basis? > =A0Will this be exposed to the JS API? =A0If not, how will the browser co= me up > with a value here? Probably no great need to have this configurable. I was mostly testing extension parameters with this (but also modelling gzip filters which do appear to make this configurable). If the client does not send the parameter, the server still responds with the default value, so the client know it. >> When compressing the data, if the combined uncompressed-length and >> deflated-data is longer than the original data, then the original data >> frame is sent instead. > > Maintaining compression state across frames (which I think is required fo= r > this to be useful) and doing this requires either being able to save/rest= ore > the compression state or saying that even the case of the compressed data > growing in size and being sent uncompressed, it still affects the > compression state. =A0The former imposes some constraints on the > implementation, and the latter imposes a performance penalty on the recei= ver > (and the sender when it decides for other reasons, such as knowing the ty= pe > of data being sent, not to compress the data). The later also has cost on the server as it prevents simple buffer management. If can deflate into a buffer the same size as the raw data, then you avoid reallocations and data copies - which are the last things you want to do if you have discovered that the deflation is increasing the size. >> Currently I'm just using the standard java Inflater/Deflater =A0gzip >> classes with a reset between frames. =A0Not exactly sure what that means >> with regards to the algorithm details that Takeshi has specified, but >> I think they are close. > > See the compression experiments I posted last May - if you don't maintain > compression state between frames, then you lose most of the benefit of > compression. =A0Being able to send uncompressed frames cheaply avoids the= cost > of this, but doesn't fix not getting the benefit of compression. > Unfortunately, Java's default deflate implementation doesn't allow this, = as > you need to flush out the compressed bits at the end of a frame (though y= ou > can play tricks with changing the compression level to 0 and back, but th= at > seems non-portable). =A0I believe you can do it with jzlib though. Yes, the java std lib does appear lacking in this regard. As I said, I'm just using it for prototyping and don't think that it's deficiencies should greatly influence any effort to standardise such an extension - specially if better libraries are available (argh! they have license clashes and eclipse IP issues... still not a problem for this group). cheers From jat@google.com Mon May 2 15:02:34 2011 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 CB607E07DF for ; Mon, 2 May 2011 15:02:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.503 X-Spam-Level: X-Spam-Status: No, score=-104.503 tagged_above=-999 required=5 tests=[AWL=1.473, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-ldJx6WvVmz for ; Mon, 2 May 2011 15:02:33 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 80699E07D9 for ; Mon, 2 May 2011 15:02:33 -0700 (PDT) Received: from kpbe19.cbf.corp.google.com (kpbe19.cbf.corp.google.com [172.25.105.83]) by smtp-out.google.com with ESMTP id p42M2Vov016830 for ; Mon, 2 May 2011 15:02:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1304373751; bh=dAyVJGf74tC6sR7KTATuTL4BkYg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rd242J7E4CJ8jgyY7wPXP2ranedm+crEqWwzRlHYzUoSSuf2mDvSKTGMztco9ViE5 xusGt2w4Mor8Qa/dlVqtg== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by kpbe19.cbf.corp.google.com with ESMTP id p42M1HF7030615 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 2 May 2011 15:02:30 -0700 Received: by gyb11 with SMTP id 11so2645917gyb.29 for ; Mon, 02 May 2011 15:02:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=SPpFw7NTEyYYRuA485Z6DZdsGWfWf6cMxyiTHWRZXP4=; b=G0YEHWlyx/cwDeTGmOAbu2Kx1qMJLsA4uyzrwewYVifhjTuyZyP0YkLuxEAdC0gho0 lBY6wvcEGOwk5HGJHYcg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=rddeAVUsAprvlWH1l4GneXMGCVCkF8y3c+IiB1Jsky2TRtzDHXDdvku+IcocIIwrMg kddUujL0rdR2NSprOZzQ== Received: by 10.151.102.16 with SMTP id e16mr7665928ybm.287.1304373750147; Mon, 02 May 2011 15:02:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.199.16 with HTTP; Mon, 2 May 2011 15:02:10 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: John Tamplin Date: Mon, 2 May 2011 18:02:10 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=00151750ec70082b4f04a2522e75 X-System-Of-Record: true Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] Payload only compression extension, again 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, 02 May 2011 22:02:34 -0000 --00151750ec70082b4f04a2522e75 Content-Type: text/plain; charset=UTF-8 On Mon, May 2, 2011 at 5:59 PM, Greg Wilkins wrote: > > See the compression experiments I posted last May - if you don't maintain > > compression state between frames, then you lose most of the benefit of > > compression. Being able to send uncompressed frames cheaply avoids the > cost > > of this, but doesn't fix not getting the benefit of compression. > > Unfortunately, Java's default deflate implementation doesn't allow this, > as > > you need to flush out the compressed bits at the end of a frame (though > you > > can play tricks with changing the compression level to 0 and back, but > that > > seems non-portable). I believe you can do it with jzlib though. > > Yes, the java std lib does appear lacking in this regard. As I said, > I'm just using it for prototyping and don't think that it's > deficiencies should greatly influence any effort to standardise such > an extension - specially if better libraries are available (argh! they > have license clashes and eclipse IP issues... still not a problem for > this group). > My point was I see little value in having a compression extension which starts the compression state afresh with every frame, as on real-world applications this gives poor performance. -- John A. Tamplin Software Engineer (GWT), Google --00151750ec70082b4f04a2522e75 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, May 2, 2011 at 5:59 PM, Greg Wilkins <gregw@intalio.com> wrote:
> See the compression experiments I posted last May - = if you don't maintain
> compression state between frames, then you lose most of the benefit of=
> compression. =C2=A0Being able to send uncompressed frames cheaply avoi= ds the cost
> of this, but doesn't fix not getting the benefit of compression. > Unfortunately, Java's default deflate implementation doesn't a= llow this, as
> you need to flush out the compressed bits at the end of a frame (thoug= h you
> can play tricks with changing the compression level to 0 and back, but= that
> seems non-portable). =C2=A0I believe you can do it with jzlib though.<= br>
Yes, the java std lib does appear lacking in this regard. =C2=A0As I = said,
I'm just using it for prototyping and don't think that it's
deficiencies should greatly influence any effort to standardise such
an extension - specially if better libraries are available (argh! they
have license clashes and eclipse IP issues... still not a problem for
this group).

My point was I see little= value in having a compression extension which starts the compression state= afresh with every frame, as on real-world applications this gives poor per= formance.

--
John A. Tamplin
Software Engineer (GWT), Google
--00151750ec70082b4f04a2522e75-- From gregw@intalio.com Mon May 2 15:52:56 2011 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 70762E06BD for ; Mon, 2 May 2011 15:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.924 X-Spam-Level: X-Spam-Status: No, score=-2.924 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NekUwEYoXGU4 for ; Mon, 2 May 2011 15:52:56 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id D3D55E0697 for ; Mon, 2 May 2011 15:52:55 -0700 (PDT) Received: by qwc23 with SMTP id 23so3825511qwc.31 for ; Mon, 02 May 2011 15:52:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.33.76 with SMTP id g12mr6511469qad.376.1304376774893; Mon, 02 May 2011 15:52:54 -0700 (PDT) Received: by 10.229.73.147 with HTTP; Mon, 2 May 2011 15:52:54 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> Date: Tue, 3 May 2011 08:52:54 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] Payload only compression extension, again 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, 02 May 2011 22:52:56 -0000 On 3 May 2011 08:02, John Tamplin wrote: > My point was I see little value in having a compression extension which > starts the compression state afresh with every frame, as on real-world > applications this gives poor performance. +1 My extension is more about prototyping plugable extension that work well in a chain of extension, plus handling the negotiation and per frame issues. I'll follow the lead of the others/experience on the exact algorithms to use (even though I think that is going to cause me endless headaches with mismatched licenses and getting IP audits done at eclipse :( cheers From buskanaka@gmail.com Mon May 2 16:22:57 2011 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 213B0E07E5 for ; Mon, 2 May 2011 16:22:57 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEUXWhAeSC8B for ; Mon, 2 May 2011 16:22:48 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38746E0676 for ; Mon, 2 May 2011 16:22:48 -0700 (PDT) Received: by ewy19 with SMTP id 19so2303760ewy.31 for ; Mon, 02 May 2011 16:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=i2j63FfI7Gox7l8PYZgpgybHUrQM9eoop6QzLajdjGE=; b=c2KKmbBqVhMcFjsxuPrNLHfOf5FESuu0pNazWL9zej4c63Ii6BIwnnpjvItjYG+DXw WYJ71yPX6mtCYtY+xbBWUjw35wMnuY/2fSudk52wxq465CD7Ew5s8DOPLLM0GlVeDodc BP01P031iTItQeig0pTgkA3j8POgbT1mnIZeU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=tg3r19SlUxfteJhVCgsSqVun2dYrWpR1IJ8ieWFBUoQLBDWq7zmyz4pVU5N16qts2z FW7PFrnQ3WQZnKBMpG4FXHShiYW3bQ/7hfMhvJAEYSiTMRMKC1Xsd0ttpljpUF9aAv7w ZtL1kYzNMzfrbIC2vBnzxh5GVh2McjMqnrXZU= Received: by 10.14.12.206 with SMTP id 54mr3698115eez.214.1304378567252; Mon, 02 May 2011 16:22:47 -0700 (PDT) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.14.53.15 with HTTP; Mon, 2 May 2011 16:22:27 -0700 (PDT) From: Joel Martin Date: Mon, 2 May 2011 18:22:27 -0500 X-Google-Sender-Auth: PFwcQJxS67tq90esG1sOHMuktbg Message-ID: To: hybi Content-Type: multipart/alternative; boundary=001636d34261275a8f04a2534d91 Subject: [hybi] Build of web-socket-js with websockets -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, 02 May 2011 23:22:57 -0000 --001636d34261275a8f04a2534d91 Content-Type: text/plain; charset=ISO-8859-1 The web-socket-js project is a WebSockets polyfill/emulator implemented in Flash. I hacked on web-socket-js today to add preliminary support for 07: https://github.com/kanaka/web-socket-js For reference, the upstream site: https://github.com/gimite/web-socket-js (implements Hixie-76) Regards, Joel Martin (kanaka) --001636d34261275a8f04a2534d91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The web-socket-js project is a=A0WebSockets polyfill/emulator implemen= ted in Flash.

I hacked on web-socket-js today to add= preliminary support for 07:
https://github.com/kana= ka/web-socket-js

For reference, the upstream site: <= a href=3D"https://github.com/gimite/web-socket-js">https://github.com/gimit= e/web-socket-js=A0(implements Hixie-76)

Regards,

Joel Martin (kanaka)
--001636d34261275a8f04a2534d91-- From gregw@intalio.com Mon May 2 18:02:23 2011 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 35142E072D for ; Mon, 2 May 2011 18:02:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kxbm9pWd4hRn for ; Mon, 2 May 2011 18:02:22 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7E245E0780 for ; Mon, 2 May 2011 18:02:22 -0700 (PDT) Received: by vws12 with SMTP id 12so5434435vws.31 for ; Mon, 02 May 2011 18:02:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.176.1 with SMTP id ce1mr1049593vdc.63.1304384541589; Mon, 02 May 2011 18:02:21 -0700 (PDT) Received: by 10.52.181.34 with HTTP; Mon, 2 May 2011 18:02:21 -0700 (PDT) In-Reply-To: <4DB7D872.3060601@warmcat.com> References: <4DB586AC.90800@warmcat.com> <4DB7C57E.8080601@warmcat.com> <4DB7D872.3060601@warmcat.com> Date: Tue, 3 May 2011 11:02:21 +1000 Message-ID: From: Greg Wilkins To: Andy Green Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] Draft websocket interoperability tests X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2011 01:02:23 -0000 I'm currently reworking the tests that I have in Jetty in terms of both protocols and extension. So far I have two protocols: + echo - echo's all binary and text messages + broadcast - broadcasts all binary and text messages to all other broadcast connections I also have the following extensions + identity - This is a NOP extension that does not change the frames at all, but does accept any extension parameters. It can be used to test extension negotiation and ordering. + fragment - This fragments the messages sent by the server and is controlled by two parameters: maxLength, which limits the size of any frame sent; minFragments, which sets a lower limit of the number of fragments sent and will send small or even empty fragments to achieve the minimal fragment limit. cheers From henrikn@microsoft.com Mon May 9 10:04:57 2011 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 C60B4E06C3 for ; Mon, 9 May 2011 10:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+MES210R8A9 for ; Mon, 9 May 2011 10:04:57 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 84E29E088C for ; Mon, 9 May 2011 10:04:51 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 10:04:51 -0700 Received: from TK5EX14MBXC218.redmond.corp.microsoft.com ([169.254.8.192]) by TK5EX14HUBC103.redmond.corp.microsoft.com ([157.54.86.9]) with mapi id 14.01.0289.008; Mon, 9 May 2011 10:04:50 -0700 From: Henrik Frystyk Nielsen To: "Hybi (hybi@ietf.org)" Thread-Topic: Editorial issue: Ignoring rather than failing on URI fragments Thread-Index: AcwOaxsxwqjsFB8DTVWb72nxpviA9g== Date: Mon, 9 May 2011 17:04:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] Editorial issue: Ignoring rather than failing on URI fragments 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, 09 May 2011 17:04:57 -0000 Regarding handling URI fragments, section 3.1 [0] of the 07 draft states in= point 4 that=20 4. If /uri/ has a component, then fail this algorithm. However, the "XMLHttpRequest, W3C Candidate Recommendation 3 August 2010" s= pecification states that the caller is supposed to DROP the fragment (i.e. = to ignore, not to fail):=20 1. Let url be a URL.=20 2. Let URL character encoding of url be UTF-8.=20 3. Resolve url relative to the XMLHttpRequest base URL. If the algorith= m returns an error raise a SYNTAX_ERR exception and terminate these steps.= =20 4. Drop from url.=20 This is also the correct behavior for HTTP clients and consistent with URI = semantics.=20 I propose that the text be changed to the following: 4. If /uri/ has a component, then drop it. Thanks, Henrik [0] http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#sect= ion-3.1 [1] http://www.w3.org/TR/XMLHttpRequest/ From julian.reschke@gmx.de Mon May 9 10:38:41 2011 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 7217DE091A for ; Mon, 9 May 2011 10:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.131 X-Spam-Level: X-Spam-Status: No, score=-105.131 tagged_above=-999 required=5 tests=[AWL=-2.532, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgb8TQCUClrc for ; Mon, 9 May 2011 10:38:40 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 16678E06EC for ; Mon, 9 May 2011 10:38:35 -0700 (PDT) Received: (qmail invoked by alias); 09 May 2011 17:31:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.142]) [217.91.35.233] by mail.gmx.net (mp017) with SMTP; 09 May 2011 19:31:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+kEDwiHb2ktFlsjUJaIcioEMONSIDA4LhRdlTVDs H5u+89y9wx1w+Y Message-ID: <4DC82506.1000306@gmx.de> Date: Mon, 09 May 2011 19:31:50 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Henrik Frystyk Nielsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Hybi \(hybi@ietf.org\)" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments 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, 09 May 2011 17:38:41 -0000 Again, the whole section should go. URIs are URIs and should be handled like URIs :-). On 09.05.2011 19:04, Henrik Frystyk Nielsen wrote: > Regarding handling URI fragments, section 3.1 [0] of the 07 draft states in point 4 that > > 4. If /uri/ has a component, then fail this algorithm. > > However, the "XMLHttpRequest, W3C Candidate Recommendation 3 August 2010" specification states that the caller is supposed to DROP the fragment (i.e. to ignore, not to fail): > > 1. Let url be a URL. > 2. Let URL character encoding of url be UTF-8. > 3. Resolve url relative to the XMLHttpRequest base URL. If the algorithm returns an error raise a SYNTAX_ERR exception and terminate these steps. > 4. Drop from url. > > This is also the correct behavior for HTTP clients and consistent with URI semantics. > > I propose that the text be changed to the following: > > 4. If /uri/ has a component, then drop it. > > Thanks, > > Henrik > > [0] http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#section-3.1 > [1] http://www.w3.org/TR/XMLHttpRequest/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From henrikn@microsoft.com Mon May 9 14:58:26 2011 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 5F4BFE0723 for ; Mon, 9 May 2011 14:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePFQx3-ICVfT for ; Mon, 9 May 2011 14:58:25 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 5B251E06BE for ; Mon, 9 May 2011 14:58:25 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 14:56:16 -0700 Received: from TK5EX14MBXC218.redmond.corp.microsoft.com ([169.254.8.192]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0289.008; Mon, 9 May 2011 14:56:15 -0700 From: Henrik Frystyk Nielsen To: Julian Reschke Thread-Topic: [hybi] Editorial issue: Ignoring rather than failing on URI fragments Thread-Index: AQHMDm79YLslDq5I0U6XYKZKtWZtr5SFCl8Q Date: Mon, 9 May 2011 21:56:15 +0000 Message-ID: References: <4DC82506.1000306@gmx.de> In-Reply-To: <4DC82506.1000306@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Hybi \(hybi@ietf.org\)" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments 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, 09 May 2011 21:58:26 -0000 I love it! I was trying to keep the suggestion small but I like this much b= etter. Henrik -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Monday, May 09, 2011 10:32 AM To: Henrik Frystyk Nielsen Cc: Hybi (hybi@ietf.org) Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fr= agments Again, the whole section should go. URIs are URIs and should be handled like URIs = :-). On 09.05.2011 19:04, Henrik Frystyk Nielsen wrote: > Regarding handling URI fragments, section 3.1 [0] of the 07 draft=20 > states in point 4 that > > 4. If /uri/ has a component, then fail this algorithm. > > However, the "XMLHttpRequest, W3C Candidate Recommendation 3 August 2010"= specification states that the caller is supposed to DROP the fragment (i.e= . to ignore, not to fail): > > 1. Let url be a URL. > 2. Let URL character encoding of url be UTF-8. > 3. Resolve url relative to the XMLHttpRequest base URL. If the algor= ithm returns an error raise a SYNTAX_ERR exception and terminate these step= s. > 4. Drop from url. > > This is also the correct behavior for HTTP clients and consistent with UR= I semantics. > > I propose that the text be changed to the following: > > 4. If /uri/ has a component, then drop it. > > Thanks, > > Henrik > > [0]=20 > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-07#sec > tion-3.1 [1] http://www.w3.org/TR/XMLHttpRequest/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Mon May 9 17:51:39 2011 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 AA1EDE07AE for ; Mon, 9 May 2011 17:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.929 X-Spam-Level: X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv2C4pPiR13L for ; Mon, 9 May 2011 17:51:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 85135E06FE for ; Mon, 9 May 2011 17:51:38 -0700 (PDT) Received: by vxg33 with SMTP id 33so707200vxg.31 for ; Mon, 09 May 2011 17:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.231 with SMTP id ff7mr644120vdc.103.1304988336341; Mon, 09 May 2011 17:45:36 -0700 (PDT) Received: by 10.52.111.7 with HTTP; Mon, 9 May 2011 17:45:36 -0700 (PDT) In-Reply-To: <4DC82506.1000306@gmx.de> References: <4DC82506.1000306@gmx.de> Date: Tue, 10 May 2011 10:45:36 +1000 Message-ID: From: Greg Wilkins To: ifette@google.com Content-Type: text/plain; charset=ISO-8859-1 Cc: "Hybi \(hybi@ietf.org\)" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 00:51:39 -0000 On 10 May 2011 03:31, Julian Reschke wrote: > Again, > > the whole section should go. URIs are URIs and should be handled like URIs > :-). Ian, This suggestion has been made many times now and widely supported each time. Has anybody made a good argument to keep URI parsing algorithms in the document? If not can we please just drop this section and get off this particular hamster wheel. cheers From macox@microsoft.com Mon May 9 18:25:09 2011 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 16F93E09AC for ; Mon, 9 May 2011 18:25:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XalHaZSEqLEI for ; Mon, 9 May 2011 18:25:08 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 45D5CE09A8 for ; Mon, 9 May 2011 18:25:08 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 9 May 2011 18:21:03 -0700 Received: from TK5EX14MBXC202.redmond.corp.microsoft.com ([169.254.2.126]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0289.008; Mon, 9 May 2011 18:21:03 -0700 From: Matthew Cox To: "hybi@ietf.org" Thread-Topic: Comments on Section 5.1 Req #2 and Sec-WebSocket-Protocol Thread-Index: AcwOsDAGPK8tiBNCTd2Mq9uWyo+zSg== Date: Tue, 10 May 2011 01:21:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.79] Content-Type: multipart/alternative; boundary="_000_FFF1050961D037449853E9383C50E9576228ACF7TK5EX14MBXC202r_" MIME-Version: 1.0 Subject: [hybi] Comments on Section 5.1 Req #2 and Sec-WebSocket-Protocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 01:25:09 -0000 --_000_FFF1050961D037449853E9383C50E9576228ACF7TK5EX14MBXC202r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 5.1 req #2 specifies that no more than one connection can be in CON= NECTING state to the same IP address/same host. I think that this should b= e removed, or at the very least the language be changed to not require it. = This is an artificial limit to address a JavaScript concern that would be = better addressed by the calling application/protocol since a client may not= have the same concerns as JavaScript. Sec-WebSocket-Protocol - Can it be added to the text that the protocols are= in preferred order in Section 5.1 like it is in Section 5.2? Specifically= in the requirements for the handshake #10 If present, this value indicates the subprotocol(s)the client wishe= s to speak. Could be changed to If present, this value indicates the subprotocol(s)the client wishe= s to speak ordered by preference. Thanks, Matthew --_000_FFF1050961D037449853E9383C50E9576228ACF7TK5EX14MBXC202r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 5.1 req #2 spec= ifies that no more than one connection can be in CONNECTING state to the sa= me IP address/same host.  I think that this should be removed, or at t= he very least the language be changed to not require it.  This is an artificial limit to address a JavaScript = concern that would be better addressed by the calling application/protocol = since a client may not have the same concerns as JavaScript.

 

Sec-WebSocket-Protocol = - Can it be added to the text that the protocols are in preferred order in = Section 5.1 like it is in Section 5.2?  Specifically in the requiremen= ts for the handshake #10

 

     = ;   If present, this value indicates the subprotocol(s)the client= wishes to speak.

 

Could be changed to

 

     = ;   If present, this value indicates the subprotocol(s)the client= wishes to speak ordered by preference.

 

Thanks,

 

Matthew

--_000_FFF1050961D037449853E9383C50E9576228ACF7TK5EX14MBXC202r_-- From tyoshino@google.com Tue May 10 00:53:09 2011 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 8014AE0864 for ; Tue, 10 May 2011 00:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRe6i9cydqtw for ; Tue, 10 May 2011 00:53:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 74ECBE0861 for ; Tue, 10 May 2011 00:53:07 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p4A7VDmS002235 for ; Tue, 10 May 2011 00:31:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305012674; bh=DKcR0dnAnfaz8J6dm+YLVJtf2Vg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=D6B3tuqD06dwKMsiy5mA2yFKE6Fnk276m62zunRwMoaekzYfdho8RGpCOXsdAmsBT x7yb2S4EjiJJ77wyPGyqw== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by hpaq11.eem.corp.google.com with ESMTP id p4A7VBdc023943 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 10 May 2011 00:31:12 -0700 Received: by gyh4 with SMTP id 4so2417656gyh.12 for ; Tue, 10 May 2011 00:31:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=i25wbcRfiFt0nHnsu/jcMv6SLaFbRIyQL/Y00e0m5Ow=; b=x8mO9YjSTDABhDqqymdMZCkz/C0iDivtKUxnw03ZcGAD3cL2a3aLgEGZLqGIkK9d4j kD0QzYooJ4nQ1YsEcDbw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=aPX389GEtz7GMgIGLVk4JyHcMiQ44fuVZnatzm8W609JgdMvHDUCNnh8Vdd591/5sV HNplWySfe2gLBNAU4xEQ== Received: by 10.91.66.39 with SMTP id t39mr4079470agk.28.1305012671236; Tue, 10 May 2011 00:31:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.53.15 with HTTP; Tue, 10 May 2011 00:30:51 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: Takeshi Yoshino Date: Tue, 10 May 2011 16:30:51 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=0016e640cc7cb249e404a2e6f0ec X-System-Of-Record: true Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] Payload only compression extension, again X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 07:53:09 -0000 --0016e640cc7cb249e404a2e6f0ec Content-Type: text/plain; charset=ISO-8859-1 I can change my proposal to accept last blocks (blocks with BFINAL=1) to allow use of java.util.zip. In my proposal, receiver expects 3 header bits 0b000 (and padding to byte boundary) on the tail of the application data portion. Not to complicate receiver logic much, I'd make change like this - sender: send( + "\x00") - receiver: inflate(received_data + "\x00\x00\xff\xff"). every time inflater encounters end of stream (the last octet of a last block), renew inflater and keep decompressing the remainder. or - sender: send() - receiver: inflate(received_data). every time inflater encounters end of stream, renew inflater and keep decompressing the remainder. if the end of received_data is not end of stream, inflate("\x00\x00\xff\xff"). Either algorithm works for Z_SYNC_FLUSH-ed and "\x00\x00\xff\xff" stripped frame, too. Takeshi On Tue, May 3, 2011 at 07:52, Greg Wilkins wrote: > On 3 May 2011 08:02, John Tamplin wrote: > > My point was I see little value in having a compression extension which > > starts the compression state afresh with every frame, as on real-world > > applications this gives poor performance. > > +1 > > My extension is more about prototyping plugable extension that work > well in a chain of extension, plus handling the negotiation and per > frame issues. I'll follow the lead of the others/experience on the > exact algorithms to use (even though I think that is going to cause me > endless headaches with mismatched licenses and getting IP audits done > at eclipse :( > > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016e640cc7cb249e404a2e6f0ec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I can change my proposal to accept last blocks (blocks with=A0BFINAL=3D1) t= o allow use of java.util.zip. In my proposal, receiver expects 3 header bit= s 0b000 (and padding to byte boundary) on the tail of the application data = portion.=A0Not to complicate receiver logic much, I'd make change like = this
- sender: send(<compressed data flushed with Z_FINISH> + "\x00&q= uot;)
- receiver: inflate(received_data + "\x00\x00\xff\xff&= quot;). every time inflater encounters end of stream (the last octet of a l= ast block), renew inflater and keep decompressing the remainder.
or
- sender: send(<compressed data flushed with= Z_FINISH>)
- receiver: inflate(received_data).=A0every time i= nflater encounters end of stream, renew inflater and keep decompressing the= remainder. if the end of received_data is not end of stream, inflate("= ;\x00\x00\xff\xff").

Either algorithm works for Z_SYNC_FLUSH-ed and "\x= 00\x00\xff\xff" stripped frame, too.

Takeshi<= br>

On Tue, May 3, 2011 at 07:52, Greg Wilki= ns <gregw@intalio= .com> wrote:
On 3 May 2011 08:02, John Tamplin <jat@google.com> wrote:
> My point was I see little value in having a compression extension whic= h
> starts the compression state afresh with every frame, as on real-world=
> applications this gives poor performance.

+1

My extension is more about prototyping plugable extension that work
well in a chain of extension, plus handling the negotiation and per
frame issues. =A0 =A0I'll follow the lead of the others/experience on t= he
exact algorithms to use (even though I think that is going to cause me
endless headaches with mismatched licenses and getting IP audits done
at eclipse :(

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

--0016e640cc7cb249e404a2e6f0ec-- From simonp@opera.com Tue May 10 01:26:14 2011 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 04BE7E0675 for ; Tue, 10 May 2011 01:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooIGzHaDfL2M for ; Tue, 10 May 2011 01:26:13 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2BDB4E0701 for ; Tue, 10 May 2011 01:26:12 -0700 (PDT) Received: from simon-pieterss-macbook.local (c-039ee355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.158.3]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4A8Q9Rs030088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 10 May 2011 08:26:10 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: ifette@google.com, "Greg Wilkins" References: <4DC82506.1000306@gmx.de> Date: Tue, 10 May 2011 10:26:08 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.10 (MacIntel) Cc: "Hybi \(hybi@ietf.org\)" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:26:14 -0000 On Tue, 10 May 2011 02:45:36 +0200, Greg Wilkins wrote: > On 10 May 2011 03:31, Julian Reschke wrote: >> Again, >> >> the whole section should go. URIs are URIs and should be handled like >> URIs >> :-). > > Ian, > > This suggestion has been made many times now and widely supported each > time. > Has anybody made a good argument to keep URI parsing algorithms in the > document? If not can we please just drop this section and get off > this particular hamster wheel. If the section is dropped, it would just move the steps into the other sections that use the output of the algorithm. AFAICT it doesn't redefine how to parse URIs. Without this section the "establish a websocket connection" would need to contain the same logic to figure out which host and port to open a connection to, whether to use TLS or not, and so forth. That seems like an editorial matter that I would leave to the editor to decide which is easier to spec. Whether to fail to open a connection or not when the is present is not editorial, however. (Either way is fine for me.) -- Simon Pieters Opera Software From julian.reschke@gmx.de Tue May 10 01:38:01 2011 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 41995E073E for ; Tue, 10 May 2011 01:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.52 X-Spam-Level: X-Spam-Status: No, score=-104.52 tagged_above=-999 required=5 tests=[AWL=-1.921, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zVDZQmLOYV0 for ; Tue, 10 May 2011 01:38:00 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5AC96E0708 for ; Tue, 10 May 2011 01:37:59 -0700 (PDT) Received: (qmail invoked by alias); 10 May 2011 08:37:57 -0000 Received: from p508FCFB0.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.207.176] by mail.gmx.net (mp062) with SMTP; 10 May 2011 10:37:57 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+T79Q6SKiTg8TQr+LFWKcldWwEfwddaUjzm9FkOp gdfP97oHshwuLc Message-ID: <4DC8F962.7080105@gmx.de> Date: Tue, 10 May 2011 10:37:54 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Simon Pieters References: <4DC82506.1000306@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Hybi \(hybi@ietf.org\)" , Greg Wilkins Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 08:38:01 -0000 On 10.05.2011 10:26, Simon Pieters wrote: > On Tue, 10 May 2011 02:45:36 +0200, Greg Wilkins wrote: > >> On 10 May 2011 03:31, Julian Reschke wrote: >>> Again, >>> >>> the whole section should go. URIs are URIs and should be handled like >>> URIs >>> :-). >> >> Ian, >> >> This suggestion has been made many times now and widely supported each >> time. >> Has anybody made a good argument to keep URI parsing algorithms in the >> document? If not can we please just drop this section and get off >> this particular hamster wheel. > > If the section is dropped, it would just move the steps into the other > sections that use the output of the algorithm. AFAICT it doesn't > redefine how to parse URIs. Without this section the "establish a > websocket connection" would need to contain the same logic to figure out > which host and port to open a connection to, whether to use TLS or not, > and so forth. That seems like an editorial matter that I would leave to > the editor to decide which is easier to spec. The algorithm can be replaced by a short paragraph that defines the ABNF for "ws" and "wss" (optimally in terms of RFC 3986) and defines the default port numbers. > Whether to fail to open a connection or not when the is > present is not editorial, however. (Either way is fine for me.) Best regards, Julian From henrikn@microsoft.com Tue May 10 10:46:26 2011 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 70260E066E for ; Tue, 10 May 2011 10:46:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzgVw-RqeVBD for ; Tue, 10 May 2011 10:46:26 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id EB4C8E06FE for ; Tue, 10 May 2011 10:46:25 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 May 2011 10:46:25 -0700 Received: from TK5EX14MBXC218.redmond.corp.microsoft.com ([169.254.8.192]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0289.008; Tue, 10 May 2011 10:46:25 -0700 From: Henrik Frystyk Nielsen To: Julian Reschke , Simon Pieters Thread-Topic: [hybi] Editorial issue: Ignoring rather than failing on URI fragments Thread-Index: AQHMDu2WbYr1SlNXiEqsC+cL26NASZSGVZsA Date: Tue, 10 May 2011 17:46:23 +0000 Message-ID: References: <4DC82506.1000306@gmx.de> <4DC8F962.7080105@gmx.de> In-Reply-To: <4DC8F962.7080105@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Hybi \(hybi@ietf.org\)" , Greg Wilkins Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 17:46:26 -0000 Julian, Would you be willing to provide a proposal for such a paragraph? It may mak= e it easier to discuss. > The algorithm can be replaced by a short paragraph that defines the ABNF = for > "ws" and "wss" (optimally in terms of RFC 3986) and defines the default p= ort > numbers. Thanks, Henrik From julian.reschke@gmx.de Tue May 10 11:17:46 2011 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 686F1E06FB for ; Tue, 10 May 2011 11:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.477 X-Spam-Level: X-Spam-Status: No, score=-104.477 tagged_above=-999 required=5 tests=[AWL=-1.878, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tcUZTVUrFidq for ; Tue, 10 May 2011 11:17:45 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id B9EB5E0698 for ; Tue, 10 May 2011 11:17:44 -0700 (PDT) Received: (qmail invoked by alias); 10 May 2011 18:17:41 -0000 Received: from p508FCFB0.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.207.176] by mail.gmx.net (mp042) with SMTP; 10 May 2011 20:17:41 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18cvNtIqDkcQLBr+oTggYFpGxcARtJfviIhSDadPP Z0s6hMJHO4mK1g Message-ID: <4DC9813C.7040005@gmx.de> Date: Tue, 10 May 2011 20:17:32 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Henrik Frystyk Nielsen References: <4DC82506.1000306@gmx.de> <4DC8F962.7080105@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Hybi \(hybi@ietf.org\)" , Greg Wilkins Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 18:17:46 -0000 On 10.05.2011 19:46, Henrik Frystyk Nielsen wrote: > Julian, > > Would you be willing to provide a proposal for such a paragraph? It may make it easier to discuss. > ... Yes. I'll try to get this done tomorrow. Best regards, Julian From piotrku@microsoft.com Tue May 10 11:54:12 2011 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 C6EBFE077A for ; Tue, 10 May 2011 11:54:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfNJJLpLlXnp for ; Tue, 10 May 2011 11:54:12 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 400ADE074F for ; Tue, 10 May 2011 11:54:12 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 10 May 2011 11:53:09 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.28]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0289.008; Tue, 10 May 2011 11:53:08 -0700 From: Piotr Kulaga To: "Hybi (hybi@ietf.org)" Thread-Topic: Close status - reserved reange clarification Thread-Index: AcwPQ1ntlSqALLZHRNG1eNlTpdGRqQ== Date: Tue, 10 May 2011 18:53:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.21] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] Close status - reserved reange clarification X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2011 18:54:12 -0000 I would like to clarify wording around reserved status code ranges (7.4.2).= Right now we have: Status codes in the range 0-999 are not used. My proposal: Status codes in the range 0-999 MUST NOT be used. Rationale: If status codes in 0-999 range cannot appear on the wire, they may potentia= lly be used by a framework/application to carry additional information (lik= e that the status code is missing). Thanks, Piotr From julian.reschke@gmx.de Wed May 11 06:09:16 2011 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 8810AE0746 for ; Wed, 11 May 2011 06:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84US0nlgBCpN for ; Wed, 11 May 2011 06:09:16 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 945D5E06D1 for ; Wed, 11 May 2011 06:09:14 -0700 (PDT) Received: (qmail invoked by alias); 11 May 2011 13:09:13 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.142]) [217.91.35.233] by mail.gmx.net (mp056) with SMTP; 11 May 2011 15:09:13 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/9NUcAbOv9gVeD60RfnSrnrGyYUMRigBR468jCxU 3m+nAPMUF2foIf Message-ID: <4DCA8A72.2070107@gmx.de> Date: Wed, 11 May 2011 15:09:06 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Henrik Frystyk Nielsen References: <4DC82506.1000306@gmx.de> <4DC8F962.7080105@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Hybi \(hybi@ietf.org\)" , Greg Wilkins Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 13:09:16 -0000 On 10.05.2011 19:46, Henrik Frystyk Nielsen wrote: > Julian, > > Would you be willing to provide a proposal for such a paragraph? It may make it easier to discuss. > >> The algorithm can be replaced by a short paragraph that defines the ABNF for >> "ws" and "wss" (optimally in terms of RFC 3986) and defines the default port >> numbers. > > Thanks, > > Henrik I was thinking about something like: 3. WebSocket URIs This specification defines two URI schemes, using the ABNF syntax defined in [RFC5234], and terminology and ABNF productions defined by the URI specification ([RFC3986]). ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] wss-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] host = port = path = query = The port component is OPTIONAL; the default for "ws" is port 80, and the default for "wss" is port 443. The URI is called "secure" if the scheme component matches "wss" case-insensitively. The "resource-name" can be constructed by concatenating: - "/" if the path component is empty, - the path component - "?" if the query component is non-empty, and - the query component OPEN: unsure about the case-normalization for "host", what is it fore OPEN: unsure about the IDNA requirements OPEN: 3.2 and 3.3 seem to just state the obvious From ibc@aliax.net Wed May 11 09:18:06 2011 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 29D81E0819 for ; Wed, 11 May 2011 09:18:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWnMmKSGhNgR for ; Wed, 11 May 2011 09:18:05 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 10A47E06FA for ; Wed, 11 May 2011 09:17:51 -0700 (PDT) Received: by qyk7 with SMTP id 7so417645qyk.10 for ; Wed, 11 May 2011 09:17:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.155 with SMTP id l27mr7191213qck.47.1305130671326; Wed, 11 May 2011 09:17:51 -0700 (PDT) Received: by 10.229.86.203 with HTTP; Wed, 11 May 2011 09:17:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 11 May 2011 18:17:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Matthew Cox Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Comments on Section 5.1 Req #2 and Sec-WebSocket-Protocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 16:18:06 -0000 2011/5/10 Matthew Cox : > Section 5.1 req #2 specifies that no more than one connection can be in > CONNECTING state to the same IP address/same host.=C2=A0 I think that thi= s should > be removed, or at the very least the language be changed to not require i= t. > This is an artificial limit to address a JavaScript concern that would be > better addressed by the calling application/protocol since a client may n= ot > have the same concerns as JavaScript. I'm agree. Which is the real reason for such artificial requeriment? If that is the behavior of JavaScript clients in webbrowsers, please, don't assume all the WebSocket clients are JavaScript. --=20 I=C3=B1aki Baz Castillo From derhoermi@gmx.net Wed May 11 18:08:21 2011 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 5AACCE0838 for ; Wed, 11 May 2011 18:08:21 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWdcNNXkbMwv for ; Wed, 11 May 2011 18:08:20 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 62126E087B for ; Wed, 11 May 2011 18:07:24 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2011 01:07:21 -0000 Received: from dslb-094-223-189-018.pools.arcor-ip.net (EHLO HIVE) [94.223.189.18] by mail.gmx.net (mp022) with SMTP; 12 May 2011 03:07:21 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX18fyUcX/KsfLR0e78fhpXAtZd2BRmoKp7yY2hIuyk LnPWIQxa9zExCT From: Bjoern Hoehrmann To: Henrik Frystyk Nielsen Date: Thu, 12 May 2011 03:07:23 +0200 Message-ID: References: In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "Hybi \(hybi@ietf.org\)" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments 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, 12 May 2011 01:08:21 -0000 * Henrik Frystyk Nielsen wrote: >Regarding handling URI fragments, section 3.1 [0] of the 07 draft states >in point 4 that > > 4. If /uri/ has a component, then fail this algorithm. > >However, the "XMLHttpRequest, W3C Candidate Recommendation 3 August >2010" specification states that the caller is supposed to DROP the >fragment (i.e. to ignore, not to fail): That is essentially an error in the XMLHttpRequest specification. I do not recall whether we discussed this in detail back in the day, but it is in any case likely though that different behavior would trigger compatibility problems, so that behavior got specified. It is a design error because there is no reason to specify a fragment identifier and then have it ignored, beyond perhaps convenience in that users of the interface do not need to pay attention to stripping frag- ments from the resource identifier. Unlike the HTTP scheme the Websocket scheme does not map to something that has media type information; since the interpretation of fragment identifiers depends on the underlying media type, it is essentially an error to ever create "ws" identifiers with fragment identifiers. More importantly, if fragment identifiers that would otherwise be ig- nored trigger errors, then it is possible to associate meaning to the fragment identifiers later. There are efforts to do just that, e.g., http://www.w3.org/TR/2011/WD-media-frags-20110317/ does it, but making that work with XMLHttpRequest in some natural manner is complicated as XMLHttpRequest ignores the fragment. So, I would be rather sceptical that ignoring the fragment identifier is the best approach for Websocket. That however is a concern for any Websocket API, not so much a concern for the on-the-wire protocol, so this working group's specification should say that handling of fragment identifiers is out of scope and needs to be addressed by higher level specifications. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From gregw@intalio.com Wed May 11 19:10:13 2011 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 8B1D3E08B0 for ; Wed, 11 May 2011 19:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GISYL68Hd2Uv for ; Wed, 11 May 2011 19:10:13 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D52B0E068D for ; Wed, 11 May 2011 19:10:12 -0700 (PDT) Received: by vxg33 with SMTP id 33so958636vxg.31 for ; Wed, 11 May 2011 19:10:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.0.236 with SMTP id 12mr2328410vdh.223.1305166211990; Wed, 11 May 2011 19:10:11 -0700 (PDT) Received: by 10.52.111.7 with HTTP; Wed, 11 May 2011 19:10:11 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 May 2011 12:10:11 +1000 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Comments on Section 5.1 Req #2 and Sec-WebSocket-Protocol 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, 12 May 2011 02:10:13 -0000 On 12 May 2011 02:17, I=F1aki Baz Castillo wrote: > 2011/5/10 Matthew Cox : >> Section 5.1 req #2 specifies that no more than one connection can be in >> CONNECTING state to the same IP address/same host.=A0 I think that this = should >> be removed, or at the very least the language be changed to not require = it. >> This is an artificial limit to address a JavaScript concern that would b= e >> better addressed by the calling application/protocol since a client may = not >> have the same concerns as JavaScript. > > I'm agree. Which is the real reason for such artificial requeriment? > If that is the behavior of JavaScript clients in webbrowsers, please, > don't assume all the WebSocket clients are JavaScript. It is there to prevent browsers from being used as very simple denial of service attack generators. Currently there is no limit on the number of ws connections that a browser can create, so the potential is still there for an attacker to create many many websockets to a host, but the idea of only allowing a single connection outstanding is that will at least slow the attack down and give the server a chance to reject connections. I think this is pretty weak protection, as intermediaries will often mask the source of the connection, so a server cannot tell if it is one attacker or just a traffic spike from many browsers. The real solution is to have a MUX extensions that browsers will use so that a single browser will always only have a single connection per host. cheers From julian.reschke@gmx.de Thu May 12 00:34:18 2011 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 52025E0724 for ; Thu, 12 May 2011 00:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.932 X-Spam-Level: X-Spam-Status: No, score=-103.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2+DLzoS0F0P for ; Thu, 12 May 2011 00:34:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 09D00E0700 for ; Thu, 12 May 2011 00:34:16 -0700 (PDT) Received: (qmail invoked by alias); 12 May 2011 07:34:14 -0000 Received: from p508FABCE.dip.t-dialin.net (EHLO [192.168.178.33]) [80.143.171.206] by mail.gmx.net (mp022) with SMTP; 12 May 2011 09:34:14 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19vepBATdRvNjoo9JV0WJ1PrnKTqbEXl/qfjfAusO u2DOfiYMHsGpaf Message-ID: <4DCB8D70.4010509@gmx.de> Date: Thu, 12 May 2011 09:34:08 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Bjoern Hoehrmann References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "Hybi \(hybi@ietf.org\)" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments 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, 12 May 2011 07:34:18 -0000 On 12.05.2011 03:07, Bjoern Hoehrmann wrote: > ... > Unlike the HTTP scheme the Websocket scheme does not map to something > that has media type information; since the interpretation of fragment > identifiers depends on the underlying media type, it is essentially an > error to ever create "ws" identifiers with fragment identifiers. > > More importantly, if fragment identifiers that would otherwise be ig- > nored trigger errors, then it is possible to associate meaning to the > fragment identifiers later. There are efforts to do just that, e.g., > http://www.w3.org/TR/2011/WD-media-frags-20110317/ does it, but making > that work with XMLHttpRequest in some natural manner is complicated as > XMLHttpRequest ignores the fragment. > > So, I would be rather sceptical that ignoring the fragment identifier > is the best approach for Websocket. That however is a concern for any > Websocket API, not so much a concern for the on-the-wire protocol, so > this working group's specification should say that handling of fragment > identifiers is out of scope and needs to be addressed by higher level > specifications. > ... What we should make clear is that although fragment identifiers currently do not make sense with websockets URIs, this does *not* affect the syntax. So if you need a literal "#" in a WS URI, you will have to percent-escape it. Best regards, Julian From duerst@it.aoyama.ac.jp Thu May 12 03:06:08 2011 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 4627DE0754 for ; Thu, 12 May 2011 03:06:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.79 X-Spam-Level: X-Spam-Status: No, score=-99.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNI7trTtY739 for ; Thu, 12 May 2011 03:06:04 -0700 (PDT) Received: from acintmta02.acbb.aoyama.ac.jp (acintmta02.acbb.aoyama.ac.jp [133.2.20.34]) by ietfa.amsl.com (Postfix) with ESMTP id 431C6E0769 for ; Thu, 12 May 2011 03:06:03 -0700 (PDT) Received: from acmse02.acbb.aoyama.ac.jp ([133.2.20.226]) by acintmta02.acbb.aoyama.ac.jp (secret/secret) with SMTP id p4CA5tSv014800 for ; Thu, 12 May 2011 19:05:56 +0900 Received: from (unknown [133.2.206.133]) by acmse02.acbb.aoyama.ac.jp with smtp id 1804_4270_6d68b500_7c7f_11e0_b9ab_001d0969ab06; Thu, 12 May 2011 19:05:55 +0900 Received: from [IPv6:::1] ([133.2.210.5]:52307) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Thu, 12 May 2011 19:05:56 +0900 Message-ID: <4DCBB0F0.1010002@it.aoyama.ac.jp> Date: Thu, 12 May 2011 19:05:36 +0900 From: =?ISO-8859-1?Q?=22Martin_J=2E_D=FCrst=22?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Julian Reschke References: <4DCB8D70.4010509@gmx.de> In-Reply-To: <4DCB8D70.4010509@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Hybi \(hybi@ietf.org\)" , Bjoern Hoehrmann Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments 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, 12 May 2011 10:06:08 -0000 On 2011/05/12 16:34, Julian Reschke wrote: > What we should make clear is that although fragment identifiers > currently do not make sense with websockets URIs, this does *not* affect > the syntax. So if you need a literal "#" in a WS URI, you will have to > percent-escape it. Yes for escaping. Also yes for 'currently'. It may well be that some subprotocol or extension will create some rather interesting and valid ways of using fragment identifiers, and we should keep that door open. BTW, mailto: is in a very similar situation. Fragment identifiers currently don't make sense in mailto: URIs, and there is explicit test to this effect in http://tools.ietf.org/html/rfc6068 (just search for fragment). Regards, Martin. From tyoshino@google.com Thu May 12 05:19:16 2011 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 2D195E06D3 for ; Thu, 12 May 2011 05:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d-yqBZHEd9R for ; Thu, 12 May 2011 05:19:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E55E5E06D7 for ; Thu, 12 May 2011 05:19:14 -0700 (PDT) Received: from kpbe15.cbf.corp.google.com (kpbe15.cbf.corp.google.com [172.25.105.79]) by smtp-out.google.com with ESMTP id p4CCJDRQ014447 for ; Thu, 12 May 2011 05:19:13 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305202754; bh=1n0qfyjYzSezndLGgOkBYms5kgI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mV1UEEDMcsq2hED1BDbhOqSgtiJoszIE4pcPDXLYvZ9Ajj3SfqKUhddvMife/steQ dDP4THVdovOWh5IJ7/+jw== Received: from yie12 (yie12.prod.google.com [10.243.66.12]) by kpbe15.cbf.corp.google.com with ESMTP id p4CCJBfP023973 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 May 2011 05:19:12 -0700 Received: by yie12 with SMTP id 12so802778yie.27 for ; Thu, 12 May 2011 05:19:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=yDj+8Fb6ZxzHN8ZM5KB/ycDFJZHvTp/TA1ZlTSYJIPE=; b=L2j5nztQdWLTVOB47IXR7Nmif3nXw1TcxurstDB/o+p4pshBMNqf4Yr4J/YJC+30C4 LhmglKYGQRbak1tjhqrw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=inGbZA2v15QkIQtDOydgDR3WTwG4i6p8mdwBuZF+WE3fHT59xMD6A9uTAgX54IPdj3 KbnO0vTbctIzKK+Wr0ag== Received: by 10.151.130.2 with SMTP id h2mr259709ybn.171.1305202751138; Thu, 12 May 2011 05:19:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Thu, 12 May 2011 05:18:51 -0700 (PDT) In-Reply-To: <20110502085534.GO10529@1wt.eu> References: <4DBAEEC0.8050409@ericsson.com> <20110429183447.GD4085@1wt.eu> <4DBE66C3.4010805@ericsson.com> <20110502085534.GO10529@1wt.eu> From: Takeshi Yoshino Date: Thu, 12 May 2011 21:18:51 +0900 Message-ID: To: Willy Tarreau Content-Type: multipart/alternative; boundary=00504502b2d1576d9604a3133265 X-System-Of-Record: true Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 12 May 2011 12:19:16 -0000 --00504502b2d1576d9604a3133265 Content-Type: text/plain; charset=ISO-8859-1 > > > >> 29. Section 4.5.2: > > >> An endpoint MAY send a Ping message any time after the connection > is > > >> established and before the connection is closed. NOTE: A ping > > >> message may serve either as a keepalive, or to verify that the > remote > > >> endpoint is still responsive. > > >> > > >> So one allows to have multiple outstanding PING messages? That sounds > a > > >> bit strange over a reliable in-order delivery channel such as TCP. And > > >> if one does allow it should there be any rules for answering pings in > > >> order one receives them? > > > > > > Indeed, we should possibly remind implementors that it's useless to > send > > > a new ping as long as one is still pending. > > > > I think there is two possible ways. Allow it and simply include a note > > that it is mostly useless. Or make it clear that one is not allowed to > > send new pings until one have received the pong. > > Good point. > > I'm posting my question about Ping/Pong -07 here since it's related to this topic. Now an endpoint may ignore some Pings (according to the sentence "In the case multiple Pings have been received ...") in -07. What is this for? It's very strange that we have this and the requirement about body "The message bodies (i.e. both ..." together. I thought the purpose of echoing back the same body is to allow endpoints to check if a certain Ping is really acked by Pong with the same body (maybe sequence number or something). But if an endpoint sends Ping "ABC" and then sends "DEF" without waiting for Pong for "ABC", Pong for "ABC" may not be sent by the other peer. This cannot be realized. We need to disallow two or more pending Ping at the same time as Willy says to address this point, too. Even with this fix, we still have problem. Now an endpoint can send unsolicited Pongs (according to the text "A Pong message MAY be sent unsolicited."). We cannot distinguish unsolicited one from one in reply to Ping. Here, it's not possible to check if Ping "ABC" is pending or not since the spec doesn't prohibit the other peer sending unsolicited Pong "ABC". How should we deal with this? Takeshi --00504502b2d1576d9604a3133265 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> >> 29. Section 4.5.2:
> >> =A0 =A0An endpoint MAY send a Ping message any time after the= connection is
> >> =A0 =A0established and before the connection is closed. =A0NO= TE: A ping
> >> =A0 =A0message may serve either as a keepalive, or to verify = that the remote
> >> =A0 =A0endpoint is still responsive.
> >>
> >> So one allows to have multiple outstanding PING messages? Tha= t sounds a
> >> bit strange over a reliable in-order delivery channel such as= TCP. And
> >> if one does allow it should there be any rules for answering = pings in
> >> order one receives them?
> >
> > Indeed, we should possibly remind implementors that it's usel= ess to send
> > a new ping as long as one is still pending.
>
> I think there is two possible ways. Allow it and simply include a note=
> that it is mostly useless. Or make it clear that one is not allowed to=
> send new pings until one have received the pong.

Good point.


I'm postin= g my question about Ping/Pong -07 here since it's related to this topic= .

Now=A0an endpoint may ignore some Pings (accordi= ng to the sentence "In the case multiple=A0Pings have been received ..= .") in -07. What is this for? It's very strange that we have this = and the requirement about body=A0"The message=A0bodies (i.e. both ...&= quot; together.

I thought the purpose of echoing back the same bod= y is to allow endpoints to check if a certain Ping is really acked by Pong = with the same body (maybe sequence number or something). But if an endpoint= sends Ping "ABC" and then sends "DEF" without waiting = for Pong for "ABC", Pong for=A0"ABC" may not be sent by= the other peer. This cannot be realized. We need to disallow two or more p= ending Ping at the same time as Willy says to address this point, too.

Even with this fix, we still have problem. N= ow an endpoint can send unsolicited Pongs (according to the text "A Po= ng message MAY be sent unsolicited.").=A0We cannot distinguish unsolic= ited one from one in reply to Ping. Here, it's not possible to check if= Ping "ABC" is pending or not since the spec doesn't prohibit= the other peer sending unsolicited Pong "ABC". How should we dea= l with this?

Takeshi
=A0
--00504502b2d1576d9604a3133265-- From gregw@intalio.com Thu May 12 06:25:54 2011 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 73FA9E07A8; Thu, 12 May 2011 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.827 X-Spam-Level: X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZrGtRQ7DoD4; Thu, 12 May 2011 06:25:54 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 923A7E0751; Thu, 12 May 2011 06:25:53 -0700 (PDT) Received: by vxg33 with SMTP id 33so1326650vxg.31 for ; Thu, 12 May 2011 06:25:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.185.231 with SMTP id ff7mr304641vdc.103.1305206752650; Thu, 12 May 2011 06:25:52 -0700 (PDT) Received: by 10.52.111.7 with HTTP; Thu, 12 May 2011 06:25:52 -0700 (PDT) In-Reply-To: References: <4DBAEEC0.8050409@ericsson.com> <20110429183447.GD4085@1wt.eu> <4DBE66C3.4010805@ericsson.com> <20110502085534.GO10529@1wt.eu> Date: Thu, 12 May 2011 23:25:52 +1000 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 12 May 2011 13:25:54 -0000 On 12 May 2011 22:18, Takeshi Yoshino wrote: > unsolicited.").=A0We cannot distinguish unsolicited one from one in reply= to > Ping. Here, it's not possible to check if Ping "ABC" is pending or not si= nce > the spec doesn't prohibit the other peer sending unsolicited Pong "ABC". = How > should we deal with this? This is all over a reliable transport, so if we send Ping "ABC", then receive Pong "XYZ", we know that the pong was unsolicited and not a corrupted "ABC". Thus we have to keep waiting for the Pong "ABC". Obviously there is a chance that a unsolicited pong matches a ping, but some careful design of payloads can easily fix that. cheers From tyoshino@google.com Thu May 12 11:37:24 2011 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 BA365E06D5 for ; Thu, 12 May 2011 11:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA9IpXknb5yC for ; Thu, 12 May 2011 11:37:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9B858E062A for ; Thu, 12 May 2011 11:37:21 -0700 (PDT) Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p4CIbKrF032318 for ; Thu, 12 May 2011 11:37:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305225440; bh=BVB9/YaaBn6LiemH4aL97YgG7nY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PKS8JNIQ/4LNhnc00mmmgAjw6MeCSdzZTXMCPbzSRoFBMLf8K9UWjlrqE4loSlysZ GhVB8lW5FXLJzaWBORgRQ== Received: from yxk8 (yxk8.prod.google.com [10.190.3.136]) by kpbe12.cbf.corp.google.com with ESMTP id p4CIbAcY003275 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 May 2011 11:37:18 -0700 Received: by yxk8 with SMTP id 8so791797yxk.32 for ; Thu, 12 May 2011 11:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=MEGsXhqIVv6TgTPKl9uOWmapQQsFD+MtE4Nnmsge89Q=; b=YuSwdPXPYAp7mOAVhAPAbHXoE+GApDFBZz4CuBHCs5oGlFB03hbBGagguW5S8LwP30 G3BbNDYr/kevbh+1LdbA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lAGM2AH3nBxtKptf14DdNxyOWrMAF4+ruxlbLTVeKie9vxf7Yg/ZbWDDdGIlyNRRMe /XuW+rhkjYk+zGY5+nfw== Received: by 10.150.69.27 with SMTP id r27mr647927yba.114.1305225438528; Thu, 12 May 2011 11:37:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Thu, 12 May 2011 11:36:58 -0700 (PDT) In-Reply-To: References: <4DBAEEC0.8050409@ericsson.com> <20110429183447.GD4085@1wt.eu> <4DBE66C3.4010805@ericsson.com> <20110502085534.GO10529@1wt.eu> From: Takeshi Yoshino Date: Fri, 13 May 2011 03:36:58 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd5905a9d84e204a3187aef X-System-Of-Record: true Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 12 May 2011 18:37:24 -0000 --000e0cd5905a9d84e204a3187aef Content-Type: text/plain; charset=ISO-8859-1 > > Obviously there is a chance that a unsolicited pong matches a ping, > but some careful design of payloads can easily fix that. > I see. Coordinating body value assignment so that unsolicited one and reply one don't conflict each other (e.g. "ABC" and "XYZ" as you said) is one possible solution. This should be discussed well when we add some keep alive feature to browser that sends Ping to the server. If we prepare some API for JavaScript to tell the browser what string to use for Ping, service designers may coordinate assignment by themselves. If we don't, we should reserve some string to be used for Ping/unsolicited Pong by browsers to avoid collision. ---- Isn't it simpler to reserve some string, say "NOOP" (or "\x00" to save bytes), for Ping body and require endpoints to ignore such Ping rather than diverting Pong for heartbeat? Thanks, Takeshi --000e0cd5905a9d84e204a3187aef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
=A0 Obviously there is a chance that a unsolicited pong matches a ping, but some careful design of payloads can easily fix that.

I see. Coordinating body value assignment so that unsolic= ited one and reply one don't conflict each other (e.g. "ABC" = and "XYZ" as you said) is one possible solution.

This should be discussed well when we add some keep ali= ve feature to browser that sends=A0Ping to the server.=A0If we prepare some= API for JavaScript to tell the browser what string to use for Ping, servic= e designers may coordinate assignment by themselves. If we don't, we sh= ould reserve some string to be used for Ping/unsolicited Pong by browsers t= o avoid collision.

----

Isn't it simpler to r= eserve some string, say "NOOP" (or "\x00" to save bytes= ), for Ping body and require endpoints to ignore such Ping rather than dive= rting Pong for heartbeat?

Thanks,
Takeshi
--000e0cd5905a9d84e204a3187aef-- From gregw@intalio.com Thu May 12 15:29:26 2011 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 2ED18E07D6; Thu, 12 May 2011 15:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kbMTf5RvXfNa; Thu, 12 May 2011 15:29:25 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70680E07C8; Thu, 12 May 2011 15:29:25 -0700 (PDT) Received: by vws12 with SMTP id 12so1761732vws.31 for ; Thu, 12 May 2011 15:29:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.110.234 with SMTP id id10mr1053203vdb.303.1305239364569; Thu, 12 May 2011 15:29:24 -0700 (PDT) Received: by 10.52.111.7 with HTTP; Thu, 12 May 2011 15:29:24 -0700 (PDT) In-Reply-To: References: <4DBAEEC0.8050409@ericsson.com> <20110429183447.GD4085@1wt.eu> <4DBE66C3.4010805@ericsson.com> <20110502085534.GO10529@1wt.eu> Date: Fri, 13 May 2011 08:29:24 +1000 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , "ifette+ietf@google.com" , TSV Dir Subject: Re: [hybi] TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 12 May 2011 22:29:26 -0000 Takeshi, what I have seen before is the use of sequence numbers where the client side uses even and the server side uses odd, so can tell by the seq number in a pong where it was generated and thus tell if it is a response or unsolicited. cheers On 13 May 2011 04:36, Takeshi Yoshino wrote: >> =A0 Obviously there is a chance that a unsolicited pong matches a ping, >> but some careful design of payloads can easily fix that. > > I see. Coordinating body value assignment so that unsolicited one and rep= ly > one don't conflict each other (e.g. "ABC" and "XYZ" as you said) is one > possible solution. > This should be discussed well when we add some keep alive feature to brow= ser > that sends=A0Ping to the server.=A0If we prepare some API for JavaScript = to tell > the browser what string to use for Ping, service designers may coordinate > assignment by themselves. If we don't, we should reserve some string to b= e > used for Ping/unsolicited Pong by browsers to avoid collision. > ---- > Isn't it simpler to reserve some string, say "NOOP" (or "\x00" to save > bytes), for Ping body and require endpoints to ignore such Ping rather th= an > diverting Pong for heartbeat? > Thanks, > Takeshi From tyoshino@google.com Thu May 12 23:01:19 2011 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 6D72BE0658 for ; Thu, 12 May 2011 23:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzBkNEQyw8tw for ; Thu, 12 May 2011 23:01:18 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 229B8E0657 for ; Thu, 12 May 2011 23:01:18 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p4D61G73006897 for ; Thu, 12 May 2011 23:01:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305266477; bh=d+aFwIIsynuI9th/CH/1Fx47LQs=; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Content-Type; b=LHnSAJ/M2lms9v94YUYYD4jwAGLaEfbmjq8vdeBMBVkHBRQhXAPmtCmrLtZrUWK2/ J0KiU8TkXkOM34PAVNzzg== Received: from gye5 (gye5.prod.google.com [10.243.50.5]) by hpaq1.eem.corp.google.com with ESMTP id p4D6006U022882 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 12 May 2011 23:01:15 -0700 Received: by gye5 with SMTP id 5so879251gye.30 for ; Thu, 12 May 2011 23:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:from:date:message-id:subject:to:cc :content-type; bh=+5Wb8Ne2IY0eoEjlgDc9c49uE+uALQB8SS58baMTC2Y=; b=g6xhofOw14d47n2wW+94dXEBiTovJA/KCRtV0N851Lvj8nCT9oMTEcOTCDlc+8EyLR IN8onryE6kVUSSOKkzUQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:cc:content-type; b=TkWRKBVm5H4t6Yi2Yby7YZRJBwh1lypk2XMbQ5AQdeKfN2qktyYP0hVBgAAS+YgInV cPF6lBOi7sA1ewlLyUig== Received: by 10.150.69.27 with SMTP id r27mr1079668yba.114.1305266475175; Thu, 12 May 2011 23:01:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Thu, 12 May 2011 23:00:55 -0700 (PDT) From: Takeshi Yoshino Date: Fri, 13 May 2011 15:00:55 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd5905a970f8504a3220849 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 13 May 2011 06:01:19 -0000 --000e0cd5905a970f8504a3220849 Content-Type: text/plain; charset=ISO-8859-1 (Detaching from TSV review thread) Greg, I see. Sounds ok to use assignment like that. As you said "it's over reliable transport" in reply to my message, we don't need to use sequence number as ping/ICMP does since there's no loss or reorder. Maybe just \x00 (reply to ping) or \x01 (unsolicited) would be fine. Basically, I don't think it's good idea to make it duty of implementor or service designer to choose body for Ping and unsolicited Pong properly. That should be covered by the spec to reduce what to be cared by user if possible. What do you think about specifying some rule for the body strings to be used for Ping and unsolicited Pong in the spec? - application data of Ping must start with \x00 - application data of in-reply-to Pong MUST have the same body as the received Ping - application data of unsolicited Pong must start with \x01 I think the following is clearer. - when received Normal-Ping (Ping with its application data starting with \x00), reply with Pong with the same body - when received NOP-Ping (Ping with its application data starting with \x01), just ignore it On Fri, May 13, 2011 at 07:29, Greg Wilkins wrote: > Takeshi, > > what I have seen before is the use of sequence numbers where the > client side uses even and the server side uses odd, so can tell by the > seq number in a pong where it was generated and thus tell if it is a > response or unsolicited. > > cheers > > > On 13 May 2011 04:36, Takeshi Yoshino wrote: > >> Obviously there is a chance that a unsolicited pong matches a ping, > >> but some careful design of payloads can easily fix that. > > > > I see. Coordinating body value assignment so that unsolicited one and > reply > > one don't conflict each other (e.g. "ABC" and "XYZ" as you said) is one > > possible solution. > > This should be discussed well when we add some keep alive feature to > browser > > that sends Ping to the server. If we prepare some API for JavaScript to > tell > > the browser what string to use for Ping, service designers may coordinate > > assignment by themselves. If we don't, we should reserve some string to > be > > used for Ping/unsolicited Pong by browsers to avoid collision. > > ---- > > Isn't it simpler to reserve some string, say "NOOP" (or "\x00" to save > > bytes), for Ping body and require endpoints to ignore such Ping rather > than > > diverting Pong for heartbeat? > > Thanks, > > Takeshi > --000e0cd5905a970f8504a3220849 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(Detaching from TSV review thread)

Greg,

I see. Sounds ok to= use assignment like that.=A0As you said "it's over reliable trans= port" in reply to my message, we don't need to use sequence number= as ping/ICMP does since there's no loss or reorder. Maybe just \x00 (r= eply to ping) or \x01 (unsolicited) would be fine.

Basically, = I don't think it's good idea to make it duty of implementor or serv= ice designer to choose body for Ping and unsolicited Pong properly. That sh= ould be covered by the spec to reduce what to be cared by user if possible.= What do you think about specifying some rule for the body strings to be us= ed for Ping and unsolicited Pong in the spec?

- applicati= on data of Ping must start with \x00
- appl= ication data of in-reply-to Pong MUST have the same body as the received Pi= ng
- application data of unsolicited Pong must star= t with \x01

I think the following is clearer.
- when received Normal-Ping (Ping with its appli= cation data starting with \x00), reply with Pong with the same body
- when received NOP-Ping (Ping with its applicatio= n data starting with \x01), just ignore it

On Fri, May 13, 2011 at 07:29, Greg Wilkins <gregw@intalio.com>= wrote:
Takeshi,

what I have seen before is the use of sequence numbers where the
client side uses even and the server side uses odd, so can tell by the
seq number in a pong where it was generated and thus tell if it is a
response or unsolicited.

cheers


On 13 May 2011 04:36, Takeshi Yoshino <tyoshino@google.com> wrote:
>> =A0 Obviously there is a chance that a unsolicited pong matches a = ping,
>> but some careful design of payloads can easily fix that.
>
> I see. Coordinating body value assignment so that unsolicited one and = reply
> one don't conflict each other (e.g. "ABC" and "XYZ&= quot; as you said) is one
> possible solution.
> This should be discussed well when we add some keep alive feature to b= rowser
> that sends=A0Ping to the server.=A0If we prepare some API for JavaScri= pt to tell
> the browser what string to use for Ping, service designers may coordin= ate
> assignment by themselves. If we don't, we should reserve some stri= ng to be
> used for Ping/unsolicited Pong by browsers to avoid collision.
> ----
> Isn't it simpler to reserve some string, say "NOOP" (or = "\x00" to save
> bytes), for Ping body and require endpoints to ignore such Ping rather= than
> diverting Pong for heartbeat?
> Thanks,
> Takeshi

--000e0cd5905a970f8504a3220849-- From salvatore.loreto@ericsson.com Thu May 12 23:31:53 2011 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 A01DBE06A7 for ; Thu, 12 May 2011 23:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnOYDP5ad9sc for ; Thu, 12 May 2011 23:31:52 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1D1F4E0657 for ; Thu, 12 May 2011 23:31:51 -0700 (PDT) X-AuditID: c1b4fb39-b7cc5ae000006f6d-65-4dccd056b381 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id BB.6C.28525.650DCCD4; Fri, 13 May 2011 08:31:50 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.137.0; Fri, 13 May 2011 08:31:04 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3FDF824F7 for ; Fri, 13 May 2011 09:31:04 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 016CD50DFA for ; Fri, 13 May 2011 09:31:04 +0300 (EEST) Received: from n244.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AA7C650908 for ; Fri, 13 May 2011 09:31:03 +0300 (EEST) Message-ID: <4DCCD027.5030002@ericsson.com> Date: Fri, 13 May 2011 09:31:03 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------060300090500020700070401" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 13 May 2011 06:31:53 -0000 --------------060300090500020700070401 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit I agree with the fact that coordinating Ping and Pong body value assigment, so that unsollicited Pong and reply Pong do not conflict each other, should be clearly specified in the spec instead of leave this duty to the implementors or service designers. More I share the concern Magnus has on the text in Section 4.5.2; the text reduce significantly the possibility to develop future extensions based on ping/pong. If people think that it is OK, I won't oppose, but I want to be sure that people are well aware of this fact. On 4/29/11 8:00 PM, Magnus Westerlund wrote: 28. Section 4.5.2: The message bodies (i.e. both the Extension data (if any) and the Application data) of the Ping and Pong MUST be the same. I find the fact that the extension body data needs to be the same to be an issue. If one develops an extension that actually has to do with the frames and their transport then not being able to change the data will be an issue. As an example could be a Websocket RTT measurement extension where you like to include in the PONG both the PING sending time from the PING message and the amount of time between receving PING and sending PONG. Thus requiring one to add additional data. -- Salvatore Loreto www.sloreto.com > (Detaching from TSV review thread) > > Greg, > > I see. Sounds ok to use assignment like that. As you said "it's over > reliable transport" in reply to my message, we don't need to use > sequence number as ping/ICMP does since there's no loss or reorder. > Maybe just \x00 (reply to ping) or \x01 (unsolicited) would be fine. > > Basically, I don't think it's good idea to make it duty of implementor > or service designer to choose body for Ping and unsolicited Pong > properly. That should be covered by the spec to reduce what to be > cared by user if possible. What do you think about specifying some > rule for the body strings to be used for Ping and unsolicited Pong in > the spec? > > - application data of Ping must start with \x00 > - application data of in-reply-to Pong MUST have the same body as the > received Ping > - application data of unsolicited Pong must start with \x01 > > I think the following is clearer. > > - when received Normal-Ping (Ping with its application data starting > with \x00), reply with Pong with the same body > - when received NOP-Ping (Ping with its application data starting with > \x01), just ignore it > > On Fri, May 13, 2011 at 07:29, Greg Wilkins > wrote: > > Takeshi, > > what I have seen before is the use of sequence numbers where the > client side uses even and the server side uses odd, so can tell by the > seq number in a pong where it was generated and thus tell if it is a > response or unsolicited. > > cheers > > > On 13 May 2011 04:36, Takeshi Yoshino > wrote: > >> Obviously there is a chance that a unsolicited pong matches a > ping, > >> but some careful design of payloads can easily fix that. > > > > I see. Coordinating body value assignment so that unsolicited > one and reply > > one don't conflict each other (e.g. "ABC" and "XYZ" as you said) > is one > > possible solution. > > This should be discussed well when we add some keep alive > feature to browser > > that sends Ping to the server. If we prepare some API for > JavaScript to tell > > the browser what string to use for Ping, service designers may > coordinate > > assignment by themselves. If we don't, we should reserve some > string to be > > used for Ping/unsolicited Pong by browsers to avoid collision. > > ---- > > Isn't it simpler to reserve some string, say "NOOP" (or "\x00" > to save > > bytes), for Ping body and require endpoints to ignore such Ping > rather than > > diverting Pong for heartbeat? > > Thanks, > > Takeshi > > --------------060300090500020700070401 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit <as individual contributor>

I agree with the fact that coordinating Ping and Pong body value assigment,
so that unsollicited Pong and reply Pong do not conflict each other,
should be clearly specified in the spec instead of leave this duty to the implementors or service designers.


More I share the concern Magnus has on the text in Section 4.5.2;
the text reduce significantly the possibility to develop future extensions based on ping/pong.
If people think that it is OK, I won't oppose, but I want to be sure that people are well aware of this fact.

On 4/29/11 8:00 PM, Magnus Westerlund wrote: 
28. Section 4.5.2:

The message
   bodies (i.e. both the Extension data (if any) and the Application
   data) of the Ping and Pong MUST be the same.

I find the fact that the extension body data needs to be the same to be
an issue. If one develops an extension that actually has to do with the
frames and their transport then not being able to change the data will
be an issue. As an example could be a Websocket RTT measurement
extension where you like to include in the PONG both the PING sending
time from the PING message and the amount of time between receving PING
and sending PONG. Thus requiring one to add additional data.




-- 
Salvatore Loreto
www.sloreto.com

(Detaching from TSV review thread)

Greg,

I see. Sounds ok to use assignment like that. As you said "it's over reliable transport" in reply to my message, we don't need to use sequence number as ping/ICMP does since there's no loss or reorder. Maybe just \x00 (reply to ping) or \x01 (unsolicited) would be fine.

Basically, I don't think it's good idea to make it duty of implementor or service designer to choose body for Ping and unsolicited Pong properly. That should be covered by the spec to reduce what to be cared by user if possible. What do you think about specifying some rule for the body strings to be used for Ping and unsolicited Pong in the spec?

- application data of Ping must start with \x00
- application data of in-reply-to Pong MUST have the same body as the received Ping
- application data of unsolicited Pong must start with \x01

I think the following is clearer.

- when received Normal-Ping (Ping with its application data starting with \x00), reply with Pong with the same body
- when received NOP-Ping (Ping with its application data starting with \x01), just ignore it

On Fri, May 13, 2011 at 07:29, Greg Wilkins <gregw@intalio.com> wrote:
Takeshi,

what I have seen before is the use of sequence numbers where the
client side uses even and the server side uses odd, so can tell by the
seq number in a pong where it was generated and thus tell if it is a
response or unsolicited.

cheers


On 13 May 2011 04:36, Takeshi Yoshino <tyoshino@google.com> wrote:
>>   Obviously there is a chance that a unsolicited pong matches a ping,
>> but some careful design of payloads can easily fix that.
>
> I see. Coordinating body value assignment so that unsolicited one and reply
> one don't conflict each other (e.g. "ABC" and "XYZ" as you said) is one
> possible solution.
> This should be discussed well when we add some keep alive feature to browser
> that sends Ping to the server. If we prepare some API for JavaScript to tell
> the browser what string to use for Ping, service designers may coordinate
> assignment by themselves. If we don't, we should reserve some string to be
> used for Ping/unsolicited Pong by browsers to avoid collision.
> ----
> Isn't it simpler to reserve some string, say "NOOP" (or "\x00" to save
> bytes), for Ping body and require endpoints to ignore such Ping rather than
> diverting Pong for heartbeat?
> Thanks,
> Takeshi

--------------060300090500020700070401-- From bruce@callenish.com Fri May 13 09:53:48 2011 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 A9FD7E081A for ; Fri, 13 May 2011 09:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ww-KVop596Xv for ; Fri, 13 May 2011 09:53:48 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 17B3CE0819 for ; Fri, 13 May 2011 09:53:47 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QKvcX-0001rg-5v; Fri, 13 May 2011 09:53:45 -0700 Message-ID: <4DCD620C.6090508@callenish.com> Date: Fri, 13 May 2011 09:53:32 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Salvatore Loreto References: <4DCCD027.5030002@ericsson.com> In-Reply-To: <4DCCD027.5030002@ericsson.com> Content-Type: multipart/alternative; boundary="------------050001030803010205020808" 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 Cc: hybi@ietf.org Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 13 May 2011 16:53:48 -0000 This is a multi-part message in MIME format. --------------050001030803010205020808 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I agree with you and Magnus that there will be lots of times you want the body of the Pong to be able to vary from the Ping. But perhaps a compromise could be reached. What if the body of the Pong must begin with the body of the Ping, but can have additional information after that? On 12/05/2011 11:31 PM, Salvatore Loreto wrote: > > > I agree with the fact that coordinating Ping and Pong body value > assigment, > so that unsollicited Pong and reply Pong do not conflict each other, > should be clearly specified in the spec instead of leave this duty to > the implementors or service designers. > > > More I share the concern Magnus has on the text in Section 4.5.2; > the text reduce significantly the possibility to develop future > extensions based on ping/pong. > If people think that it is OK, I won't oppose, but I want to be sure > that people are well aware of this fact. > > On 4/29/11 8:00 PM, Magnus Westerlund wrote: > > 28. Section 4.5.2: > > The message > bodies (i.e. both the Extension data (if any) and the Application > data) of the Ping and Pong MUST be the same. > > I find the fact that the extension body data needs to be the same to be > an issue. If one develops an extension that actually has to do with the > frames and their transport then not being able to change the data will > be an issue. As an example could be a Websocket RTT measurement > extension where you like to include in the PONG both the PING sending > time from the PING message and the amount of time between receving PING > and sending PONG. Thus requiring one to add additional data. > --------------050001030803010205020808 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with you and Magnus that there will be lots of times you want the body of the Pong to be able to vary from the Ping. But perhaps a compromise could be reached. What if the body of the Pong must begin with the body of the Ping, but can have additional information after that?

On 12/05/2011 11:31 PM, Salvatore Loreto wrote:
<as individual contributor>

I agree with the fact that coordinating Ping and Pong body value assigment,
so that unsollicited Pong and reply Pong do not conflict each other,
should be clearly specified in the spec instead of leave this duty to the implementors or service designers.


More I share the concern Magnus has on the text in Section 4.5.2;
the text reduce significantly the possibility to develop future extensions based on ping/pong.
If people think that it is OK, I won't oppose, but I want to be sure that people are well aware of this fact.

On 4/29/11 8:00 PM, Magnus Westerlund wrote: 
28. Section 4.5.2:

The message
   bodies (i.e. both the Extension data (if any) and the Application
   data) of the Ping and Pong MUST be the same.

I find the fact that the extension body data needs to be the same to be
an issue. If one develops an extension that actually has to do with the
frames and their transport then not being able to change the data will
be an issue. As an example could be a Websocket RTT measurement
extension where you like to include in the PONG both the PING sending
time from the PING message and the amount of time between receving PING
and sending PONG. Thus requiring one to add additional data.

--------------050001030803010205020808-- From michael.platov@gmail.com Fri May 13 14:47:42 2011 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 95D6FE0881 for ; Fri, 13 May 2011 14:47:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHXAM4-pmTcF for ; Fri, 13 May 2011 14:47:41 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A57D2E077E for ; Fri, 13 May 2011 14:47:41 -0700 (PDT) Received: by vws12 with SMTP id 12so2547219vws.31 for ; Fri, 13 May 2011 14:47:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:from:date:message-id:subject:to :content-type; bh=kPrDCxtDNhtEcLhEDwCbVgRSE3nzuOJzfriKF99CBUo=; b=JeCdk8A1rO6qR+U5JpXVmOn0eTWLd4spjocAwh7JGEAk36FL9uvqYBJ0ZhdlNL5K0j iCXSckwybrkZ31lUEEy00b6wP+qWe3wgRHUR1fCsj4lEQmM1382zUflWdfwL8Nu+Z4vs TYia2xia7qWJS3qpdE/Ab7QCT+fSTS3OlPqF8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; b=eZ/8vQJ5LZJBuRGp6NhyGDgkoYlXEHmWMV+rxTr4DBqBrNjnSRZmX2+HMnQc0/P4m3 VpIB1ABmZjyeKqucwd2w8PgxaufbkyK1bytIVr94Mq1NuEh1Gt0UMkJ3+y7J05niUbap np0zRhnr0jj0n5b8kfpJGL7a07nKvbGqrEpLY= Received: by 10.52.66.175 with SMTP id g15mr2616174vdt.176.1305323261139; Fri, 13 May 2011 14:47:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.165.6 with HTTP; Fri, 13 May 2011 14:47:21 -0700 (PDT) From: Michael Date: Sat, 14 May 2011 01:47:21 +0400 Message-ID: To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [hybi] draft-07 support at websocketstest.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: Fri, 13 May 2011 21:47:42 -0000 Hi All, A websockets test server at http://websocketstest.com has been updated to support hybi-draft-07! The test page now includes several new tests specific to the latest draft: * ping - sending a server side ping message and checking that the browser responds back with a pong message * fragments - sending a message to the server and receiving the same message as a response in multiple fragments The server was also tested to work with Andy Green's libwebsockets library (ping, client and fraggle client tools), and draft-07 enabled build of firefox mentioned in [0]. Some protocols that are especially useful for testing are built-in. Protocols for libwebsocket tools: * lws-mirror-protocol * dumb-increment-protocol * fraggle-protocol (server will close connection after 20 retries) Test protocols described in[1]: * org.ietf.websocket.test-echo-assemble * org.ietf.websocket.test-echo-fragment * org.ietf.websocket.test-produce for the folks how want to run the tests using command line tools or other clients, the address of the websocket endpoint is ws://ws.websocketstest.com deflate-stream extension is not yet supported (due to some server side buffer management issues), but instead of the deflate-stream extension, this server supports per-frame deflate extension draft proposed by Tokeshi Yoshino [2], which, hopefully, will find its way into a standard. A client-side websocket library and some protocol tests created in the process are available at [3]. Hope this will be helpful to other protocol implementors for interoperability testing. PS: I'm not sure if that was already mentioned before or not, but 07-draft has an error in section 4.4 Fragmentation "As an example, for a text message sent as three fragments, the first fragment would have an opcode of 0x4 and a FIN bit clear, the second fragment would have an opcode of 0x0 and a FIN bit clear, and the third fragment would have an opcode of 0x0 and a FIN bit that is set." But according to the section 4.6: "Opcodes 0x3-0x7 are reserved for further non-control frames yet to be defined." So, it seems there is a typo in the 4.4 and instead of 0x4 it should be 0x1 (because the message in this example is text) Thanks! Michael ----- 0. http://www6.ietf.org/mail-archive/web/hybi/current/msg07362.html 1. http://www.ietf.org/mail-archive/web/hybi/current/msg06781.html 2. http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-00 3. https://github.com/mplatov/ruby-websocket-client From tyoshino@google.com Tue May 17 04:03:49 2011 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 F3B7DE0715 for ; Tue, 17 May 2011 04:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4j6GpJEakCzg for ; Tue, 17 May 2011 04:03:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 31529E070B for ; Tue, 17 May 2011 04:03:47 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p4HB3kou029743 for ; Tue, 17 May 2011 04:03:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1305630227; bh=xoNiRvS6eA4T09n9j7mH0pQZZ9k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=ZWQGw4wlFwaSLeSBWkKkfuzpgIM9+hrFWn8XHbYvREa9k93DLL9nODdQS0JjmIMcW oZvN96poolvCMQRI+eOuw== Received: from yxa15 (yxa15.prod.google.com [10.190.1.15]) by wpaz37.hot.corp.google.com with ESMTP id p4HB356G012752 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 17 May 2011 04:03:45 -0700 Received: by yxa15 with SMTP id 15so103876yxa.9 for ; Tue, 17 May 2011 04:03:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=maYdQL+85g5VljORGLQASqnp1ptznvR/ZpYfeQIG5iI=; b=Bn0RMHmUUZ3HwUz2gFkvHK7wNgz1M6wioflTdZMn09lVa5fBGyPtyar2R/he4LLX3o dxdDoN7IVDji15pBT1uA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=TZeqkbLROXgF+EsYUFBGHFY6Mmc4/ye1o06/Fp869+KEL2GMmoHNaMm7eYYpFHggQ4 sPFN65rL1H4YEJh87tRQ== Received: by 10.150.69.27 with SMTP id r27mr351436yba.114.1305630225149; Tue, 17 May 2011 04:03:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Tue, 17 May 2011 04:03:25 -0700 (PDT) In-Reply-To: <4DCD620C.6090508@callenish.com> References: <4DCCD027.5030002@ericsson.com> <4DCD620C.6090508@callenish.com> From: Takeshi Yoshino Date: Tue, 17 May 2011 20:03:25 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=000e0cd5905ac72f8d04a376b968 X-System-Of-Record: true Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Tue, 17 May 2011 11:03:49 -0000 --000e0cd5905ac72f8d04a376b968 Content-Type: text/plain; charset=ISO-8859-1 Full body matching requirement has been introduced by http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-03 for both close and ping/pong. What was the original goal of this requirement for ping/pong? Is it still valid? Full body matching requirement for close frames has been thrown away after long discussion. Now it looks like it's sufficient to have single boolean to indicate it's nop or reply in application data. Here's relaxed version. foo and bar mean "any string" a) implement heartbeat by diverting Pong - Ping would be "Ping foo" - to reply to "Ping foo", send "Pong \x00 bar" (bar is foo by default) - to send unsolicited Pong, send "Pong \x01 bar" b) implement heartbeat by diverting Ping - to send Normal-Ping, send "Ping \x00 foo" - to send NOP-Ping, send "Ping \x01 foo" - to reply "Ping \x00 foo", send "Pong bar" (bar is foo by default) - just ignore "Ping \x01 foo" when received to adopt Bruce's idea, change "(bar is foo by default)" to "(bar is foo + buz)". it implements echo and allows the receiver to send additional info. I've removed unnecessary \x00 and \x01, but it's fine for me to keep them to keep framing symmetric. Takeshi --000e0cd5905ac72f8d04a376b968 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Full body matching requirement has been introduced by=A0http://too= ls.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-03=A0for both clo= se and ping/pong. What was the original goal of this requirement for ping/p= ong? Is it still valid? Full body matching requirement for close frames has= been thrown away after long discussion.

Now it looks like it's sufficient to have single bo= olean to indicate it's nop or reply in application data.

=
Here's relaxed version.

foo an= d bar mean "any string"

a) implement heartbeat by diverting Pong
- Ping would be "Ping foo"
- to reply to "Ping fo= o", send "Pong \x00 bar" (bar is foo by default)
- to send unsolicited Pong, send "Pong \x01 bar"

b) implement heartbeat by diverting Ping
- to send Normal-Ping, send "Ping \x00 foo"
- to send NOP-Ping, send "Ping \x01 foo"
- to reply "Ping \x00 foo", send "Pong bar" (bar is f= oo by default)
- just ignore "Ping \x01 foo" when= received

to adopt Bruce's idea, change "(bar is foo by = default)" to "(bar is foo + buz)". it implements echo and al= lows the receiver to send additional info.

I'v= e removed unnecessary \x00 and \x01, but it's fine for me to keep them= =A0to keep framing symmetric.

Takeshi

--000e0cd5905ac72f8d04a376b968-- From ibc@aliax.net Tue May 17 05:48:59 2011 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 62E24E0811 for ; Tue, 17 May 2011 05:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwp20RpYeSAO for ; Tue, 17 May 2011 05:48:58 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06B41E074D for ; Tue, 17 May 2011 05:48:57 -0700 (PDT) Received: by qyk29 with SMTP id 29so2229907qyk.10 for ; Tue, 17 May 2011 05:48:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.215.70 with SMTP id hd6mr396992qab.266.1305636537153; Tue, 17 May 2011 05:48:57 -0700 (PDT) Received: by 10.229.183.209 with HTTP; Tue, 17 May 2011 05:48:57 -0700 (PDT) Date: Tue, 17 May 2011 14:48:57 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [hybi] Basic question about WS and different browser windows X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2011 12:48:59 -0000 Hi, perhaps this question does not fit well in this maillist, sorry for tha= t. Imagine a web-chat application (similar to Gmail chat) in which different
are created for each chat session within the main page. Previously the JavaScript in such page has opened a WS connection with the server which is used for the chat messages. Gmail allows opening a chat window into a separate/new windows (a new browser window, with small size). If we do the same, would it be needed to open a new WS connection from the new browser window? or could it share the same connection? (I expect this purely depends on how JavaScript works....). Or perhaps there would be a single WS connection from the main page, such page would receive new WS messages and could update the HTML of the other window? Just wondering. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From Gabriel.Montenegro@microsoft.com Tue May 17 12:25:26 2011 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 C42FBE077D for ; Tue, 17 May 2011 12:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZMAZ6fu7xXj for ; Tue, 17 May 2011 12:25:24 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 97FD0E0719 for ; Tue, 17 May 2011 12:25:24 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 17 May 2011 12:25:24 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 17 May 2011 12:25:24 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0270.002; Tue, 17 May 2011 12:25:23 -0700 From: Gabriel Montenegro To: Takeshi Yoshino , "hybi@ietf.org" Thread-Topic: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07) Thread-Index: AQHMFIIkUI9h8h8BPE+on6RW26XbNZSRY/Lw Date: Tue, 17 May 2011 19:25:23 +0000 Message-ID: References: <4DCCD027.5030002@ericsson.com> <4DCD620C.6090508@callenish.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.28] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402D3F1DTK5EX14MBXW603w_" MIME-Version: 1.0 Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Tue, 17 May 2011 19:25:26 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402D3F1DTK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable [As an individual] I don't think setting Ping/Pong as a platform for further applications is a= good idea, for the same reasons that using ICMP as a platform for more int= elligent applications is a good idea. Since ICMP does not follow the usual = codepaths, any valid network characteristic measurements better not use, an= d they better use traffic that looks more closely like what an actual app w= ould use (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated = as application traffic after network elements start being cognizant of Webs= ockets. So the idea of using Ping/Pong for further apps doesn't appear very= convincing to me. I'd much rather we kept Ping/Pong intentionally limited to its original pur= pose of just being a bare bones mechanism, and leave any other uses as prop= er extensions. The current text to say that only the last Ping need to be responded to dis= courages the peers from sending more than one, but it would be better to ma= ke it explicit that having more than one outstanding Ping (without its corr= esponding Pong) MUST NOT be done. I think the 0x00 and 0x01 to distinguish unsolicited Pong is fine. From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Tak= eshi Yoshino Sent: Tuesday, May 17, 2011 04:03 To: hybi@ietf.org Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft= -ietf-hybi-thewebsocketprotocol-07) Full body matching requirement has been introduced by http://tools.ietf.org= /html/draft-ietf-hybi-thewebsocketprotocol-03 for both close and ping/pong.= What was the original goal of this requirement for ping/pong? Is it still = valid? Full body matching requirement for close frames has been thrown away= after long discussion. Now it looks like it's sufficient to have single boolean to indicate it's n= op or reply in application data. Here's relaxed version. foo and bar mean "any string" a) implement heartbeat by diverting Pong - Ping would be "Ping foo" - to reply to "Ping foo", send "Pong \x00 bar" (bar is foo by default) - to send unsolicited Pong, send "Pong \x01 bar" b) implement heartbeat by diverting Ping - to send Normal-Ping, send "Ping \x00 foo" - to send NOP-Ping, send "Ping \x01 foo" - to reply "Ping \x00 foo", send "Pong bar" (bar is foo by default) - just ignore "Ping \x01 foo" when received to adopt Bruce's idea, change "(bar is foo by default)" to "(bar is foo + b= uz)". it implements echo and allows the receiver to send additional info. I've removed unnecessary \x00 and \x01, but it's fine for me to keep them t= o keep framing symmetric. Takeshi --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402D3F1DTK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

[As an individual]

 <= /p>

I don’t think setti= ng Ping/Pong as a platform for further applications is a good idea, for the= same reasons that using ICMP as a platform for more intelligent applications is a good idea. Since ICMP does not follow the usual codepath= s, any valid network characteristic measurements better not use, and they b= etter use traffic that looks more closely like what an actual app would use= (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated as application traffic after network el= ements start being cognizant of Websockets. So the idea of using Ping/Pong = for further apps doesn’t appear very convincing to me.

 <= /p>

I’d much rather we = kept Ping/Pong intentionally limited to its original purpose of just being = a bare bones mechanism, and leave any other uses as proper extensions.

 <= /p>

The current text to say t= hat only the last Ping need to be responded to discourages the peers from s= ending more than one, but it would be better to make it explicit that having more than one outstanding Ping (without its correspon= ding Pong) MUST NOT be done.

 <= /p>

I think the 0x00 and 0x01= to distinguish unsolicited Pong is fine.

 <= /p>

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino
Sent: Tuesday, May 17, 2011 04:03
To: hybi@ietf.org
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review o= f draft-ietf-hybi-thewebsocketprotocol-07)

 

Full body matching requirement has been introduced b= y http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-= 03 for both close and ping/pong. What was the original goal of this requirement for ping/pong? Is it still valid= ? Full body matching requirement for close frames has been thrown away afte= r long discussion.

 

Now it looks like it's sufficient to have single boo= lean to indicate it's nop or reply in application data.

 

Here's relaxed version.

 

foo and bar mean "any string"

 

a) implement heartbeat by diverting Pong<= /p>

- Ping would be "Ping foo"

- to reply to "Ping foo", send "Pong = \x00 bar" (bar is foo by default)

- to send unsolicited Pong, send "Pong \x01 bar= "

 

b) implement heartbeat by diverting Ping<= /p>

- to send Normal-Ping, send "Ping \x00 foo"= ;

- to send NOP-Ping, send "Ping \x01 foo"

- to reply "Ping \x00 foo", send "Pon= g bar" (bar is foo by default)

- just ignore "Ping \x01 foo" when receive= d

 

to adopt Bruce's idea, change "(bar is foo by d= efault)" to "(bar is foo + buz)". it implements echo and= allows the receiver to send additional info.

 

I've removed unnecessary \x00 and \x01, but it's fin= e for me to keep them to keep framing symmetric.

 

Takeshi

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402D3F1DTK5EX14MBXW603w_-- From gregw@intalio.com Tue May 17 23:11:20 2011 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 5B3F2E068C for ; Tue, 17 May 2011 23:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.777 X-Spam-Level: X-Spam-Status: No, score=-2.777 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5ioN-AcbVHZ for ; Tue, 17 May 2011 23:11:19 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B4104E0681 for ; Tue, 17 May 2011 23:11:19 -0700 (PDT) Received: by vws12 with SMTP id 12so1048871vws.31 for ; Tue, 17 May 2011 23:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.31.37 with SMTP id x5mr2131429vdh.264.1305699078835; Tue, 17 May 2011 23:11:18 -0700 (PDT) Received: by 10.52.188.35 with HTTP; Tue, 17 May 2011 23:11:18 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 16:11:18 +1000 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Basic question about WS and different browser windows X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 06:11:20 -0000 I=F1aki, I think this is a question for the W3C/WHATWG working groups on websockets. However, expect the answer to your question is going to be tied up in the shared workers mechanism and I have heard it suggested before that for such applications you should arrange for a shared worker to open the WS connection rather than the div itself. My own preference would be that browsers used a MUX system, so that individual frames could open WS connections without any knowledge of how they mapped to TCP/IP connection. So instead of having to explicitly talk to a shared worker to get it to send/receive datagrams on your behalf, you would just use the standard WS javascript API and the MUX extension would work behind the scenes to transport that over a shared connection. cheers On 17 May 2011 22:48, I=F1aki Baz Castillo wrote: > Hi, perhaps this question does not fit well in this maillist, sorry for t= hat. > > Imagine a web-chat application (similar to Gmail chat) in which > different
are created for each chat session within the main > page. Previously the JavaScript in such page has opened a WS > connection with the server which is used for the chat messages. > > Gmail allows opening a chat window into a separate/new windows (a new > browser window, with small size). If we do the same, would it be > needed to open a new WS connection from the new browser window? or > could it share the same connection? (I expect this purely depends on > how JavaScript works....). > > Or perhaps there would be a single WS connection from the main page, > such page would receive new WS messages and could update the HTML of > the other window? > > Just wondering. Thanks a lot. > > -- > I=F1aki Baz Castillo > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ibc@aliax.net Wed May 18 01:28:55 2011 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 8110CE07E2 for ; Wed, 18 May 2011 01:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QW7+MkHnMyBb for ; Wed, 18 May 2011 01:28:54 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2A5E07D9 for ; Wed, 18 May 2011 01:28:53 -0700 (PDT) Received: by qwc23 with SMTP id 23so949050qwc.31 for ; Wed, 18 May 2011 01:28:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr1190367qci.209.1305707331938; Wed, 18 May 2011 01:28:51 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 18 May 2011 01:28:51 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 10:28:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Basic question about WS and different browser windows X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 08:28:55 -0000 2011/5/18 Greg Wilkins : > My own preference would be that browsers used a MUX system, so that > individual frames could open WS connections without any knowledge of > how they mapped to TCP/IP connection. =C2=A0So instead of having to > explicitly talk to a shared worker to get it to send/receive datagrams > on your behalf, you would just use the standard WS javascript API and > the MUX extension would work behind the scenes to transport that over > a shared connection. Thanks. In this case, could the messages received via a single WS connection arrive to two separate windows of the web browser? Interesting stuf here, there are lot of possibilities, but maybe there should be less :) Thanks. --=20 I=C3=B1aki Baz Castillo From izuzak@gmail.com Wed May 18 02:16:33 2011 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 39985E07C6 for ; Wed, 18 May 2011 02:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zie2jcshyDfO for ; Wed, 18 May 2011 02:16:28 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id CE7E0E0671 for ; Wed, 18 May 2011 02:16:27 -0700 (PDT) Received: by vxg33 with SMTP id 33so1127151vxg.31 for ; Wed, 18 May 2011 02:16:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=+49c9orGk8sMvEfNoBCso0QHpaY/Yhgj4TT4ESTSfAk=; b=FTqDEwUx0v0tun5nrMLALEKwwcPjeg6jLoWwBXqYLr9HnaerAcOMfbTur9uiU1xtWs Gj82KIr2QMZU2ZlfvbOirn3cnrLyEcDONPi9cksWzi12TxeyX3z9E1LCwadkuhjTHPJw sk/mkW7tfij0CXX9zm/5IndrOxbUcoAQ+uk1M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=lO78Uc8U4lZQ/wUaQDE7qWwH/SHo+rMURzrom9RsGK7uao4kvuihNAP6LzyfghnpCo fqVdWyalr+XA0qadKoQtP6wtuQY9FAzAEAfdlmhrWRG12pTFnztSr1/EMp8noRt1wTqj Wl5sdsOSo8DdWELCouvps/GnITWNgvjCNCIl8= Received: by 10.52.73.170 with SMTP id m10mr2471365vdv.160.1305710187134; Wed, 18 May 2011 02:16:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.166.164 with HTTP; Wed, 18 May 2011 02:15:57 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?B?SXZhbiDFvXXFvmFr?= Date: Wed, 18 May 2011 11:15:57 +0200 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Basic question about WS and different browser windows X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 09:16:33 -0000 On Wed, May 18, 2011 at 08:11, Greg Wilkins wrote: > I=C3=B1aki, > > I think this is a question for the W3C/WHATWG working groups on websocket= s. > > However, =C2=A0expect the answer to your question is going to be tied up = in > the shared workers mechanism and I have heard it suggested before that > for such applications you should arrange for a shared worker to open > the WS connection rather than the div itself. This is a nit pick (and for a different discussion list) but ... since both the main window and the newly created chat window have the same origin ("https://mail.gmail.com/"), aren't there simpler ways of passing data from the main window to the new one? Since the main window has a reference to the newly created window, it can just write data to that new window's body directly (same-origin policy would allow it). However, in general, if the windows were on different origins, then still you could go about it more simply than using shared workers -- by postMessage-ing data to the new window (since still you'd have a reference to it from the main window). Cheers, Ivan From piotrku@microsoft.com Wed May 18 12:07:28 2011 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 485F9E06BB for ; Wed, 18 May 2011 12:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KP1clNuRhi5v for ; Wed, 18 May 2011 12:07:25 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 90F33E06B1 for ; Wed, 18 May 2011 12:07:25 -0700 (PDT) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 12:07:24 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.28]) by TK5EX14HUBC104.redmond.corp.microsoft.com ([157.54.80.25]) with mapi id 14.01.0289.008; Wed, 18 May 2011 12:07:24 -0700 From: Piotr Kulaga To: Gabriel Montenegro , Takeshi Yoshino , "hybi@ietf.org" Thread-Topic: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07) Thread-Index: AcwVjUa0HJI3Zcy9SlGX7BhtGbiZpw== Date: Wed, 18 May 2011 19:07:24 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.21] Content-Type: multipart/alternative; boundary="_000_ED13A76FCE9E96498B049688227AEA292C6A81E4TK5EX14MBXC206r_" MIME-Version: 1.0 Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 18 May 2011 19:07:28 -0000 --_000_ED13A76FCE9E96498B049688227AEA292C6A81E4TK5EX14MBXC206r_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In my opinion, ping/pong frames should not carry application payload (foo a= nd bar strings). If the payload is not well defined (i.e. reason, timestamp= , etc.) there is no way the peer would understand how it should interpret t= he data. I would leave this problem the a protocol well-defined extensibili= ty mechanism. If application wants to add payload to a ping/pong frame it s= hould negotiate extension with the server and set a reserved bit on the fra= me. This way the basic protocol is simple and application can send/receive = additional data if necessary (and negotiated). I am ok with the 0x00 and 0x01 proposal. From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gab= riel Montenegro Sent: Tuesday, May 17, 2011 12:25 PM To: Takeshi Yoshino; hybi@ietf.org Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft= -ietf-hybi-thewebsocketprotocol-07) [As an individual] I don't think setting Ping/Pong as a platform for further applications is a= good idea, for the same reasons that using ICMP as a platform for more int= elligent applications is a good idea. Since ICMP does not follow the usual = codepaths, any valid network characteristic measurements better not use, an= d they better use traffic that looks more closely like what an actual app w= ould use (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated = as application traffic after network elements start being cognizant of Webs= ockets. So the idea of using Ping/Pong for further apps doesn't appear very= convincing to me. I'd much rather we kept Ping/Pong intentionally limited to its original pur= pose of just being a bare bones mechanism, and leave any other uses as prop= er extensions. The current text to say that only the last Ping need to be responded to dis= courages the peers from sending more than one, but it would be better to ma= ke it explicit that having more than one outstanding Ping (without its corr= esponding Pong) MUST NOT be done. I think the 0x00 and 0x01 to distinguish unsolicited Pong is fine. From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Tak= eshi Yoshino Sent: Tuesday, May 17, 2011 04:03 To: hybi@ietf.org Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft= -ietf-hybi-thewebsocketprotocol-07) Full body matching requirement has been introduced by http://tools.ietf.org= /html/draft-ietf-hybi-thewebsocketprotocol-03 for both close and ping/pong.= What was the original goal of this requirement for ping/pong? Is it still = valid? Full body matching requirement for close frames has been thrown away= after long discussion. Now it looks like it's sufficient to have single boolean to indicate it's n= op or reply in application data. Here's relaxed version. foo and bar mean "any string" a) implement heartbeat by diverting Pong - Ping would be "Ping foo" - to reply to "Ping foo", send "Pong \x00 bar" (bar is foo by default) - to send unsolicited Pong, send "Pong \x01 bar" b) implement heartbeat by diverting Ping - to send Normal-Ping, send "Ping \x00 foo" - to send NOP-Ping, send "Ping \x01 foo" - to reply "Ping \x00 foo", send "Pong bar" (bar is foo by default) - just ignore "Ping \x01 foo" when received to adopt Bruce's idea, change "(bar is foo by default)" to "(bar is foo + b= uz)". it implements echo and allows the receiver to send additional info. I've removed unnecessary \x00 and \x01, but it's fine for me to keep them t= o keep framing symmetric. Takeshi --_000_ED13A76FCE9E96498B049688227AEA292C6A81E4TK5EX14MBXC206r_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In my opinion, ping/pong = frames should not carry application payload (foo and bar strings). If the p= ayload is not well defined (i.e. reason, timestamp, etc.) there is no way the peer would understand how it should interpret the data= . I would leave this problem the a protocol well-defined extensibility mech= anism. If application wants to add payload to a ping/pong frame it should n= egotiate extension with the server and set a reserved bit on the frame. This way the basic protocol is simple= and application can send/receive additional data if necessary (and negotia= ted).

 <= /p>

I am ok with the 0x00 and= 0x01 proposal.

 <= /p>

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gabriel Montenegro
Sent: Tuesday, May 17, 2011 12:25 PM
To: Takeshi Yoshino; hybi@ietf.org
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review o= f draft-ietf-hybi-thewebsocketprotocol-07)

 

[As an individual]

 <= /p>

I don’t think setti= ng Ping/Pong as a platform for further applications is a good idea, for the= same reasons that using ICMP as a platform for more intelligent applications is a good idea. Since ICMP does not follow the usual codepath= s, any valid network characteristic measurements better not use, and they b= etter use traffic that looks more closely like what an actual app would use= (UDP, TCP). Similarly, I would expect Ping/Pong to not be treated as application traffic after network el= ements start being cognizant of Websockets. So the idea of using Ping/Pong = for further apps doesn’t appear very convincing to me.

 <= /p>

I’d much rather we = kept Ping/Pong intentionally limited to its original purpose of just being = a bare bones mechanism, and leave any other uses as proper extensions.

 <= /p>

The current text to say t= hat only the last Ping need to be responded to discourages the peers from s= ending more than one, but it would be better to make it explicit that having more than one outstanding Ping (without its correspon= ding Pong) MUST NOT be done.

 <= /p>

I think the 0x00 and 0x01= to distinguish unsolicited Pong is fine.

 <= /p>

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino
Sent: Tuesday, May 17, 2011 04:03
To: hybi@ietf.org
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review o= f draft-ietf-hybi-thewebsocketprotocol-07)

 

Full body matching requirement has been introduced b= y http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-= 03 for both close and ping/pong. What was the original goal of this requirement for ping/pong? Is it still valid= ? Full body matching requirement for close frames has been thrown away afte= r long discussion.

 

Now it looks like it's sufficient to have single boo= lean to indicate it's nop or reply in application data.

 

Here's relaxed version.

 

foo and bar mean "any string"

 

a) implement heartbeat by diverting Pong<= /p>

- Ping would be "Ping foo"

- to reply to "Ping foo", send "Pong = \x00 bar" (bar is foo by default)

- to send unsolicited Pong, send "Pong \x01 bar= "

 

b) implement heartbeat by diverting Ping<= /p>

- to send Normal-Ping, send "Ping \x00 foo"= ;

- to send NOP-Ping, send "Ping \x01 foo"

- to reply "Ping \x00 foo", send "Pon= g bar" (bar is foo by default)

- just ignore "Ping \x01 foo" when receive= d

 

to adopt Bruce's idea, change "(bar is foo by d= efault)" to "(bar is foo + buz)". it implements echo and= allows the receiver to send additional info.

 

I've removed unnecessary \x00 and \x01, but it's fin= e for me to keep them to keep framing symmetric.

 

Takeshi

 

--_000_ED13A76FCE9E96498B049688227AEA292C6A81E4TK5EX14MBXC206r_-- From ibc@aliax.net Wed May 18 12:09:01 2011 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 6C4C6E06BB for ; Wed, 18 May 2011 12:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YK5mpAH22ozu for ; Wed, 18 May 2011 12:09:00 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 90309E06B1 for ; Wed, 18 May 2011 12:09:00 -0700 (PDT) Received: by qwc23 with SMTP id 23so1388101qwc.31 for ; Wed, 18 May 2011 12:09:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.67.142 with SMTP id r14mr1736581qci.209.1305745739719; Wed, 18 May 2011 12:08:59 -0700 (PDT) Received: by 10.229.225.136 with HTTP; Wed, 18 May 2011 12:08:59 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 May 2011 21:08:59 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?B?SXZhbiDFvXXFvmFr?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] Basic question about WS and different browser windows X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 19:09:01 -0000 2011/5/18 Ivan =C5=BDu=C5=BEak : > Since the main > window has a reference to the newly created window, it can just write > data to that new window's body directly (same-origin policy would > allow it). I expect JavaScript allows that, but I'm not an expert in JavaScript :) Thanks for the explanation. --=20 I=C3=B1aki Baz Castillo From theturtle32@gmail.com Wed May 18 13:06:04 2011 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 8D28DE0778 for ; Wed, 18 May 2011 13:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyBQzdXXo1Z3 for ; Wed, 18 May 2011 13:06:03 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id A4AA9E0771 for ; Wed, 18 May 2011 13:06:03 -0700 (PDT) Received: by pwi5 with SMTP id 5so1232248pwi.31 for ; Wed, 18 May 2011 13:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=F/OGf5f9mRpdXz/oEk5/tS43cA+jOifiWZHfth+3XFs=; b=YCHpWUtVEIExfs+r3TD/ROZKaXYlaV4HeMBVIaTTqxH2n/TGbQdbsxQ3u9xQzIZTvN ygvfKEuMc3LH+MTiAjVDAMPFKbTznJIy2vWT9vT8IGpIprGG0YB52TCrOnMJ0KiDaaY6 CJ6Aia0hps2Xzg5c6eOJ5WPv/FXNjQidxrqjk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=s6udV+o1Sf0MFaKlwnqevUis/Z9emXa6gVh82wlBDNbGYKK+JZvZpJU4TbHiRxWcFB cfvxbXDSAXllfymsQvWDKPYp102LyqeBYOJtQf0QGzbhal0ngOlkNAxZf5OHB3k1Sdgq di5ELr1nAjU4uahwJWMqJGm4hX7R+Jbr6lf9c= Received: by 10.68.20.38 with SMTP id k6mr3409400pbe.410.1305749163238; Wed, 18 May 2011 13:06:03 -0700 (PDT) Received: from [10.0.109.211] (mobile-198-228-208-002.mycingular.net [198.228.208.2]) by mx.google.com with ESMTPS id k10sm1248661pbl.76.2011.05.18.13.05.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 13:06:01 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-5-1024443533 Message-Id: X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Wed, 18 May 2011 13:05:52 -0700 To: Piotr Kulaga Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 18 May 2011 20:06:04 -0000 --Apple-Mail-5-1024443533 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 I also see no purpose for correlating ping/pong data. Or restricting the nu= mber of outstanding pings. If you send 5 pings, you should expect 5 pongs, e= nd of story. The only real purpose for them is to see if the other end is s= till responsive, so send a ping and if you haven't gotten a pong after a cer= tain user-decided timeout, close the connection. It needs no further compli= cation. Brian Sent from my iPhone On May 18, 2011, at 12:07 PM, Piotr Kulaga wrote: > In my opinion, ping/pong frames should not carry application payload (foo a= nd bar strings). If the payload is not well defined (i.e. reason, timestamp,= etc.) there is no way the peer would understand how it should interpret the= data. I would leave this problem the a protocol well-defined extensibility m= echanism. If application wants to add payload to a ping/pong frame it should= negotiate extension with the server and set a reserved bit on the frame. Th= is way the basic protocol is simple and application can send/receive additio= nal data if necessary (and negotiated). >=20 > =20 >=20 > I am ok with the 0x00 and 0x01 proposal. >=20 > =20 >=20 > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Ga= briel Montenegro > Sent: Tuesday, May 17, 2011 12:25 PM > To: Takeshi Yoshino; hybi@ietf.org > Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draf= t-ietf-hybi-thewebsocketprotocol-07) >=20 > =20 >=20 > [As an individual] >=20 > =20 >=20 > I don=E2=80=99t think setting Ping/Pong as a platform for further applicat= ions is a good idea, for the same reasons that using ICMP as a platform for m= ore intelligent applications is a good idea. Since ICMP does not follow the u= sual codepaths, any valid network characteristic measurements better not use= , and they better use traffic that looks more closely like what an actual ap= p would use (UDP, TCP). Similarly, I would expect Ping/Pong to not be treate= d as application traffic after network elements start being cognizant of Web= sockets. So the idea of using Ping/Pong for further apps doesn=E2=80=99t app= ear very convincing to me. >=20 > =20 >=20 > I=E2=80=99d much rather we kept Ping/Pong intentionally limited to its ori= ginal purpose of just being a bare bones mechanism, and leave any other uses= as proper extensions.=20 >=20 > =20 >=20 > The current text to say that only the last Ping need to be responded to di= scourages the peers from sending more than one, but it would be better to ma= ke it explicit that having more than one outstanding Ping (without its corre= sponding Pong) MUST NOT be done. >=20 > =20 >=20 > I think the 0x00 and 0x01 to distinguish unsolicited Pong is fine. >=20 > =20 >=20 > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Ta= keshi Yoshino > Sent: Tuesday, May 17, 2011 04:03 > To: hybi@ietf.org > Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draf= t-ietf-hybi-thewebsocketprotocol-07) >=20 > =20 >=20 > Full body matching requirement has been introduced by http://tools.ietf.or= g/html/draft-ietf-hybi-thewebsocketprotocol-03 for both close and ping/pong.= What was the original goal of this requirement for ping/pong? Is it still v= alid? Full body matching requirement for close frames has been thrown away a= fter long discussion. >=20 > =20 >=20 > Now it looks like it's sufficient to have single boolean to indicate it's n= op or reply in application data. >=20 > =20 >=20 > Here's relaxed version. >=20 > =20 >=20 > foo and bar mean "any string" >=20 > =20 >=20 > a) implement heartbeat by diverting Pong >=20 > - Ping would be "Ping foo" >=20 > - to reply to "Ping foo", send "Pong \x00 bar" (bar is foo by default) >=20 > - to send unsolicited Pong, send "Pong \x01 bar" >=20 > =20 >=20 > b) implement heartbeat by diverting Ping >=20 > - to send Normal-Ping, send "Ping \x00 foo" >=20 > - to send NOP-Ping, send "Ping \x01 foo" >=20 > - to reply "Ping \x00 foo", send "Pong bar" (bar is foo by default) >=20 > - just ignore "Ping \x01 foo" when received >=20 > =20 >=20 > to adopt Bruce's idea, change "(bar is foo by default)" to "(bar is foo + b= uz)". it implements echo and allows the receiver to send additional info. >=20 > =20 >=20 > I've removed unnecessary \x00 and \x01, but it's fine for me to keep them t= o keep framing symmetric. >=20 > =20 >=20 > Takeshi >=20 > =20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --Apple-Mail-5-1024443533 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
+1
I also see no purpose for c= orrelating ping/pong data.  Or restricting the number of outstanding pi= ngs.  If you send 5 pings, you should expect 5 pongs, end of story. &nb= sp;The only real purpose for them is to see if the other end is still respon= sive, so send a ping and if you haven't gotten a pong after a certain user-d= ecided timeout, close the connection.  It needs no further complication= .

Brian


Sent from my iPhone
=

On May 18, 2011, at 12:07 PM, Piotr Kulaga <piotrku@microsoft.com> wrote:

=

In my opinion, ping/pong fr= ames should not carry application payload (foo and bar strings). If the payl= oad is not well defined (i.e. reason, timestamp, etc.) there is no way the peer would understand how it should interpret the data.= I would leave this problem the a protocol well-defined extensibility mechan= ism. If application wants to add payload to a ping/pong frame it should nego= tiate extension with the server and set a reserved bit on the frame. This way the basic protocol is simple a= nd application can send/receive additional data if necessary (and negotiated= ).

 

I am ok with the 0x00 and 0= x01 proposal.

 

From: hybi-bounces@ietf.org [mailto:hybi-bounces= @ietf.org] On Behalf Of Gabriel Montenegro
Sent: Tuesday, May 17, 2011 12:25 PM
To: Takeshi Yoshino; hybi@ietf.org
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of= draft-ietf-hybi-thewebsocketprotocol-07)

 

[As an individual]

 

I don=E2=80=99t think setti= ng Ping/Pong as a platform for further applications is a good idea, for the s= ame reasons that using ICMP as a platform for more intelligent applications is a good idea. Since ICMP does not follow the usual codepaths= , any valid network characteristic measurements better not use, and they bet= ter use traffic that looks more closely like what an actual app would use (U= DP, TCP). Similarly, I would expect Ping/Pong to not be treated as application traffic after network ele= ments start being cognizant of Websockets. So the idea of using Ping/Pong fo= r further apps doesn=E2=80=99t appear very convincing to me.

 

I=E2=80=99d much rather we k= ept Ping/Pong intentionally limited to its original purpose of just being a b= are bones mechanism, and leave any other uses as proper extensions.

 

The current text to say tha= t only the last Ping need to be responded to discourages the peers from send= ing more than one, but it would be better to make it explicit that having more than one outstanding Ping (without its correspond= ing Pong) MUST NOT be done.

 

I think the 0x00 and 0x01 t= o distinguish unsolicited Pong is fine.

 

From: hybi-bounces@ietf.org [mailto:hybi-bounces= @ietf.org] On Behalf Of Takeshi Yoshino
Sent: Tuesday, May 17, 2011 04:03
To: hybi@ietf.org
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of= draft-ietf-hybi-thewebsocketprotocol-07)

 

Full body matching requirement has been introduced by=  http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-= 03 for both close and ping/pong. What was the original goal of this requirement for ping/pong? Is it still valid?= Full body matching requirement for close frames has been thrown away after l= ong discussion.

 

Now it looks like it's sufficient to have single bool= ean to indicate it's nop or reply in application data.

 

Here's relaxed version.

 

foo and bar mean "any string"

 

a) implement heartbeat by diverting Pong

- Ping would be "Ping foo"

- to reply to "Ping foo", send "Pong \x00 bar" (bar i= s foo by default)

- to send unsolicited Pong, send "Pong \x01 bar"=

 

b) implement heartbeat by diverting Ping

- to send Normal-Ping, send "Ping \x00 foo"

- to send NOP-Ping, send "Ping \x01 foo"

- to reply "Ping \x00 foo", send "Pong bar" (bar is f= oo by default)

- just ignore "Ping \x01 foo" when received

 

to adopt Bruce's idea, change "(bar is foo by default= )" to "(bar is foo + buz)". it implements echo and allows the receiver to se= nd additional info.

 

I've removed unnecessary \x00 and \x01, but it's fine= for me to keep them to keep framing symmetric.

 

Takeshi

 

____________________= ___________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman= /listinfo/hybi
= --Apple-Mail-5-1024443533-- From piotrku@microsoft.com Wed May 18 17:43:18 2011 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 97742E06C2 for ; Wed, 18 May 2011 17:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBoaRfwfFGpF for ; Wed, 18 May 2011 17:43:17 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 4100BE0674 for ; Wed, 18 May 2011 17:43:17 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 18 May 2011 17:43:16 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.28]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.01.0289.008; Wed, 18 May 2011 17:43:16 -0700 From: Piotr Kulaga To: Brian McKelvey Thread-Topic: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07) Thread-Index: AcwVjUa0HJI3Zcy9SlGX7BhtGbiZpwARGKcAAAVSYfA= Date: Thu, 19 May 2011 00:43:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.21] Content-Type: multipart/alternative; boundary="_000_ED13A76FCE9E96498B049688227AEA292C6A85DETK5EX14MBXC206r_" MIME-Version: 1.0 Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 19 May 2011 00:43:18 -0000 --_000_ED13A76FCE9E96498B049688227AEA292C6A85DETK5EX14MBXC206r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGVyc29uYWxseSBJIGRvIG5vdCBzZWUgYW55IHBvaW50IG9mIGFsbG93aW5nIG11bHRpcGxlIG91 dHN0YW5kaW5nIHBpbmdzLiBJZiBhIHNlbmRlciBkaWQgbm90IGdldCBhIHJlc3BvbnNlIHRvIGZp cnN0IG9mIHRoZW0sIHNlbmRpbmcgYW5vdGhlciBvbmUgcHJvYmFibHkgd2lsbCBub3QgaW5jcmVh c2UgaXRzIGNoYW5jZXMuIFRvIG1lLCBzYXlpbmcgdGhhdCBvbmx5IG9uZSBwaW5nIGlzIGFsbG93 ZWQgaXMgYSBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgcHJvdG9jb2wgd2hpY2ggZG9lcyBub3QgbGlt aXQgcHJvdG9jb2zigJlzIGZ1bmN0aW9uYWxpdHkuDQoNCkZyb206IEJyaWFuIE1jS2VsdmV5IFtt YWlsdG86dGhldHVydGxlMzJAZ21haWwuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBNYXkgMTgsIDIw MTEgMTowNiBQTQ0KVG86IFBpb3RyIEt1bGFnYQ0KQ2M6IEdhYnJpZWwgTW9udGVuZWdybzsgVGFr ZXNoaSBZb3NoaW5vOyBoeWJpQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW2h5YmldIFBpbmcvUG9u ZyBib2R5ICh3YXMgUmU6IFRTVi1EaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1oeWJp LXRoZXdlYnNvY2tldHByb3RvY29sLTA3KQ0KDQorMQ0KSSBhbHNvIHNlZSBubyBwdXJwb3NlIGZv ciBjb3JyZWxhdGluZyBwaW5nL3BvbmcgZGF0YS4gIE9yIHJlc3RyaWN0aW5nIHRoZSBudW1iZXIg b2Ygb3V0c3RhbmRpbmcgcGluZ3MuICBJZiB5b3Ugc2VuZCA1IHBpbmdzLCB5b3Ugc2hvdWxkIGV4 cGVjdCA1IHBvbmdzLCBlbmQgb2Ygc3RvcnkuICBUaGUgb25seSByZWFsIHB1cnBvc2UgZm9yIHRo ZW0gaXMgdG8gc2VlIGlmIHRoZSBvdGhlciBlbmQgaXMgc3RpbGwgcmVzcG9uc2l2ZSwgc28gc2Vu ZCBhIHBpbmcgYW5kIGlmIHlvdSBoYXZlbid0IGdvdHRlbiBhIHBvbmcgYWZ0ZXIgYSBjZXJ0YWlu IHVzZXItZGVjaWRlZCB0aW1lb3V0LCBjbG9zZSB0aGUgY29ubmVjdGlvbi4gIEl0IG5lZWRzIG5v IGZ1cnRoZXIgY29tcGxpY2F0aW9uLg0KDQpCcmlhbg0KDQoNClNlbnQgZnJvbSBteSBpUGhvbmUN Cg0KT24gTWF5IDE4LCAyMDExLCBhdCAxMjowNyBQTSwgUGlvdHIgS3VsYWdhIDxwaW90cmt1QG1p Y3Jvc29mdC5jb208bWFpbHRvOnBpb3Rya3VAbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KSW4gbXkg b3BpbmlvbiwgcGluZy9wb25nIGZyYW1lcyBzaG91bGQgbm90IGNhcnJ5IGFwcGxpY2F0aW9uIHBh eWxvYWQgKGZvbyBhbmQgYmFyIHN0cmluZ3MpLiBJZiB0aGUgcGF5bG9hZCBpcyBub3Qgd2VsbCBk ZWZpbmVkIChpLmUuIHJlYXNvbiwgdGltZXN0YW1wLCBldGMuKSB0aGVyZSBpcyBubyB3YXkgdGhl IHBlZXIgd291bGQgdW5kZXJzdGFuZCBob3cgaXQgc2hvdWxkIGludGVycHJldCB0aGUgZGF0YS4g SSB3b3VsZCBsZWF2ZSB0aGlzIHByb2JsZW0gdGhlIGEgcHJvdG9jb2wgd2VsbC1kZWZpbmVkIGV4 dGVuc2liaWxpdHkgbWVjaGFuaXNtLiBJZiBhcHBsaWNhdGlvbiB3YW50cyB0byBhZGQgcGF5bG9h ZCB0byBhIHBpbmcvcG9uZyBmcmFtZSBpdCBzaG91bGQgbmVnb3RpYXRlIGV4dGVuc2lvbiB3aXRo IHRoZSBzZXJ2ZXIgYW5kIHNldCBhIHJlc2VydmVkIGJpdCBvbiB0aGUgZnJhbWUuIFRoaXMgd2F5 IHRoZSBiYXNpYyBwcm90b2NvbCBpcyBzaW1wbGUgYW5kIGFwcGxpY2F0aW9uIGNhbiBzZW5kL3Jl Y2VpdmUgYWRkaXRpb25hbCBkYXRhIGlmIG5lY2Vzc2FyeSAoYW5kIG5lZ290aWF0ZWQpLg0KDQpJ IGFtIG9rIHdpdGggdGhlIDB4MDAgYW5kIDB4MDEgcHJvcG9zYWwuDQoNCkZyb206IGh5YmktYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmh5Ymkt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEdhYnJpZWwgTW9udGVuZWdybw0KU2VudDog VHVlc2RheSwgTWF5IDE3LCAyMDExIDEyOjI1IFBNDQpUbzogVGFrZXNoaSBZb3NoaW5vOyBoeWJp QGlldGYub3JnPG1haWx0bzpoeWJpQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtoeWJpXSBQaW5n L1BvbmcgYm9keSAod2FzIFJlOiBUU1YtRGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYt aHliaS10aGV3ZWJzb2NrZXRwcm90b2NvbC0wNykNCg0KW0FzIGFuIGluZGl2aWR1YWxdDQoNCkkg ZG9u4oCZdCB0aGluayBzZXR0aW5nIFBpbmcvUG9uZyBhcyBhIHBsYXRmb3JtIGZvciBmdXJ0aGVy IGFwcGxpY2F0aW9ucyBpcyBhIGdvb2QgaWRlYSwgZm9yIHRoZSBzYW1lIHJlYXNvbnMgdGhhdCB1 c2luZyBJQ01QIGFzIGEgcGxhdGZvcm0gZm9yIG1vcmUgaW50ZWxsaWdlbnQgYXBwbGljYXRpb25z IGlzIGEgZ29vZCBpZGVhLiBTaW5jZSBJQ01QIGRvZXMgbm90IGZvbGxvdyB0aGUgdXN1YWwgY29k ZXBhdGhzLCBhbnkgdmFsaWQgbmV0d29yayBjaGFyYWN0ZXJpc3RpYyBtZWFzdXJlbWVudHMgYmV0 dGVyIG5vdCB1c2UsIGFuZCB0aGV5IGJldHRlciB1c2UgdHJhZmZpYyB0aGF0IGxvb2tzIG1vcmUg Y2xvc2VseSBsaWtlIHdoYXQgYW4gYWN0dWFsIGFwcCB3b3VsZCB1c2UgKFVEUCwgVENQKS4gU2lt aWxhcmx5LCBJIHdvdWxkIGV4cGVjdCBQaW5nL1BvbmcgdG8gbm90IGJlIHRyZWF0ZWQgYXMgYXBw bGljYXRpb24gdHJhZmZpYyBhZnRlciBuZXR3b3JrIGVsZW1lbnRzIHN0YXJ0IGJlaW5nIGNvZ25p emFudCBvZiBXZWJzb2NrZXRzLiBTbyB0aGUgaWRlYSBvZiB1c2luZyBQaW5nL1BvbmcgZm9yIGZ1 cnRoZXIgYXBwcyBkb2VzbuKAmXQgYXBwZWFyIHZlcnkgY29udmluY2luZyB0byBtZS4NCg0KSeKA mWQgbXVjaCByYXRoZXIgd2Uga2VwdCBQaW5nL1BvbmcgaW50ZW50aW9uYWxseSBsaW1pdGVkIHRv IGl0cyBvcmlnaW5hbCBwdXJwb3NlIG9mIGp1c3QgYmVpbmcgYSBiYXJlIGJvbmVzIG1lY2hhbmlz bSwgYW5kIGxlYXZlIGFueSBvdGhlciB1c2VzIGFzIHByb3BlciBleHRlbnNpb25zLg0KDQpUaGUg Y3VycmVudCB0ZXh0IHRvIHNheSB0aGF0IG9ubHkgdGhlIGxhc3QgUGluZyBuZWVkIHRvIGJlIHJl c3BvbmRlZCB0byBkaXNjb3VyYWdlcyB0aGUgcGVlcnMgZnJvbSBzZW5kaW5nIG1vcmUgdGhhbiBv bmUsIGJ1dCBpdCB3b3VsZCBiZSBiZXR0ZXIgdG8gbWFrZSBpdCBleHBsaWNpdCB0aGF0IGhhdmlu ZyBtb3JlIHRoYW4gb25lIG91dHN0YW5kaW5nIFBpbmcgKHdpdGhvdXQgaXRzIGNvcnJlc3BvbmRp bmcgUG9uZykgTVVTVCBOT1QgYmUgZG9uZS4NCg0KSSB0aGluayB0aGUgMHgwMCBhbmQgMHgwMSB0 byBkaXN0aW5ndWlzaCB1bnNvbGljaXRlZCBQb25nIGlzIGZpbmUuDQoNCkZyb206IGh5YmktYm91 bmNlc0BpZXRmLm9yZzxtYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnPiBbbWFpbHRvOmh5Ymkt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRha2VzaGkgWW9zaGlubw0KU2VudDogVHVl c2RheSwgTWF5IDE3LCAyMDExIDA0OjAzDQpUbzogaHliaUBpZXRmLm9yZzxtYWlsdG86aHliaUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbaHliaV0gUGluZy9Qb25nIGJvZHkgKHdhcyBSZTogVFNW LURpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRmLWh5YmktdGhld2Vic29ja2V0cHJvdG9j b2wtMDcpDQoNCkZ1bGwgYm9keSBtYXRjaGluZyByZXF1aXJlbWVudCBoYXMgYmVlbiBpbnRyb2R1 Y2VkIGJ5IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaHliaS10aGV3ZWJz b2NrZXRwcm90b2NvbC0wMyBmb3IgYm90aCBjbG9zZSBhbmQgcGluZy9wb25nLiBXaGF0IHdhcyB0 aGUgb3JpZ2luYWwgZ29hbCBvZiB0aGlzIHJlcXVpcmVtZW50IGZvciBwaW5nL3Bvbmc/IElzIGl0 IHN0aWxsIHZhbGlkPyBGdWxsIGJvZHkgbWF0Y2hpbmcgcmVxdWlyZW1lbnQgZm9yIGNsb3NlIGZy YW1lcyBoYXMgYmVlbiB0aHJvd24gYXdheSBhZnRlciBsb25nIGRpc2N1c3Npb24uDQoNCk5vdyBp dCBsb29rcyBsaWtlIGl0J3Mgc3VmZmljaWVudCB0byBoYXZlIHNpbmdsZSBib29sZWFuIHRvIGlu ZGljYXRlIGl0J3Mgbm9wIG9yIHJlcGx5IGluIGFwcGxpY2F0aW9uIGRhdGEuDQoNCkhlcmUncyBy ZWxheGVkIHZlcnNpb24uDQoNCmZvbyBhbmQgYmFyIG1lYW4gImFueSBzdHJpbmciDQoNCmEpIGlt cGxlbWVudCBoZWFydGJlYXQgYnkgZGl2ZXJ0aW5nIFBvbmcNCi0gUGluZyB3b3VsZCBiZSAiUGlu ZyBmb28iDQotIHRvIHJlcGx5IHRvICJQaW5nIGZvbyIsIHNlbmQgIlBvbmcgXHgwMCBiYXIiIChi YXIgaXMgZm9vIGJ5IGRlZmF1bHQpDQotIHRvIHNlbmQgdW5zb2xpY2l0ZWQgUG9uZywgc2VuZCAi UG9uZyBceDAxIGJhciINCg0KYikgaW1wbGVtZW50IGhlYXJ0YmVhdCBieSBkaXZlcnRpbmcgUGlu Zw0KLSB0byBzZW5kIE5vcm1hbC1QaW5nLCBzZW5kICJQaW5nIFx4MDAgZm9vIg0KLSB0byBzZW5k IE5PUC1QaW5nLCBzZW5kICJQaW5nIFx4MDEgZm9vIg0KLSB0byByZXBseSAiUGluZyBceDAwIGZv byIsIHNlbmQgIlBvbmcgYmFyIiAoYmFyIGlzIGZvbyBieSBkZWZhdWx0KQ0KLSBqdXN0IGlnbm9y ZSAiUGluZyBceDAxIGZvbyIgd2hlbiByZWNlaXZlZA0KDQp0byBhZG9wdCBCcnVjZSdzIGlkZWEs IGNoYW5nZSAiKGJhciBpcyBmb28gYnkgZGVmYXVsdCkiIHRvICIoYmFyIGlzIGZvbyArIGJ1eiki LiBpdCBpbXBsZW1lbnRzIGVjaG8gYW5kIGFsbG93cyB0aGUgcmVjZWl2ZXIgdG8gc2VuZCBhZGRp dGlvbmFsIGluZm8uDQoNCkkndmUgcmVtb3ZlZCB1bm5lY2Vzc2FyeSBceDAwIGFuZCBceDAxLCBi dXQgaXQncyBmaW5lIGZvciBtZSB0byBrZWVwIHRoZW0gdG8ga2VlcCBmcmFtaW5nIHN5bW1ldHJp Yy4NCg0KVGFrZXNoaQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KaHliaSBtYWlsaW5nIGxpc3QNCmh5YmlAaWV0Zi5vcmc8bWFpbHRvOmh5YmlAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkNCg== --_000_ED13A76FCE9E96498B049688227AEA292C6A85DETK5EX14MBXC206r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0 IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9v biBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UGVyc29uYWxseSBJIGRvIG5vdCBzZWUgYW55IHBvaW50IG9mIGFsbG93aW5nIG11bHRpcGxl IG91dHN0YW5kaW5nIHBpbmdzLiBJZiBhIHNlbmRlciBkaWQgbm90IGdldCBhIHJlc3BvbnNlIHRv IGZpcnN0IG9mIHRoZW0sIHNlbmRpbmcgYW5vdGhlciBvbmUgcHJvYmFibHkNCiB3aWxsIG5vdCBp bmNyZWFzZSBpdHMgY2hhbmNlcy4gVG8gbWUsIHNheWluZyB0aGF0IG9ubHkgb25lIHBpbmcgaXMg YWxsb3dlZCBpcyBhIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSBwcm90b2NvbCB3aGljaCBkb2VzIG5v dCBsaW1pdCBwcm90b2NvbOKAmXMgZnVuY3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBC cmlhbiBNY0tlbHZleSBbbWFpbHRvOnRoZXR1cnRsZTMyQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNl bnQ6PC9iPiBXZWRuZXNkYXksIE1heSAxOCwgMjAxMSAxOjA2IFBNPGJyPg0KPGI+VG86PC9iPiBQ aW90ciBLdWxhZ2E8YnI+DQo8Yj5DYzo8L2I+IEdhYnJpZWwgTW9udGVuZWdybzsgVGFrZXNoaSBZ b3NoaW5vOyBoeWJpQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gUGlu Zy9Qb25nIGJvZHkgKHdhcyBSZTogVFNWLURpcmVjdG9yYXRlIHJldmlldyBvZiBkcmFmdC1pZXRm LWh5YmktdGhld2Vic29ja2V0cHJvdG9jb2wtMDcpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiYjNDM7MTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbHNvIHNlZSBubyBwdXJwb3NlIGZvciBj b3JyZWxhdGluZyBwaW5nL3BvbmcgZGF0YS4gJm5ic3A7T3IgcmVzdHJpY3RpbmcgdGhlIG51bWJl ciBvZiBvdXRzdGFuZGluZyBwaW5ncy4gJm5ic3A7SWYgeW91IHNlbmQgNSBwaW5ncywgeW91IHNo b3VsZCBleHBlY3QgNSBwb25ncywgZW5kIG9mIHN0b3J5LiAmbmJzcDtUaGUgb25seSByZWFsIHB1 cnBvc2UgZm9yIHRoZW0gaXMgdG8gc2VlIGlmIHRoZSBvdGhlciBlbmQgaXMgc3RpbGwgcmVzcG9u c2l2ZSwNCiBzbyBzZW5kIGEgcGluZyBhbmQgaWYgeW91IGhhdmVuJ3QgZ290dGVuIGEgcG9uZyBh ZnRlciBhIGNlcnRhaW4gdXNlci1kZWNpZGVkIHRpbWVvdXQsIGNsb3NlIHRoZSBjb25uZWN0aW9u LiAmbmJzcDtJdCBuZWVkcyBubyBmdXJ0aGVyIGNvbXBsaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJpYW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NClNlbnQg ZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gTWF5IDE4LCAy MDExLCBhdCAxMjowNyBQTSwgUGlvdHIgS3VsYWdhICZsdDs8YSBocmVmPSJtYWlsdG86cGlvdHJr dUBtaWNyb3NvZnQuY29tIj5waW90cmt1QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIG15IG9waW5p b24sIHBpbmcvcG9uZyBmcmFtZXMgc2hvdWxkIG5vdCBjYXJyeSBhcHBsaWNhdGlvbiBwYXlsb2Fk IChmb28gYW5kIGJhciBzdHJpbmdzKS4gSWYgdGhlDQogcGF5bG9hZCBpcyBub3Qgd2VsbCBkZWZp bmVkIChpLmUuIHJlYXNvbiwgdGltZXN0YW1wLCBldGMuKSB0aGVyZSBpcyBubyB3YXkgdGhlIHBl ZXIgd291bGQgdW5kZXJzdGFuZCBob3cgaXQgc2hvdWxkIGludGVycHJldCB0aGUgZGF0YS4gSSB3 b3VsZCBsZWF2ZSB0aGlzIHByb2JsZW0gdGhlIGEgcHJvdG9jb2wgd2VsbC1kZWZpbmVkIGV4dGVu c2liaWxpdHkgbWVjaGFuaXNtLiBJZiBhcHBsaWNhdGlvbiB3YW50cyB0byBhZGQgcGF5bG9hZCB0 byBhDQogcGluZy9wb25nIGZyYW1lIGl0IHNob3VsZCBuZWdvdGlhdGUgZXh0ZW5zaW9uIHdpdGgg dGhlIHNlcnZlciBhbmQgc2V0IGEgcmVzZXJ2ZWQgYml0IG9uIHRoZSBmcmFtZS4gVGhpcyB3YXkg dGhlIGJhc2ljIHByb3RvY29sIGlzIHNpbXBsZSBhbmQgYXBwbGljYXRpb24gY2FuIHNlbmQvcmVj ZWl2ZSBhZGRpdGlvbmFsIGRhdGEgaWYgbmVjZXNzYXJ5IChhbmQgbmVnb3RpYXRlZCkuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+SSBhbSBvayB3aXRoIHRoZSAweDAwIGFuZCAweDAxIHByb3Bvc2FsLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPg0KPGEgaHJlZj0ibWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZyI+ aHliaS1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZ10N CjxiPk9uIEJlaGFsZiBPZiA8L2I+R2FicmllbCBNb250ZW5lZ3JvPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIE1heSAxNywgMjAxMSAxMjoyNSBQTTxicj4NCjxiPlRvOjwvYj4gVGFrZXNoaSBZ b3NoaW5vOyA8YSBocmVmPSJtYWlsdG86aHliaUBpZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtoeWJpXSBQaW5nL1BvbmcgYm9keSAod2FzIFJlOiBU U1YtRGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaHliaS10aGV3ZWJzb2NrZXRwcm90 b2NvbC0wNyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltBcyBhbiBpbmRp dmlkdWFsXTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgZG9u4oCZdCB0aGluayBzZXR0aW5nIFBpbmcvUG9uZyBh cyBhIHBsYXRmb3JtIGZvciBmdXJ0aGVyIGFwcGxpY2F0aW9ucyBpcyBhIGdvb2QgaWRlYSwgZm9y IHRoZSBzYW1lDQogcmVhc29ucyB0aGF0IHVzaW5nIElDTVAgYXMgYSBwbGF0Zm9ybSBmb3IgbW9y ZSBpbnRlbGxpZ2VudCBhcHBsaWNhdGlvbnMgaXMgYSBnb29kIGlkZWEuIFNpbmNlIElDTVAgZG9l cyBub3QgZm9sbG93IHRoZSB1c3VhbCBjb2RlcGF0aHMsIGFueSB2YWxpZCBuZXR3b3JrIGNoYXJh Y3RlcmlzdGljIG1lYXN1cmVtZW50cyBiZXR0ZXIgbm90IHVzZSwgYW5kIHRoZXkgYmV0dGVyIHVz ZSB0cmFmZmljIHRoYXQgbG9va3MgbW9yZSBjbG9zZWx5IGxpa2Ugd2hhdA0KIGFuIGFjdHVhbCBh cHAgd291bGQgdXNlIChVRFAsIFRDUCkuIFNpbWlsYXJseSwgSSB3b3VsZCBleHBlY3QgUGluZy9Q b25nIHRvIG5vdCBiZSB0cmVhdGVkIGFzIGFwcGxpY2F0aW9uIHRyYWZmaWMgYWZ0ZXIgbmV0d29y ayBlbGVtZW50cyBzdGFydCBiZWluZyBjb2duaXphbnQgb2YgV2Vic29ja2V0cy4gU28gdGhlIGlk ZWEgb2YgdXNpbmcgUGluZy9Qb25nIGZvciBmdXJ0aGVyIGFwcHMgZG9lc27igJl0IGFwcGVhciB2 ZXJ5IGNvbnZpbmNpbmcgdG8gbWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SeKAmWQgbXVjaCByYXRoZXIgd2Ug a2VwdCBQaW5nL1BvbmcgaW50ZW50aW9uYWxseSBsaW1pdGVkIHRvIGl0cyBvcmlnaW5hbCBwdXJw b3NlIG9mIGp1c3QgYmVpbmcgYSBiYXJlDQogYm9uZXMgbWVjaGFuaXNtLCBhbmQgbGVhdmUgYW55 IG90aGVyIHVzZXMgYXMgcHJvcGVyIGV4dGVuc2lvbnMuIDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBjdXJy ZW50IHRleHQgdG8gc2F5IHRoYXQgb25seSB0aGUgbGFzdCBQaW5nIG5lZWQgdG8gYmUgcmVzcG9u ZGVkIHRvIGRpc2NvdXJhZ2VzIHRoZSBwZWVycyBmcm9tDQogc2VuZGluZyBtb3JlIHRoYW4gb25l LCBidXQgaXQgd291bGQgYmUgYmV0dGVyIHRvIG1ha2UgaXQgZXhwbGljaXQgdGhhdCBoYXZpbmcg bW9yZSB0aGFuIG9uZSBvdXRzdGFuZGluZyBQaW5nICh3aXRob3V0IGl0cyBjb3JyZXNwb25kaW5n IFBvbmcpIE1VU1QgTk9UIGJlIGRvbmUuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSAweDAw IGFuZCAweDAxIHRvIGRpc3Rpbmd1aXNoIHVuc29saWNpdGVkIFBvbmcgaXMgZmluZS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+DQo8YSBocmVmPSJtYWls dG86aHliaS1ib3VuY2VzQGlldGYub3JnIj5oeWJpLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWls dG86aHliaS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5UYWtlc2hpIFlv c2hpbm88YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWF5IDE3LCAyMDExIDA0OjAzPGJyPg0K PGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86aHliaUBpZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtoeWJpXSBQaW5nL1BvbmcgYm9keSAod2FzIFJl OiBUU1YtRGlyZWN0b3JhdGUgcmV2aWV3IG9mIGRyYWZ0LWlldGYtaHliaS10aGV3ZWJzb2NrZXRw cm90b2NvbC0wNyk8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkZ1bGwgYm9keSBtYXRjaGluZyByZXF1aXJlbWVudCBoYXMgYmVlbiBpbnRy b2R1Y2VkIGJ5Jm5ic3A7PGEgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1oeWJpLXRoZXdlYnNvY2tldHByb3RvY29sLTAzIj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLWh5YmktdGhld2Vic29ja2V0cHJvdG9jb2wtMDM8L2E+Jm5ic3A7Zm9y DQogYm90aCBjbG9zZSBhbmQgcGluZy9wb25nLiBXaGF0IHdhcyB0aGUgb3JpZ2luYWwgZ29hbCBv ZiB0aGlzIHJlcXVpcmVtZW50IGZvciBwaW5nL3Bvbmc/IElzIGl0IHN0aWxsIHZhbGlkPyBGdWxs IGJvZHkgbWF0Y2hpbmcgcmVxdWlyZW1lbnQgZm9yIGNsb3NlIGZyYW1lcyBoYXMgYmVlbiB0aHJv d24gYXdheSBhZnRlciBsb25nIGRpc2N1c3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Ob3cgaXQgbG9va3MgbGlrZSBpdCdzIHN1 ZmZpY2llbnQgdG8gaGF2ZSBzaW5nbGUgYm9vbGVhbiB0byBpbmRpY2F0ZSBpdCdzIG5vcCBvciBy ZXBseSBpbiBhcHBsaWNhdGlvbiBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGVyZSdzIHJlbGF4ZWQgdmVyc2lvbi48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5mb28gYW5kIGJhciBtZWFuICZxdW90O2FueSBzdHJpbmcmcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmEpIGltcGxlbWVudCBo ZWFydGJlYXQgYnkgZGl2ZXJ0aW5nIFBvbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gUGluZyB3b3VsZCBiZSAmcXVvdDtQaW5n IGZvbyZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tIHRvIHJlcGx5IHRvICZxdW90O1BpbmcgZm9vJnF1b3Q7LCBzZW5kICZxdW90O1Bv bmcgXHgwMCBiYXImcXVvdDsgKGJhciBpcyBmb28gYnkgZGVmYXVsdCk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB0byBzZW5kIHVuc29saWNp dGVkIFBvbmcsIHNlbmQgJnF1b3Q7UG9uZyBceDAxIGJhciZxdW90OzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5iKSBpbXBs ZW1lbnQgaGVhcnRiZWF0IGJ5IGRpdmVydGluZyBQaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB0byBzZW5kIE5v cm1hbC1QaW5nLCBzZW5kICZxdW90O1BpbmcgXHgwMCBmb28mcXVvdDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB0byBzZW5kIE5PUC1QaW5n LCBzZW5kICZxdW90O1BpbmcgXHgwMSBmb28mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSB0byByZXBseSAm cXVvdDtQaW5nIFx4MDAgZm9vJnF1b3Q7LCBzZW5kICZxdW90O1BvbmcgYmFyJnF1b3Q7IChiYXIg aXMgZm9vIGJ5IGRlZmF1bHQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBqdXN0IGlnbm9yZSAmcXVvdDtQaW5nIFx4MDEgZm9v JnF1b3Q7IHdoZW4gcmVjZWl2ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPnRvIGFkb3B0IEJydWNlJ3MgaWRlYSwgY2hhbmdlICZxdW90 OyhiYXIgaXMgZm9vIGJ5IGRlZmF1bHQpJnF1b3Q7IHRvICZxdW90OyhiYXIgaXMgZm9vICYjNDM7 IGJ1eikmcXVvdDsuIGl0IGltcGxlbWVudHMgZWNobyBhbmQgYWxsb3dzIHRoZSByZWNlaXZlciB0 byBzZW5kIGFkZGl0aW9uYWwgaW5mby48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkndmUgcmVtb3ZlZCB1bm5lY2Vzc2FyeSBceDAwIGFu ZCBceDAxLCBidXQgaXQncyBmaW5lIGZvciBtZSB0byBrZWVwIHRoZW0mbmJzcDt0byBrZWVwIGZy YW1pbmcgc3ltbWV0cmljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+VGFrZXNoaTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KaHliaSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86aHliaUBpZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkiPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaHliaTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_ED13A76FCE9E96498B049688227AEA292C6A85DETK5EX14MBXC206r_-- From gregw@intalio.com Wed May 18 18:15:42 2011 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 8704FE06C2 for ; Wed, 18 May 2011 18:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.902 X-Spam-Level: X-Spam-Status: No, score=-2.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRl8INWxGpow for ; Wed, 18 May 2011 18:15:41 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A27E8E068E for ; Wed, 18 May 2011 18:15:41 -0700 (PDT) Received: by vws12 with SMTP id 12so1866512vws.31 for ; Wed, 18 May 2011 18:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.133 with SMTP id fk5mr3795699vdc.184.1305767741051; Wed, 18 May 2011 18:15:41 -0700 (PDT) Received: by 10.52.188.35 with HTTP; Wed, 18 May 2011 18:15:41 -0700 (PDT) In-Reply-To: References: Date: Thu, 19 May 2011 11:15:41 +1000 Message-ID: From: Greg Wilkins To: Piotr Kulaga Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 19 May 2011 01:15:42 -0000 On 19 May 2011 10:43, Piotr Kulaga wrote: > Personally I do not see any point of allowing multiple outstanding pings.= If > a sender did not get a response to first of them, sending another one > probably will not increase its chances. To me, saying that only one ping = is > allowed is a simplification of the protocol which does not limit protocol= =92s > functionality. I agree that multiple outstanding pings do not initially appear useful. But then I don't see why we need to restrict it to only 1. Either it will not have a use and thus nobody will send multiple pings, or somebody will discover a use and we should let them. cheers From theturtle32@gmail.com Wed May 18 18:24:09 2011 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 993CAE06C2 for ; Wed, 18 May 2011 18:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJ-h3Pq+AXts for ; Wed, 18 May 2011 18:24:09 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2E43AE068E for ; Wed, 18 May 2011 18:24:09 -0700 (PDT) Received: by pwi5 with SMTP id 5so1365575pwi.31 for ; Wed, 18 May 2011 18:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=fhSFdLS4tBPhCV/3eP47uetNrptuYoYuMTM/HcPmgzs=; b=dmFFuEA+jpWH9QY3XDSbf7V3sQX5CJeqv8zh3sCzoSCibE8evTIVKV4lrLUTgjulNx 4qYqdMFzmW4Wn4MFjdBLNb0742tqMhKWxo3plxAe3DtCyV3QYAzmozl3/RnvWZiaFYT5 MwqONLFHAM9CbMJPdlB9MsOYGyxjMk/1CXE+Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=Phgi/CfoikZ1Rit/wJsEadGe1140I90QMYwF/d9LcIt9YhnoLehkx82HydVxVK5rJm vQ6BFU3yoO8zE7cYg6KbU9oOJnMXDw6iTFwVYivsC8lP3I5lTP63vQlwK+E4+dTAfttV U7D1JlZQszRxFUDF1zQIN/exLnrhiNirc0MNE= Received: by 10.142.218.15 with SMTP id q15mr1498459wfg.311.1305768248846; Wed, 18 May 2011 18:24:08 -0700 (PDT) Received: from [10.0.109.211] (mobile-198-228-208-002.mycingular.net [198.228.208.2]) by mx.google.com with ESMTPS id v6sm1338701pbc.27.2011.05.18.18.24.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 18 May 2011 18:24:07 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <83059ABD-9F8A-49AB-86AB-B6345CDD9C39@gmail.com> X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Wed, 18 May 2011 18:23:59 -0700 To: Greg Wilkins Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 19 May 2011 01:24:09 -0000 Indeed.. It's simpler for the protocol to state that a pong should be sent i= n response to a ping and leave it at that. Sent from my iPhone On May 18, 2011, at 6:15 PM, Greg Wilkins wrote: > On 19 May 2011 10:43, Piotr Kulaga wrote: >> Personally I do not see any point of allowing multiple outstanding pings.= If >> a sender did not get a response to first of them, sending another one >> probably will not increase its chances. To me, saying that only one ping i= s >> allowed is a simplification of the protocol which does not limit protocol= =E2=80=99s >> functionality. >=20 >=20 > I agree that multiple outstanding pings do not initially appear useful. >=20 > But then I don't see why we need to restrict it to only 1. Either > it will not have a use and thus nobody will send multiple pings, or > somebody will discover a use and we should let them. >=20 >=20 > cheers From pmcmanus@mozilla.com Wed May 18 18:42:52 2011 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 B73E6E06BA for ; Wed, 18 May 2011 18:42:52 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KssVd5QLEpie for ; Wed, 18 May 2011 18:42:52 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 1A057E0674 for ; Wed, 18 May 2011 18:42:51 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id D20CA10303; Wed, 18 May 2011 21:42:50 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id ADB46101F5; Wed, 18 May 2011 21:42:46 -0400 (EDT) From: Patrick McManus To: Brian McKelvey In-Reply-To: <83059ABD-9F8A-49AB-86AB-B6345CDD9C39@gmail.com> References: <83059ABD-9F8A-49AB-86AB-B6345CDD9C39@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 18 May 2011 21:42:39 -0400 Message-ID: <1305769359.383.133.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 19 May 2011 01:42:52 -0000 On Wed, 2011-05-18 at 18:23 -0700, Brian McKelvey wrote: > Indeed.. It's simpler for the protocol to state that a pong should be sent in response to a ping and leave it at that. > agreed - I'm not seeing a compelling reason to make any particular change from -07, though I would expect implementations to use it much more conservatively than is allowed. And that's ok. From jamie@shareable.org Thu May 19 16:28:30 2011 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 71179E06D3 for ; Thu, 19 May 2011 16:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc8LYCAHfep6 for ; Thu, 19 May 2011 16:28:29 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id C7C93E068B for ; Thu, 19 May 2011 16:28:29 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QNCdn-0000OP-LG; Fri, 20 May 2011 00:28:27 +0100 Date: Fri, 20 May 2011 00:28:27 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110519232827.GA969@shareable.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 19 May 2011 23:28:30 -0000 Greg Wilkins wrote: > On 19 May 2011 10:43, Piotr Kulaga wrote: > > Personally I do not see any point of allowing multiple outstanding pings. If > > a sender did not get a response to first of them, sending another one > > probably will not increase its chances. To me, saying that only one ping is > > allowed is a simplification of the protocol which does not limit protocol’s > > functionality. > > > I agree that multiple outstanding pings do not initially appear useful. > > But then I don't see why we need to restrict it to only 1. Either > it will not have a use and thus nobody will send multiple pings, or > somebody will discover a use and we should let them. Naturally I have a use, and it came up in my very first application for WebSocket. What follows is an example. A server needs to know which clients are currently "online" for the purpose of reporting this to other clients, detecting dead clients etc. "Online" is defined (in this example) as "received something in the last 30 seconds". This ensures it's fairly up to date, which is important in a number of applications. No guarantees can be made about the network, but we choose to treat a delay of up to 10 seconds in the client-to-server direction as acceptable. (This is based on 3G experiences, which commonly delay for that long.) Therefore the client sends 1 ping message every *20* seconds, if there is no other client-to-server data. The client must send another ping after 20 seconds even if it hasn't had a pong for the previous ping yet. Pongs can be delayed quite a lot due to queueing behind other messages already queued from server-to-client, plus network delays. If the client had to wait for pong before sending another ping, that would cause spurious "offline" statuses whenever there was a lot of data transiting in server-to-client direction. Or we'd have to use a custom keepalive protocol to avoid the restriction. Or we couldn't provide such an up to date measure. (In reality we'll probably use a custom keepalive protocol anyway, to reduce the amount of packets needed, but that's a separate issue.) -- Jamie From Gabriel.Montenegro@microsoft.com Thu May 19 16:44:38 2011 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 4E842E074C for ; Thu, 19 May 2011 16:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p55bPLRYrPNQ for ; Thu, 19 May 2011 16:44:37 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 391D1E06D3 for ; Thu, 19 May 2011 16:44:37 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 May 2011 16:44:37 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 19 May 2011 16:44:36 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Thu, 19 May 2011 16:44:36 -0700 From: Gabriel Montenegro To: Jamie Lokier , Greg Wilkins Thread-Topic: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07) Thread-Index: AcwVjUa0m40rVBn+TCqGvkziRY4GLAARGKcAAAmwAIAAASH6gAAui92AAA5D4fA= Date: Thu, 19 May 2011 23:44:35 +0000 Message-ID: References: <20110519232827.GA969@shareable.org> In-Reply-To: <20110519232827.GA969@shareable.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.28] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 19 May 2011 23:44:38 -0000 VGhpcyB1c2FnZSBpcyBzdXBwb3J0ZWQgaW4gcmV2aXNpb24gMDcsIHdoaWNoIG9ubHkgaGFzIHRl eHQgb24gdGhlIHJlc3BvbmRlciAodGhlICJQaW5nZWUiPykgYWxsb3dpbmcgaXQgdG8gcmVzcG9u ZCBvbmx5IHRvIHRoZSBsYXRlc3QgUGluZywgYnV0IGl0IGhhcyBubyBjb25zdHJhaW4gb24gdGhl IGluaXRpYXRvciAodGhlICJQaW5nZXIiKSwgd2hpY2ggaXMgY3VycmVudGx5IGZyZWUgdG8gc2Vu ZCBtb3JlIHRoYW4gb25lICh3aGljaCB5b3UgaW5kaWNhdGUgbWlnaHQgYWN0dWFsbHkgbWFrZSBz ZW5zZSBpbiB5b3VyIGNhc2UpLiANCg0KSSdtIGN1cmlvdXMsIGlmIGEgUG9uZyBoYXMgbm90IGJl ZW4gcmVjZWl2ZWQgaW4gc3VjaCBsb25nIHRpbWUsIHdoeSBpcyB0aGUgY291cnNlIG9mIGFjdGlv biB0byBQaW5nIGFnYWluIHZlcnN1cyBkZWNsYXJpbmcgdGhhdCBub2RlIGdvbmUgb3IgZG93biBh bmQgdW5hdmFpbGFibGU/IEkgdGhvdWdodCB5b3VyIGdvYWwgd2FzIHRvIGRldGVjdCBkZWFkIG5v ZGVzLiBXb3VsZG4ndCB0aGlzIGNvbnN0aXR1dGUgYSBkZWFkIG5vZGU/DQoNCj4gLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSmFtaWUgTG9raWVyIFttYWlsdG86amFtaWVAc2hh cmVhYmxlLm9yZ10NCj4gU2VudDogVGh1cnNkYXksIE1heSAxOSwgMjAxMSAxNjoyOA0KPiBUbzog R3JlZyBXaWxraW5zDQo+IENjOiBQaW90ciBLdWxhZ2E7IGh5YmlAaWV0Zi5vcmc7IEdhYnJpZWwg TW9udGVuZWdybw0KPiBTdWJqZWN0OiBSZTogW2h5YmldIFBpbmcvUG9uZyBib2R5ICh3YXMgUmU6 IFRTVi1EaXJlY3RvcmF0ZSByZXZpZXcgb2YgZHJhZnQtaWV0Zi0NCj4gaHliaS10aGV3ZWJzb2Nr ZXRwcm90b2NvbC0wNykNCj4gDQo+IEdyZWcgV2lsa2lucyB3cm90ZToNCj4gPiBPbiAxOSBNYXkg MjAxMSAxMDo0MywgUGlvdHIgS3VsYWdhIDxwaW90cmt1QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0K PiA+ID4gUGVyc29uYWxseSBJIGRvIG5vdCBzZWUgYW55IHBvaW50IG9mIGFsbG93aW5nIG11bHRp cGxlIG91dHN0YW5kaW5nDQo+ID4gPiBwaW5ncy4gSWYgYSBzZW5kZXIgZGlkIG5vdCBnZXQgYSBy ZXNwb25zZSB0byBmaXJzdCBvZiB0aGVtLCBzZW5kaW5nDQo+ID4gPiBhbm90aGVyIG9uZSBwcm9i YWJseSB3aWxsIG5vdCBpbmNyZWFzZSBpdHMgY2hhbmNlcy4gVG8gbWUsIHNheWluZw0KPiA+ID4g dGhhdCBvbmx5IG9uZSBwaW5nIGlzIGFsbG93ZWQgaXMgYSBzaW1wbGlmaWNhdGlvbiBvZiB0aGUg cHJvdG9jb2wNCj4gPiA+IHdoaWNoIGRvZXMgbm90IGxpbWl0IHByb3RvY29s4oCZcyBmdW5jdGlv bmFsaXR5Lg0KPiA+DQo+ID4NCj4gPiBJIGFncmVlIHRoYXQgbXVsdGlwbGUgb3V0c3RhbmRpbmcg cGluZ3MgZG8gbm90IGluaXRpYWxseSBhcHBlYXIgdXNlZnVsLg0KPiA+DQo+ID4gQnV0IHRoZW4g SSBkb24ndCBzZWUgd2h5IHdlIG5lZWQgdG8gcmVzdHJpY3QgaXQgdG8gb25seSAxLiAgICBFaXRo ZXINCj4gPiBpdCB3aWxsIG5vdCBoYXZlIGEgdXNlIGFuZCB0aHVzIG5vYm9keSB3aWxsIHNlbmQg bXVsdGlwbGUgcGluZ3MsICBvcg0KPiA+IHNvbWVib2R5IHdpbGwgZGlzY292ZXIgYSB1c2UgYW5k IHdlIHNob3VsZCBsZXQgdGhlbS4NCj4gDQo+IE5hdHVyYWxseSBJIGhhdmUgYSB1c2UsIGFuZCBp dCBjYW1lIHVwIGluIG15IHZlcnkgZmlyc3QgYXBwbGljYXRpb24gZm9yIFdlYlNvY2tldC4NCj4g V2hhdCBmb2xsb3dzIGlzIGFuIGV4YW1wbGUuDQo+IA0KPiBBIHNlcnZlciBuZWVkcyB0byBrbm93 IHdoaWNoIGNsaWVudHMgYXJlIGN1cnJlbnRseSAib25saW5lIiBmb3IgdGhlIHB1cnBvc2Ugb2YN Cj4gcmVwb3J0aW5nIHRoaXMgdG8gb3RoZXIgY2xpZW50cywgZGV0ZWN0aW5nIGRlYWQgY2xpZW50 cyBldGMuDQo+IA0KPiAiT25saW5lIiBpcyBkZWZpbmVkIChpbiB0aGlzIGV4YW1wbGUpIGFzICJy ZWNlaXZlZCBzb21ldGhpbmcgaW4gdGhlIGxhc3QgMzANCj4gc2Vjb25kcyIuICBUaGlzIGVuc3Vy ZXMgaXQncyBmYWlybHkgdXAgdG8gZGF0ZSwgd2hpY2ggaXMgaW1wb3J0YW50IGluIGEgbnVtYmVy IG9mDQo+IGFwcGxpY2F0aW9ucy4NCj4gDQo+IE5vIGd1YXJhbnRlZXMgY2FuIGJlIG1hZGUgYWJv dXQgdGhlIG5ldHdvcmssIGJ1dCB3ZSBjaG9vc2UgdG8gdHJlYXQgYSBkZWxheQ0KPiBvZiB1cCB0 byAxMCBzZWNvbmRzIGluIHRoZSBjbGllbnQtdG8tc2VydmVyIGRpcmVjdGlvbiBhcyBhY2NlcHRh YmxlLg0KPiAoVGhpcyBpcyBiYXNlZCBvbiAzRyBleHBlcmllbmNlcywgd2hpY2ggY29tbW9ubHkg ZGVsYXkgZm9yIHRoYXQgbG9uZy4pDQo+IA0KPiBUaGVyZWZvcmUgdGhlIGNsaWVudCBzZW5kcyAx IHBpbmcgbWVzc2FnZSBldmVyeSAqMjAqIHNlY29uZHMsIGlmIHRoZXJlIGlzIG5vDQo+IG90aGVy IGNsaWVudC10by1zZXJ2ZXIgZGF0YS4NCj4gDQo+IFRoZSBjbGllbnQgbXVzdCBzZW5kIGFub3Ro ZXIgcGluZyBhZnRlciAyMCBzZWNvbmRzIGV2ZW4gaWYgaXQgaGFzbid0IGhhZCBhIHBvbmcNCj4g Zm9yIHRoZSBwcmV2aW91cyBwaW5nIHlldC4NCj4gDQo+IFBvbmdzIGNhbiBiZSBkZWxheWVkIHF1 aXRlIGEgbG90IGR1ZSB0byBxdWV1ZWluZyBiZWhpbmQgb3RoZXIgbWVzc2FnZXMgYWxyZWFkeQ0K PiBxdWV1ZWQgZnJvbSBzZXJ2ZXItdG8tY2xpZW50LCBwbHVzIG5ldHdvcmsgZGVsYXlzLg0KPiAN Cj4gSWYgdGhlIGNsaWVudCBoYWQgdG8gd2FpdCBmb3IgcG9uZyBiZWZvcmUgc2VuZGluZyBhbm90 aGVyIHBpbmcsIHRoYXQgd291bGQgY2F1c2UNCj4gc3B1cmlvdXMgIm9mZmxpbmUiIHN0YXR1c2Vz IHdoZW5ldmVyIHRoZXJlIHdhcyBhIGxvdCBvZiBkYXRhIHRyYW5zaXRpbmcgaW4gc2VydmVyLQ0K PiB0by1jbGllbnQgZGlyZWN0aW9uLiAgT3Igd2UnZCBoYXZlIHRvIHVzZSBhIGN1c3RvbSBrZWVw YWxpdmUgcHJvdG9jb2wgdG8gYXZvaWQNCj4gdGhlIHJlc3RyaWN0aW9uLiAgT3Igd2UgY291bGRu J3QgcHJvdmlkZSBzdWNoIGFuIHVwIHRvIGRhdGUgbWVhc3VyZS4NCj4gDQo+IChJbiByZWFsaXR5 IHdlJ2xsIHByb2JhYmx5IHVzZSBhIGN1c3RvbSBrZWVwYWxpdmUgcHJvdG9jb2wgYW55d2F5LCB0 byByZWR1Y2UgdGhlDQo+IGFtb3VudCBvZiBwYWNrZXRzIG5lZWRlZCwgYnV0IHRoYXQncyBhIHNl cGFyYXRlIGlzc3VlLikNCj4gDQo+IC0tIEphbWllDQoNCg== From Gabriel.Montenegro@microsoft.com Thu May 19 18:03:24 2011 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 4EA13E074A for ; Thu, 19 May 2011 18:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gh6SO0QiA4zX for ; Thu, 19 May 2011 18:03:23 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB43E0658 for ; Thu, 19 May 2011 18:03:23 -0700 (PDT) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 19 May 2011 18:03:23 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 19 May 2011 18:03:22 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Thu, 19 May 2011 18:03:22 -0700 From: Gabriel Montenegro To: Alan Coopersmith , Brodie Thiesfield Thread-Topic: [hybi] method of allocation of reserved bits to extensions Thread-Index: AQHMBUGA1u9834hjukKLiEqBfS9wQZRy7rGAgAAGGoCAAAmtgIAABKqAgAAHugCAAAPlAIABEbwAgABxQgCAAB0/gIAgWNRg Date: Fri, 20 May 2011 01:03:22 +0000 Message-ID: References: <4DBA3809.4010004@oracle.com> In-Reply-To: <4DBA3809.4010004@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hybi , "jg@freedesktop.org" , Greg Wilkins Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 20 May 2011 01:03:24 -0000 [as individual] We have very few reserved bits. These are not meant for use by just any ext= ension, similarly, the bits in the TCP or IP headers are not "up for grabs"= , but are doled out very carefully. =20 Dynamic, on-the-fly assignment of reserved bits was proposed by Greg and Br= odie here: http://www.ietf.org/mail-archive/web/hybi/current/msg07345.html=20 =20 If we were to allow such a thing, then no particular extension would be gua= ranteed to run successfully, as it would depend on a resource (a reserved b= it) that it is not guaranteed to have until the handshake is over. This wou= ld be too unpredictable. Extensions are free to define bits or control fram= es within their defined payload (as already noted in the draft). =20 Reserved bits should only be allocated for very compelling reasons, either = because there is an extension that has full backing of the WG or because th= ere is a new version of the protocol that needs it. I think we should word = our IANA considerations on bit assignment with a very strict assignment pol= icy of "Standards Action": http://tools.ietf.org/html/rfc5226#section-4.1=20 =20 Does this seem reasonable? Gabriel > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of A= lan > Coopersmith > Sent: Thursday, April 28, 2011 21:01 > To: Brodie Thiesfield > Cc: Hybi; jg@freedesktop.org; Greg Wilkins > Subject: Re: [hybi] method of allocation of reserved bits to extensions >=20 > On 04/28/11 07:16 PM, Brodie Thiesfield wrote: > > Hi Timothy, > > > > On Fri, Apr 29, 2011 at 4:31 AM, Timothy Meade wrot= e: > >> On Apr 27, 2011 11:12 PM, "Greg Wilkins" wrote: > >>> > >>> this is good. But I think we also need to say the same for op-codes. > >>> > >>> I think each extension needs to say how many bits, data op-codes and > >>> control op-codes it needs and then these should all be allocated in > >>> order. > >>> > >> > >> It might be instructive to look at X Protocol opcodes for core and > >> extensions and how that played out over time. > > > > I found the following description of the opcodes: > > http://www.x.org/wiki/Development/Documentation/Protocol/OpCodes > > > > From the summary of the scheme above: > > * each extension is assigned a single major identifying opcode > > * the extension then defines sub-codes for itself if necessary > > > > So this is pretty much the same as we are looking at in websockets but > > we have a lot less opcode space to allocate. > > > > Can you supply a pointer to a summary of the problems that occurred > > with the X scheme? I'm assuming that it didn't turn out all rosy. >=20 > I don't know why you'd assume that, since the X extension mechanism is th= e key > that's kept the X protocol alive for 25 years as graphics technology chan= ged > rapidly. >=20 > The primary problem I'm aware of is that while each extension got one of = the > 128 available requests, and bundled all it's actions into subcodes of tha= t request, > they didn't do similar "namespacing" for event & error codes. >=20 > We've not yet had a situation where we needed more than 128 extensions > simulataneously active, but have hit the limits of 64 extension events an= d errors, > as some extensions used quite a few. >=20 > It does occasionally make user bug reports challenging as the dynamic > assignment of extension codes based on which ones are enabled during the = build > and runtime of the X server means that getting an error report of a faile= d > request 153 doesn't let you know which extension it was. > (This is why the standard libX11 error handler always prints the extensio= n names, > but some applications and toolkits use custom error handlers that do not.= ) >=20 > -- > -Alan Coopersmith- alan.coopersmith@oracle.com > Oracle Solaris Platform Engineering: X Window System >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From gregw@intalio.com Thu May 19 23:42:34 2011 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 6157FE06E3 for ; Thu, 19 May 2011 23:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.917 X-Spam-Level: X-Spam-Status: No, score=-2.917 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2Y431nAdjqJ for ; Thu, 19 May 2011 23:42:33 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D9E36E06D1 for ; Thu, 19 May 2011 23:42:32 -0700 (PDT) Received: by vws12 with SMTP id 12so2947446vws.31 for ; Thu, 19 May 2011 23:42:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.133 with SMTP id fk5mr5813886vdc.184.1305873751800; Thu, 19 May 2011 23:42:31 -0700 (PDT) Received: by 10.52.187.71 with HTTP; Thu, 19 May 2011 23:42:31 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> Date: Fri, 20 May 2011 16:42:31 +1000 Message-ID: From: Greg Wilkins To: Gabriel Montenegro Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Coopersmith , Hybi , Brodie Thiesfield , "jg@freedesktop.org" Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 20 May 2011 06:42:34 -0000 Gabriel I'm concerned that if we really restrict usage of the reserved bits, then we will force extensions into using whole bytes at the start of the payload, when they really only want 1 bit. If we really do get into the situation where we have many extensions, then we could have many wasted bits. How about just having a mechanism that if we can allocated as many reserved bits as we like, and if more than 3 are allocated then extra bytes are prepended to the payload (as needed) for the extra bits. Thus we could have unlimited extensions needing unlimited bits. If a client doesn't want to play that game, then all it need do is never handshake with extensions that need more than 3 bits. cheers On 20 May 2011 11:03, Gabriel Montenegro wrote: > [as individual] > > We have very few reserved bits. These are not meant for use by just any e= xtension, similarly, the bits in the TCP or IP headers are not "up for grab= s", but are doled out very carefully. > > Dynamic, on-the-fly assignment of reserved bits was proposed by Greg and = Brodie here: > http://www.ietf.org/mail-archive/web/hybi/current/msg07345.html > > If we were to allow such a thing, then no particular extension would be g= uaranteed to run successfully, as it would depend on a resource (a reserved= bit) that it is not guaranteed to have until the handshake is over. This w= ould be too unpredictable. Extensions are free to define bits or control fr= ames within their defined payload (as already noted in the draft). > > Reserved bits should only be allocated for very compelling reasons, eithe= r because there is an extension that has full backing of the WG or because = there is a new version of the protocol that needs it. I think we should wor= d our IANA considerations on bit assignment with a very strict assignment p= olicy of "Standards Action": > http://tools.ietf.org/html/rfc5226#section-4.1 > > Does this seem reasonable? > > Gabriel > >> -----Original Message----- >> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Alan >> Coopersmith >> Sent: Thursday, April 28, 2011 21:01 >> To: Brodie Thiesfield >> Cc: Hybi; jg@freedesktop.org; Greg Wilkins >> Subject: Re: [hybi] method of allocation of reserved bits to extensions >> >> On 04/28/11 07:16 PM, Brodie Thiesfield wrote: >> > Hi Timothy, >> > >> > On Fri, Apr 29, 2011 at 4:31 AM, Timothy Meade wro= te: >> >> On Apr 27, 2011 11:12 PM, "Greg Wilkins" wrote: >> >>> >> >>> this is good. But I think we also need to say the same for op-codes. >> >>> >> >>> I think each extension needs to say how many bits, data op-codes and >> >>> control op-codes it needs and then these should all be allocated in >> >>> order. >> >>> >> >> >> >> It might be instructive to look at X Protocol opcodes for core and >> >> extensions and how that played out over time. >> > >> > I found the following description of the opcodes: >> > http://www.x.org/wiki/Development/Documentation/Protocol/OpCodes >> > >> > From the summary of the scheme above: >> > * each extension is assigned a single major identifying opcode >> > * the extension then defines sub-codes for itself if necessary >> > >> > So this is pretty much the same as we are looking at in websockets but >> > we have a lot less opcode space to allocate. >> > >> > Can you supply a pointer to a summary of the problems that occurred >> > with the X scheme? I'm assuming that it didn't turn out all rosy. >> >> I don't know why you'd assume that, since the X extension mechanism is t= he key >> that's kept the X protocol alive for 25 years as graphics technology cha= nged >> rapidly. >> >> The primary problem I'm aware of is that while each extension got one of= the >> 128 available requests, and bundled all it's actions into subcodes of th= at request, >> they didn't do similar "namespacing" for event & error codes. >> >> We've not yet had a situation where we needed more than 128 extensions >> simulataneously active, but have hit the limits of 64 extension events a= nd errors, >> as some extensions used quite a few. >> >> It does occasionally make user bug reports challenging as the dynamic >> assignment of extension codes based on which ones are enabled during the= build >> and runtime of the X server means that getting an error report of a fail= ed >> request 153 doesn't let you know which extension it was. >> (This is why the standard libX11 error handler always prints the extensi= on names, >> but some applications and toolkits use custom error handlers that do not= .) >> >> -- >> =A0 =A0 =A0 -Alan Coopersmith- =A0 =A0 =A0 =A0alan.coopersmith@oracle.co= m >> =A0 =A0 =A0 =A0Oracle Solaris Platform Engineering: X Window System >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > > From salvatore.loreto@ericsson.com Thu May 19 23:55:45 2011 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 56C7CE06A7 for ; Thu, 19 May 2011 23:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rB59BkNXcHhH for ; Thu, 19 May 2011 23:55:44 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2F09EE0655 for ; Thu, 19 May 2011 23:55:43 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-7d-4dd6106ebb77 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 07.58.09774.E6016DD4; Fri, 20 May 2011 08:55:42 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.137.0; Fri, 20 May 2011 08:55:42 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 182242441 for ; Fri, 20 May 2011 09:55:42 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D4D6050F32 for ; Fri, 20 May 2011 09:55:41 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 898F150357 for ; Fri, 20 May 2011 09:55:41 +0300 (EEST) Message-ID: <4DD6106D.5000805@ericsson.com> Date: Fri, 20 May 2011 09:55:41 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: hybi@ietf.org References: <83059ABD-9F8A-49AB-86AB-B6345CDD9C39@gmail.com> <1305769359.383.133.camel@ds9> In-Reply-To: <1305769359.383.133.camel@ds9> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 20 May 2011 06:55:45 -0000 On 5/19/11 4:42 AM, Patrick McManus wrote: > On Wed, 2011-05-18 at 18:23 -0700, Brian McKelvey wrote: >> Indeed.. It's simpler for the protocol to state that a pong should be sent in response to a ping and leave it at that. >> > agreed - I'm not seeing a compelling reason to make any particular > change from -07, though I would expect implementations to use it much > more conservatively than is allowed. And that's ok. > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > (as individual) I am OK with the 0x00 and 0x01 proposal to distinguish unsolicited pings and with the fact that to simplify the current spec and let room for future extensions the ping/pong frames (in the current spec) should not carry any application payload and so no need to correlate ping/pong data and yes I agree with the Brian text proposal (above) cheers /Sal -- Salvatore Loreto www.sloreto.com From andy.warmcat.com@googlemail.com Fri May 20 00:50:22 2011 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 9DF12E06D1 for ; Fri, 20 May 2011 00:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKVilprcNI0t for ; Fri, 20 May 2011 00:50:22 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC0DE06B2 for ; Fri, 20 May 2011 00:50:21 -0700 (PDT) Received: by bwz13 with SMTP id 13so3227139bwz.31 for ; Fri, 20 May 2011 00:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=R/I3WwxdMHYtQFZEg9mif34waBsYKzRMc/rPmBOQjM4=; b=O8AZMZhV3WDyx18s/bI6OOZkStNlKVqfpB5zDRPedTkmhQ0L3jUSBTxPjdGBn0lz66 NgaCQDoi3/A6QLnk15XqWN25O8TfY/MJesfmaXnkcOVDb6iwn0xyDthOWkvA/82Si7Q1 MFhbRQX+7ETjhewiz9u0ggTRUa9c4AxofoFTY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ta5SeTLr6F7teYer2BscWU9fGJhiUld7N5FRgFiGElURu0CnObnUJnrg4nKN3KmJEd Z1ZRiKLYE4Bm5ViN+tTprX90wGC2GBhFM05dhz0UFvU2yx9w5GfxqpTqABK5uILs2xqa MdDN6SghUXKl3dfgcjZ/prdGm8GBqmV1YOO8s= Received: by 10.204.24.4 with SMTP id t4mr939748bkb.109.1305877820411; Fri, 20 May 2011 00:50:20 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id 16sm1972553bkm.18.2011.05.20.00.50.17 (version=SSLv3 cipher=OTHER); Fri, 20 May 2011 00:50:18 -0700 (PDT) Sender: Andy Green Message-ID: <4DD61D35.10404@warmcat.com> Date: Fri, 20 May 2011 08:50:13 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc16 Thunderbird/3.1.10 MIME-Version: 1.0 To: Greg Wilkins References: <4DBA3809.4010004@oracle.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Alan Coopersmith , Hybi , Gabriel Montenegro , Brodie Thiesfield , "jg@freedesktop.org" Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 20 May 2011 07:50:22 -0000 On 05/20/2011 07:42 AM, Somebody in the thread at some point said: > Gabriel > > I'm concerned that if we really restrict usage of the reserved bits, > then we will force extensions into using whole bytes at the start of > the payload, when they really only want 1 bit. If we really do get > into the situation where we have many extensions, then we could have > many wasted bits. > > How about just having a mechanism that if we can allocated as many > reserved bits as we like, and if more than 3 are allocated then extra > bytes are prepended to the payload (as needed) for the extra bits. > Thus we could have unlimited extensions needing unlimited bits. > > If a client doesn't want to play that game, then all it need do is > never handshake with extensions that need more than 3 bits. Sounds good to me. This idea of reserved bits being misered is not only unnecessary but it is really inefficient - it'll lead to only special, big, connected players being able to use them and because they are permanently allocated to particular extensions in that model, there will always be a desire to withhold them "for later". Dynamic allocation way anyone can randomly decide their extension will use them, no central allocation is needed and multiple extensions using reserved bits will always play well (plus or minus other doubts about extension ordering not related to reserved bits). -Andy From pieterh@gmail.com Fri May 20 03:08:50 2011 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 D2712E0760 for ; Fri, 20 May 2011 03:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WU+nI3oDi3TX for ; Fri, 20 May 2011 03:08:50 -0700 (PDT) Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1C0E0733 for ; Fri, 20 May 2011 03:08:49 -0700 (PDT) Received: by qyk7 with SMTP id 7so2307811qyk.10 for ; Fri, 20 May 2011 03:08:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type; bh=jnP2dIGCFSB1ekezoHhxO9NpHF6snJD3BZxxFe4xp40=; b=aboBcDeP154xCwpWbaRagok6LwRiQLXhGiOu418MtrFq+drswu1bfle9V3cuJZtuNm r5dxx3ABdflKuTVE3qtVlTCS4/FLxibLX4q1JEzuLu6r7jhuKZxsgn4wijHuPH8KAOru SLl3IjhXaAvk4BB9dqwLN/cNodTVDc0YucnSA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=lCpj1jkKngDnj6SP0RS5JjCBAE1qpMiDsEV4QEReJWrtYErmXnRyoYGnIbKiLJL3iK 1kGTlHPcZq250Sj63BWG+/2AM18v8lVRrIlx40IYD9mA6NqwC5+K2+XXK5k6LJYyQ24x /yV4w7R/Ym/Jmjbjnl3a/hrQ+8qgEj+QJjr14= Received: by 10.229.106.83 with SMTP id w19mr3169189qco.186.1305886129178; Fri, 20 May 2011 03:08:49 -0700 (PDT) MIME-Version: 1.0 Sender: pieterh@gmail.com Received: by 10.229.181.202 with HTTP; Fri, 20 May 2011 03:08:29 -0700 (PDT) In-Reply-To: <20110519232827.GA969@shareable.org> References: <20110519232827.GA969@shareable.org> From: Pieter Hintjens Date: Fri, 20 May 2011 12:08:29 +0200 X-Google-Sender-Auth: 9As2FKsQrTmnnB3he_-B3PfPX7U Message-ID: To: Jamie Lokier Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 20 May 2011 10:08:50 -0000 On Fri, May 20, 2011 at 1:28 AM, Jamie Lokier wrote: > If the client had to wait for pong before sending another ping, that > would cause spurious "offline" statuses whenever there was a lot of > data transiting in server-to-client direction. We had exactly this problem in AMQP and resolved it quite effectively by treating _any_ incoming data as a liveness indicator. Any reason you'd not do this? -Pieter Hintjens From theturtle32@gmail.com Fri May 20 11:05:49 2011 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 90580E0753 for ; Fri, 20 May 2011 11:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPRpydxDyrOO for ; Fri, 20 May 2011 11:05:49 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id ABA36E073D for ; Fri, 20 May 2011 11:05:48 -0700 (PDT) Received: by bwz13 with SMTP id 13so3721194bwz.31 for ; Fri, 20 May 2011 11:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yKTgk/an7fu++ktlgh1L8+/cxjbPNqVQX/dj989He3M=; b=M3Zla+B5alf4V08FsKzeX01On50godgLvr2Jnbdby5W3SuEf3tkkxP4Bv1pYoSzndz M4Box+PqvzFAsXjLUu97vhtgZMiF3WgF/PLUqSql85E76w6w7phzdR/IampxZMTlktet vWeOAJIzQgfIGGLQdjOaiQuAnQXwTTmrkj9EE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SpgNtN8bVvKda/k5WpaIVIiSGIVOuxCpWKIaOSKog3W6pM0CFnstd4MRAHpjdOZ9iy ZG6Ww3gTvv1m+53I7i5CXKN7peiRCCHo03NjlH0+M5kpgGAxNe+raEYewUdndtBLOib1 OM3SCOgTHC79ctRaURGULaT/FB4bEi5OauPuY= MIME-Version: 1.0 Received: by 10.204.154.215 with SMTP id p23mr248803bkw.113.1305914747371; Fri, 20 May 2011 11:05:47 -0700 (PDT) Received: by 10.204.14.140 with HTTP; Fri, 20 May 2011 11:05:46 -0700 (PDT) In-Reply-To: <4DD61D35.10404@warmcat.com> References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> Date: Fri, 20 May 2011 11:05:46 -0700 Message-ID: From: Brian To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Greg Wilkins , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 20 May 2011 18:05:49 -0000 This seems fine to me too, but a bit more complicated than just letting extensions prepend a byte for themselves to the payload data. Honestly.. quibbling over wasting 7 bits by allocating a whole byte in this day and age seems silly, even for things like cell phones. My cell phone (iPhone on AT&T in Los Angeles) is routinely able to transfer data at over a megabit per second (and even faster when I get out of the city). So if there are a small handfull of "wasted" bytes in the payload to accommodate extension data/flags, nobody's really going to notice. I would support the dynamically allocated flags mechanism that can dynamically add more bytes to accomodate more extensions, but I just think it seems a little unnecessary. Brian On Fri, May 20, 2011 at 12:50 AM, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)= " wrote: > On 05/20/2011 07:42 AM, Somebody in the thread at some point said: >> >> Gabriel >> >> I'm concerned that if we really restrict usage of the reserved bits, >> then we will force extensions into using whole bytes at the start of >> the payload, when they really only want 1 bit. =C2=A0If we really do get >> into the situation where we have many extensions, then we could have >> many wasted bits. >> >> How about just having a mechanism that if we can allocated as many >> reserved bits as we like, and if more than 3 are allocated then extra >> bytes are prepended to the payload (as needed) for the extra bits. >> Thus we could have unlimited extensions needing unlimited bits. >> >> If a client doesn't want to play that game, then all it need do is >> never handshake with extensions that need more than 3 bits. > > Sounds good to me. > > This idea of reserved bits being misered is not only unnecessary but it i= s > really inefficient - it'll lead to only special, big, connected players > being able to use them and because they are permanently allocated to > particular extensions in that model, there will always be a desire to > withhold them "for later". > > Dynamic allocation way anyone can randomly decide their extension will us= e > them, no central allocation is needed and multiple extensions using reser= ved > bits will always play well (plus or minus other doubts about extension > ordering not related to reserved bits). > > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From jamie@shareable.org Fri May 20 14:26:26 2011 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 E64E9E0714 for ; Fri, 20 May 2011 14:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC1RK6d551wh for ; Fri, 20 May 2011 14:26:22 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0DA8AE06CF for ; Fri, 20 May 2011 14:26:21 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QNXD8-0007tV-U7; Fri, 20 May 2011 22:26:18 +0100 Date: Fri, 20 May 2011 22:26:18 +0100 From: Jamie Lokier To: Pieter Hintjens Message-ID: <20110520212618.GB969@shareable.org> References: <20110519232827.GA969@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 20 May 2011 21:26:27 -0000 Pieter Hintjens wrote: > On Fri, May 20, 2011 at 1:28 AM, Jamie Lokier wrote: > > > If the client had to wait for pong before sending another ping, that > > would cause spurious "offline" statuses whenever there was a lot of > > data transiting in server-to-client direction. > > We had exactly this problem in AMQP and resolved it quite effectively > by treating _any_ incoming data as a liveness indicator. Any reason > you'd not do this? (I was going to agree, but then I remembered complicated things from coherent systems that had hoped to avoid here. So yes and no!) That's better, but it addresses a different issue than this thread. That's a good way to keep a TCP connection alive. Optimal seems to be to decouple directions, and (for each direction) a one-way keepalive when there hasn't been any transmission for a fixed time; all received data indicates liveness. But keeping a connection alive isn't quite the same as reliably detecting a dead one! (To reconnect, break a transaction, etc.) With the example timings I gave, the client has to send keepalives every 20 seconds _even if_ it treats any data from the server as indicating liveness, otherwise the server will flag the client as "offline" spuriously. For "quiet" connections, explicit ping/pong work, but the the client must send pings 20 seconds apart from _each other_, not wait 20 seconds after receiving a pong (an easy coding error). If we discard the whole concept of ping/pong, I think you and I are in sharp agreement. But this sub-thread is about whether it's ever useful to overlap ping/pong. My reply is: If you insist on using ping/pong, perhaps feeling the need to use the features of WebSocket draft -07 instead of inventing your own, then yes sometimes they need to overlap. But it's even better to abandon ping/pong and use a more robust keepalive method. In a way, you have highlighted a problem with the explicit ping/pong strategy implicitly advocated in draft -07. Unfortunately, treating all data as liveness has a different set of problems (good for keeping a connection alive, but unreliable at detecting connection loss in a bounded time), which is often ignorable, but breaks things that depend on "confirm the client was definitely alive in the last 30 seconds". Think about variable network delays. The only robust solution I've come up with combines all-data-liveness and round-tripped sequence stamps. Hence yes and no to your question. -- Jamie From jamie@shareable.org Fri May 20 15:17:53 2011 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 E4426E0797 for ; Fri, 20 May 2011 15:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.932 X-Spam-Level: X-Spam-Status: No, score=-3.932 tagged_above=-999 required=5 tests=[AWL=-1.333, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VuSSxt7YyC6d for ; Fri, 20 May 2011 15:17:52 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id B318FE06BE for ; Fri, 20 May 2011 15:17:49 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QNY0v-00083t-Oj; Fri, 20 May 2011 23:17:45 +0100 Date: Fri, 20 May 2011 23:17:45 +0100 From: Jamie Lokier To: Gabriel Montenegro Message-ID: <20110520221745.GC969@shareable.org> References: <20110519232827.GA969@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 20 May 2011 22:17:54 -0000 Gabriel Montenegro wrote: > This usage is supported in revision 07, which only has text on the > responder (the "Pingee"?) allowing it to respond only to the latest > Ping, but it has no constrain on the initiator (the "Pinger"), which > is currently free to send more than one (which you indicate might > actually make sense in your case). That's a good reason for a ping/pong body. If the responder only has to respond to the last ping, the sender may need to know which ping is being responded to make assertions about when the responder was alive and estimate or bound the RTT. > I'm curious, if a Pong has not been received in such long time, why > is the course of action to Ping again versus declaring that node gone > or down and unavailable? I thought your goal was to detect dead > nodes. Wouldn't this constitute a dead node? See Pieter Hintjens reply, and my reply to that. If there is bulky data being transmitted, it can delay a pong, potentially for a long time (depending on how your queues work), but it doesn't mean the connection is dead. Quite the contrary. I don't mean to advocate that ping/pong is always appropriate anyway. (As Pieter points out, watching the data is better. Another reason: Asymmetric timeouts. If you need keepalive just to stay "subscribed" to a message source, then the keepalive bandwidth can greatly exceed actual data!! Dropping pongs, and using _different_ timings for server and client can reduce keepalive bandwidth while maintaining a required level of "subscriber up-to-dateness".) But if you feel the need to use ping/pong (perhaps to feel like you're making more use of the WS spec, and less wheel invention), when you have short keepalive timing constraints, that would push towards overlap sometimes. -- Jamie From pieterh@gmail.com Fri May 20 16:27:20 2011 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 2B0A3E0786 for ; Fri, 20 May 2011 16:27:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd7iejk7kQXq for ; Fri, 20 May 2011 16:27:18 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 98C09E0772 for ; Fri, 20 May 2011 16:27:18 -0700 (PDT) Received: by yic13 with SMTP id 13so1834062yic.31 for ; Fri, 20 May 2011 16:27:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=ev4SINiLW3P0RG1PrnBfDtuLGe4TVwb9z9HM8KuINYU=; b=cG/BU8JJiuvTnLH4NWO8lkTE0rqFJfvaA2XAhMkF7ICeEKJfClhrlZmL3I9KTFr+Cs JF6AdrBoA4FD2iPs5RKYVttbWCd5ARbmu/I4Dc2PJgpc6lSpIWboqMbw+CAW7W78khzA eEQwKS3Q85A5/HkK6RrMTEX+VyQp86/G8XPdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=S0gJcefxDZay8KzslZQq0EkKTUgvTIn9RPop2kNvncMwgmjR8wwooGJr5NHK5Do0+S k89FS93CfSGbcau671a2uTnfCY8aE4c/nI7KVcRhdxjmA6sSwLlWXcwSADP3Hpm9Cr53 /RIXxfFCLQRxiPan82fxlh7x83krH6mNponBg= Received: by 10.236.183.193 with SMTP id q41mr281828yhm.80.1305934038091; Fri, 20 May 2011 16:27:18 -0700 (PDT) MIME-Version: 1.0 Sender: pieterh@gmail.com Received: by 10.236.61.106 with HTTP; Fri, 20 May 2011 16:26:58 -0700 (PDT) In-Reply-To: <20110520212618.GB969@shareable.org> References: <20110519232827.GA969@shareable.org> <20110520212618.GB969@shareable.org> From: Pieter Hintjens Date: Sat, 21 May 2011 01:26:58 +0200 X-Google-Sender-Auth: RFK2PprUb4jM290acRgc7oali4o Message-ID: To: Jamie Lokier Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Fri, 20 May 2011 23:27:20 -0000 On Fri, May 20, 2011 at 11:26 PM, Jamie Lokier wrote: > (I was going to agree, but then I remembered complicated things from > coherent systems that had hoped to avoid here. =A0So yes and no!) ... Thanks for the detailed answer, Jamie. -Pieter From bruce@callenish.com Sun May 22 14:03:26 2011 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 E745BE068F for ; Sun, 22 May 2011 14:03:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5jHkUaqTX6b for ; Sun, 22 May 2011 14:03:25 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id E3649E0651 for ; Sun, 22 May 2011 14:03:25 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QOEdI-0000kc-7x for hybi@ietf.org; Sun, 22 May 2011 12:48:12 -0700 Message-ID: <4DD9686C.7020509@callenish.com> Date: Sun, 22 May 2011 12:47:56 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: "hybi@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Sun, 22 May 2011 21:03:27 -0000 It seems there are still a number of issues around Ping/Pong. Here are my thoughts on them: 1) Should multiple Pings be allowed before a response Pong is received? Surely this is the business of the implementation/application and not the specification. If someone has a use for such a thing, why not allow it? 2) Should Ping and Pong be allowed to have a body? I think it is a useful and desirable feature. It allows matching Pongs to Pings, as well as being an area for experimenting with new ideas in how the Ping and Pong are used. The argument has been brought up that the bodies are useless without a standard way of interpreting them. This is absolutely true. Why not allow experimentation so that people can come up with standards for them? What is the downside to allowing it? 3) Should there be an indicator for unsolicited Pongs and/or Pings that need no response. I don't see why this is necessary or desirable so long as the body of the Pong in some way indicates the Ping it is responding to. Allowing unsolicited Pongs removes any usecase for Pings without responses as far as I can see. As far as unsolicited Pongs go, if the Pong body does not match a Ping that was sent out, then surely it can be assumed to be an unsolicited Pong. What is the marker trying to indicate? That if we have a Pong that claims to be solicited and does not match the Ping body that there is a bug in the server implementation, or perhaps that the server is mistaken in the client it thinks it is communicating with? Is this really necessary? 4) Should we allow the Pong body to contain extra data beyond just echoing the Ping body? Again, I think this is a harmless way to allow experimentation on uses for Ping and Pong. I don't see any reason for disallowing it. It has been claimed that there could not be any value in allowing additional information because Ping/Pong frames run at a higher priority than other Websocket traffic, and so any data they carry on network characteristics would not reflect the behaviour of other data in the channel. This makes a couple of assumptions that I think are questionable. First, are all possible uses of Ping and Pong concerned with network characteristics? Even if so, are all possible network characteristics rendered moot by higher priority traffic? I don't see it necessarily follows that these two assumptions are valid. So if it were up to me, I would just change the spec to indicate that the Pong must respond with the Ping body, but is allowed to add any data it wishes to afterward. In fact, you could even change it to respond with just a hash of the Ping body followed by any other data it wanted to (SHA1 + Base64 for consistency). I wouldn't add in a flag for unsolicited vs. solicited Pongs since the Pong response does that for us by indicating the Ping it is responding to, but if others wanted it then I wouldn't stand in their way. Although, if you are going to specify a byte for a single flag then you may want to indicate the other 7 bits are reserved for future use. From brofield@gmail.com Sun May 22 16:24:02 2011 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 9179AE06D9 for ; Sun, 22 May 2011 16:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCqwpmX59FwS for ; Sun, 22 May 2011 16:24:01 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 869A4E0651 for ; Sun, 22 May 2011 16:24:01 -0700 (PDT) Received: by pzk5 with SMTP id 5so3279395pzk.31 for ; Sun, 22 May 2011 16:24:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=gY1lkT4wQ1PStJ0Or/48QZ4PmDTUSUGUoFYozgPvpZQ=; b=W+1E2IzquDCLjFjjFchdjnGRlV+uZEaslQ2+2MyLEuTs7j7+V/XBKj3MGxKBRlrU4K bz2zXl1C0caB9IEAwPhQf2gqAH0dQfWp4wJ4d1RRtPbXrEeQXPtUx7SgwvQzmU8SWypf KDWcilNeDsM1GUkwpw+TilGGxsi6jct/Alhuk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=QkpNM9XFH45/Pwobkc4wyrvKTuQJ1uWyoE1XHJwezh/gTnDh0mGL8KTT3INQKl8zUp LQdkGaK1xfLDNZ9Pd4PfYTi8qPCKN4BW2V6EarWx4XwvaNQKF/IBE47+XjfTw9Mqmtf1 nAEv8S7G1xupK7qIStKqBW/AxaWt7WXwSlkpY= MIME-Version: 1.0 Received: by 10.68.39.72 with SMTP id n8mr1528535pbk.93.1306106639235; Sun, 22 May 2011 16:23:59 -0700 (PDT) Sender: brofield@gmail.com Received: by 10.68.40.134 with HTTP; Sun, 22 May 2011 16:23:59 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> Date: Mon, 23 May 2011 08:23:59 +0900 X-Google-Sender-Auth: D6Xo4XQ1ZQw9VzPPSy4WWWQ9mSQ Message-ID: From: Brodie Thiesfield To: Gabriel Montenegro Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Alan Coopersmith , Hybi , "jg@freedesktop.org" , Greg Wilkins Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2011 23:24:02 -0000 On Fri, May 20, 2011 at 10:03 AM, Gabriel Montenegro wrote: > [as individual] > > We have very few reserved bits. These are not meant for use by just any e= xtension, similarly, the bits in the TCP or IP headers are not "up for grab= s", but are doled out very carefully. > > Dynamic, on-the-fly assignment of reserved bits was proposed by Greg and = Brodie here: > http://www.ietf.org/mail-archive/web/hybi/current/msg07345.html > > If we were to allow such a thing, then no particular extension would be g= uaranteed to run successfully, as it would depend on a resource (a reserved= bit) that it is not guaranteed to have until the handshake is over. This w= ould be too unpredictable. Extensions are free to define bits or control fr= ames within their defined payload (as already noted in the draft). Until the handshake is completed there is no websocket connection and no guarantee that any extension will be accepted by the server anyhow. I don't see that this is a problem. It is more efficient in size considerations to use available bits in the framing for extensions to use in their signalling. Since size was important in the beginning and the reason we have the variable size length field, I assume that saving up to 3 bytes per frame for extensions that need flags is still desirable. I still believe that it would be better for the server to explicitly allocate the bit to the extension rather than have implicit allocation of a bit via extension order. It allows server to refuse to allocate specific bits as desired (e.g. new protocol version has allocated it) without changes to extensions or clients using older protocol versions. It also facilitates Greg's idea of adding an overflow block of extra reserved bits if that proves necessary. However, I don't feel particularly strongly about this issue and can live with the worst-case scenario of every negotiated extension extending the payload by a byte in order to get a single bit flag. Regards, Brodie > > Reserved bits should only be allocated for very compelling reasons, eithe= r because there is an extension that has full backing of the WG or because = there is a new version of the protocol that needs it. I think we should wor= d our IANA considerations on bit assignment with a very strict assignment p= olicy of "Standards Action": > http://tools.ietf.org/html/rfc5226#section-4.1 > > Does this seem reasonable? > > Gabriel > >> -----Original Message----- >> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Alan >> Coopersmith >> Sent: Thursday, April 28, 2011 21:01 >> To: Brodie Thiesfield >> Cc: Hybi; jg@freedesktop.org; Greg Wilkins >> Subject: Re: [hybi] method of allocation of reserved bits to extensions >> >> On 04/28/11 07:16 PM, Brodie Thiesfield wrote: >> > Hi Timothy, >> > >> > On Fri, Apr 29, 2011 at 4:31 AM, Timothy Meade wro= te: >> >> On Apr 27, 2011 11:12 PM, "Greg Wilkins" wrote: >> >>> >> >>> this is good. But I think we also need to say the same for op-codes. >> >>> >> >>> I think each extension needs to say how many bits, data op-codes and >> >>> control op-codes it needs and then these should all be allocated in >> >>> order. >> >>> >> >> >> >> It might be instructive to look at X Protocol opcodes for core and >> >> extensions and how that played out over time. >> > >> > I found the following description of the opcodes: >> > http://www.x.org/wiki/Development/Documentation/Protocol/OpCodes >> > >> > From the summary of the scheme above: >> > * each extension is assigned a single major identifying opcode >> > * the extension then defines sub-codes for itself if necessary >> > >> > So this is pretty much the same as we are looking at in websockets but >> > we have a lot less opcode space to allocate. >> > >> > Can you supply a pointer to a summary of the problems that occurred >> > with the X scheme? I'm assuming that it didn't turn out all rosy. >> >> I don't know why you'd assume that, since the X extension mechanism is t= he key >> that's kept the X protocol alive for 25 years as graphics technology cha= nged >> rapidly. >> >> The primary problem I'm aware of is that while each extension got one of= the >> 128 available requests, and bundled all it's actions into subcodes of th= at request, >> they didn't do similar "namespacing" for event & error codes. >> >> We've not yet had a situation where we needed more than 128 extensions >> simulataneously active, but have hit the limits of 64 extension events a= nd errors, >> as some extensions used quite a few. >> >> It does occasionally make user bug reports challenging as the dynamic >> assignment of extension codes based on which ones are enabled during the= build >> and runtime of the X server means that getting an error report of a fail= ed >> request 153 doesn't let you know which extension it was. >> (This is why the standard libX11 error handler always prints the extensi= on names, >> but some applications and toolkits use custom error handlers that do not= .) >> >> -- >> =A0 =A0 =A0 -Alan Coopersmith- =A0 =A0 =A0 =A0alan.coopersmith@oracle.co= m >> =A0 =A0 =A0 =A0Oracle Solaris Platform Engineering: X Window System >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi > > From tyoshino@google.com Sun May 22 21:37:25 2011 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 6FD75E06FD for ; Sun, 22 May 2011 21:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S4zj3ujt6MW9 for ; Sun, 22 May 2011 21:37:24 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 89FE2E06A6 for ; Sun, 22 May 2011 21:37:24 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p4N4bNPT011394 for ; Sun, 22 May 2011 21:37:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306125443; bh=xXsC17F+NltW5p+ZTkye7MUxRHs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=UO2grgHR2tgvA+fmq2E74LXSTcdS0ZFoQtDLzjAyMSTfcpOz858DBxNLzg8cIlSfe 1zGs47g6yILH99+kfVpng== Received: from ywe9 (ywe9.prod.google.com [10.192.5.9]) by hpaq12.eem.corp.google.com with ESMTP id p4N4bLIS007659 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 22 May 2011 21:37:22 -0700 Received: by ywe9 with SMTP id 9so1772031ywe.19 for ; Sun, 22 May 2011 21:37:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=iNn+QOdtFJZDy2zFYx3lDKAt9zgOWYGzt/db3crdg10=; b=xqLD+Fs2e33rXCEn5Jxm7zdszw75C+iF9mIsSYnP4quQWQ4hcI1tccqY/uoY88Bmxr nPOfqEjfSAc01sRBDnKA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Y80M5cfGhHg/Ns+EK0NHxYFGf3EPUqt1qsTXCPvPD2uHMmKuvTHUwRAv1550YLkZ+X XEDoLl5VngjEeDwyEWCQ== Received: by 10.151.77.33 with SMTP id e33mr2293582ybl.0.1306125441117; Sun, 22 May 2011 21:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Sun, 22 May 2011 21:37:01 -0700 (PDT) In-Reply-To: <4DD9686C.7020509@callenish.com> References: <4DD9686C.7020509@callenish.com> From: Takeshi Yoshino Date: Mon, 23 May 2011 13:37:01 +0900 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=000e0cd630e2f32fbf04a3ea060c X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 23 May 2011 04:37:25 -0000 --000e0cd630e2f32fbf04a3ea060c Content-Type: text/plain; charset=ISO-8859-1 > > 3) Should there be an indicator for unsolicited Pongs and/or Pings that > need no response. > I don't see why this is necessary or desirable so long as the body of the > Pong in some way indicates the Ping it is responding to. Allowing > unsolicited Pongs removes any usecase for Pings without responses as far as > I can see. I think so. What I'm proposing is doing either of adding flag to Ping or adding flag to Pong. Not both. Here, I'll reply to your comments assuming we add flag to Pong. > As far as unsolicited Pongs go, if the Pong body does not match a Ping that > was sent out, then surely it can be assumed to be an unsolicited Pong. > > It's possible that A sends an unsolicited Pong with the same body as a Ping sent by B. How do you choose Pong body for unsolicited Pong? As initially most of implementors are not interested in using the body of Ping and unsolicited Pong, they'll try to use an empty string. Some may choose non empty string X for its Ping body but some other may also use the same string X for its unsolicited Pongs' body. It will be quickly out of control. So then, Pings can be often acked by unsolicited Pongs. It's not so harmful as the only weird thing we'll see is the very very small RTT for such Pings for now, but I prefer to mark them in the spec level to reduce the possibility of problems in the future extension. > What is the marker trying to indicate? That if we have a Pong that claims > to be solicited and does not match the Ping body that there is a bug in the > server implementation, or perhaps that the server is mistaken in the client > it thinks it is communicating with? Is this really necessary? > That's not the case I was arguing. Pong that claims to be unsolicited and does match the Ping body is what I have concern over. --000e0cd630e2f32fbf04a3ea060c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
3) Should there = be an indicator for unsolicited Pongs and/or Pings that need no response.

I don't see why this is necessary or desirable so long as the body of t= he Pong in some way indicates the Ping it is responding to. Allowing unsoli= cited Pongs removes any usecase for Pings without responses as far as I can= see.

I think so. What I'm proposing is doing either of a= dding flag to Ping or adding flag to Pong. Not both.

Here, I'll reply to your comments assuming we add flag to Pong.
=A0
As far as unsolicited Pongs g= o, if the Pong body does not match a Ping that was sent out, then surely it= can be assumed to be an unsolicited Pong.


It's possible that A sends an= unsolicited Pong with the same body as a Ping sent by B. How do you choose= Pong body for unsolicited Pong?=A0As initially most of implementors are no= t interested in using the body of=A0Ping and unsolicited Pong, they'll = try to use an empty string. Some may choose non empty string X for its Ping= body but some other may also use the same string X for its unsolicited Pon= gs' body. It will be quickly out of control.

So then, Pings can be often acked by unsolicited = Pongs. It's not so harmful as the only weird thing we'll see is the= very very small RTT for such Pings for now, but I prefer to mark them in t= he spec level to reduce the possibility of problems in the future extension= .
=A0
What is the marker trying to indicate? That if we have a Pong that claims t= o be solicited and does not match the Ping body that there is a bug in the = server implementation, or perhaps that the server is mistaken in the client= it thinks it is communicating with? Is this really necessary?

That's not the case I was arguing. Pon= g that claims to be unsolicited and does match the Ping body is what I have= concern over.

--000e0cd630e2f32fbf04a3ea060c-- From andy.warmcat.com@googlemail.com Mon May 23 02:09:54 2011 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 68BE8E0726 for ; Mon, 23 May 2011 02:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cS9rdHnaxfD3 for ; Mon, 23 May 2011 02:09:53 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABCAE0657 for ; Mon, 23 May 2011 02:09:53 -0700 (PDT) Received: by gyf3 with SMTP id 3so2498403gyf.31 for ; Mon, 23 May 2011 02:09:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:subject:content-type:content-transfer-encoding; bh=jHvW42ggjlQmkA1QJ7dn4D2/cENYvkuOC6eqck4CAtw=; b=tlaCBaP7MJk8hTsgjfns7hXUBaz040shs2Zo4v74oKFN9TNshlFpnIpT1jkQ56g4Et WjnzJ7nRMORpw5We2I/xO3tIkAle1oduw1a7AT+ftZRLTMZJ78J3G+iuqOxO39mE/fbc /jD8zc6N3rJminBxPokkQlSNg98XwYlzh2IxA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=hTwWqUYK8fd+obqaE8twfXCHMI2Sfl7i3pJc6fvLluftSxrWYyt+LQEg7JTcvW6jeV +cVCaIdwLmQnZLH7lKuQ3w76QrGUUbhsLK51FYtEKCnk8+XNZip0TojiYW8Sb6P0mdDg 8pxY9iQCPztJXi26F1dA2nUj+FW0SQTce5prY= Received: by 10.91.164.27 with SMTP id r27mr2770239ago.204.1306141792737; Mon, 23 May 2011 02:09:52 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id u11sm4640764anq.49.2011.05.23.02.09.48 (version=SSLv3 cipher=OTHER); Mon, 23 May 2011 02:09:49 -0700 (PDT) Sender: Andy Green Message-ID: <4DDA2456.3030706@warmcat.com> Date: Mon, 23 May 2011 10:09:42 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc16 Thunderbird/3.1.10 MIME-Version: 1.0 To: Hybi Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] libwebsockets very pre-alpha x-google-mux implementation 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, 23 May 2011 09:09:54 -0000 Hi - If you like or need to live on the bleeding edge, you might be interested in the very very pre-alpha x-google-mux support I just committed. http://git.warmcat.com/cgi-bin/cgit/libwebsockets/commit/?id=a41314f3bf6c6f827c7af95dc17431be5b5fa711 1) To enable it, reconfigure with --enable-x-google-mux 2) It conflicts with deflate-stream, use the -u switch on the test client to disable deflate-stream 3) It deviates from the google standard by sending full headers in the addchannel subcommand rather than just changed ones from original connect 4) Quota is not implemented yet 5) Close of subchannel is not really implemented yet 6) Google opcode 0xf is changed to 0x7 to account for v7 protocol changes to opcode layout However despite those caveats, in fact it can run the test client reliably over one socket (both dumb-increment and lws-mirror-protocol), you can open a browser on the same test server too and see the circles, etc. It's obviously not ready for primetime but since I found implementing it so very difficult I guess it can already be quite interesting for other people looking to implement. It manages to keep almost all the mux-specific stuff in lib/extension-x-google-mux.c / .h but to do that, it has to add a variety of generic extension callbacks all over the place. Most of the churn in the other main files is just breaking out existing code into functions that the extension can use from a different context. I particularly draw peoples' attention again to the code around "candidate_children_list", I believe this architecture is required for mux to work at all. Patches welcome! -Andy From bruce@callenish.com Tue May 24 12:48:39 2011 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 4E6B1E0719 for ; Tue, 24 May 2011 12:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2d3qHT68E2U for ; Tue, 24 May 2011 12:48:38 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id DFA66E064E for ; Tue, 24 May 2011 12:48:38 -0700 (PDT) Received: from [24.108.133.142] (helo=[192.168.145.101]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QOxan-0005Qi-KW; Tue, 24 May 2011 12:48:37 -0700 Message-ID: <4DDC0B84.9070500@callenish.com> Date: Tue, 24 May 2011 12:48:20 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Takeshi Yoshino References: <4DD9686C.7020509@callenish.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Tue, 24 May 2011 19:48:39 -0000 I see. Thanks for the clarification. I take your point. It is perhaps because the body is so under-specified that this problem arises. You could get around it by, for example, requiring PING to always start with a timestamp and requiring an unsolicited PONG not to. Or you could require a UUID from both PING and unsolicited PONG. But any of those ideas is no better (and probably worse) than your solution, so I'm happy to support it. On 22/05/2011 9:37 PM, Takeshi Yoshino wrote: > > That's not the case I was arguing. Pong that claims to be unsolicited > and does match the Ping body is what I have concern over. > From julian.reschke@gmx.de Tue May 24 13:44:04 2011 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 85CF2E076D for ; Tue, 24 May 2011 13:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaR7sOUQW5Uq for ; Tue, 24 May 2011 13:44:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id A3191E0784 for ; Tue, 24 May 2011 13:44:03 -0700 (PDT) Received: (qmail invoked by alias); 24 May 2011 20:44:02 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 24 May 2011 22:44:02 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/2NPkRGb/2VHUDS0n/TfT1KEbbLYYhR0PzQ+hk7H 5qbkzrQA2W3Yuo Message-ID: <4DDC1890.9020005@gmx.de> Date: Tue, 24 May 2011 22:44:00 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: hybi@ietf.org References: <20110422230002.3988.41816.idtracker@ietfc.amsl.com> <4DB3D2E7.4010705@gmx.de> In-Reply-To: <4DB3D2E7.4010705@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [hybi] Section 3 (URIs), was: I-D Action:draft-ietf-hybi-thewebsocketprotocol-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: Tue, 24 May 2011 20:44:04 -0000 On 2011-04-24 09:36, Julian Reschke wrote: > Hi there, > > this still needs work: > > - it's unclear why we define parsing - is the parsing consistent with > RFC 3986? If yes, why do we have the section? If no, what's the difference? > > - it now talks about URIs and doesn't mention IRIs anymore, but still > considers cases if non-ASII characters. > > I still believe that it would be sufficient to define the URI scheme in > ABNF, and be done with it. > ... Another problem with the current text is that it appears to be vague -- what does 1. If the /uri/ string is not an absolute URI, then fail this algorithm. [RFC3986] mean? What's the definition of "absolute URI" here? Best regards, Julian From pmcmanus@mozilla.com Tue May 24 16:53:50 2011 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 D265CE06D7 for ; Tue, 24 May 2011 16:53:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m6PKvwUDrRJ6 for ; Tue, 24 May 2011 16:53:50 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 58B40E064E for ; Tue, 24 May 2011 16:53:49 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id B059B10307; Tue, 24 May 2011 19:53:48 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 99E6E102A7 for ; Tue, 24 May 2011 19:53:44 -0400 (EDT) From: Patrick McManus To: hybi In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 May 2011 19:53:43 -0400 Message-ID: <1306281223.1782.9.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2011 23:53:50 -0000 I apologize for quoting from so deep in the archive, but the thread is still, somewhat to my horror, active: On Wed, 2011-04-27 at 21:16 -0400, John Tamplin wrote: > We had this discussion during the framing discussion, and we couldn't > reach consensus then. So, instead we simply said that each extension > defines how bits are to be interpreted. That could mean the bits are > statically allocated, or it could mean some negotiation scheme like > what you propose. > > I would be opposed to delaying the spec to try and get consensus on > negotiating the usage of reserved bits into the base spec, since it > can be just as easily postponed until the first extension that wants > to make use of some reserved bit. > I agree with everything John says above. Our AD has given strong guidance to create a IANA registry to record this, and I think that makes sense as well. From pmcmanus@mozilla.com Tue May 24 18:05:01 2011 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 ADE91E0754 for ; Tue, 24 May 2011 18:05:01 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAt-5w1O11JT for ; Tue, 24 May 2011 18:04:59 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id D2718E06CC for ; Tue, 24 May 2011 18:04:59 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id F3FAE10305; Tue, 24 May 2011 21:04:58 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 0657B102A7; Tue, 24 May 2011 21:04:54 -0400 (EDT) From: Patrick McManus To: Takeshi Yoshino In-Reply-To: References: <4DD9686C.7020509@callenish.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 May 2011 21:04:53 -0400 Message-ID: <1306285493.1782.33.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 01:05:01 -0000 On Mon, 2011-05-23 at 13:37 +0900, Takeshi Yoshino wrote: > > It's possible that A sends an unsolicited Pong with the same body as a > Ping sent by B. How do you choose Pong body for unsolicited Pong? I think that's looking at it backwards. If B cares about having the mandatory pong reply be matched to B's ping then B can simply create a non-predictable payload that -07 already requires to be echoed in the pong. No change to the protocol is necessary, right? > As initially most of implementors are not interested in using the > body of Ping and unsolicited Pong, they'll try to use an empty string. > Some may choose non empty string X for its Ping body but some other > may also use the same string X for its unsolicited Pongs' body. It > will be quickly out of control. > If the implementor cares about such things then those bodies are extremely poor implementation decisions. It makes sense to add some guidance to the text to help them out, but there is no reason to add constraints here or change the existing protocol imo. If the implementor changes their mind about being interested in such things they can change the implementation of their ping body at the same time. From gregw@intalio.com Tue May 24 19:40:04 2011 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 097A4E078C for ; Tue, 24 May 2011 19:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.927 X-Spam-Level: X-Spam-Status: No, score=-2.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4lu7Rum+nqH for ; Tue, 24 May 2011 19:40:03 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F767E0751 for ; Tue, 24 May 2011 19:40:03 -0700 (PDT) Received: by vws12 with SMTP id 12so6599072vws.31 for ; Tue, 24 May 2011 19:40:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.31.37 with SMTP id x5mr6405727vdh.264.1306291202392; Tue, 24 May 2011 19:40:02 -0700 (PDT) Received: by 10.52.187.71 with HTTP; Tue, 24 May 2011 19:40:02 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> Date: Wed, 25 May 2011 12:40:02 +1000 Message-ID: From: Greg Wilkins To: Brian Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 02:40:04 -0000 The simplest solution is to say that the 3 bits (and spare opcodes) in the framing are reserved for future versions of the protocol - ie off bounds to all extensions. Extensions that want to send bits and extra opcodes will always have to allocated bytes in the payload to carry them. Then we have two choices - come up with an allocation scheme in the spec (eg based on ordering like I've suggested), that may save a few bits per frame; or we could leave this to the extensions to do their own allocation (minimum 1 octect for extensions wanting flags and/or opcodes). I tend to agree that the bit savings might not be worth the effort to specify such a system, specially if we have a frame-deflate extension that would compress all those wasted bits anyway. The only outcome I'm strongly against is the status quo - where we have a few scarce resources with no fair share mechanism defined. This will just result in unfair market forces being used to make defacto allocations of those bits (and opcodes for that matter). It is better not to have them than to have them with no fair share policy. cheers On 21 May 2011 04:05, Brian wrote: > This seems fine to me too, but a bit more complicated than just > letting extensions prepend a byte for themselves to the payload data. > Honestly.. quibbling over wasting 7 bits by allocating a whole byte in > this day and age seems silly, even for things like cell phones. =C2=A0My > cell phone (iPhone on AT&T in Los Angeles) is routinely able to > transfer data at over a megabit per second (and even faster when I get > out of the city). =C2=A0So if there are a small handfull of "wasted" byte= s > in the payload to accommodate extension data/flags, nobody's really > going to notice. > > I would support the dynamically allocated flags mechanism that can > dynamically add more bytes to accomodate more extensions, but I just > think it seems a little unnecessary. > > Brian > > On Fri, May 20, 2011 at 12:50 AM, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB= =B8)" wrote: >> On 05/20/2011 07:42 AM, Somebody in the thread at some point said: >>> >>> Gabriel >>> >>> I'm concerned that if we really restrict usage of the reserved bits, >>> then we will force extensions into using whole bytes at the start of >>> the payload, when they really only want 1 bit. =C2=A0If we really do ge= t >>> into the situation where we have many extensions, then we could have >>> many wasted bits. >>> >>> How about just having a mechanism that if we can allocated as many >>> reserved bits as we like, and if more than 3 are allocated then extra >>> bytes are prepended to the payload (as needed) for the extra bits. >>> Thus we could have unlimited extensions needing unlimited bits. >>> >>> If a client doesn't want to play that game, then all it need do is >>> never handshake with extensions that need more than 3 bits. >> >> Sounds good to me. >> >> This idea of reserved bits being misered is not only unnecessary but it = is >> really inefficient - it'll lead to only special, big, connected players >> being able to use them and because they are permanently allocated to >> particular extensions in that model, there will always be a desire to >> withhold them "for later". >> >> Dynamic allocation way anyone can randomly decide their extension will u= se >> them, no central allocation is needed and multiple extensions using rese= rved >> bits will always play well (plus or minus other doubts about extension >> ordering not related to reserved bits). >> >> -Andy >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > From jat@google.com Tue May 24 20:05:13 2011 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 EA353E07A5 for ; Tue, 24 May 2011 20:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCLBnfutYi4s for ; Tue, 24 May 2011 20:05:13 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9ACCAE07A2 for ; Tue, 24 May 2011 20:05:07 -0700 (PDT) Received: from wpaz29.hot.corp.google.com (wpaz29.hot.corp.google.com [172.24.198.93]) by smtp-out.google.com with ESMTP id p4P355EE012399 for ; Tue, 24 May 2011 20:05:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306292706; bh=/pM21mnSpybVitb951MdDPz+dmo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=OgxwOJEJrjFm5VdW9NGFkBc+c6cL195Aa4Pi277ymQkx8r+nQTFAB0mcMIzSZgLg/ NTOgC/7U8Vqi/grNNxIdA== Received: from gyh4 (gyh4.prod.google.com [10.243.50.196]) by wpaz29.hot.corp.google.com with ESMTP id p4P34Z2f021614 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 20:05:04 -0700 Received: by gyh4 with SMTP id 4so3489226gyh.26 for ; Tue, 24 May 2011 20:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=t1Paya1/ayHwUx3ZrZv0i71v+TZCC5vyhPoZnEZHFq4=; b=Jd4ViAEB3nnVPiC/wMfIB3gVP4XtXFvcsH88o/pXaB3yyKvUGHl7C44XcU0caCKYZs GocUHn26SYeqSrx+2/tA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=c5pbXZA5r1mKTb4Q1EBGWU7Eq0qZmdejzqy3Sw8CfYTthaSLPe29VDd46Rlf2XG5b7 6+1i2uvdH1i65Aakoz9g== Received: by 10.151.87.21 with SMTP id p21mr4650237ybl.230.1306292704090; Tue, 24 May 2011 20:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 24 May 2011 20:04:44 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> From: John Tamplin Date: Tue, 24 May 2011 23:04:44 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd24576999cf304a410f807 X-System-Of-Record: true Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:05:14 -0000 --000e0cd24576999cf304a410f807 Content-Type: text/plain; charset=UTF-8 On Tue, May 24, 2011 at 10:40 PM, Greg Wilkins wrote: > The simplest solution is to say that the 3 bits (and spare opcodes) in > the framing are reserved for future versions of the protocol - ie off > bounds to all extensions. > > Extensions that want to send bits and extra opcodes will always have > to allocated bytes in the payload to carry them. > > Then we have two choices - come up with an allocation scheme in the > spec (eg based on ordering like I've suggested), that may save a few > bits per frame; or we could leave this to the extensions to do their > own allocation (minimum 1 octect for extensions wanting flags and/or > opcodes). I tend to agree that the bit savings might not be worth > the effort to specify such a system, specially if we have a > frame-deflate extension that would compress all those wasted bits > anyway. > > The only outcome I'm strongly against is the status quo - where we > have a few scarce resources with no fair share mechanism defined. > This will just result in unfair market forces being used to make > defacto allocations of those bits (and opcodes for that matter). It > is better not to have them than to have them with no fair share > policy. > So why do you object to leaving it up to the definition of the first extension that wants to allocate a reserved bit? At that point, it could define the dynamic allocation method you want. It isn't like any one party can railroad through a standards definition allocating one or more of the bits. I don't object to the idea, but I do not want to hold up the base spec, which isn't going to define a use for these bits anyway, trying to get consensus on how they should be allocated (though personally my preference is a registry rather than the complexity of dynamically allocating them). It sounds to me like you are saying "if I can't have it my way, nobody can have them". If they can't ever be used for extensions, it isn't entirely clear what they could be used for, so we would be better off just allocating them to the opcode than leaving them unused. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd24576999cf304a410f807 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 24, 2011 at 10:40 PM, Greg Wilkins <= span dir=3D"ltr"><gregw@intalio.com= > wrote:
The simplest solution is to say that the 3 bits (and spare opcodes) in
the framing are reserved for future versions of the protocol - ie off
bounds to all extensions.

Extensions that want to send bits and extra opcodes will always have
to allocated bytes in the payload to carry them.

Then we have two choices - come up with an allocation scheme in the
spec (eg based on ordering like I've suggested), that may save a few bits per frame; =C2=A0or we could leave this to the extensions to do their<= br> own allocation (minimum 1 octect for extensions wanting flags and/or
opcodes). =C2=A0 I tend to agree that the bit savings might not be worth the effort to specify such a system, specially if we have a
frame-deflate extension that would compress all those wasted bits
anyway.

The only outcome I'm strongly against is the status quo - where we
have a few scarce resources with no fair share mechanism defined.
This will just result in unfair market forces being used to make
defacto allocations of those bits (and opcodes for that matter). =C2=A0 It<= br> is better not to have them than to have them with no fair share
policy.

So why do you object to leavin= g it up to the definition of the first extension that wants to allocate a r= eserved bit? =C2=A0At that point, it could define the dynamic allocation me= thod you want. =C2=A0It isn't like any one party can railroad through a= standards definition allocating one or more of the bits. =C2=A0I don't= object to the idea, but I do not want to hold up the base spec, which isn&= #39;t going to define a use for these bits anyway, trying to get consensus = on how they should be allocated (though personally my preference is a regis= try rather than the complexity of dynamically allocating them).

It sounds to me like you are saying "if I can't hav= e it my way, nobody can have them". =C2=A0If they can't ever be us= ed for extensions, it isn't entirely clear what they could be used for,= so we would be better off just allocating them to the opcode than leaving = them unused.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd24576999cf304a410f807-- From brofield@gmail.com Tue May 24 20:08:51 2011 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 A9931E06E3 for ; Tue, 24 May 2011 20:08:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cMSzt5AuAyB for ; Tue, 24 May 2011 20:08:50 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id DABDDE0751 for ; Tue, 24 May 2011 20:08:50 -0700 (PDT) Received: by pzk5 with SMTP id 5so4334167pzk.31 for ; Tue, 24 May 2011 20:08:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=iBr1lmvQQcbZBel7SzoDhYx+DXmKhJgp/JTRRvctftQ=; b=Cy+l8mWoPtxc84Jicu/borxkK+MGRWdCSIaBTG8PmugLQgETmpy6sUvvTCvzlAdq2d ImgTwMd8BZSgq6JtX3U4mi4mh5IaFjGw1RvlIze0zWO5A2o4MUvGe88FZzqlXQv0YbD6 2HiZSY8/iz9v76q4tij9rbum0bYVdrxcuNUUg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=fJpXnWpbT5/EDYwT2rRrC/eKY0vySSsEWhbCF3FArPWJ2g/TdPc5QZYn5wU6MnINP/ A7NX7i2grM80PJz8iAud0rI0Zg+9F5cVlaOhR4gVq6lv/sVazqDco/THZwVOpzWG1kWI P+czV9qw1ydmH7ngbkjMYQvk98VwKjuznrd4o= MIME-Version: 1.0 Received: by 10.68.1.163 with SMTP id 3mr3279325pbn.160.1306292930154; Tue, 24 May 2011 20:08:50 -0700 (PDT) Sender: brofield@gmail.com Received: by 10.68.40.134 with HTTP; Tue, 24 May 2011 20:08:50 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> Date: Wed, 25 May 2011 12:08:50 +0900 X-Google-Sender-Auth: OxLPqVQLNqTPYTW_HQt1pVJSJZE Message-ID: From: Brodie Thiesfield To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:08:51 -0000 On Wed, May 25, 2011 at 11:40 AM, Greg Wilkins wrote: > The simplest solution is to say that the 3 bits (and spare opcodes) in > the framing are reserved for future versions of the protocol - ie off > bounds to all extensions. As stated earlier, I'm happy to live with no arbitrary extension use of the reserved bits. This will require the explicit permission to use reserved bits to be removed from the spec (see section 4.8). Removing extension use of opcodes doesn't seem reasonable, but without some sort of allocation scheme there will be no guaranteed interop between extensions as multiple extensions may attempt to use the same opcode. This will be the actual cause of the unpredictibility that Gabriel was worried about. Since there are already extensions being created that make use of extended opcodes (e.g. the elusive google-mux), now is really the time now to figure out how opcodes are allocated. At the very least, two opcodes (e.g. 0x7 and 0xF) should be explicity reserved for future expansion of the opcode space, which gives us somewhere to move if we continue the free for all now. Regards, Brodie > > Extensions that want to send bits and extra opcodes will always have > to allocated bytes in the payload to carry them. > > Then we have two choices - come up with an allocation scheme in the > spec (eg based on ordering like I've suggested), that may save a few > bits per frame; =C2=A0or we could leave this to the extensions to do thei= r > own allocation (minimum 1 octect for extensions wanting flags and/or > opcodes). =C2=A0 I tend to agree that the bit savings might not be worth > the effort to specify such a system, specially if we have a > frame-deflate extension that would compress all those wasted bits > anyway. > > The only outcome I'm strongly against is the status quo - where we > have a few scarce resources with no fair share mechanism defined. > This will just result in unfair market forces being used to make > defacto allocations of those bits (and opcodes for that matter). =C2=A0 I= t > is better not to have them than to have them with no fair share > policy. > > cheers > > > > On 21 May 2011 04:05, Brian wrote: >> This seems fine to me too, but a bit more complicated than just >> letting extensions prepend a byte for themselves to the payload data. >> Honestly.. quibbling over wasting 7 bits by allocating a whole byte in >> this day and age seems silly, even for things like cell phones. =C2=A0My >> cell phone (iPhone on AT&T in Los Angeles) is routinely able to >> transfer data at over a megabit per second (and even faster when I get >> out of the city). =C2=A0So if there are a small handfull of "wasted" byt= es >> in the payload to accommodate extension data/flags, nobody's really >> going to notice. >> >> I would support the dynamically allocated flags mechanism that can >> dynamically add more bytes to accomodate more extensions, but I just >> think it seems a little unnecessary. >> >> Brian >> >> On Fri, May 20, 2011 at 12:50 AM, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB= =B8)" wrote: >>> On 05/20/2011 07:42 AM, Somebody in the thread at some point said: >>>> >>>> Gabriel >>>> >>>> I'm concerned that if we really restrict usage of the reserved bits, >>>> then we will force extensions into using whole bytes at the start of >>>> the payload, when they really only want 1 bit. =C2=A0If we really do g= et >>>> into the situation where we have many extensions, then we could have >>>> many wasted bits. >>>> >>>> How about just having a mechanism that if we can allocated as many >>>> reserved bits as we like, and if more than 3 are allocated then extra >>>> bytes are prepended to the payload (as needed) for the extra bits. >>>> Thus we could have unlimited extensions needing unlimited bits. >>>> >>>> If a client doesn't want to play that game, then all it need do is >>>> never handshake with extensions that need more than 3 bits. >>> >>> Sounds good to me. >>> >>> This idea of reserved bits being misered is not only unnecessary but it= is >>> really inefficient - it'll lead to only special, big, connected players >>> being able to use them and because they are permanently allocated to >>> particular extensions in that model, there will always be a desire to >>> withhold them "for later". >>> >>> Dynamic allocation way anyone can randomly decide their extension will = use >>> them, no central allocation is needed and multiple extensions using res= erved >>> bits will always play well (plus or minus other doubts about extension >>> ordering not related to reserved bits). >>> >>> -Andy >>> _______________________________________________ >>> hybi mailing list >>> hybi@ietf.org >>> https://www.ietf.org/mailman/listinfo/hybi >>> >> > From tyoshino@google.com Tue May 24 20:08:57 2011 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 828DCE07B8 for ; Tue, 24 May 2011 20:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MsH3BvdPVfO for ; Tue, 24 May 2011 20:08:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CB0ABE06E3 for ; Tue, 24 May 2011 20:08:56 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p4P38um8022197 for ; Tue, 24 May 2011 20:08:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306292936; bh=2wXmBa+Y5b9XtO0r+Q9OxN2koGY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ieIki+noc41bP4Uk4jsWDBzL5CBgA5UIxJ4tm6asf1NL59W30XQF4IR0YbJdvYBEc GbnZHjk6uiMYfYeBHP0cA== Received: from yia27 (yia27.prod.google.com [10.243.65.27]) by wpaz13.hot.corp.google.com with ESMTP id p4P38ZEM012043 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 20:08:55 -0700 Received: by yia27 with SMTP id 27so3846789yia.33 for ; Tue, 24 May 2011 20:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=vRfIByYWaN0DbZIi/OIrJy1HS4qt7S0Tl8uArMB43/g=; b=Kswx3DDIdrpHoUe9fA3b87wSlX3NryklPDsz86XDjOISO7Pnq986QtlpvJUZITjjkP 95uToKsZbwTGw6uGezvA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=G6SsbUDf7kKU3bg7eB8LACMnA9/VNOLEzy8kpbqsnVwJFOKdC+Ep6zjcmhYYgcyVzX 9Pvy4BvDRRrPhclHCNew== Received: by 10.150.69.27 with SMTP id r27mr4776109yba.114.1306292935108; Tue, 24 May 2011 20:08:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Tue, 24 May 2011 20:08:35 -0700 (PDT) In-Reply-To: <1306285493.1782.33.camel@ds9> References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> From: Takeshi Yoshino Date: Wed, 25 May 2011 12:08:35 +0900 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=000e0cd5905a5eaa0604a41106f2 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 03:08:57 -0000 --000e0cd5905a5eaa0604a41106f2 Content-Type: text/plain; charset=ISO-8859-1 Hi, On Wed, May 25, 2011 at 10:04, Patrick McManus wrote: > I think that's looking at it backwards. > > If B cares about having the mandatory pong reply be matched to B's ping > then B can simply create a non-predictable payload that -07 already > requires to be echoed in the pong. > Hmm, I feel that having 1 byte pre-specified indicator rather simplifies this and is cheap enough. Yes, preparing something unpredictable solves this. I think it's fine when user-agents and servers for the service are under one vendor/people's control. A and B can just negotiate and use different body. But this is interoperability problem between user-agents and servers provided by various vendors/people. To be sure that the possibility of collision between body X which I use for my user-agent and any of server A, server B, ..., etc. is low enough, maybe I would use random bytes of 3 or more byte long. It costs than indicator. > If the implementor cares about such things then those bodies are > extremely poor implementation decisions. It makes sense to add some > Yes. > guidance to the text to help them out, but there is no reason to add > Agreed. At least some advice should be given. > constraints here or change the existing protocol imo. If the implementor > changes their mind about being interested in such things they can change > the implementation of their ping body at the same time. > Punting this and decide later is one option, but I'm not sure if it works with small effort of code/spec change and coordination. Different from extension etc. which will be defined in the future and then implemented, Ping/Pong will be implemented by everyone based on the current text. Thanks, Takeshi --000e0cd5905a5eaa0604a41106f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Wed, May 25, 2011 at 10:04, Patrick McManus <pmcmanus@mozilla= .com> wrote:
I think that's lookin= g at it backwards.

If B cares about having the mandatory pong reply be matched to B's ping=
then B can simply create a non-predictable payload that -07 already
requires to be echoed in the pong.

Hmm,= I feel that having 1 byte pre-specified indicator rather simplifies this a= nd is cheap enough. Yes, preparing something unpredictable solves this. I t= hink it's fine when user-agents and servers for the service are under o= ne vendor/people's control. A and B can just negotiate and use differen= t body. But this is interoperability problem between user-agents and server= s provided by various vendors/people. To be sure that the possibility of co= llision between body X which I use for my user-agent and any of server A, s= erver B, ..., etc. is low enough, maybe I would use random bytes of 3 or mo= re byte long. It costs than indicator.
=A0
If the impl= ementor cares about such things then those bodies are
extremely poor implementation decisions. It makes sense to add some

Yes.
=A0
guidance to the text to help them out, but there is no reason to add

Agreed. At least some advice should be given.=
=A0
constraints here or change the existing protocol imo. If the implementor changes their mind about being interested in such things they can change the implementation of their ping body at the same time.
=A0
Punting this and decide later is one option, but I'm no= t sure if it works with small effort of code/spec change and coordination. = Different from extension etc. which will be defined in the future and then = implemented, Ping/Pong will be implemented by everyone based on the current= text.

Thanks,
Takeshi

--000e0cd5905a5eaa0604a41106f2-- From tyoshino@google.com Tue May 24 20:11:10 2011 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 E3255E0751 for ; Tue, 24 May 2011 20:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xhdLF1aPgjx for ; Tue, 24 May 2011 20:11:10 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D5183E06E3 for ; Tue, 24 May 2011 20:11:09 -0700 (PDT) Received: from wpaz37.hot.corp.google.com (wpaz37.hot.corp.google.com [172.24.198.101]) by smtp-out.google.com with ESMTP id p4P3B8ve018408 for ; Tue, 24 May 2011 20:11:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306293069; bh=8YYj5B0lTkVJ4fqU5P6TF5ul9js=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=l9ZmrwTOC9B4mS0KFJmfLqm5KiwPpIo5ntVyu912nrYmFmgz3ftSI8Gxjpr2UBAjN m78DuNOGu+6DK/5wuG5sQ== Received: from gxk23 (gxk23.prod.google.com [10.202.11.23]) by wpaz37.hot.corp.google.com with ESMTP id p4P3AohO009717 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 20:11:07 -0700 Received: by gxk23 with SMTP id 23so3001919gxk.28 for ; Tue, 24 May 2011 20:11:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=jLEpa5tpEuuLjP8lbp8+wfy5hEzkLTmFJtn8v9SumxM=; b=R4wdbxEf1UbaeSRCC7Qg8uQAP3IHB8wXPb/xDrvZ/e0QD8mmooDIieKseNu10luiIZ lA+1ZI/4z5VSW5+s9HCQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=LMZ+LwhUT7T0m8DtAcmTH55ICa3TVucxNEh0MjxG7KhvAB9/W9SmZbX7T/aTE0ZAdP ZXb6rx5kGWR3gxLsFKnw== Received: by 10.151.50.15 with SMTP id c15mr4881709ybk.285.1306293067090; Tue, 24 May 2011 20:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Tue, 24 May 2011 20:10:47 -0700 (PDT) In-Reply-To: <4DDC0B84.9070500@callenish.com> References: <4DD9686C.7020509@callenish.com> <4DDC0B84.9070500@callenish.com> From: Takeshi Yoshino Date: Wed, 25 May 2011 12:10:47 +0900 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=0015175709063c8c3704a4110e17 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 03:11:11 -0000 --0015175709063c8c3704a4110e17 Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 25, 2011 at 04:48, Bruce Atherton wrote: > I see. Thanks for the clarification. I take your point. It is perhaps > because the body is so under-specified that this problem arises. You could > get around it by, for example, requiring PING to always start with a > timestamp and requiring an unsolicited PONG not to. Or you could require a > UUID from both PING and unsolicited PONG. > > But any of those ideas is no better (and probably worse) than your > solution, so I'm happy to support it. Yeah. I'm fine if anything by which I can distinguish them is specified by the spec. --0015175709063c8c3704a4110e17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 25, 2011 at 04:48, Bruce Atherton <bruce@callenish.= com> wrote:
I see. Thanks for the clarification. I take your point. It is perhaps becau= se the body is so under-specified that this problem arises. You could get a= round it by, for example, requiring PING to always start with a timestamp a= nd requiring an unsolicited PONG not to. Or you could require a UUID from b= oth PING and unsolicited PONG.

But any of those ideas is no better (and probably worse) than your solution= , so I'm happy to support it.

Yeah. I&#= 39;m fine if anything by which I can distinguish them is specified by the s= pec.

--0015175709063c8c3704a4110e17-- From brofield@gmail.com Tue May 24 20:18:56 2011 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 48D07E0751 for ; Tue, 24 May 2011 20:18:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcXLVWovOVYf for ; Tue, 24 May 2011 20:18:55 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id AC28BE0682 for ; Tue, 24 May 2011 20:18:55 -0700 (PDT) Received: by pzk5 with SMTP id 5so4336759pzk.31 for ; Tue, 24 May 2011 20:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Fz3Pu5lxy7cob4WejZDpa+gm1l6x4ZCK+43KkmzK9Tc=; b=atEvfVbyyG2PH6+5/7d5WJBlX3nQNPIDtxF5tYTnjPRIzavSlBrZt8Lvq2FTTkqa2Q s9McyX4BEMoT9c+xO2Fv427pBsbQdDZB3U+hYcj4fh/siNvNBJuWet2ng6spS1fk1Jja l2U6CH+fQoXAGewlqDlZVezQhD/7vI+S2OEus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=hucVlpiLqbO0CwIhytCFfdoIO/i8W1YLotR4sXUQwzGUkikaGVWh9JjSfjJmNrqHWR qJx9gPRMkQ47+H5SyLuE4UB9Ooy/M1f8cNsnfCDX0/x0vej64SqvAe5btolCpTku0Ran E49TpCHLPz9fmpVYtXdCQmPhh2rEjo42Nxpno= MIME-Version: 1.0 Received: by 10.68.22.2 with SMTP id z2mr3117042pbe.428.1306293535431; Tue, 24 May 2011 20:18:55 -0700 (PDT) Sender: brofield@gmail.com Received: by 10.68.40.134 with HTTP; Tue, 24 May 2011 20:18:55 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> Date: Wed, 25 May 2011 12:18:55 +0900 X-Google-Sender-Auth: 6SiQ0771NXG0zMZL2pRE9_6qjEc Message-ID: From: Brodie Thiesfield To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Greg Wilkins Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:18:56 -0000 On Wed, May 25, 2011 at 12:04 PM, John Tamplin wrote: > On Tue, May 24, 2011 at 10:40 PM, Greg Wilkins wrote: >> >> The simplest solution is to say that the 3 bits (and spare opcodes) in >> the framing are reserved for future versions of the protocol - ie off >> bounds to all extensions. >> >> ....snip... >> >> The only outcome I'm strongly against is the status quo - where we >> have a few scarce resources with no fair share mechanism defined. >> This will just result in unfair market forces being used to make >> defacto allocations of those bits (and opcodes for that matter). =A0 It >> is better not to have them than to have them with no fair share >> policy. > > So why do you object to leaving it up to the definition of the first > extension that wants to allocate a reserved bit? =A0At that point, it cou= ld > define the dynamic allocation method you want. =A0It isn't like any one p= arty > can railroad through a standards definition allocating one or more of the > bits. =A0I don't object to the idea, but I do not want to hold up the bas= e > spec, which isn't going to define a use for these bits anyway, trying to = get > consensus on how they should be allocated (though personally my preferenc= e > is a registry rather than the complexity of dynamically allocating them). Then making them reserved and off-limits to arbitrary use by extensions, and requiring the use of the IANA registry is your preference as well? > It sounds to me like you are saying "if I can't have it my way, nobody ca= n > have them". =A0If they can't ever be used for extensions, it isn't entire= ly > clear what they could be used for, so we would be better off just allocat= ing > them to the opcode than leaving them unused. If they are registered it doesn't mean they can't be used. Just that the extension that uses them must be blessed with the registration. All other extensions just add a byte to their payload and use it for their flags. Regards, Brodie From jat@google.com Tue May 24 20:31:48 2011 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 F139BE06F3 for ; Tue, 24 May 2011 20:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AOCUW14eGYJ for ; Tue, 24 May 2011 20:31:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id CC5E5E078C for ; Tue, 24 May 2011 20:31:47 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p4P3VkBS027430 for ; Tue, 24 May 2011 20:31:46 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306294307; bh=0z3hXdJknAQEhJ8B7UN6FaWVGZc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=nJZLShIw3mE3NvseZWldkUMfWjifopsZffi0ZedE1h+hGw8N4DmF2IGb8xD+xbOdA L44UZ84u3anLVJb/yYjvQ== Received: from gwj15 (gwj15.prod.google.com [10.200.10.15]) by wpaz33.hot.corp.google.com with ESMTP id p4P3VSNK025127 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 20:31:45 -0700 Received: by gwj15 with SMTP id 15so3581462gwj.25 for ; Tue, 24 May 2011 20:31:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=BJr0S+wdjbef7vmV+rK5EyPb5/+BaZ5MLhKgR0ZURU8=; b=ORXVlZNV4R5nnFp4TlluMXjY9O7GvClKe54Hn74UKcaXZ5gVBGnmHXDO6bXat3RoXo B0rfmdEcQOS9Gt9VMxjA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=vnJaDQtqs6qM24x9S0wKoMvZ9tQFi00hiZtFl/RiAoGnLAD2G/krs9/tPKbs8niOHZ 0wOD5fgRdBVLRtgcc0Tw== Received: by 10.150.236.7 with SMTP id j7mr4955337ybh.287.1306294305119; Tue, 24 May 2011 20:31:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 24 May 2011 20:31:24 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> From: John Tamplin Date: Tue, 24 May 2011 23:31:24 -0400 Message-ID: To: Brodie Thiesfield Content-Type: multipart/alternative; boundary=000e0cd240c0075d7f04a4115823 X-System-Of-Record: true Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Greg Wilkins Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 03:31:49 -0000 --000e0cd240c0075d7f04a4115823 Content-Type: text/plain; charset=UTF-8 On Tue, May 24, 2011 at 11:18 PM, Brodie Thiesfield wrote: > >> The only outcome I'm strongly against is the status quo - where we > >> have a few scarce resources with no fair share mechanism defined. > >> This will just result in unfair market forces being used to make > >> defacto allocations of those bits (and opcodes for that matter). It > >> is better not to have them than to have them with no fair share > >> policy. > > > > So why do you object to leaving it up to the definition of the first > > extension that wants to allocate a reserved bit? At that point, it could > > define the dynamic allocation method you want. It isn't like any one > party > > can railroad through a standards definition allocating one or more of the > > bits. I don't object to the idea, but I do not want to hold up the base > > spec, which isn't going to define a use for these bits anyway, trying to > get > > consensus on how they should be allocated (though personally my > preference > > is a registry rather than the complexity of dynamically allocating them). > > Then making them reserved and off-limits to arbitrary use by > extensions, and requiring the use of the IANA registry is your > preference as well? That isn't what Greg was suggesting -- he was saying they were not available for extensions at all, but yes having a registry would be fine with me. > > It sounds to me like you are saying "if I can't have it my way, nobody > can > > have them". If they can't ever be used for extensions, it isn't entirely > > clear what they could be used for, so we would be better off just > allocating > > them to the opcode than leaving them unused. > > If they are registered it doesn't mean they can't be used. Just that > the extension that uses them must be blessed with the registration. > All other extensions just add a byte to their payload and use it for > their flags. > Again, that isn't what Greg was suggesting. Also, if reserved opcodes can't be used (which Greg was also suggesting), then there is no room for any experimentation, which seems a recipe for poor progress getting useful extensions. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd240c0075d7f04a4115823 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 24, 2011 at 11:18 PM, Brodie Thiesfi= eld <brodie@jel= lycan.com> wrote:
>> The only outcome I'm strongly against is the= status quo - where we
>> have a few scarce resources with no fair share mechanism defined.<= br> >> This will just result in unfair market forces being used to make >> defacto allocations of those bits (and opcodes for that matter). = =C2=A0 It
>> is better not to have them than to have them with no fair share >> policy.
>
> So why do you object to leaving it up to the definition of the first > extension that wants to allocate a reserved bit? =C2=A0At that point, = it could
> define the dynamic allocation method you want. =C2=A0It isn't like= any one party
> can railroad through a standards definition allocating one or more of = the
> bits. =C2=A0I don't object to the idea, but I do not want to hold = up the base
> spec, which isn't going to define a use for these bits anyway, try= ing to get
> consensus on how they should be allocated (though personally my prefer= ence
> is a registry rather than the complexity of dynamically allocating the= m).

Then making them reserved and off-limits to arbitrary use by
extensions, and requiring the use of the IANA registry is your
preference as well?

That isn't what Gre= g was suggesting -- he was saying they were not available for extensions at= all, but yes having a registry would be fine with me.
=C2=A0
> It sounds to me like you are saying "if I can't have it my wa= y, nobody can
> have them". =C2=A0If they can't ever be used for extensions, = it isn't entirely
> clear what they could be used for, so we would be better off just allo= cating
> them to the opcode than leaving them unused.

If they are registered it doesn't mean they can't be used. Ju= st that
the extension that uses them must be blessed with the registration.
All other extensions just add a byte to their payload and use it for
their flags.

Again, that isn't what= Greg was suggesting.

Also, if reserved opcodes ca= n't be used (which Greg was also suggesting), then there is no room for= any experimentation, which seems a recipe for poor progress getting useful= extensions.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd240c0075d7f04a4115823-- From pmcmanus@mozilla.com Tue May 24 20:37:42 2011 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 E3434E07A6 for ; Tue, 24 May 2011 20:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jaIPD+7NLVJx for ; Tue, 24 May 2011 20:37:42 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 726A9E0751 for ; Tue, 24 May 2011 20:37:42 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 05FB110308; Tue, 24 May 2011 23:37:41 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 94275102A7; Tue, 24 May 2011 23:37:37 -0400 (EDT) From: Patrick McManus To: Takeshi Yoshino In-Reply-To: References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> Content-Type: text/plain; charset="UTF-8" Date: Tue, 24 May 2011 23:37:36 -0400 Message-ID: <1306294656.1782.50.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 03:37:43 -0000 On Wed, 2011-05-25 at 12:08 +0900, Takeshi Yoshino wrote: > . Yes, preparing something unpredictable solves this. right, without further changes to the protocol. Then we could ship websockets and people could start writing applications instead of documents. Stability is a worthwhile goal. > But this is interoperability problem between user-agents and servers > provided by various vendors/people I disagree, because [see below] > enough, maybe I would use random bytes of 3 or more byte long. right. The ping-generating-peer doesn't need cooperation from the other peer in order to create a unique payload. Interoperabiity does not require that each end use the same algorithm - either the client or the server can be the ping generating peer. From w@1wt.eu Tue May 24 21:38:40 2011 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 DB853E0665 for ; Tue, 24 May 2011 21:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-3.812, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w10nT8sdI7XI for ; Tue, 24 May 2011 21:38:40 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 17F09E0699 for ; Tue, 24 May 2011 21:38:39 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p4P4cW8k006354; Wed, 25 May 2011 06:38:32 +0200 Date: Wed, 25 May 2011 06:38:32 +0200 From: Willy Tarreau To: Patrick McManus Message-ID: <20110525043832.GA6328@1wt.eu> References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> <1306294656.1782.50.camel@ds9> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1306294656.1782.50.camel@ds9> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 04:38:41 -0000 Hi Patrick, On Tue, May 24, 2011 at 11:37:36PM -0400, Patrick McManus wrote: > On Wed, 2011-05-25 at 12:08 +0900, Takeshi Yoshino wrote: > > > . Yes, preparing something unpredictable solves this. > > right, without further changes to the protocol. Then we could ship > websockets and people could start writing applications instead of > documents. Stability is a worthwhile goal. > > > But this is interoperability problem between user-agents and servers > > provided by various vendors/people > > I disagree, because [see below] > > > enough, maybe I would use random bytes of 3 or more byte long. > > right. The ping-generating-peer doesn't need cooperation from the other > peer in order to create a unique payload. Interoperabiity does not > require that each end use the same algorithm - either the client or the > server can be the ping generating peer. I would add that if one peer randomly sends pong messages, it's just deliberately trying to get its communication degraded. Ping/pong may be used in order to improve quality of service by detecting quickly that a connection seems to be broken. There's nothing to win by fooling this. It's similar to ICMP ping : instead of wondering what would happen if Google sends me fake echo reply messages when I ping them to check if my DSL line is OK, I prefer to ask why would they do this in the first place and for what purpose ? Here it's the same. We could similarly have peers that randomly send crap just because it's fun, or send wrong size message on purpose, we can imagine anything. It just has no use for the one sending that crap, so basically I4d say that unsollicited pong messages must be ignored, and that even if the other end fakes a perfect pong that you take for valid, we should't care. This fake pong will lead to wrong RTT estimates and the valid one will be ignored, end of the story. In ICMP we have a sequence number in ping messages. This might be useful to ensure we're getting the association right, and it's easier to recommend using a counter than sending a random message. Some users might prefer to send a timestamp in the message maybe. Regards, Willy From gregw@intalio.com Tue May 24 22:08:03 2011 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 340D6E06EF for ; Tue, 24 May 2011 22:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.934 X-Spam-Level: X-Spam-Status: No, score=-2.934 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3QGySecOhec9 for ; Tue, 24 May 2011 22:08:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5F45DE065B for ; Tue, 24 May 2011 22:08:02 -0700 (PDT) Received: by vxg33 with SMTP id 33so6658559vxg.31 for ; Tue, 24 May 2011 22:08:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.32.104 with SMTP id h8mr1232047vdi.64.1306300081315; Tue, 24 May 2011 22:08:01 -0700 (PDT) Received: by 10.52.187.71 with HTTP; Tue, 24 May 2011 22:08:01 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> Date: Wed, 25 May 2011 15:08:01 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:08:03 -0000 On 25 May 2011 13:31, John Tamplin wrote: > On Tue, May 24, 2011 at 11:18 PM, Brodie Thiesfield > wrote: >> >> >> The only outcome I'm strongly against is the status quo - where we >> >> have a few scarce resources with no fair share mechanism defined. >> >> This will just result in unfair market forces being used to make >> >> defacto allocations of those bits (and opcodes for that matter). =A0 = It >> >> is better not to have them than to have them with no fair share >> >> policy. >> > >> > So why do you object to leaving it up to the definition of the first >> > extension that wants to allocate a reserved bit? =A0At that point, it >> > could >> > define the dynamic allocation method you want. =A0It isn't like any on= e >> > party >> > can railroad through a standards definition allocating one or more of >> > the >> > bits. =A0I don't object to the idea, but I do not want to hold up the = base >> > spec, which isn't going to define a use for these bits anyway, trying = to >> > get >> > consensus on how they should be allocated (though personally my >> > preference >> > is a registry rather than the complexity of dynamically allocating >> > them). >> >> Then making them reserved and off-limits to arbitrary use by >> extensions, and requiring the use of the IANA registry is your >> preference as well? > > That isn't what Greg was suggesting -- he was saying they were not availa= ble > for extensions at all, but yes having a registry would be fine with me. I don't want them available for extensions if it is just a free-for-all, because then non-technical market forces will come into play for their allocation and interoperability will be poor unless you only use defacto standard extensions. IANA registry is also a way to avoid the free for all, but it feels a bit heavy bureaucracy for just 3 bits, which will soon be consumed and then we are back to having no available bits and extensions have to use the payload anyway. But IANA is better than the status quo of no allocation. >> > It sounds to me like you are saying "if I can't have it my way, nobody >> > can >> > have them". =A0If they can't ever be used for extensions, it isn't >> > entirely >> > clear what they could be used for, so we would be better off just >> > allocating >> > them to the opcode than leaving them unused. >> >> If they are registered it doesn't mean they can't be used. Just that >> the extension that uses them must be blessed with the registration. >> All other extensions just add a byte to their payload and use it for >> their flags. > > Again, that isn't what Greg was suggesting. > Also, if reserved opcodes can't be used (which Greg was also suggesting), > then there is no room for any experimentation, which seems a recipe for p= oor > progress getting useful extensions. Extensions can always have their own opcodes by putting them as a byte in the payload (which is what you have previously advocated for extension opcodes anyway). Sure we can go to IANA and create a registry for the 8 or so available opcodes, but I'm sure they will soon be allocated to some worthy extensions and then future experimentation will have to use payload opcodes anyway. I just think that we have too few bits and opcodes available to make a fixed allocation work (either by defacto standards or by IANA registry), as all will soon be consumed and we then have to think of other solutions anyway. I think a simple dynamic allocation mechanism would work for a large pool of possible extensions, but we would be limited by how many active extensions could be applied on the same connection. So eitherway, I see that eventually we will have to handle extensions with flags and codes in the payload, so why not just go there directly and not have to deal with either designing a system now or working with IANA to allocated very limited resources. cheers From jat@google.com Tue May 24 22:14:30 2011 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 799AAE0699 for ; Tue, 24 May 2011 22:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4WJJ31jXqZL for ; Tue, 24 May 2011 22:14:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C57DEE065B for ; Tue, 24 May 2011 22:14:29 -0700 (PDT) Received: from hpaq11.eem.corp.google.com (hpaq11.eem.corp.google.com [172.25.149.11]) by smtp-out.google.com with ESMTP id p4P5ESQ1008339 for ; Tue, 24 May 2011 22:14:29 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306300469; bh=3uu0f8EK6HQLGLlNET9zYZLZJWk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=OWSRtQS/8fMM/xd/xDNniVlFJLNA3Ofi9SbO3gvqYIjKlvV37U3NT0O9gvzbvn1Ms Qq/v5ZcdrHqigDfoQSpBA== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by hpaq11.eem.corp.google.com with ESMTP id p4P5EQIV015541 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 22:14:27 -0700 Received: by gyf2 with SMTP id 2so3605401gyf.25 for ; Tue, 24 May 2011 22:14:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=63aJ4Lc6gqdcQxYaAdkaxnigaaaaXuVmZAIpSHAfXYE=; b=aIjniDSWlukImBKiiyRCvcwb9iOlATPzXy/ebTEhlC6A3UU0R1lz7GcF44PJz2khSn 6djzHVReKdwCHffc2yeg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=K0H/Jl8HzL2gBCFg++lUwAVcxz36xi0U0mQQZ6j9HlULZ6vCFJ7UF28aQ2/lOaaMai YNR0PFQbg/Zdn0ElQmBw== Received: by 10.150.73.3 with SMTP id v3mr4753087yba.173.1306300466172; Tue, 24 May 2011 22:14:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 24 May 2011 22:14:04 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> From: John Tamplin Date: Wed, 25 May 2011 01:14:04 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd58e2a4194e804a412c78f X-System-Of-Record: true Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 05:14:30 -0000 --000e0cd58e2a4194e804a412c78f Content-Type: text/plain; charset=UTF-8 On Wed, May 25, 2011 at 1:08 AM, Greg Wilkins wrote: > > Again, that isn't what Greg was suggesting. > > Also, if reserved opcodes can't be used (which Greg was also suggesting), > > then there is no room for any experimentation, which seems a recipe for > poor > > progress getting useful extensions. > > Extensions can always have their own opcodes by putting them as a byte > in the payload (which is what you have previously advocated for > extension opcodes anyway). Not if you don't define some extension opcode. Ie, if I can't use a reserved opcode, saying my frame is a binary frame and the first byte is really a new opcode doesn't work with fragmentation and multiplexing being done by intermediaries which think it is just a regular binary frame. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd58e2a4194e804a412c78f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, May 25, 2011 at 1:08 AM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
> Again, that isn't what Greg was = suggesting.
> Also, if reserved opcodes can't be used (which Greg was also sugge= sting),
> then there is no room for any experimentation, which seems a recipe fo= r poor
> progress getting useful extensions.

Extensions can always have their own opcodes by putting them as a byt= e
in the payload (which is what you have previously advocated for
extension opcodes anyway).

Not if you don&= #39;t define some extension opcode. =C2=A0Ie, if I can't use a reserved= opcode, saying my frame is a binary frame and the first byte is really a n= ew opcode doesn't work with fragmentation and multiplexing being done b= y intermediaries which think it is just a regular binary frame.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd58e2a4194e804a412c78f-- From gregw@intalio.com Tue May 24 23:00:58 2011 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 52CC113000D for ; Tue, 24 May 2011 23:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YAU1N4TKq6Pn for ; Tue, 24 May 2011 23:00:57 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id AABC913000B for ; Tue, 24 May 2011 23:00:57 -0700 (PDT) Received: by vws12 with SMTP id 12so6690515vws.31 for ; Tue, 24 May 2011 23:00:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.73.2 with SMTP id h2mr1299850vdv.104.1306303256938; Tue, 24 May 2011 23:00:56 -0700 (PDT) Received: by 10.52.187.71 with HTTP; Tue, 24 May 2011 23:00:56 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> Date: Wed, 25 May 2011 16:00:56 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Alan Coopersmith , "jg@freedesktop.org" , Gabriel Montenegro , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 06:00:58 -0000 On 25 May 2011 15:14, John Tamplin wrote: > On Wed, May 25, 2011 at 1:08 AM, Greg Wilkins wrote: >> >> > Again, that isn't what Greg was suggesting. >> > Also, if reserved opcodes can't be used (which Greg was also >> > suggesting), >> > then there is no room for any experimentation, which seems a recipe fo= r >> > poor >> > progress getting useful extensions. >> >> Extensions can always have their own opcodes by putting them as a byte >> in the payload (which is what you have previously advocated for >> extension opcodes anyway). > > Not if you don't define some extension opcode. =A0Ie, if I can't use a > reserved opcode, saying my frame is a binary frame and the first byte is > really a new opcode doesn't work with fragmentation and multiplexing bein= g > done by intermediaries which think it is just a regular binary frame. Why can't the extension just send frames with the normal binary frame opcode which then contain the extension specific opcode in the payload. Intermediaries will see these as binary frames - which they are. Intermediaries that don't know the extension are not allowed to mess with the framing/fragmentation, so thats not a problem. The receiving extension takes the real opcode out of the payload and handles it as a control, text, binary, whatever frame as appropriate. ie, I don't see what is wrong with using the normal binary opcode for an extension that sends binary payload, or the normal text opcode for an extension that sends a text payload (eg adding mime headers as text). cheers From tyoshino@google.com Tue May 24 23:32:00 2011 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 28514E079F for ; Tue, 24 May 2011 23:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIFfPzvAPp5o for ; Tue, 24 May 2011 23:31:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 37741E075E for ; Tue, 24 May 2011 23:31:59 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p4P6Vv8h002402 for ; Tue, 24 May 2011 23:31:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306305117; bh=zeF329QHy6mLfGngH/2owR67c2I=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=udF8YRsAD8hHEroFvyRcr+sYaT5b2KWFGYCdVMpVKJ22STmBmryTLd5R/NvK++Ax8 nlwHyBxbSuFDxyD3rDx5A== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq7.eem.corp.google.com with ESMTP id p4P6VtmI025230 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 24 May 2011 23:31:56 -0700 Received: by gyf3 with SMTP id 3so3692686gyf.31 for ; Tue, 24 May 2011 23:31:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=wm3WoMugltz7JxsXQ2/pdJsMGgDt+YHnualfYP363sk=; b=LiiGMDnia9jEYw+DnEK4c6ingVSNAxYUIpNr6p5V854xZyaIN5CjwphEulb+rxu620 l/Ykh2Hj9/aZeGXKVTWg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=hTReTLVhyKE95ibDagliWkAv83WmMuyFKla492X8NgLg3YOa9yZqpGiGZy62ZAZ5xP WsryjlmPAgdGEqJfPc6A== Received: by 10.151.99.21 with SMTP id b21mr5062652ybm.57.1306305115091; Tue, 24 May 2011 23:31:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Tue, 24 May 2011 23:31:35 -0700 (PDT) In-Reply-To: <1306294656.1782.50.camel@ds9> References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> <1306294656.1782.50.camel@ds9> From: Takeshi Yoshino Date: Wed, 25 May 2011 15:31:35 +0900 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=0015174c1c1e5a75c304a413dcaa X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 06:32:00 -0000 --0015174c1c1e5a75c304a413dcaa Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 25, 2011 at 12:37, Patrick McManus wrote: > right, without further changes to the protocol. Then we could ship > websockets and people could start writing applications instead of > documents. Stability is a worthwhile goal. I really care the time of shipment, too. I don't want this to be show stopper, but want to get attention to this point from people who want to use some extended Ping, unsolicited Pong, etc. to get this thought out enough. > > enough, maybe I would use random bytes of 3 or more byte long. > > right. The ping-generating-peer doesn't need cooperation from the other > peer in order to create a unique payload. Interoperabiity does not > Yes. > require that each end use the same algorithm - either the client or the > server can be the ping generating peer. > Sorry, I couldn't get you. A and B don't have to use the same algorithm, but in fact those algorithms need coordination. A's algorithm must choose X for its Ping where X != Y which B's algorithm chooses for its unsolicited Pong. Well, I agree that I'm saying something paranoid, but it's true. How about this? Semantically a bit smaller change. "Body of Ping and unsolicited body can be empty. IF Ping or unsolicited Pong have non-empty body, they must start with 0x00 and 0x01" This doesn't break interoperability with -07 or add new constraint to body as long as the user-agent doesn't have any data to be put into body. When some peer want to disambiguate them, it can safely do it by prefixing body with 0x00 or 0x01 without any new negotiation, coordination or randomness. For any foobar, 0x00 foobar != 0x01 foobar 0x00 foobar != "" 0x01 foobar != "" --0015174c1c1e5a75c304a413dcaa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 25, 2011 at 12:37, Patrick McManus <= span dir=3D"ltr"><pmcmanus@mozil= la.com> wrote:
right, without further changes to the protocol. Then we c= ould ship
websockets and people could start writing applications instead of
documents. Stability is a worthwhile goal.

= I really care the time of shipment, too. I don't want this to be show s= topper, but want to get attention to this point from people who want to use= some extended Ping, unsolicited Pong, etc. to get this thought out enough.=
=A0
> =A0eno= ugh, maybe I would use random bytes of 3 or more byte long.

right. The ping-generating-peer doesn't need cooperation from the= other
peer in order to create a unique payload. Interoperabiity does not

Yes.
=A0
require that each end use the same algorithm - either the client or the
server can be the ping generating peer.

Sorry, I couldn't get you. A and B don't have to use the same algo= rithm, but in fact those algorithms need coordination. A's algorithm mu= st choose X for its Ping where X !=3D Y which B's algorithm chooses for= its unsolicited Pong.=A0Well, I agree that I'm saying something parano= id, but it's true.

How about this? Semantically a bit smaller change.
"Body of Ping and unsolicited body can be empty. IF Ping or unso= licited Pong have non-empty body, they must start with 0x00 and 0x01"<= /div>
This doesn't break interoperability with -07 or add new constraint= to body as long as the user-agent doesn't have any data to be put into= body. When some peer want to disambiguate them, it can safely do it by pre= fixing body with 0x00 or 0x01 without any new negotiation, coordination or = randomness.

For any foobar,
0x00 foobar !=3D 0x01 foobar<= /div>
0x00 foobar !=3D ""
0x01 foobar !=3D "&q= uot;

--0015174c1c1e5a75c304a413dcaa-- From sm@resistor.net Wed May 25 00:01:50 2011 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 25CAEE0688 for ; Wed, 25 May 2011 00:01:50 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxzvMkDC1KzY for ; Wed, 25 May 2011 00:01:49 -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 20735E0662 for ; Wed, 25 May 2011 00:01:48 -0700 (PDT) Received: from subman.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5.Beta0) with ESMTP id p4P71bqo017171 for ; Wed, 25 May 2011 00:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1306306904; bh=TVIasn3Uadireqc/9JoOom3BkIAg17luP/8pJA+y7+4=; h=Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=vA+covrETaQzA7tZPwnBVe+p0zSXKx64b18ClJC8kLYy03kbFzPMXOK1QolaIvOma CBBDdQiiUCgGqPofmhQ6zw9Vru8E2QU1rZBEP4/ZlH9ZjgrzU2G+lcOkyq/G/WeAFd Z61tGDhzUkBPonZ3eIKEbLAg8Ku+9xdYYTDvWhFs= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1306306904; bh=TVIasn3Uadireqc/9JoOom3BkIAg17luP/8pJA+y7+4=; h=Message-Id:X-Mailer:Date:To:From:Subject:In-Reply-To:References: Mime-Version:Content-Type; b=GA/grqseWQ0dkxKaXdM1ncEl5xo+WWkGShUDHIAka/SUwSmu7iPGa5whAlzRRIa8R Otnr4ZcmoRB55DWIf4pvmo48JRcCbRBppfA/fGUrYqcLU4DvTe0dvtsZZTgsPK35Xi xMzR9jowzCLISByLqwU2eCpW+hbyDOvypaaywzA8= Message-Id: <6.2.5.6.2.20110524234152.03017c30@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Tue, 24 May 2011 23:52:41 -0700 To: hybi@ietf.org From: SM In-Reply-To: References: <4DBA3809.4010004@oracle.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 07:01:50 -0000 At 18:03 19-05-2011, Gabriel Montenegro wrote: >Reserved bits should only be allocated for very compelling reasons, >either because there is an extension that has full backing of the WG >or because there is a new version of the protocol that needs it. I >think we should word our IANA considerations on bit assignment with >a very strict assignment policy of "Standards Action": >http://tools.ietf.org/html/rfc5226#section-4.1 Reserved bits can be allocated in future. When a bit is marked as "reserved" it does not mean that it will never be used. Having a strict assignment requirement has advantages and disadvantages. If people find it difficult to get an assignment, they will squat on the bits. It would be good if the working group give some thought to this question. Regards, -sm From tyoshino@google.com Wed May 25 01:05:07 2011 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 0BC64E06D6 for ; Wed, 25 May 2011 01:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KQeCRkXGqZt7 for ; Wed, 25 May 2011 01:05:06 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5048AE06D5 for ; Wed, 25 May 2011 01:05:06 -0700 (PDT) Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p4P855Sk030958 for ; Wed, 25 May 2011 01:05:05 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306310705; bh=cKSid0i98Q/3xmhblZu/q21WkWE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wnd/oL85yxi2Kj2KEgt8JYU2kKJvxEoIAwAAw62zNRcRUouk8SwxFF4LSRmkoIoPK +dMBj5Sb6mgbBPKo1aZDg== Received: from ywg4 (ywg4.prod.google.com [10.192.7.4]) by wpaz33.hot.corp.google.com with ESMTP id p4P84dPZ017278 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 25 May 2011 01:05:04 -0700 Received: by ywg4 with SMTP id 4so3310053ywg.38 for ; Wed, 25 May 2011 01:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IQzMwMR0s9b5K1SXmw/keMTyhChojMkjj4d0NX8KDyU=; b=cxp+TWFx1Ww4zGeVX0M5ecgodKFBka12+DcPDm/40WG7Ef579IvB2j4125oYaAVHo1 G8VY4PSy1xPF7qySC+rQ== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=c+qxfniaZfdyEWjaC3b0Rk9Z7+9S4Ez2wrRrb4oPsAAWrMRhlj8HO155yDx4E+Fghq 6Rl01sxQqDVK6thbIdoQ== Received: by 10.151.99.6 with SMTP id b6mr4885076ybm.342.1306310704150; Wed, 25 May 2011 01:05:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.50.13 with HTTP; Wed, 25 May 2011 01:04:44 -0700 (PDT) In-Reply-To: <4DA6A003.3070308@warmcat.com> References: <4DA6A003.3070308@warmcat.com> From: Takeshi Yoshino Date: Wed, 25 May 2011 17:04:44 +0900 Message-ID: To: Andy Green Content-Type: multipart/alternative; boundary=0015175114de7cba0604a41529dd X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Subprotocol semantics. How SHOULD/MUST user-agent and server deal with it X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 08:05:07 -0000 --0015175114de7cba0604a41529dd Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 14, 2011 at 16:19, Andy Green wrote: > On 04/14/2011 07:57 AM, Somebody in the thread at some point said: > f) supports multiple subprotocols but Sec-WebSocket-Protocol in request > >> didn't contain any of them >> > > It sounds clear to me that we should drop the request in case f). >> > > Right... whatever the plan was for no explicit protocol being negotiated, > it no longer makes any sense. > > The protocol should always have to be explicitly requested by the client > even if the server only supports that one, you don't know if a different > client who assumes it is a different protocol is connecting to you > otherwise. There'd be no error and if the protocols were similar the > failure mode might take a long time to show or be subtle. > Thanks, Andy. As no one seems to be interested in usefulness of these strange cases, I'd suggest explicitly drop these cases a) - d) in the client requirements normative section. So the resulting spec texts for Sec-WebSocket-Protocol handling is like this. ==== Sec-WebSocket-Protocol in request - 1#(token | quoted-string) - characters in each of element after unquoting must be in the range U+0021 to U+007E Sec-WebSocket-Protocol in response - (token | quoted-string) -- This forbids case b) - characters in string after unquoting must be in the range U+0021 to U+007E User agent must - (if subprotocols is given) format and send subprotocols - (otherwise) send nothing User agent fail when - sent subprotocols but didn't receive subprotocol # This forbids case c) - sent subprotocols and received subprotocol but it's not in sent subprotocols # This forbids case a) - didn't send subprotocols but received subprotocol # This forbids case d) - received bad formatted subprotocol Otherwise, pass received subprotocol to upper layer Server side fail when - received bad formatted subprotocols - whenever the server is not satisfied with subprotocols -- This relegates decision for e) and f) to server implementation Server - (if received subprotocols) must choose one subprotocol from subprotocols, format and send it - (otherwise) must not send subprotocol ==== --0015175114de7cba0604a41529dd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 14, 2011 at 16:19, Andy Green <andy@warmcat.com>= ; wrote:
On 04/14/2011 07:57 AM, Somebody in the thread at some point said:
f) su= pports multiple subprotocols but Sec-WebSocket-Protocol in request
didn't contain any of them

It sounds clear to me that we should drop the request in case f).

Right... whatever the plan was for no explicit protocol being negotiated, i= t no longer makes any sense.

The protocol should always have to be explicitly requested by the client ev= en if the server only supports that one, you don't know if a different = client who assumes it is a different protocol is connecting to you otherwis= e. =A0There'd be no error and if the protocols were similar the failure= mode might take a long time to show or be subtle.

Thanks, Andy.

<= /div>
As no one seems to be interested in usefulness of these strange c= ases, I'd suggest explicitly drop these cases a) - d) in the client req= uirements normative section. So the resulting spec texts for Sec-WebSocket-= Protocol handling is like this.

=3D=3D=3D=3D
Sec-WebSocket-Protocol in reques= t
- 1#(token | quoted-string)
- characters in each of e= lement after unquoting must be in the range U+0021 to U+007E

=
Sec-WebSocket-Protocol in response
- (token | quoted-string)=
-- This forbids case b)
- characters in string after u= nquoting must be in the range U+0021 to U+007E

User agent must
- (if subprotocols is given) format and send subp= rotocols
- (otherwise) send nothing

User= agent fail when
- sent subprotocols but didn't receive subpr= otocol=A0=A0# This forbids case c)
- sent subprotocols and received subprotocol but it's not in = sent subprotocols =A0# This forbids case a)
- didn't se= nd subprotocols but received subprotocol=A0=A0# This forbids case d)
<= div> - received bad formatted subprotocol
Otherwise, pass received sub= protocol to upper layer

Server side fail when
- received bad formatted subprotocols
- whenever the server= is not satisfied with subprotocols
-- This relegates decision for e) and f) to server implementation

Server
- (if received subprotocols) must cho= ose one subprotocol from subprotocols, format and send it
- (othe= rwise) must not send subprotocol
=3D=3D=3D=3D

--0015175114de7cba0604a41529dd-- From pmcmanus@mozilla.com Wed May 25 04:10:19 2011 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 59BC5E0681 for ; Wed, 25 May 2011 04:10:19 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IhYLfOWr1OXY for ; Wed, 25 May 2011 04:10:18 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5F968E0680 for ; Wed, 25 May 2011 04:10:18 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 5937710305; Wed, 25 May 2011 07:10:17 -0400 (EDT) Received: from [192.168.16.226] (cpe-67-253-92-25.maine.res.rr.com [67.253.92.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id A1705101F5; Wed, 25 May 2011 07:10:13 -0400 (EDT) From: Patrick McManus To: Takeshi Yoshino In-Reply-To: References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> <1306294656.1782.50.camel@ds9> Content-Type: text/plain; charset="UTF-8" Date: Wed, 25 May 2011 07:10:12 -0400 Message-ID: <1306321812.1782.60.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 11:10:19 -0000 On Wed, 2011-05-25 at 15:31 +0900, Takeshi Yoshino wrote: > > Sorry, I couldn't get you. A and B don't have to use the same > algorithm, but in fact those algorithms need coordination. A's > algorithm must choose X for its Ping where X != Y which B's algorithm > chooses for its unsolicited Pong. Well, I agree that I'm saying > something paranoid, but it's true. But if A's algorithm is "unpredictable random sequence" then B cannot realistically match A's value even if they are uncoordinated. Just make the random space sufficiently large - these are infrequent events after all. > How about this? Semantically a bit smaller change. > "Body of Ping and unsolicited body can be empty. IF Ping or > unsolicited Pong have non-empty body, they must start with 0x00 and > 0x01" > This doesn't break interoperability with -07 or add new constraint to that does break interoperability, though. a Ping of "0x23 0x24 0x25 0x26" is legal under -07 and invalid under that text. s/must/SHOULD would repair that, I suppose. If we need to change the text then let's do it. But really, is any serious problem being solved that an implementation cannot solve for its self with the selection of an unpredictable body in the ping using the -07 rules? It's time to ship the protocol already. From theturtle32@gmail.com Wed May 25 09:54:13 2011 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 A2C25E06B5 for ; Wed, 25 May 2011 09:54:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[AWL=0.698, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iUB+FCtn2RG5 for ; Wed, 25 May 2011 09:54:13 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3844BE066C for ; Wed, 25 May 2011 09:54:13 -0700 (PDT) Received: by pzk5 with SMTP id 5so4606890pzk.31 for ; Wed, 25 May 2011 09:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=sonucXeozuJ7WCMD6TbAt27vpluY9Wo1K4dAUW9BhoU=; b=Ay29J74vKvAvmJWNZkckVUcpDdfZScNIV+4gDDQNFpwYdyWgU4DM0/Eqkv8ohD30Yz qu0p78trBQrtD9WTmH129OY1mnjXi6jQqpe83XHHLUvPhVtI5kAVcvylKSkM+RvghzUG /5hk900nR7NTpu/ITa4Vu9yrh4zsysMn4NCM4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=VOIikJprU6mKuFJtwDwDliwHTuOOi0V7+MshHFdrcFscLOH3hpVShzqCDjbo6Fx6Id 0OUp3vfXdYrGFogI4BWMlitLpbXFarjJ0ztxlYq4/81nF0+dC7Ym6u7M8umjqs79DEdP 3gGplYLlWP5pglfP4TtW1887o6M3+fdYdQg5c= Received: by 10.142.2.33 with SMTP id 33mr1270892wfb.232.1306342452779; Wed, 25 May 2011 09:54:12 -0700 (PDT) Received: from [10.8.112.161] (mobile-198-228-210-244.mycingular.net [198.228.210.244]) by mx.google.com with ESMTPS id n4sm5779815pbj.97.2011.05.25.09.54.09 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 25 May 2011 09:54:10 -0700 (PDT) References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> <1306294656.1782.50.camel@ds9> <1306321812.1782.60.camel@ds9> In-Reply-To: <1306321812.1782.60.camel@ds9> Mime-Version: 1.0 (iPhone Mail 8F190) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPhone Mail (8F190) From: Brian McKelvey Date: Wed, 25 May 2011 09:54:03 -0700 To: Patrick McManus Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 16:54:13 -0000 Sent from my iPhone On May 25, 2011, at 4:10 AM, Patrick McManus wrote: > If we need to change the text then let's do it. But really, is any > serious problem being solved that an implementation cannot solve for its > self with the selection of an unpredictable body in the ping using the > -07 rules? No. This is, IMO, totally unimportant. It's fine exactly the way it is. > It's time to ship the protocol already. :-) From gregw@intalio.com Wed May 25 15:48:44 2011 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 9C6A7E07FB for ; Wed, 25 May 2011 15:48:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.944 X-Spam-Level: X-Spam-Status: No, score=-2.944 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqqhUv5u6QKL for ; Wed, 25 May 2011 15:48:44 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1EBFE06E5 for ; Wed, 25 May 2011 15:48:43 -0700 (PDT) Received: by vxg33 with SMTP id 33so134805vxg.31 for ; Wed, 25 May 2011 15:48:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.133 with SMTP id fk5mr189273vdc.184.1306363723248; Wed, 25 May 2011 15:48:43 -0700 (PDT) Received: by 10.52.187.71 with HTTP; Wed, 25 May 2011 15:48:43 -0700 (PDT) In-Reply-To: <4DD9686C.7020509@callenish.com> References: <4DD9686C.7020509@callenish.com> Date: Thu, 26 May 2011 08:48:43 +1000 Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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: Wed, 25 May 2011 22:48:44 -0000 +1 to all this. On 23 May 2011 05:47, Bruce Atherton wrote: > It seems there are still a number of issues around Ping/Pong. Here are my > thoughts on them: > > 1) Should multiple Pings be allowed before a response Pong is received? > > Surely this is the business of the implementation/application and not the > specification. If someone has a use for such a thing, why not allow it? > > 2) Should Ping and Pong be allowed to have a body? > > I think it is a useful and desirable feature. It allows matching Pongs to > Pings, as well as being an area for experimenting with new ideas in how the > Ping and Pong are used. > > The argument has been brought up that the bodies are useless without a > standard way of interpreting them. This is absolutely true. Why not allow > experimentation so that people can come up with standards for them? > > What is the downside to allowing it? > > 3) Should there be an indicator for unsolicited Pongs and/or Pings that need > no response. > > I don't see why this is necessary or desirable so long as the body of the > Pong in some way indicates the Ping it is responding to. Allowing > unsolicited Pongs removes any usecase for Pings without responses as far as > I can see. As far as unsolicited Pongs go, if the Pong body does not match a > Ping that was sent out, then surely it can be assumed to be an unsolicited > Pong. > > What is the marker trying to indicate? That if we have a Pong that claims to > be solicited and does not match the Ping body that there is a bug in the > server implementation, or perhaps that the server is mistaken in the client > it thinks it is communicating with? Is this really necessary? > > 4) Should we allow the Pong body to contain extra data beyond just echoing > the Ping body? > > Again, I think this is a harmless way to allow experimentation on uses for > Ping and Pong. I don't see any reason for disallowing it. > > It has been claimed that there could not be any value in allowing additional > information because Ping/Pong frames run at a higher priority than other > Websocket traffic, and so any data they carry on network characteristics > would not reflect the behaviour of other data in the channel. This makes a > couple of assumptions that I think are questionable. First, are all possible > uses of Ping and Pong concerned with network characteristics? Even if so, > are all possible network characteristics rendered moot by higher priority > traffic? I don't see it necessarily follows that these two assumptions are > valid. > > So if it were up to me, I would just change the spec to indicate that the > Pong must respond with the Ping body, but is allowed to add any data it > wishes to afterward. In fact, you could even change it to respond with just > a hash of the Ping body followed by any other data it wanted to (SHA1 + > Base64 for consistency). > > I wouldn't add in a flag for unsolicited vs. solicited Pongs since the Pong > response does that for us by indicating the Ping it is responding to, but if > others wanted it then I wouldn't stand in their way. Although, if you are > going to specify a byte for a single flag then you may want to indicate the > other 7 bits are reserved for future use. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From tyoshino@google.com Wed May 25 21:35:21 2011 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 32FB9E069C for ; Wed, 25 May 2011 21:35:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a9LyIgeLig1u for ; Wed, 25 May 2011 21:35:20 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1F83AE0686 for ; Wed, 25 May 2011 21:35:19 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p4Q4ZIic009943 for ; Wed, 25 May 2011 21:35:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306384518; bh=TjHV8RvG17VOAHINdw9jAzP/OKk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=XZN8ZwqfMRkEHERjn05O+xpkHNFIjUBXCuHYPdQ6oXXhuPwUu/7zpladh88cD7CIO eOGZWxPLBQl83QjbjSVhA== Received: from gxk21 (gxk21.prod.google.com [10.202.11.21]) by hpaq6.eem.corp.google.com with ESMTP id p4Q4ZGgr026409 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 25 May 2011 21:35:17 -0700 Received: by gxk21 with SMTP id 21so171476gxk.5 for ; Wed, 25 May 2011 21:35:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=hlezY6mW+vVZ4z0c5Kts4pDRj9Ba9GGB4SCxeYnHwg8=; b=RM9RRUIlXA1OcSpnrfmUPouLkyxuK4KWIwDtaBckra/VgcCBZTU2Dzpk1Ys+LwCjMi MI/SUWzEg9Vc3jNgZknA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=PsXP+YuHZ8guhukHios3oI24LcqsKvBLpFk85HQfOg0X/FoPsEQxqtUGMuQ45PwNOs ZBkgYaJrvi1a8ntTVuCQ== Received: by 10.90.151.15 with SMTP id y15mr464853agd.55.1306384516143; Wed, 25 May 2011 21:35:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.53.15 with HTTP; Wed, 25 May 2011 21:34:56 -0700 (PDT) In-Reply-To: <1306321812.1782.60.camel@ds9> References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> <1306294656.1782.50.camel@ds9> <1306321812.1782.60.camel@ds9> From: Takeshi Yoshino Date: Thu, 26 May 2011 13:34:56 +0900 Message-ID: To: Patrick McManus Content-Type: multipart/alternative; boundary=00163630efe7065a0c04a426595b X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 26 May 2011 04:35:21 -0000 --00163630efe7065a0c04a426595b Content-Type: text/plain; charset=ISO-8859-1 On Wed, May 25, 2011 at 20:10, Patrick McManus wrote: > > But if A's algorithm is "unpredictable random sequence" then B cannot > realistically match A's value even if they are uncoordinated. Just make > the random space sufficiently large - these are infrequent events after > all. > Yes. I know. My point is the trade off between "please choose and implement some algorithm (e.g. random 3, 4 or more octet) that very possibly never generates body which collide with others' by yourself when necessary" and "the spec clearly disambiguates them by 1 octet indicator". I think the former works practically. But that's not what something called "specification" should do I think in principle. Things people may leave under-specified are things that defined in lower or under layer which have their own agreement/spec, or extensions that has negotiation mechanism by which entities can coordinate their behavior. This is not the case. > that does break interoperability, though. a Ping of "0x23 0x24 0x25 > 0x26" is legal under -07 and invalid under that text. s/must/SHOULD > would repair that, I suppose. > Yes. For non-empty cases, it does break. > -07 rules? It's time to ship the protocol already. > I'm ok with this shipped without adding indicator if no one else thinks it's necessary. It's time to ship, yes. Personally I have no plan to use non-empty ping/pong body. As Bruce listed, there're some other issues raised recently. Here are my thoughts on them. a) Allow multiple in-flight Pings? Yes. Harmless. Jamie's opinion makes sense. Keep the current text. b) Allow Ping and Pong to have a body? Yes. Harmless. Keep the current text. b-yes-1) Disambiguate solicited and unsolicited Pong by the spec? I can live without this, but I think we should. b-yes-2) Allow the Pong body to contain extra data beyond just echoing the Ping body? OK. Harmless. I don't have any preference on this. This needs text change. c) Have solicited Pong respond to only the most recent Ping? I don't understand why we allow this kind of unsynchronized behavior purposely. It's not a good way to discourage multiple in-flight Pings. If it's good to disallow multiple in-flight Pings, the spec should say "multiple in-flight Pings MUST not be sent" directly. I think most of implementation would handle received data frame-by-frame. Once it sees a Ping frame, it will enqueue a Pong to its sending queue, forget it and move on the next frame. This text looks just confusing. Again, I can live with this. Thanks, Takeshi --00163630efe7065a0c04a426595b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, May 25, 2011 at 20:10, Patrick McManus <= span dir=3D"ltr"><pmcmanus@mozilla.com> wrote:
that does break interoperability, though. a Ping of "0x23 0x24 0x= 25
0x26" is legal under -07 and invalid under that text. s/must/SHOULD would repair that, I suppose.

Yes. For = non-empty cases, it does break.
=A0
-07 rules? It's time to ship the protocol already.

I'm ok with this shipped without= adding indicator if no one else thinks it's necessary. It's time t= o ship, yes. Personally I have no plan to use non-empty ping/pong body.

As Bruce listed, there're some other issues raised = recently. Here are my thoughts on them.

a) Allow multiple in-= flight Pings?
Yes. Harmless. Jamie's opinion makes sense. Kee= p the current text.

b) Allow Ping and Pong to have a body?
Y= es. Harmless. Keep the current text.

b-yes-1) Disa= mbiguate solicited and unsolicited Pong by the spec?
I can live w= ithout this, but=A0I think we should.

b-yes-2)=A0Allow the Pong body to contain extra data be= yond just echoing the Ping body?
OK. Harmless. I don't = have any preference on this. This needs text change.

c) Have solicited Pong respond to=A0only the most recent Ping?
I don't understand why we allow this kind of unsynchronized behavior= purposely.=A0It's not a good way to discourage multiple in-flight Ping= s. If it's good to disallow multiple in-flight Pings, the spec should s= ay "multiple in-flight Pings MUST not be sent" directly. I think = most of implementation would handle received data frame-by-frame. Once it s= ees a Ping frame, it will enqueue a Pong to its sending queue, forget it an= d move on the next frame. This text looks just confusing.
Again, I can live with this.

Thanks,
Takeshi
--00163630efe7065a0c04a426595b-- From gettysjim@gmail.com Thu May 26 05:47:51 2011 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 29FA6130044 for ; Thu, 26 May 2011 05:47:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AApnEIS2gBYl for ; Thu, 26 May 2011 05:47:50 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4093B130018 for ; Thu, 26 May 2011 05:47:50 -0700 (PDT) Received: by vxg33 with SMTP id 33so610292vxg.31 for ; Thu, 26 May 2011 05:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:organization :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=p20XGITUBJT7/zWJsfxnn9KIliVFDDUcYaBK8q6rUcM=; b=BSZ/kG0LoEMyB0+vIxNLJ95NT5avPtwq28PCLM9M6exyaTNKskPpXsP8KXdEQiP1Sz eC6goLoSTadr7Wg4gdXyEYzsaTItNFcyTapoHUQD9wuMN3LcNIjwsJl3tQllELapqQ2R dJWRSbcIhW5V9di9BaQZYp1bLW2gdhi+tBY5c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; b=jZyGPhBHjFjyiWq/bHPPRgeoXoJcCAZ01/hV2sso7XVbyUSNVog2S/xl4XSoQwVzY6 49yOaVkZr6YMBrfxikpIQrve73NU5AM1Ll4PBnK5zRo+Y8yOY/NPGLF9zDpMWNsFrYx/ uL/+gJXdnqVG3RwyM2wMwBQ6ebB7ao5ruZsI8= Received: by 10.52.114.196 with SMTP id ji4mr978864vdb.29.1306413529683; Thu, 26 May 2011 05:38:49 -0700 (PDT) Received: from [192.168.1.119] (c-98-229-99-32.hsd1.ma.comcast.net [98.229.99.32]) by mx.google.com with ESMTPS id cx6sm300306vbb.6.2011.05.26.05.38.47 (version=SSLv3 cipher=OTHER); Thu, 26 May 2011 05:38:48 -0700 (PDT) Sender: Jim Gettys Message-ID: <4DDE49D6.3010708@freedesktop.org> Date: Thu, 26 May 2011 08:38:46 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: Greg Wilkins References: <4DBA3809.4010004@oracle.com> <4DD61D35.10404@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Thu, 26 May 2011 08:37:14 -0700 Cc: Hybi , Alan Coopersmith , Gabriel Montenegro , Brodie Thiesfield Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 26 May 2011 13:19:59 -0000 On 05/25/2011 01:08 AM, Greg Wilkins wrote: > > I don't want them available for extensions if it is just a > free-for-all, because then non-technical market forces will come into > play for their allocation and interoperability will be poor unless you > only use defacto standard extensions. > > IANA registry is also a way to avoid the free for all, but it feels a > bit heavy bureaucracy for just 3 bits, which will soon be consumed and > then we are back to having no available bits and extensions have to > use the payload anyway. > > But IANA is better than the status quo of no allocation. > > >>>> It sounds to me like you are saying "if I can't have it my way, nobody >>>> can >>>> have them". If they can't ever be used for extensions, it isn't >>>> entirely >>>> clear what they could be used for, so we would be better off just >>>> allocating >>>> them to the opcode than leaving them unused. >>> If they are registered it doesn't mean they can't be used. Just that >>> the extension that uses them must be blessed with the registration. >>> All other extensions just add a byte to their payload and use it for >>> their flags. >> Again, that isn't what Greg was suggesting. >> Also, if reserved opcodes can't be used (which Greg was also suggesting), >> then there is no room for any experimentation, which seems a recipe for poor >> progress getting useful extensions. > Extensions can always have their own opcodes by putting them as a byte > in the payload (which is what you have previously advocated for > extension opcodes anyway). Sure we can go to IANA and create a > registry for the 8 or so available opcodes, but I'm sure they will > soon be allocated to some worthy extensions and then future > experimentation will have to use payload opcodes anyway. > > I just think that we have too few bits and opcodes available to make a > fixed allocation work (either by defacto standards or by IANA > registry), as all will soon be consumed and we then have to think of > other solutions anyway. I think a simple dynamic allocation > mechanism would work for a large pool of possible extensions, but we > would be limited by how many active extensions could be applied on the > same connection. > > So eitherway, I see that eventually we will have to handle extensions > with flags and codes in the payload, so why not just go there directly > and not have to deal with either designing a system now or working > with IANA to allocated very limited resources. > There is a technique we used in X11 design we should have pushed on much more broadly: enabling the client to do assignment/allocation of protocol elements as much as possible: we did this with resource ID's, and should have done this elsewhere in the protocol. Our really big mistake was the Atom system, but I'll leave that for a different discussion if appropriate. But the extension system has a similar mistake we made. In the X protocol, extensions are a two phase process. You perform a "QueryExtension", in which you provide the name of the extension (which is a string). If it exists, the server tells you what opcode it will be available at (and a base number in the error numbering field for reporting errors, and a base number in the event fields that events may return from the extension). In the X protocol, opcodes are two fields, a major opcode (1 byte) and a minor opcode (1 byte). So long as there is no collision in the names of extensions, there is no reason for a registry. There is also a protocol request to list the extensions available at the server. By convention extensions have version numbering in them. The downside of what we did (in the X protocol in general), is that while maximally extensible, it's more "chatty" than it might be requiring round trips to synchronise client and server state, which we've had to kludge around by pipelining requests. We hadn't yet internalised that going over the net was so expensive to always optimise for that case. It would have been better to just list the extension names available up front at connection open, and (when an extension is first used), have the client have to send a request to assign it a free opcode, avoiding the RTT delays. You could also imagine (given your limited opcode space) you might be able to support more extensions simultaneously, switching assignments dynamically. You could even have your servers list the most frequently used extensions first, and pre-assign them, so that the client doesn't have to send this message in many cases. We haven't needed to in X, because we have 256 available opcodes, and haven't exhausted the op-code space. Dunno if you can go this route: but it's what I'd do if I could and it were my headache. - Jim From Gabriel.Montenegro@microsoft.com Thu May 26 09:45:03 2011 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 E498FE070A for ; Thu, 26 May 2011 09:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uODrbEkHSeG for ; Thu, 26 May 2011 09:45:01 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 5D31AE06E1 for ; Thu, 26 May 2011 09:45:01 -0700 (PDT) Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 09:45:01 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 26 May 2011 09:45:00 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 26 May 2011 09:44:54 -0700 From: Gabriel Montenegro To: Takeshi Yoshino , Patrick McManus Thread-Topic: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-07) Thread-Index: AQHMG15XBeWRPtk6eUCpfPMRIN9xX5SfUTVA Date: Thu, 26 May 2011 16:44:53 +0000 Message-ID: References: <4DD9686C.7020509@callenish.com> <1306285493.1782.33.camel@ds9> <1306294656.1782.50.camel@ds9> <1306321812.1782.60.camel@ds9> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402F245ETK5EX14MBXW603w_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft-ietf-hybi-thewebsocketprotocol-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, 26 May 2011 16:45:04 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402F245ETK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable After discussion with Salvatore, this is our take on this: The only thing that absolutely needs to change, then is this: b-yes-2) Allow the Pong body to contain extra data beyond just echoing the = Ping body? OK. Harmless. I don't have any preference on this. This needs text change. And the corresponding change is in section 4.5.3 on Pong: OLD: The message bodies (i.e. both the Extension data (if any) and the Application data) of the Ping and Pong MUST be the same. NEW: The message body's Application data of the Ping and Pong MUST be the same. Thanks, Gabriel From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Tak= eshi Yoshino Sent: Wednesday, May 25, 2011 21:35 To: Patrick McManus Cc: hybi@ietf.org Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review of draft= -ietf-hybi-thewebsocketprotocol-07) On Wed, May 25, 2011 at 20:10, Patrick McManus > wrote: But if A's algorithm is "unpredictable random sequence" then B cannot realistically match A's value even if they are uncoordinated. Just make the random space sufficiently large - these are infrequent events after all. Yes. I know. My point is the trade off between "please choose and implement some algorit= hm (e.g. random 3, 4 or more octet) that very possibly never generates body= which collide with others' by yourself when necessary" and "the spec clear= ly disambiguates them by 1 octet indicator". I think the former works practically. But that's not what something called = "specification" should do I think in principle. Things people may leave und= er-specified are things that defined in lower or under layer which have the= ir own agreement/spec, or extensions that has negotiation mechanism by whic= h entities can coordinate their behavior. This is not the case. that does break interoperability, though. a Ping of "0x23 0x24 0x25 0x26" is legal under -07 and invalid under that text. s/must/SHOULD would repair that, I suppose. Yes. For non-empty cases, it does break. -07 rules? It's time to ship the protocol already. I'm ok with this shipped without adding indicator if no one else thinks it'= s necessary. It's time to ship, yes. Personally I have no plan to use non-e= mpty ping/pong body. As Bruce listed, there're some other issues raised recently. Here are my th= oughts on them. a) Allow multiple in-flight Pings? Yes. Harmless. Jamie's opinion makes sense. Keep the current text. b) Allow Ping and Pong to have a body? Yes. Harmless. Keep the current text. b-yes-1) Disambiguate solicited and unsolicited Pong by the spec? I can live without this, but I think we should. b-yes-2) Allow the Pong body to contain extra data beyond just echoing the = Ping body? OK. Harmless. I don't have any preference on this. This needs text change. c) Have solicited Pong respond to only the most recent Ping? I don't understand why we allow this kind of unsynchronized behavior purpos= ely. It's not a good way to discourage multiple in-flight Pings. If it's go= od to disallow multiple in-flight Pings, the spec should say "multiple in-f= light Pings MUST not be sent" directly. I think most of implementation woul= d handle received data frame-by-frame. Once it sees a Ping frame, it will e= nqueue a Pong to its sending queue, forget it and move on the next frame. T= his text looks just confusing. Again, I can live with this. Thanks, Takeshi --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402F245ETK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

After discussion with Sal= vatore, this is our take on this:

 <= /p>

The only thing that absol= utely needs to change, then is this:

 <= /p>

b-yes-2) Allow the Pong body to contain extra d= ata beyond just echoing the Ping body?

OK. Harmless. I don't have any preference on this. T= his needs text change.

 <= /p>

And the corresponding cha= nge is in section 4.5.3 on Pong:

 <= /p>

OLD:

The message

   bodies (i.e.= both the Extension data (if any) and the Application

   data) of the= Ping and Pong MUST be the same.

NEW:

 The message body= 217;s Application data of the Ping and Pong MUST be the same.

 <= /p>

Thanks,=

 <= /p>

Gabriel=

 <= /p>

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Takeshi Yoshino
Sent: Wednesday, May 25, 2011 21:35
To: Patrick McManus
Cc: hybi@ietf.org
Subject: Re: [hybi] Ping/Pong body (was Re: TSV-Directorate review o= f draft-ietf-hybi-thewebsocketprotocol-07)

 

On Wed, May 25, 2011 at 20:10, Patrick McManus <<= a href=3D"mailto:pmcmanus@mozilla.com" target=3D"_blank">pmcmanus@mozilla.c= om> wrote:

But if A's algorithm is "unpredictable random s= equence" then B cannot

realistically match A's value even if they are uncoo= rdinated. Just make
the random space sufficiently large - these are infrequent events after
all.

 

Yes. I know.

 

My point is the trade off between "please choos= e and implement some algorithm (e.g. random 3, 4 or more octet) that very p= ossibly never generates body which collide with others' by yourself when ne= cessary" and "the spec clearly disambiguates them by 1 octet indicator".

 

I think the former works practically. But that's not= what something called "specification" should do I think in princ= iple. Things people may leave under-specified are things that defined in lo= wer or under layer which have their own agreement/spec, or extensions that has negotiation mechanism by which entities can coordin= ate their behavior. This is not the case.

 

that does break interoperability, though. a Ping of = "0x23 0x24 0x25

0x26" is legal under -07 and invalid under that= text. s/must/SHOULD
would repair that, I suppose.

 

Yes. For non-empty cases, it does break.<= /p>

 

-07 rules? It's time to ship the protocol already.

 

I'm ok with this shipped without adding indicator if= no one else thinks it's necessary. It's time to ship, yes. Personally I ha= ve no plan to use non-empty ping/pong body.

 

As Bruce listed, there're some other issues raised r= ecently. Here are my thoughts on them.

 

a) Allow multiple in-flight Pings?

Yes. Harmless. Jamie's opinion makes sense. Keep the= current text.

 

b) Allow Ping and Pong to have a body?

Yes. Harmless. Keep the current text.

 

b-yes-1) Disambiguate solicited and unsolicited Pong= by the spec?

I can live without this, but I think we should.=

 

b-yes-2) Allow the Pong body to contain extra d= ata beyond just echoing the Ping body?

OK. Harmless. I don't have any preference on this. T= his needs text change.

 

c) Have solicited Pong respond to only the most= recent Ping?

I don't understand why we allow this kind of unsynch= ronized behavior purposely. It's not a good way to discourage multiple= in-flight Pings. If it's good to disallow multiple in-flight Pings, the sp= ec should say "multiple in-flight Pings MUST not be sent" directly. I think most of implementation would hand= le received data frame-by-frame. Once it sees a Ping frame, it will enqueue= a Pong to its sending queue, forget it and move on the next frame. This te= xt looks just confusing.

Again, I can live with this.

 

Thanks,

Takeshi

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11402F245ETK5EX14MBXW603w_-- From salvatore.loreto@ericsson.com Thu May 26 09:55:13 2011 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 366A6130019 for ; Thu, 26 May 2011 09:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.598 X-Spam-Level: X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsCYt5Szkf5Y for ; Thu, 26 May 2011 09:55:12 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id BC363130028 for ; Thu, 26 May 2011 09:55:11 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-f3-4dde85ee37aa Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B5.20.20773.EE58EDD4; Thu, 26 May 2011 18:55:10 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.137.0; Thu, 26 May 2011 18:55:09 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id ADFF92441 for ; Thu, 26 May 2011 19:55:09 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7275C50FF1 for ; Thu, 26 May 2011 19:55:09 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1CBD050FE9 for ; Thu, 26 May 2011 19:55:09 +0300 (EEST) Message-ID: <4DDE85EC.2010001@ericsson.com> Date: Thu, 26 May 2011 19:55:08 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: hybi@ietf.org References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> In-Reply-To: <6.2.5.6.2.20110524234152.03017c30@resistor.net> Content-Type: multipart/alternative; boundary="------------000500050906040804060704" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 26 May 2011 16:55:13 -0000 --------------000500050906040804060704 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit After discussion with Gabriel, taking in consideration the long mail discussion and different positions on this topic, we have decided thata IANA strict assignment policy is the right way to handle the allocation of reserved bits /Sal -- Salvatore Loreto www.sloreto.com On 5/25/11 9:52 AM, SM wrote: > At 18:03 19-05-2011, Gabriel Montenegro wrote: >> Reserved bits should only be allocated for very compelling reasons, >> either because there is an extension that has full backing of the WG >> or because there is a new version of the protocol that needs it. I >> think we should word our IANA considerations on bit assignment with >> a very strict assignment policy of "Standards Action": >> http://tools.ietf.org/html/rfc5226#section-4.1 > Reserved bits can be allocated in future. When a bit is marked as > "reserved" it does not mean that it will never be used. > > Having a strict assignment requirement has advantages and > disadvantages. If people find it difficult to get an assignment, > they will squat on the bits. It would be good if the working group > give some thought to this question. > > Regards, > -sm > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --------------000500050906040804060704 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit After discussion with Gabriel,
taking in consideration the long mail discussion and different positions on this topic,
we have decided that a IANA strict assignment policy is the right way to handle the allocation of reserved bits


/Sal



-- 
Salvatore Loreto
www.sloreto.com




On 5/25/11 9:52 AM, SM wrote: 
At 18:03 19-05-2011, Gabriel Montenegro wrote:

Reserved bits should only be allocated for very compelling reasons, 
either because there is an extension that has full backing of the WG 
or because there is a new version of the protocol that needs it. I 
think we should word our IANA considerations on bit assignment with 
a very strict assignment policy of "Standards Action":
http://tools.ietf.org/html/rfc5226#section-4.1

Reserved bits can be allocated in future.  When a bit is marked as 
"reserved" it does not mean that it will never be used.

Having a strict assignment requirement has advantages and 
disadvantages.  If people find it difficult to get an assignment, 
they will squat on the bits.  It would be good if the working group 
give some thought to this question.

Regards,
-sm 

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

--------------000500050906040804060704-- From andy.warmcat.com@googlemail.com Thu May 26 10:40:25 2011 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 0C2E9E0721 for ; Thu, 26 May 2011 10:40:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikmgY7I+Pcyl for ; Thu, 26 May 2011 10:40:24 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 086F3E06E9 for ; Thu, 26 May 2011 10:40:23 -0700 (PDT) Received: by wwa36 with SMTP id 36so715586wwa.13 for ; Thu, 26 May 2011 10:40:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:sender:message-id:date:from:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=VsSkG72Rp0ifSduy189alcyJWQ6yaBOUlSJW3fiXclc=; b=ZKpdl+DSTGKDIe2BK0EBJ1pAcWOiDUUhDS/64ZE4jS4SxgBSFBIxBl7hDVs0Wj5Dpm PHY+Wnt7LuchUUHxBkuTIscXGlv2Ap8F3o9p992esNbi9NMIE9Jz7vIM2lnbUh6g362+ mIJSxuTsON+VnzlWhVhxLQmXzRNBzeF1uZ/64= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=tD/eln73nZQcgc1b0NpZ8r2gqLtLir8+K6jy5Zz0Qz4QUbFQYd+I+8dPjr+m+tOmUo qp127Ny9Kvpb+dix+1mqb0SYkgw9NqDEQnT5/aNcIi7oD7iFAPSpsypyMmXpmGS/AFOF M7RVqmFvFvVFZDgnX0o7oyuWTukGP1xWVmUvs= Received: by 10.227.178.135 with SMTP id bm7mr1116927wbb.52.1306431622788; Thu, 26 May 2011 10:40:22 -0700 (PDT) Received: from otae.warmcat.com (s15404224.onlinehome-server.info [87.106.134.80]) by mx.google.com with ESMTPS id ge4sm624131wbb.13.2011.05.26.10.40.20 (version=SSLv3 cipher=OTHER); Thu, 26 May 2011 10:40:21 -0700 (PDT) Sender: Andy Green Message-ID: <4DDE9083.1010108@warmcat.com> Date: Thu, 26 May 2011 18:40:19 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc16 Thunderbird/3.1.10 MIME-Version: 1.0 To: Salvatore Loreto References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> <4DDE85EC.2010001@ericsson.com> In-Reply-To: <4DDE85EC.2010001@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 26 May 2011 17:40:25 -0000 On 05/26/2011 05:55 PM, Somebody in the thread at some point said: > After discussion with Gabriel, > taking in consideration the long mail discussion and different positions > on this topic, > we have decided thata IANA strict assignment policy is the right way to > handle the allocation of reserved bits ... and reserved opcodes? -Andy From Gabriel.Montenegro@microsoft.com Thu May 26 14:09:37 2011 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 6DCCAE07A9 for ; Thu, 26 May 2011 14:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuS1JLcxuTt2 for ; Thu, 26 May 2011 14:09:36 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 83E92E0694 for ; Thu, 26 May 2011 14:09:36 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 14:09:36 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 26 May 2011 14:09:36 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 26 May 2011 14:09:35 -0700 From: Gabriel Montenegro To: =?iso-2022-jp?B?IkFuZHkgR3JlZW4gKBskQk5TMEJXLxsoQiki?= , Salvatore Loreto Thread-Topic: [hybi] method of allocation of reserved bits to extensions Thread-Index: AQHMGqhX1u9834hjukKLiEqBfS9wQZSfy14AgAAMoID//8UJ0A== Date: Thu, 26 May 2011 21:09:35 +0000 Message-ID: References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> <4DDE85EC.2010001@ericsson.com> <4DDE9083.1010108@warmcat.com> In-Reply-To: <4DDE9083.1010108@warmcat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 26 May 2011 21:09:37 -0000 Also reserved opcodes, yes. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > "Andy Green (???)" > Sent: Thursday, May 26, 2011 10:40 > To: Salvatore Loreto > Cc: hybi@ietf.org > Subject: Re: [hybi] method of allocation of reserved bits to extensions >=20 > On 05/26/2011 05:55 PM, Somebody in the thread at some point said: > > After discussion with Gabriel, > > taking in consideration the long mail discussion and different > > positions on this topic, we have decided thata IANA strict assignment > > policy is the right way to handle the allocation of reserved bits >=20 > ... and reserved opcodes? >=20 > -Andy > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From gregw@intalio.com Thu May 26 15:28:41 2011 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 68BC113002A for ; Thu, 26 May 2011 15:28:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.947 X-Spam-Level: X-Spam-Status: No, score=-2.947 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F14O-ESEhffF for ; Thu, 26 May 2011 15:28:39 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id CA3F2130029 for ; Thu, 26 May 2011 15:28:39 -0700 (PDT) Received: by qyk29 with SMTP id 29so3493790qyk.10 for ; Thu, 26 May 2011 15:28:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.79.196 with SMTP id q4mr1097874qck.132.1306448919129; Thu, 26 May 2011 15:28:39 -0700 (PDT) Received: by 10.229.218.5 with HTTP; Thu, 26 May 2011 15:28:38 -0700 (PDT) In-Reply-To: <4DDE85EC.2010001@ericsson.com> References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> <4DDE85EC.2010001@ericsson.com> Date: Fri, 27 May 2011 08:28:38 +1000 Message-ID: From: Greg Wilkins To: Salvatore Loreto Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 26 May 2011 22:28:41 -0000 On 27 May 2011 02:55, Salvatore Loreto wrote: > After discussion with Gabriel, > taking in consideration the long mail discussion and different positions on > this topic, > we have decided that a IANA strict assignment policy is the right way to > handle the allocation of reserved bits OK, but can we add some text to the specification saying that experimental/proprietary extensions must not squat on opcodes/bits pending IANA allocation, but instead put them in the payload until such as they are allocated opcodes/bits. cheers From Gabriel.Montenegro@microsoft.com Thu May 26 18:03:28 2011 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 61528E06A5 for ; Thu, 26 May 2011 18:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SCAhiOSp4U3Z for ; Thu, 26 May 2011 18:03:27 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id CF470E0697 for ; Thu, 26 May 2011 18:03:27 -0700 (PDT) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 26 May 2011 18:03:27 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.1.289.8; Thu, 26 May 2011 18:03:26 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0289.008; Thu, 26 May 2011 18:03:26 -0700 From: Gabriel Montenegro To: Greg Wilkins , Salvatore Loreto Thread-Topic: [hybi] method of allocation of reserved bits to extensions Thread-Index: AQHMGqhX1u9834hjukKLiEqBfS9wQZSfy14AgABdLgD//7WU4A== Date: Fri, 27 May 2011 01:03:26 +0000 Message-ID: References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> <4DDE85EC.2010001@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 27 May 2011 01:03:28 -0000 No need for such language. "Standards action" IANA policy is enough in addi= tion to the wording already in 07. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of G= reg > Wilkins > Sent: Thursday, May 26, 2011 15:29 > To: Salvatore Loreto > Cc: hybi@ietf.org > Subject: Re: [hybi] method of allocation of reserved bits to extensions >=20 > On 27 May 2011 02:55, Salvatore Loreto > wrote: > > After discussion with Gabriel, > > taking in consideration the long mail discussion and different > > positions on this topic, we have decided that a IANA strict assignment > > policy is the right way to handle the allocation of reserved bits >=20 > OK, but can we add some text to the specification saying that > experimental/proprietary extensions must not squat on opcodes/bits pendin= g > IANA allocation, but instead put them in the payload until such as they a= re > allocated opcodes/bits. >=20 > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From derhoermi@gmx.net Thu May 26 18:27:35 2011 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 3B682E0733 for ; Thu, 26 May 2011 18:27:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.832 X-Spam-Level: X-Spam-Status: No, score=-3.832 tagged_above=-999 required=5 tests=[AWL=-1.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZhCK9Sc1xk34 for ; Thu, 26 May 2011 18:27:33 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 412F8E0697 for ; Thu, 26 May 2011 18:27:32 -0700 (PDT) Received: (qmail invoked by alias); 27 May 2011 01:27:31 -0000 Received: from dslb-094-223-152-222.pools.arcor-ip.net (EHLO HIVE) [94.223.152.222] by mail.gmx.net (mp035) with SMTP; 27 May 2011 03:27:31 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+uG5Qq/vOu/5YuZb1mhRQXNImhO9zepnQP6GKbdo zGMWdNgRUdRpQr From: Bjoern Hoehrmann To: Gabriel Montenegro Date: Fri, 27 May 2011 03:27:32 +0200 Message-ID: References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> <4DDE85EC.2010001@ericsson.com> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] method of allocation of reserved bits to extensions 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, 27 May 2011 01:27:35 -0000 * Gabriel Montenegro wrote: >No need for such language. "Standards action" IANA policy is enough in >addition to the wording already in 07. I am not sure what you are saying. If the idea is that people need to go through some standards process in order to make use of shared resources, like reserved bits or opcodes, then it seems the working group needs to condemn not doing so in the strongest possible terms. We have experience with any number of other protocol elements where people just do their thing without bothering to do anything to document or register anything, be they privileged port numbers, internet media types, character set i- dentifiers, properties on the global object in ECMAScript environments, HTML elements and so on and so forth. If the working group does not want this to be the case for Websockets, and considering that the group does not have much influence beyond very clearly stating the ideas in its deliverables, I find the request to be very explicit about this quite reasonable, and do not see what "need" is absent here. At the very least I would expect some argument why whatever language you find sufficient is indeed sufficient, such as a comparison to comparable protocols where this kind of language did indeed prevent bad actors from abusing shared resources, including why all the counter- examples aren't very comparable to Websockets. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From djc.ochtman@gmail.com Mon May 30 05:13:24 2011 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 D479FE0716 for ; Mon, 30 May 2011 05:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDdi0Atj7Asu for ; Mon, 30 May 2011 05:13:23 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id BD223E0651 for ; Mon, 30 May 2011 05:13:23 -0700 (PDT) Received: by qwc23 with SMTP id 23so2322917qwc.31 for ; Mon, 30 May 2011 05:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:from:date :x-google-sender-auth:message-id:subject:to:content-type; bh=5Xl7rWNA1hjkZ5VNi5Nr6qVHW9UtbeWv06Y8IfJTboQ=; b=AFgx4bJC8suvxQAwscF+GZAhgwU+e0GeriM5ca4KnJS87xaQ5PXvSBe5t8V6tDrqjj 4QAihCloiLeTPFB8fz+P/zyoldESL10/m13PmCqCIBZM4gCySpQtuF35VfXMWz3ImRy9 eNLxBRyCqzhmVwKb443z5odsJsFwtjg01eCos= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:from:date:x-google-sender-auth:message-id :subject:to:content-type; b=otqlA+QSgY9x3cKlTiKYIMH5CUL80ia92q7FTne5NnlrZTZQcMrwjoqDO8Z/waoyX4 jXjULLUjRcsIhPclQkA/8PUHe2UST0EOV72+E71w81Mrc1nTIz2Xq29z+VeSoZSC20KX hJnMmKNAKnRtEQq37imUf7pnqwGPCK2palXGY= Received: by 10.229.20.83 with SMTP id e19mr3466985qcb.288.1306757603085; Mon, 30 May 2011 05:13:23 -0700 (PDT) MIME-Version: 1.0 Sender: djc.ochtman@gmail.com Received: by 10.229.32.143 with HTTP; Mon, 30 May 2011 05:13:03 -0700 (PDT) From: Dirkjan Ochtman Date: Mon, 30 May 2011 14:13:03 +0200 X-Google-Sender-Auth: p9zX9FZxbRMRwiBgpH_1NBmz_CM Message-ID: To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Subject: [hybi] Section 5.2.2 clarifications 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, 30 May 2011 12:27:29 -0000 Hi all, (I'm new here; I hope this is the correct venue for remarks like this.) I just upgraded from Firefox 5 to Firefox 6 [1], which includes upgrading from the -76 to the -07 version of the protocol. I found a small Python server for -76 on the internet, which I've since adapted for the environment at work, and tried to upgrade the script to -07 from the spec (since there doesn't seem to be much code out there yet). Most of the spec seems quite clear, which is great, but I had some trouble with the server handshake (section 5.2.2). In particular, it seems like the Upgrade and Connection headers (which are shown in the example in non-normative section 1.2) should be mentioned here, as well. Step 3 in this section only mentions the Status line, the Sec-WebSocket-Accept header and the optional -Protocol and -Extensions headers. Step 3 starts out to mention that a "valid HTTP response" is required, and this clearly requires the Upgrade header in this context (per RFC 2616), but from the RFC I don't see why the Connection header would be mandatory here. In any case, it would be nice to expand step 3 a little bit. Including an example here would also be quite useful (similar to what section 1.2 has for the server part of the handshake). Finally, it might be sensible to reference the HTTP Status-Line definition again in part 1 of step 3. And one very minor nit: section 8.2.1 talks about "op codes", whereas the rest of the document uses "opcode" and "opcodes". Hope this is helpful, Dirkjan [1] I've also just filed https://bugzilla.mozilla.org/show_bug.cgi?id=660613 against the Mozilla implementation. From alexey.melnikov@isode.com Tue May 31 04:55:59 2011 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 006B9E083B for ; Tue, 31 May 2011 04:55:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.25 X-Spam-Level: X-Spam-Status: No, score=-102.25 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jt2SjrM8jAkf for ; Tue, 31 May 2011 04:55:58 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id ADA31E082F for ; Tue, 31 May 2011 04:55:50 -0700 (PDT) Received: from [188.29.122.43] (188.29.122.43.threembb.co.uk [188.29.122.43]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 31 May 2011 12:55:48 +0100 Message-ID: <4DE4D722.7010408@isode.com> Date: Tue, 31 May 2011 12:55:14 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 X-Accept-Language: en-us, en To: Greg Wilkins References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2.20110524234152.03017c30@resistor.net> <4DDE85EC.2010001@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 11:55:59 -0000 Greg Wilkins wrote: >On 27 May 2011 02:55, Salvatore Loreto wrote: > > >>After discussion with Gabriel, >>taking in consideration the long mail discussion and different positions on >>this topic, >>we have decided that a IANA strict assignment policy is the right way to >>handle the allocation of reserved bits >> >> >OK, but can we add some text to the specification saying that >experimental/proprietary extensions must not squat on opcodes/bits >pending IANA allocation, but instead put them in the payload until >such as they are allocated opcodes/bits. > > I don't object to such text being added, but I suspect it will be ignored. From Gabriel.Montenegro@microsoft.com Tue May 31 09:27:54 2011 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 5544BE0751 for ; Tue, 31 May 2011 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WcwPlMWfAyAb for ; Tue, 31 May 2011 09:27:49 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 75426E0747 for ; Tue, 31 May 2011 09:27:49 -0700 (PDT) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Tue, 31 May 2011 09:27:48 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.1.289.8; Tue, 31 May 2011 09:27:48 -0700 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.209]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0289.008; Tue, 31 May 2011 09:27:48 -0700 From: Gabriel Montenegro To: Bjoern Hoehrmann Thread-Topic: [hybi] method of allocation of reserved bits to extensions Thread-Index: AQHMGqhX1u9834hjukKLiEqBfS9wQZSfy14AgABdLgD//7WU4IAAfGcAgAbM/oA= Date: Tue, 31 May 2011 16:27:48 +0000 Message-ID: References: <4DBA3809.4010004@oracle.com> <6.2.5.6.2 In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 16:27:54 -0000 We have as many counterexamples of the opposite with the bits in the IP hea= der, TCP headers, IP TOS bits, as well as protocol numbers (e.g., for IP, T= CP, ESP, IPv6, UDP, etc), etc. There is nothing new about IANA sections and= process to control shared resources. Sure, there's no police and people ca= n use bits as they see fit and sometimes they do so, but rules are already = clear, and no extra wording will change that.=20 > -----Original Message----- > From: Bjoern Hoehrmann [mailto:derhoermi@gmx.net] > Sent: Thursday, May 26, 2011 18:28 > To: Gabriel Montenegro > Cc: Greg Wilkins; Salvatore Loreto; hybi@ietf.org > Subject: Re: [hybi] method of allocation of reserved bits to extensions >=20 > * Gabriel Montenegro wrote: > >No need for such language. "Standards action" IANA policy is enough in > >addition to the wording already in 07. >=20 > I am not sure what you are saying. If the idea is that people need to go = through > some standards process in order to make use of shared resources, like res= erved > bits or opcodes, then it seems the working group needs to condemn not doi= ng > so in the strongest possible terms. We have experience with any number of > other protocol elements where people just do their thing without botherin= g to > do anything to document or register anything, be they privileged port num= bers, > internet media types, character set i- dentifiers, properties on the glob= al object > in ECMAScript environments, HTML elements and so on and so forth. >=20 > If the working group does not want this to be the case for Websockets, an= d > considering that the group does not have much influence beyond very clear= ly > stating the ideas in its deliverables, I find the request to be very expl= icit about > this quite reasonable, and do not see what "need" is absent here. At the = very > least I would expect some argument why whatever language you find suffici= ent > is indeed sufficient, such as a comparison to comparable protocols where = this > kind of language did indeed prevent bad actors from abusing shared resour= ces, > including why all the counter- examples aren't very comparable to Websock= ets. > -- > Bj=F6rn H=F6hrmann =B7 mailto:bjoern@hoehrmann.de =B7 http://bjoern.hoehr= mann.de > Am Badedeich 7 =B7 Telefon: +49(0)160/4415681 =B7 http://www.bjoernsworld= .de > 25899 Dageb=FCll =B7 PGP Pub. KeyID: 0xA4357E78 =B7 http://www.websitedev= .de/ From gregw@intalio.com Tue May 31 14:52:29 2011 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 E758FE0919 for ; Tue, 31 May 2011 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kfqJMbywZFro for ; Tue, 31 May 2011 14:52:29 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2F138E06B5 for ; Tue, 31 May 2011 14:52:28 -0700 (PDT) Received: by vws12 with SMTP id 12so5061543vws.31 for ; Tue, 31 May 2011 14:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.231 with SMTP id el7mr1081873vdb.229.1306878748265; Tue, 31 May 2011 14:52:28 -0700 (PDT) Received: by 10.52.108.35 with HTTP; Tue, 31 May 2011 14:52:27 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> Date: Wed, 1 Jun 2011 07:52:27 +1000 Message-ID: From: Greg Wilkins To: Gabriel Montenegro Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 21:52:30 -0000 On 1 June 2011 02:27, Gabriel Montenegro wrote: > We have as many counterexamples of the opposite with the bits in the IP h= eader, TCP headers, IP TOS bits, as well as protocol numbers (e.g., for IP,= TCP, ESP, IPv6, UDP, etc), etc. There is nothing new about IANA sections a= nd process to control shared resources. Sure, there's no police and people = can use bits as they see fit and sometimes they do so, but rules are alread= y clear, and no extra wording will change that. I was thinking that the extra text was not so much trying to enforce IANA rules/exclusions. More to remind the developers that extra data can be added to the payload for extra op-codes and flags. Ie reduce the temptation to squat on the reserved bits by steering them to an acceptable alternative. regards From jat@google.com Tue May 31 14:58:29 2011 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 AC10BE070C for ; Tue, 31 May 2011 14:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1UczWghbpbXp for ; Tue, 31 May 2011 14:58:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 124D1E06B5 for ; Tue, 31 May 2011 14:58:28 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p4VLwSYr001796 for ; Tue, 31 May 2011 14:58:28 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306879108; bh=p9EemY5YWm4ewCVNKKqrM3XDnUg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZI1KwZcHZrJBFEaOxKgS/YffKYhizUQpHaH2PjEv/9ivxZSNG4mN9T5G/pZzUu2Pt Mp555PQi/Hfx5ehD0LDHA== Received: from gyf2 (gyf2.prod.google.com [10.243.50.66]) by wpaz5.hot.corp.google.com with ESMTP id p4VLvZUJ008950 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 31 May 2011 14:58:27 -0700 Received: by gyf2 with SMTP id 2so2873015gyf.11 for ; Tue, 31 May 2011 14:58:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=1ERHtaXtSNwyfYqGMr82h582KUnAjc5CdKIZd44QTJ4=; b=mSosq+A+98t3TCrF7HvHWfM6Jqniy2nMHsK5rfkKmnP0R+yqAH9TEWF7SZG9Qk8o17 LPhHc6xR2lS3AVQ2aiLg== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=nmdfHsdQi8a1+i7FYSOp3jcXryQa7GWAsSeqzSxqYKY85os6x+z2zj7rLhT4m96a4o Cws9MXAIIYlC/+NUJ2nA== Received: by 10.151.5.15 with SMTP id h15mr5376700ybi.2.1306879107174; Tue, 31 May 2011 14:58:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 31 May 2011 14:58:07 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> From: John Tamplin Date: Tue, 31 May 2011 17:58:07 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd489f6f2938104a4998010 X-System-Of-Record: true Cc: "hybi@ietf.org" , Gabriel Montenegro , Bjoern Hoehrmann Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 21:58:29 -0000 --000e0cd489f6f2938104a4998010 Content-Type: text/plain; charset=UTF-8 On Tue, May 31, 2011 at 5:52 PM, Greg Wilkins wrote: > I was thinking that the extra text was not so much trying to enforce > IANA rules/exclusions. More to remind the developers that extra data > can be added to the payload for extra op-codes and flags. Ie reduce > the temptation to squat on the reserved bits by steering them to an > acceptable alternative. > I disagree with using existing opcodes for something different -- if a frame is labelled as binary, then it should represent binary payload data that will be delivered to the app. If you want to have the payload that means something else, then it needs a different opcode. Even if you allowed hijacking the existing frame definitions, it seems like you still have the same problem in assigning values for the "secondary opcode" stored in the first byte. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd489f6f2938104a4998010 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 31, 2011 at 5:52 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
I was thinking that the extra text was not so much trying to enforce
IANA rules/exclusions. =C2=A0More to remind the developers that extra data<= br> can be added to the payload for extra op-codes and flags. =C2=A0Ie reduce the temptation to squat on the reserved bits by steering them to an
acceptable alternative.

I disagree with= using existing opcodes for something different -- if a frame is labelled a= s binary, then it should represent binary payload data that will be deliver= ed to the app. =C2=A0If you want to have the payload that means something e= lse, then it needs a different opcode. =C2=A0Even if you allowed hijacking = the existing frame definitions, it seems like you still have the same probl= em in assigning values for the "secondary opcode" stored in the f= irst byte.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd489f6f2938104a4998010-- From gregw@intalio.com Tue May 31 15:44:23 2011 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 DB0F9E08E0 for ; Tue, 31 May 2011 15:44:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P2envkmiYum for ; Tue, 31 May 2011 15:44:23 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1C14E08BF for ; Tue, 31 May 2011 15:44:22 -0700 (PDT) Received: by vxg33 with SMTP id 33so5096585vxg.31 for ; Tue, 31 May 2011 15:44:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.97.7 with SMTP id dw7mr1235250vdb.109.1306881861602; Tue, 31 May 2011 15:44:21 -0700 (PDT) Received: by 10.52.108.35 with HTTP; Tue, 31 May 2011 15:44:21 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> Date: Wed, 1 Jun 2011 08:44:21 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Gabriel Montenegro , Bjoern Hoehrmann Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 22:44:24 -0000 On 1 June 2011 07:58, John Tamplin wrote: > On Tue, May 31, 2011 at 5:52 PM, Greg Wilkins wrote: >> >> I was thinking that the extra text was not so much trying to enforce >> IANA rules/exclusions. =A0More to remind the developers that extra data >> can be added to the payload for extra op-codes and flags. =A0Ie reduce >> the temptation to squat on the reserved bits by steering them to an >> acceptable alternative. > > I disagree with using existing opcodes for something different -- if a fr= ame > is labelled as binary, then it should represent binary payload data that > will be delivered to the app. =A0If you want to have the payload that mea= ns > something else, then it needs a different opcode. =A0Even if you allowed > hijacking the existing frame definitions, it seems like you still have th= e > same problem in assigning values for the "secondary opcode" stored in the > first byte. I can see that argument and while not entirely convinced by it, don't object to it either. Which suggests that if we want to go the IANA path and not have cyber-squatting, then we need to define an opcode that says the frame is an extension frame and that the interpretation of it is entirely up to the extension(s) cheers From jat@google.com Tue May 31 15:50:31 2011 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 BB0D0E078B for ; Tue, 31 May 2011 15:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96yzX48f-X-v for ; Tue, 31 May 2011 15:50:30 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5E652E0731 for ; Tue, 31 May 2011 15:50:30 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p4VMoOmB020815 for ; Tue, 31 May 2011 15:50:25 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1306882229; bh=Vqq9hUkJCxC9hwsRtULFO3da/TQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=N7efjme5MOOlC1idw1PceKoFe5qI6ANK4OlvjUvBsL3Fb37rUN/LSrrMAaW9pDsqe ToOiUR0zEMtw9BOmZA8Fg== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq12.eem.corp.google.com with ESMTP id p4VMjhbK022874 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 31 May 2011 15:50:23 -0700 Received: by qwj9 with SMTP id 9so3130641qwj.7 for ; Tue, 31 May 2011 15:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aiixd8EkdaFKJRHKO3TOOGkwWORSs13fUSrW/+1hKYo=; b=o26MpviuzSSrv5yibqmteBZN5BNpTz4vv9uMkrfzjrwkPLdpwvt6dfO4sHE/q4D5vj 70SWBFDwakqeZ6ufnfaA== DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=Ove9GOeex6f2qhd3ckJMeKHywfTnj13wSuGGlvwuU4T2os8NrHmXeUOnLRMDfhB7jL wG4DWJGLO0WxazjGeJlg== Received: by 10.229.42.73 with SMTP id r9mr4752701qce.189.1306882223141; Tue, 31 May 2011 15:50:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.78.229 with HTTP; Tue, 31 May 2011 15:50:03 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> From: John Tamplin Date: Tue, 31 May 2011 18:50:03 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=00163683249cac728f04a49a3a36 X-System-Of-Record: true Cc: "hybi@ietf.org" , Gabriel Montenegro , Bjoern Hoehrmann Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 22:50:31 -0000 --00163683249cac728f04a49a3a36 Content-Type: text/plain; charset=UTF-8 On Tue, May 31, 2011 at 6:44 PM, Greg Wilkins wrote: > I can see that argument and while not entirely convinced by it, don't > object to it either. > > Which suggests that if we want to go the IANA path and not have > cyber-squatting, then we need to > define an opcode that says the frame is an extension frame and that > the interpretation of it is entirely up to the extension(s) > So what happens when multiple extensions are defined? How do you make sure their use of such extension frames don't conflict? That sounds at least as complicated as the proposal to dynamically assign opcodes/bits. I don't know if it is necessary -- I don't know about IANA allocation procedures, but I would hope that bits can be allocated temporarily for experimentation. For example, something like "opcode 0x7 is reserved for experimentation with MUX-related extensions until 31 Dec 2011". If that is feasible, then I think having a central registry is a good idea, rather than saying only opcodes/bits are registered but secondary extension opcodes are free-for-all. -- John A. Tamplin Software Engineer (GWT), Google --00163683249cac728f04a49a3a36 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, May 31, 2011 at 6:44 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
I can see that argument and while not ent= irely convinced by it, don't
object to it either.

Which suggests that if we want to go the IANA path and not have
cyber-squatting, then we need to
define an opcode that says the frame is an extension frame and that
the interpretation of it is entirely up to the extension(s)


I don't know if it is necessary -- I don't know abou= t IANA allocation procedures, but I would hope that bits can be allocated t= emporarily for experimentation. =C2=A0For example, something like "opc= ode 0x7 is reserved for experimentation with MUX-related extensions until 3= 1 Dec 2011". =C2=A0If that is feasible, then I think having a central = registry is a good idea, rather than saying only opcodes/bits are registere= d but secondary extension opcodes are free-for-all.

--
John A. Tamplin
Software Engineer (GWT), Google
--00163683249cac728f04a49a3a36-- From simonp@opera.com Tue May 31 16:03:15 2011 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 24887E073A for ; Tue, 31 May 2011 16:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id msGjrjbDVdJx for ; Tue, 31 May 2011 16:03:13 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 80A3B13000D for ; Tue, 31 May 2011 16:03:10 -0700 (PDT) Received: from simon-pieterss-macbook.local (oslo.jvpn.opera.com [213.236.208.46]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p4VN34jp002627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 May 2011 23:03:05 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "hybi@ietf.org" References: <20110527233153.4C33D11C7C00C@ps20323.dreamhostps.com> Date: Wed, 01 Jun 2011 01:03:02 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: User-Agent: Opera Mail/11.11 (MacIntel) Subject: Re: [hybi] [whatwg] websocket onerror Re: [html5] r6156 - [giow] (0) Update all the WebSocket terminology to match the next WSP draft. X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:03:15 -0000 On Wed, 01 Jun 2011 00:36:46 +0200, Ian Hickson wrote: > On Wed, 1 Jun 2011, Simon Pieters wrote: >> > + attribute Function > >> Why is onerror commented out? > > Not much point having it if nothing can fire an 'error' event. Is it intentional that bogus frames are not to be exposed like in -00? -- Simon Pieters Opera Software From gregw@intalio.com Tue May 31 17:53:17 2011 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 548FDE0752 for ; Tue, 31 May 2011 17:53:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.954 X-Spam-Level: X-Spam-Status: No, score=-2.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYfIBnd-yeDW for ; Tue, 31 May 2011 17:53:16 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA8BE06B9 for ; Tue, 31 May 2011 17:53:16 -0700 (PDT) Received: by vws12 with SMTP id 12so5173908vws.31 for ; Tue, 31 May 2011 17:53:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.32.2 with SMTP id e2mr240853vdi.189.1306889595728; Tue, 31 May 2011 17:53:15 -0700 (PDT) Received: by 10.52.108.35 with HTTP; Tue, 31 May 2011 17:53:15 -0700 (PDT) In-Reply-To: References: <4DBA3809.4010004@oracle.com> Date: Wed, 1 Jun 2011 10:53:15 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Gabriel Montenegro Subject: Re: [hybi] method of allocation of reserved bits to extensions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2011 00:53:17 -0000 On 1 June 2011 08:50, John Tamplin wrote: > On Tue, May 31, 2011 at 6:44 PM, Greg Wilkins wrote: >> >> I can see that argument and while not entirely convinced by it, don't >> object to it either. >> >> Which suggests that if we want to go the IANA path and not have >> cyber-squatting, then we need to >> define an opcode that says the frame is an extension frame and that >> the interpretation of it is entirely up to the extension(s) > > So what happens when multiple extensions are defined? =A0How do you make = sure > their use of such extension frames don't conflict? I am not proposing to give extensions any powers that they don't already have now. Extensions will be entirely responsible for separating their own meta data from payload data and it will be the order of extensions that keeps them separated. So if you have extensions A, B and C, each wanting to have opcodes and flags then you might see a payload like: Except that in reality the semantics of that is actually < B payload of < payload >>> Which essentially means that on the wire all you would see is because extension A might be doing crypto, compression, muxing or something else that smunges up the payload, so the meta data for B would only be visible once the receiver had unwrapped the A extension, and the meta data for C would only be visible once the B extension had unwrapped it's payload mutations etc. >=A0That sounds at least as > complicated as the proposal to dynamically assign opcodes/bits. I'm not proposing anything other than reminding developers that wish to have meta data for an extension that they can put it in the payload rather than squat on the reserved bits and opcodes. > I don't know if it is necessary -- I don't know about IANA allocation > procedures, but I would hope that bits can be allocated temporarily for > experimentation. =A0For example, something like "opcode 0x7 is reserved f= or > experimentation with MUX-related extensions until 31 Dec 2011". =A0If tha= t is > feasible, then I think having a central registry is a good idea, rather t= han > saying only opcodes/bits are registered but secondary extension opcodes a= re > free-for-all. What I'm advocating is that all experimental extensions use flags and opcodes in the payload and do not use the reserved bits temporarily or otherwise. If the Working Group eventually looks at one of these extensions and decides that it should be part of a future version of the spec, we can then allocate reserved bits and thus improve the efficiency of the extension. cheers