From brofield@gmail.com Mon Aug 1 00:39: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 6499921F84E4 for ; Mon, 1 Aug 2011 00:39: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 WmB56Q4EPPR2 for ; Mon, 1 Aug 2011 00:39:19 -0700 (PDT) Received: from mail-pz0-f53.google.com (mail-pz0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id BF42521F84E2 for ; Mon, 1 Aug 2011 00:39:19 -0700 (PDT) Received: by pzk6 with SMTP id 6so10270732pzk.26 for ; Mon, 01 Aug 2011 00:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=3WLnrizOcPdBFqZf9v0qiVK+ARP8JXcqoxMnAgXKuOA=; b=i5+5VR9dx3UVXXR3VLnJ8TddB2OoRBN+Uh1/7xwIpP76BshYGksZ9aBTWjQB+2wFqX GfJDfNcNFWVWgkDCwuvPIkc0hvTZgD5924vefCssmmJ1JIKlOW97B0Dfv58ToKRIk1Pb 57AS45vDkoR9DD/PVHYVY2xgDKrFH3m+6NjeQ= MIME-Version: 1.0 Received: by 10.68.11.10 with SMTP id m10mr7791460pbb.270.1312184364598; Mon, 01 Aug 2011 00:39:24 -0700 (PDT) Sender: brofield@gmail.com Received: by 10.68.56.233 with HTTP; Mon, 1 Aug 2011 00:39:24 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Aug 2011 16:39:24 +0900 X-Google-Sender-Auth: -WRu75hSXpYPyKMLCq4W1U36ThE Message-ID: From: Brodie Thiesfield To: Greg Wilkins Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] extension params (was draft-10 questions) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 07:39:20 -0000 On Mon, Aug 1, 2011 at 1:53 PM, Greg Wilkins wrote: > Can't this be an instance of being forgiving in what you parse and > strict in what you generate? > > We should allow ws servers to use existing HTTP parsers and to accept > quoted strings for any of the header values. Since we are using HTTP for the upgrade, I think that servers should follow the HTTP spec and accept the HTTP header syntax. In any case accepting quoted-string is not an onerous requirement. > However we could also say that ws clients MUST NOT generate any header > values that need to be quoted. It should not cause problems since only strings containing double quotes need quoting, however I don't see the need to add this restriction. Regards, Brodie > On 1 August 2011 10:23, Brodie Thiesfield wrote: >> All, >> >> During the recent IETF meeting the format of the websocket extension >> header parameters was brought up. The issue being should the header >> follow the rules of HTTP (allowing quoted strings) or the simplified >> rules of websocket draft (allowing only tokens). >> >> On Mon, Aug 1, 2011 at 1:02 AM, Patrick McManus w= rote: >>> On Sun, 2011-07-31 at 06:13 -0700, Tobias Oberstein wrote: >>>> 2. >>>> In the context of a persistent http connection, what is allowed _befor= e_ the WebSocket handshake >>>> (that is before client sends GET with upgrade header)? >>> >>> prior to the 101 the connection is http. So yes, you can send the >>> bootstrap http request on a reused http connection. You can do anything >>> HTTP allows you to do, because the handshake is carried out over HTTP. >>> That's the point of reusing the infrastructure. >> >> Since a websocket connection is plain HTTP prior to upgrade, then a >> server supporting normal HTTP requests on a connection (i.e. not a WS >> specific server) will already be using its full HTTP parser. >> >> It is not possible to determine what is a WS upgrade message until the >> headers have already been parsed, e.g. the following message is a >> valid upgrade but that is not known until the last byte is parsed. >> Additionally, take away the "Upgrade" header from the end and it is a >> plain HTTP GET with some unnecessary headers. >> >> =A0 =A0 =A0 =A0GET /chat HTTP/1.1 >> =A0 =A0 =A0 =A0Host: server.example.com >> =A0 =A0 =A0 =A0Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ=3D=3D >> =A0 =A0 =A0 =A0Sec-WebSocket-Origin: http://example.com >> =A0 =A0 =A0 =A0Sec-WebSocket-Protocol: chat, superchat >> =A0 =A0 =A0 =A0Sec-WebSocket-Version: 8 >> =A0 =A0 =A0 =A0Connection: Upgrade >> =A0 =A0 =A0 =A0Upgrade: websocket >> >> The WS headers have already been parsed by the HTTP parser. Unless the >> special parsing of the Sec-Websocket-Extension depends solely on the >> header key, there can be no special parsing. If it does depend on the >> header key, then won't this require a change to the HTTP spec to >> introduce the rule that this header key is parsed specially? If it was >> so defined, then every header key of every HTTP message will need to >> be examined to see if it requires the simplified parsing. >> >> If a WS only handshake is ever defined, then all limitations can be >> decided here, but since the current handshake is using HTTP for >> bootstrapping, I don't think that we can specify any format for any >> part of the upgrade message that differs from HTTP. >> >> Of course, a server implementation may not implement a full HTTP >> parser and return a 400 error on quoted string, but for the spec I >> believe that we are bound by their spec until the protocol has been >> switched to WS. >> >> >> Regards, >> Brodie >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > From julian.reschke@gmx.de Mon Aug 1 01:27: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 4D98221F86BB for ; Mon, 1 Aug 2011 01:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.271 X-Spam-Level: X-Spam-Status: No, score=-104.271 tagged_above=-999 required=5 tests=[AWL=-1.672, 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 H-Xq82fYb9wM for ; Mon, 1 Aug 2011 01:27:22 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 567E421F86AF for ; Mon, 1 Aug 2011 01:27:22 -0700 (PDT) Received: (qmail invoked by alias); 01 Aug 2011 08:27:25 -0000 Received: from p508FDB9A.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.219.154] by mail.gmx.net (mp040) with SMTP; 01 Aug 2011 10:27:25 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+10BMs8H+18FwYYPCWM/HklJvQi88UrSjCBkqfxv enCEVFv3nbrpJC Message-ID: <4E366369.6050706@gmx.de> Date: Mon, 01 Aug 2011 10:27:21 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Brodie Thiesfield References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] extension params (was draft-10 questions) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 08:27:23 -0000 On 2011-08-01 02:23, Brodie Thiesfield wrote: > All, > > During the recent IETF meeting the format of the websocket extension > header parameters was brought up. The issue being should the header > follow the rules of HTTP (allowing quoted strings) or the simplified > rules of websocket draft (allowing only tokens). Yes. In value parameters. That's not a strict HTTP rule, but doing so would help reusing existing parsers. > ... > Since a websocket connection is plain HTTP prior to upgrade, then a > server supporting normal HTTP requests on a connection (i.e. not a WS > specific server) will already be using its full HTTP parser. > > It is not possible to determine what is a WS upgrade message until the > headers have already been parsed, e.g. the following message is a > valid upgrade but that is not known until the last byte is parsed. > Additionally, take away the "Upgrade" header from the end and it is a > plain HTTP GET with some unnecessary headers. > > GET /chat HTTP/1.1 > Host: server.example.com > Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== > Sec-WebSocket-Origin: http://example.com > Sec-WebSocket-Protocol: chat, superchat > Sec-WebSocket-Version: 8 > Connection: Upgrade > Upgrade: websocket > > The WS headers have already been parsed by the HTTP parser. Unless the > special parsing of the Sec-Websocket-Extension depends solely on the > header key, there can be no special parsing. If it does depend on the > header key, then won't this require a change to the HTTP spec to > introduce the rule that this header key is parsed specially? If it was > so defined, then every header key of every HTTP message will need to > be examined to see if it requires the simplified parsing. > ... It does not depend on the header name; if it did it wouldn't be implementable at all. The concern is just that if we do not allow Sec-WebSocket-Extensions: bar; baz="2" in addition to Sec-WebSocket-Extensions: bar; baz=2 then there's a risk of some implementations re-using parser code, accepting the latter form, and some not doing so, creating interop problems. SO far I haven't heard back from Ian (who apparently talked to the other Ian), but I think it was mentioned in the session that this does affect the API. It does not. Best regards, Julian From pmcmanus@mozilla.com Mon Aug 1 05:37: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 60F0611E8393 for ; Mon, 1 Aug 2011 05:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 Bfw1ghEBuJ-R for ; Mon, 1 Aug 2011 05:37:57 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 92B0511E8218 for ; Mon, 1 Aug 2011 05:37:34 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id C8E8010194; Mon, 1 Aug 2011 08:37:39 -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 6FD3610190; Mon, 1 Aug 2011 08:37:31 -0400 (EDT) From: Patrick McManus To: Tobias Oberstein In-Reply-To: <634914A010D0B943A035D226786325D422BDDCE1D2@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BDDCE1C9@EXVMBX020-12.exch020.serverdata.net> <1312128157.1862.296.camel@ds9> <634914A010D0B943A035D226786325D422BDDCE1D2@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset="UTF-8" Date: Mon, 01 Aug 2011 08:37:22 -0400 Message-ID: <1312202242.1862.307.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] draft-10 questions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 12:37:57 -0000 On Sun, 2011-07-31 at 10:12 -0700, Tobias Oberstein wrote: > > just to be sure to get that right: > > A js served to a browser from http://somehost:80 can contact _any_ ws(s)://XXX:YYY ? > > It's at the sole discretion of that other host to accept (depending e.g. on ws-origin) the ws ? > > so for WebSockets in browsers, the "same origin policy" does not apply at all? yes. Same origin is not necessary because websockets contains a mandatory origin header and, thanks to the hash based handshake, we know the server implements the spec that understands that semantic. > e.g. under what circumstances will a cookie A set by the original js serving http://somehost:80 be > delivered in the headers of an ws outgoing from that js? > > or, is that browser implementation dependent? > It certainly isn't specified by hybi :). In FF the normal HTTP cookie rules apply (which is to say the most interesting factor is the hostname of the ws server), because wherever we can we treat that handshake like just another http transaction. That also means things like HSTS (will) apply to the handshake. CSP too when that mapping is figured out. One distinction we have decided to draw is to prevent downgrading mixed content with websockets (i.e. you cannot connect to a ws:// url from a https:// based context). From tobias.oberstein@tavendo.de Mon Aug 1 06:56: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 28BA511E809D for ; Mon, 1 Aug 2011 06:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, 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 PsX04WkOjCIR for ; Mon, 1 Aug 2011 06:56:16 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9960F21F8D25 for ; Mon, 1 Aug 2011 06:56:16 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.39]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 1 Aug 2011 06:56:22 -0700 From: Tobias Oberstein To: Patrick McManus Date: Mon, 1 Aug 2011 06:56:02 -0700 Thread-Topic: AW: [hybi] draft-10 questions Thread-Index: AcxQR8/+KQkJWodVQlav2iGPUMXhKgACYHTA Message-ID: <634914A010D0B943A035D226786325D422BDDCE2D7@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BDDCE1C9@EXVMBX020-12.exch020.serverdata.net> <1312128157.1862.296.camel@ds9> <634914A010D0B943A035D226786325D422BDDCE1D2@EXVMBX020-12.exch020.serverdata.net> <1312202242.1862.307.camel@ds9> In-Reply-To: <1312202242.1862.307.camel@ds9> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] draft-10 questions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 13:56:17 -0000 dGhhbmtzIGZvciB5b3VyIGV4cGxhbmF0aW9ucy4gaW50ZXJlc3RpbmcuDQoNCj09DQogDQoxIG1v cmUgdW5yZWxhdGVkIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgZHJhZnQ6DQoNClRoZSBzcGVjIHNh eXMgImFsbCBjbGllbnQtdG8tc2VydmVyIGZyYW1lcyBNVVNUIGJlIG1hc2tlZCIuDQoNCkRvZXMg dGhhdCBhbHNvIGFwcGx5IHRvIGZyYW1lcyBvZiBwYXlsb2FkIGxlbmd0aCAwPw0KDQpGb3IgZXhh bXBsZSwgaGVyZSBhIHJlYWwtd29ybGQgY2xpZW50LXRvLXNlcnZlciBjbG9zZSBmcmFtZSBJJ3Zl IHNlZW46DQoNCjg4ODAyNDE5MzgyMQ0KDQpJdCBpbmNsdWRlcyBhIG1hc2ssIGJ1dCBubyBwYXls b2FkLg0KDQpJbiBvdGhlciB3b3Jkcywgd2hhdCBvZiB0aGUgZm9sbG93aW5nIG9wdGlvbnMgaXMg bWVhbnQ6DQoNCkEpDQpBbGwgY2xpZW50LXRvLXNlcnZlciBmcmFtZXMgTVVTVCBiZSBtYXNrZWQs IHJlZ2FyZGxlc3Mgd2hldGhlciBwYXlsb2FkIGxlbmd0aCA+IDAgb3IgPSAwLg0KIA0KQikNCkFs bCBjbGllbnQtdG8tc2VydmVyIGZyYW1lcywgd2hlbiBoYXZpbmcgcGF5bG9hZCBsZW5ndGggPiAw IE1VU1QgYmUgbWFza2VkLCB3aGVuIGhhdmluZyBwYXlsb2FkIGxlbmd0aCA9IDAgTUFZIGJlIG1h c2tlZC4NCg0KQykNCkFsbCBjbGllbnQtdG8tc2VydmVyIGZyYW1lcywgd2hlbiBoYXZpbmcgcGF5 bG9hZCBsZW5ndGggPiAwIE1VU1QgYmUgbWFza2VkLCB3aGVuIGhhdmluZyBwYXlsb2FkIGxlbmd0 aCA9IDAgTVVTVCBOT1QgYmUgbWFza2VkLg0KDQo/Pw0KDQpBbiBhbmFsb2cgcXVlc3Rpb24gaXM6 IHdoYXQgYWJvdXQgc2VydmVyLXRvLWNsaWVudCBmcmFtZXMuDQoNClRob3NlIE1BWSBiZSBtYXNr ZWQuDQoNCkJ1dCwgYWdhaW4sIHdoYXQgYWJvdXQgZnJhbWVzIG9mIHBheWxvYWQgbGVuZ3RoIDA/ IE1hc2sgZm9yYmlkZGVuIG9yIG9wdGlvbmFsPw0K From jat@google.com Mon Aug 1 07:05: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 C803511E80C7 for ; Mon, 1 Aug 2011 07:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.951 X-Spam-Level: X-Spam-Status: No, score=-105.951 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 MUWbXbeMfrkY for ; Mon, 1 Aug 2011 07:05:25 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id C846621F8CAA for ; Mon, 1 Aug 2011 07:05:24 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p71E5NiM009267 for ; Mon, 1 Aug 2011 07:05:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312207524; bh=JQcUCFAx+MrsMPJAyJPGCF6Lb3g=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=w7fZvDPP2tXJZMM+BmL8bhnhaW6zoIqyFwK0/En0QifM89CVUL+na84EF1+82Aa6R TCSNuOv4MmJB6EPFLbCaA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Mx/Ky47Q3tPLmbSV9vFNYbgydSWAaLcM1dMNrlF8nppnBF9Bn3w2xrdGMnrqg5yxq d/CvEMV9cooVGTG/VOK/w== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by hpaq3.eem.corp.google.com with ESMTP id p71E4u3j029589 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 1 Aug 2011 07:05:22 -0700 Received: by gwb17 with SMTP id 17so3968894gwb.15 for ; Mon, 01 Aug 2011 07:05:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QNaKAO99AJ3tUnEcs8SLm8Hzmlv54oJZZkbTbxCUprg=; b=Q88geeB8lsK59yByJb716qU1usGfBTKMzsO4+6nCKHiprfKnWP3SnVZg4hnimZl5jr tg4cqVRM0CwjsV2wDlaA== Received: by 10.150.150.34 with SMTP id x34mr844820ybd.59.1312207522150; Mon, 01 Aug 2011 07:05:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 1 Aug 2011 07:05:02 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BDDCE2D7@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BDDCE1C9@EXVMBX020-12.exch020.serverdata.net> <1312128157.1862.296.camel@ds9> <634914A010D0B943A035D226786325D422BDDCE1D2@EXVMBX020-12.exch020.serverdata.net> <1312202242.1862.307.camel@ds9> <634914A010D0B943A035D226786325D422BDDCE2D7@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Mon, 1 Aug 2011 10:05:02 -0400 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd6d02e3ab98004a9721faa X-System-Of-Record: true Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] draft-10 questions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:05:25 -0000 --000e0cd6d02e3ab98004a9721faa Content-Type: text/plain; charset=UTF-8 On Mon, Aug 1, 2011 at 9:56 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > thanks for your explanations. interesting. > > == > > 1 more unrelated question regarding the draft: > > The spec says "all client-to-server frames MUST be masked". > > Does that also apply to frames of payload length 0? > There is no exclusion and "all" would seem to include them, so yes. You could argue it is not useful, though I don't know that the number of empty-payload messages is going to be high enough to justify additional complexity in implementations. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6d02e3ab98004a9721faa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 1, 2011 at 9:56 AM, Tobias Oberstein= <tobia= s.oberstein@tavendo.de> wrote:
thanks for your explanations. interesting.

=3D=3D

1 more unrelated question regarding the draft:

The spec says "all client-to-server frames MUST be masked".

Does that also apply to frames of payload length 0?
There is no exclusion and "all" would seem to includ= e them, so yes.

You could argue it is not useful, = though I don't know that the number of empty-payload messages is going = to be high enough to justify additional complexity in implementations.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd6d02e3ab98004a9721faa-- From tobias.oberstein@tavendo.de Mon Aug 1 07:24: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 C4F4321F8E86 for ; Mon, 1 Aug 2011 07:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 k9NCUUP4zaNZ for ; Mon, 1 Aug 2011 07:24:56 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3DE8121F8E80 for ; Mon, 1 Aug 2011 07:24:56 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.39]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 1 Aug 2011 07:25:02 -0700 From: Tobias Oberstein To: John Tamplin Date: Mon, 1 Aug 2011 07:24:41 -0700 Thread-Topic: [hybi] draft-10 questions Thread-Index: AcxQVBIMihNipNLBR6CHy/Pk1jktCgAAYTVQ Message-ID: <634914A010D0B943A035D226786325D422BDDCE30E@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BDDCE1C9@EXVMBX020-12.exch020.serverdata.net> <1312128157.1862.296.camel@ds9> <634914A010D0B943A035D226786325D422BDDCE1D2@EXVMBX020-12.exch020.serverdata.net> <1312202242.1862.307.camel@ds9> <634914A010D0B943A035D226786325D422BDDCE2D7@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Patrick McManus Subject: Re: [hybi] draft-10 questions X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:24:56 -0000 PiAxIG1vcmUgdW5yZWxhdGVkIHF1ZXN0aW9uIHJlZ2FyZGluZyB0aGUgZHJhZnQ6DQo+DQo+IFRo ZSBzcGVjIHNheXMgImFsbCBjbGllbnQtdG8tc2VydmVyIGZyYW1lcyBNVVNUIGJlIG1hc2tlZCIu DQo+DQo+IERvZXMgdGhhdCBhbHNvIGFwcGx5IHRvIGZyYW1lcyBvZiBwYXlsb2FkIGxlbmd0aCAw Pw0KPg0KPiBUaGVyZSBpcyBubyBleGNsdXNpb24gYW5kICJhbGwiIHdvdWxkIHNlZW0gdG8gaW5j bHVkZSB0aGVtLCBzbyB5ZXMuDQoNCnRoYW5rcyBmb3IgcmVhc3N1cmFuY2UNCg0KPg0KPiBZb3Ug Y291bGQgYXJndWUgaXQgaXMgbm90IHVzZWZ1bCwgdGhvdWdoIEkgZG9uJ3Qga25vdyB0aGF0IHRo ZSBudW1iZXIgb2YgZW1wdHktcGF5bG9hZCBtZXNzYWdlcyBpcyBnb2luZyB0byBiZSBoaWdoIGVu b3VnaCB0byBqdXN0aWZ5IGFkZGl0aW9uYWwgY29tcGxleGl0eSBpbiBpbXBsZW1lbnRhdGlvbnMu DQoNCnllcCwgYXMgbXkgaW1wcmVzc2lvbiBpcyB0aGF0IFdlYlNvY2tldHMgaXMgY29uY2VybmVk IGFib3V0IHdpcmUgdm9sdW1lLCB0aGF0IHdhcyBteSB0cmlnZ2VyLCBidXQgSSB3b250IGFyZ3Vl LCBzaW5jZQ0KLSBwaW5ncyBmb3Iga2VlcC1hbGl2ZSBhcmUgcHJvYmFibHkgdGhlIG9ubHkgc2Vu c2libGUgdXNlIG9mIGVtcHR5IHBheWxvYWQgZnJhbWVzDQotIG1hc2tpbmcgZW1wdHktcGF5bG9h ZCBwaW5ncyB0cmlwbGVzIHRoZWlyIHZvbHVtZSwgYnV0DQotIHRoZSByZWd1bGFyIGNhc2Ugd291 bGQgYmUgdGhlIHNlcnZlciBwaW5naW5nIHRoZSBjbGllbnQsIG5vdCByZXZlcnNlDQoNCg== From stpeter@stpeter.im Mon Aug 1 07:51: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 D639721F8D2B for ; Mon, 1 Aug 2011 07:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.417 X-Spam-Level: X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, 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 hu0Cd4IgfMgl for ; Mon, 1 Aug 2011 07:51:08 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 452EE21F8D2A for ; Mon, 1 Aug 2011 07:51:08 -0700 (PDT) Received: from squire.local (unknown [216.17.251.72]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 6E70A41309; Mon, 1 Aug 2011 08:52:29 -0600 (MDT) Message-ID: <4E36BD5F.10601@stpeter.im> Date: Mon, 01 Aug 2011 08:51:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Server-Initiated HTTP , Gabriel Montenegro Subject: Re: [hybi] consensus call on not specifying DNS SRV as mandatory to implement X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 14:51:08 -0000 On 7/31/11 6:07 PM, Iñaki Baz Castillo wrote: > 2011/7/30 Gabriel Montenegro : >> At the meeting and on the mailing list leading up to it, the chairs did not >> see consensus for the following action: >> >> Specify DNS SRV as mandatory to implement in the websocket >> protocol specification. >> >> We’re confirming on the mailing list, and will declare this consensus call >> final by next Friday Aug 5. > > > I was proposing it, but after long discussions in the maillist I've > understood that mandating DNS SRV in WS clients would break too much > assumptions in HTTP world (which commonly just sees above HTTP layer > and not below). > > The existence of HTTP proxies is also a big handicap since those > proxies should be upgraded/modified in order to perform DNS SRV > resolution *just* in case the HTTP request is a WebSocket handshake. > This last argument is enough to not mandate SRV resolution. > > So I see two options (for the future): > > 1) As Greg says: consider again DNS SRV if we ever have a non HTTP handshake. IMHO that's possible but unlikely. > 2) Introduce SRV (optional of course) in HTTP protocol (WS would just > inherit it automatically). That's been tried, but it failed: https://datatracker.ietf.org/doc/draft-jennings-http-srv/ It was a nice idea, though. :) Peter -- Peter Saint-Andre https://stpeter.im/ From salvatore.loreto@ericsson.com Mon Aug 1 10:03: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 653EA11E80AB for ; Mon, 1 Aug 2011 10:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_55=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 lg5eG57Ar5bn for ; Mon, 1 Aug 2011 10:03:08 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0C711E8077 for ; Mon, 1 Aug 2011 10:03:07 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-c1-4e36dc513ccb Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 87.65.20773.15CD63E4; Mon, 1 Aug 2011 19:03:13 +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; Mon, 1 Aug 2011 19:03:13 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 159862461; Mon, 1 Aug 2011 20:03:13 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D08FD51285; Mon, 1 Aug 2011 20:03:12 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8407A51284; Mon, 1 Aug 2011 20:03:12 +0300 (EEST) Message-ID: <4E36DC50.6000005@ericsson.com> Date: Mon, 1 Aug 2011 20:03:12 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] minutes: HyBi meeting at IETF81 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:03:09 -0000 Hi there, here the minutes draft version from HyBi meeting at IETF81. Please review the minutes and send any correction to the chairs by Monday August 25th, as the "proceeding submission cutoff" is Friday August 29th. Special thank to Li Kepeng to collect the notes during the meetings. cheers /Sal --- Salvatore Loreto www.sloreto.com ======================================================================== HyBi note from the meeting Thursday, July 26th, 2011 17:40 - 19:40 Afternoon Session II Note Taker : Li Kepeng, Gabriel Montenegro Slides at https://datatracker.ietf.org/meeting/81/materials.html#wg-hybi Audio record: tbd. ======================================================================== Administrative/Agenda bash (Chairs - 10m) ------------------------------------------------------------------------ Salvatore: almost time to start to work on a test suites Greg thinks his draft has some wrong ideas, better to restart from scratch Thread initiated on the subject here: http://www.ietf.org/mail-archive/web/hybi/current/msg07969.html Test suite proposal here: http://www.ietf.org/mail-archive/web/hybi/current/msg07975.html status and other business about the finalization of the main spec (Alexey Melnikov - 80m) ------------------------------------------------------------------------------------------------ (draft-ietf-hybi-thewebsocketprotocol-10) *Major Issues*: - Remove deflate-stream from the base spec --Agreed - Use DNS SRV as part of the base spec --Agreed Richard Barnes: agree Sal: we have spent a lot of time on being compliant with the existing infrastructure - Add ability to add max frame size announcement --Agreed -Richard Barnes to help with security review and wording in sec considerations Add HSTS, CSP, etc From jabber: kepeng_li\40jabber.org: please capture an action item for the chairs/editors to ask for double-checking of the URI schemes by the uri-review discussion list -Server "failing a websocket connection" and server dropping without telling the reason to the client -Two cases: either during the handshake or after it (once the connection is established) -Mechanisms exist, add clarification to the text -Editorial issue -Version in upgrade token? No. -Not required - Mark N ok with not doing this - X-namespace? No resolution yet. -the issue will be discussed on the HyBi mailing list -Perhaps. This is gaining steam in app-related discussions and the IESG will probably be looking out for this issue. -[Side discussion afterwards: check with appswg, and if this is gaining ground, we can go with it.] - Language tagging: optional tag NOT to be added. -Just clarify "MUST NOT be shown to users" and avoid tagging altogether - Major.minor version? ok -No minor -Just clarify that major ver change: no backward compat - Cookies -Just remove mention of cookies, let HTTP stand -[action item: editors to double-check other text that may be affected by the removal of any mention of cookies.] - Reconnection logic - OK -add some randomization to avoid synchronization -Ian: treat this as two separate cases: fail at connect (e.g., server overload) vs fail after connect - GET method? OK -Richard Barnes: seems like a handshake could be devised to not have masking -Again rathole on masking -We'll leave it as is - Masking: ok -but better description to avoid future ratholes and confusion - Large frames or messages and DoS security considerations -Document potential issues and mitigations § Frame size announcement to be added § Option for either side to terminate at any time -Need not be all buffered, could be a handle to a stream -API issue - Origin vs sec-websocket-origin, why both? -Need to double-check with Adam Barth -CoRS-like pre-flight check also being done? -"contact the server" to be clarified - Error code ranges: -4 or so currently -Have only 2? -Ian: Having more code ranges reduces probability of collisions -Alexey: weak argument -Ian: perhaps but it being imperfect still allows it to be useful -Resolution: reduce number to 2 (or 3) - HTTP allows both token and quoted-string (Julian Reschke) -Ian: No need for quoted-string § If want quoted-string, also suggest text -Julian Reschke: let's take this to the mailing list - The rest of the issues are minor or editorial or there is no change to be done. extensions and other options : (Ian Fette -20m) --------------------------------------------------------------------------- -Good support for both Frame compression and multiplex -Timeout also mentioned, some support. Kepeng Li: it is useful for the request to indicate the request-timeout and connection-timeout Open Discussion (All - 10m) ---------------------------------------------------------------------- None From stpeter@stpeter.im Mon Aug 1 10:46: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 CECAA11E8114 for ; Mon, 1 Aug 2011 10:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 izNpbJgYvlr8 for ; Mon, 1 Aug 2011 10:46:56 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3BE11E810D for ; Mon, 1 Aug 2011 10:46:56 -0700 (PDT) Received: from squire.local (unknown [216.17.251.72]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 78BDD41309; Mon, 1 Aug 2011 11:48:18 -0600 (MDT) Message-ID: <4E36E68D.80400@stpeter.im> Date: Mon, 01 Aug 2011 11:46:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Salvatore Loreto References: <4E36DC50.6000005@ericsson.com> In-Reply-To: <4E36DC50.6000005@ericsson.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] minutes: HyBi meeting at IETF81 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 17:46:56 -0000 On 8/1/11 11:03 AM, Salvatore Loreto wrote: > - Use DNS SRV as part of the base spec --Agreed Is that a typo? I thought there was consensus to *exclude* DNS SRV from the base spec. Peter -- Peter Saint-Andre https://stpeter.im/ From w@1wt.eu Mon Aug 1 11:16: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 2492A21F8DA6 for ; Mon, 1 Aug 2011 11:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.315 X-Spam-Level: X-Spam-Status: No, score=-4.315 tagged_above=-999 required=5 tests=[AWL=-2.272, 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 mQSNMNMB+Zi2 for ; Mon, 1 Aug 2011 11:16:25 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6277321F8DA5 for ; Mon, 1 Aug 2011 11:16:24 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p71IGQS5026251; Mon, 1 Aug 2011 20:16:26 +0200 Date: Mon, 1 Aug 2011 20:16:26 +0200 From: Willy Tarreau To: Peter Saint-Andre Message-ID: <20110801181626.GB25560@1wt.eu> References: <4E36DC50.6000005@ericsson.com> <4E36E68D.80400@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E36E68D.80400@stpeter.im> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] minutes: HyBi meeting at IETF81 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 18:16:26 -0000 On Mon, Aug 01, 2011 at 11:46:53AM -0600, Peter Saint-Andre wrote: > > > On 8/1/11 11:03 AM, Salvatore Loreto wrote: > > > - Use DNS SRV as part of the base spec --Agreed > > Is that a typo? I thought there was consensus to *exclude* DNS SRV from > the base spec. That's what I heard too during the conf, but it is possible the notes were taken based on the final agreement not to change the spec (from what I recall hearing at the end of the discussion). > Peter Willy From bruce@callenish.com Mon Aug 1 13:27:36 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 E62F121F8B80 for ; Mon, 1 Aug 2011 13:27:36 -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 BgarKhm5WkKE for ; Mon, 1 Aug 2011 13:27:36 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC5421F84F7 for ; Mon, 1 Aug 2011 13:27:36 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qnz5O-0005pP-JW; Mon, 01 Aug 2011 13:27:38 -0700 Message-ID: <4E370C3E.3050608@callenish.com> Date: Mon, 01 Aug 2011 13:27:42 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Colomiets References: <4E35539B.3090406@gmx.de> <4E3556C1.2090300@gmx.de> 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: Server-Initiated HTTP Subject: Re: [hybi] consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:27:37 -0000 On 31/07/2011 8:37 AM, Paul Colomiets wrote: > Of course maximum frame size is something different. It asks sender to > split longer messages to chunks of specified size. Thinking more about > this, I think I'm opposed to the idea of specifing frame size. The > problem with frame size limit, is that it gives lazy developers a > false impression that they can set buffer size to the maximum frame > size. In majority cases it's simply not true. And it's not very hard > to split message into frames in the intermediary either. +1 for > announcing message size -0 for announcing frame size This makes no sense to me. The application controls both the client and the server portions of the messages being sent. Why would anyone need a maximum message size? If you don't want them to be bigger than a certain maximum, then just don't send any that are larger. Letting the other end know about the maximum frame size you can handle makes much more sense. The server implementation and the client implementation know nothing about each other other than that they both speak Websockets protocol. They have no clue what the maximum frame size is that they can safely send unless they can signal each other. I don't understand what you mean about lazy programmers setting buffer size to maximum frame size. If my Websockets implementation broadcasts that it can handle a maximum frame size of 8K, then it probably will have buffers that are 8K. That only makes sense. How that gets assembled into messages is an implementation detail. Perhaps a stream is used to pass the message to the application layer, perhaps it isn't. Likely it depends on the size of messages that the application wants to send and the application can determine how it receives messages from the lower layers. So to the point of the thread topic, I'm in favour of allowing the sending of a maximum frame size. From salvatore.loreto@ericsson.com Mon Aug 1 13:38: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 02C771F0C3D for ; Mon, 1 Aug 2011 13:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 QCLE1DW6IKrS for ; Mon, 1 Aug 2011 13:38:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 332EE1F0C43 for ; Mon, 1 Aug 2011 13:38:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-4c-4e370eca39ba Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id E7.5E.09774.ACE073E4; Mon, 1 Aug 2011 22:38:34 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Mon, 1 Aug 2011 22:38:34 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 17647204A; Mon, 1 Aug 2011 23:38:33 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E1E1851285; Mon, 1 Aug 2011 23:38:29 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8A22551203; Mon, 1 Aug 2011 23:38:29 +0300 (EEST) Message-ID: <4E370EC5.7080501@ericsson.com> Date: Mon, 1 Aug 2011 23:38:29 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: Willy Tarreau References: <4E36DC50.6000005@ericsson.com> <4E36E68D.80400@stpeter.im> <20110801181626.GB25560@1wt.eu> In-Reply-To: <20110801181626.GB25560@1wt.eu> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] minutes: HyBi meeting at IETF81 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:38:29 -0000 On 8/1/11 9:16 PM, Willy Tarreau wrote: > On Mon, Aug 01, 2011 at 11:46:53AM -0600, Peter Saint-Andre wrote: >> >> >> On 8/1/11 11:03 AM, Salvatore Loreto wrote: >> >>> - Use DNS SRV as part of the base spec --Agreed >> Is that a typo? I thought there was consensus to *exclude* DNS SRV from >> the base spec. > That's what I heard too during the conf, but it is possible the notes > were taken based on the final agreement not to change the spec (from > what I recall hearing at the end of the discussion). sorry it is a typo! it should be > - Use DNS SRV as part of the base spec --Rejected I will change it immediately. cheers /Sal From tobias.oberstein@tavendo.de Mon Aug 1 13:56: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 B45C11F0C3C for ; Mon, 1 Aug 2011 13:56:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 lRi3OSs3xm6H for ; Mon, 1 Aug 2011 13:56:08 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id A32151F0C3E for ; Mon, 1 Aug 2011 13:56:08 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.39]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 1 Aug 2011 13:56:15 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Mon, 1 Aug 2011 13:56:12 -0700 Thread-Topic: [hybi] consensus call on ability to announce max frame size Thread-Index: AcxQjXH+VmM0jaBR5E+tUEsYF3eUSg== Message-ID: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 20:56:09 -0000 How would that related to intermediaries? Even if two endpoints agree on a maximum frame size of N (where N >=3D 125 + 6 .. since that is a masked control msg max. size and control frames must never be fragmented), an intermediary might want to have frame size < N. Or > N. It may further fragment or coalesce. In the latter case, even if the endpoints agree, the frames arriving at those endpoints may be longer since they could have been coalesced by an intermediary. Or is some path MTU discovery for frame length the idea? Lots of complexity .. Why is there a need for max. frame size anyway? A specific implementation might buffer all frames to disk .. or compute something on the fly. So there would never be out of mem. Isn't the fact that the WebSockets JS API is message based something independent of the WS protocol? Couldn't there be a data-frame based API in some other context? Or even a stream based one? from the draft: "The WebSocket message does not necessarily correspond to a particular network layer framing, as a fragmented message may be coalesced, or vice versa, e.g. by an intermediary." An intermediary MUST NOT change the fragmentation of a message if any reserved bit values are used and the meaning of these values is not known to the intermediary. o An intermediary MUST NOT change the fragmentation of any message in the context of a connection where extensions have been negotiated and the intermediary is not aware of the semantics of the negotiated extensions. From diogo.pereira@ist.utl.pt Mon Aug 1 15:30: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 8D7501F0C53 for ; Mon, 1 Aug 2011 15:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 EGGbVi-nXAtg for ; Mon, 1 Aug 2011 15:30:56 -0700 (PDT) Received: from smtp2.ist.utl.pt (smtp2.ist.utl.pt [IPv6:2001:690:2100:1::16]) by ietfa.amsl.com (Postfix) with ESMTP id 737301F0C49 for ; Mon, 1 Aug 2011 15:30:55 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 952AB7000444 for ; Mon, 1 Aug 2011 23:31:00 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id jCyzI1I71hQ5 for ; Mon, 1 Aug 2011 23:31:00 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 6608D7000452 for ; Mon, 1 Aug 2011 23:31:00 +0100 (WEST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id E9573200526A for ; Mon, 1 Aug 2011 23:30:59 +0100 (WEST) Received: by gxk19 with SMTP id 19so4470430gxk.31 for ; Mon, 01 Aug 2011 15:30:58 -0700 (PDT) Received: by 10.42.153.7 with SMTP id k7mr3057181icw.457.1312237858104; Mon, 01 Aug 2011 15:30:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.15.66 with HTTP; Mon, 1 Aug 2011 15:30:28 -0700 (PDT) In-Reply-To: References: From: Diogo Pereira Date: Mon, 1 Aug 2011 23:30:28 +0100 Message-ID: To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Aug 2011 22:30:56 -0000 On Mon, Aug 1, 2011 at 21:56, Tobias Oberstein wrote: > Why is there a need for max. frame size anyway? Good question. If the API is messaged based then the implementation has to buffer the entire message. A frame size limit does not help. If the API is stream based there is no buffering problem at all. If the API is frame based (and it shouldn't be), the implementation can still fairly easily perform local fragmentation. -- Diogo From Gabriel.Montenegro@microsoft.com Mon Aug 1 23:59: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 7DF7611E80A6 for ; Mon, 1 Aug 2011 23:59:29 -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 uDUj7pXtVip7 for ; Mon, 1 Aug 2011 23:59:29 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id DC87D11E8094 for ; Mon, 1 Aug 2011 23:59:28 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Mon, 1 Aug 2011 23:59:31 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Aug 2011 23:59:31 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.51]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.002; Mon, 1 Aug 2011 23:59:30 -0700 From: Gabriel Montenegro To: Salvatore Loreto , Willy Tarreau Thread-Topic: [hybi] minutes: HyBi meeting at IETF81 Thread-Index: AQHMUGz7G2+iBNbfbk+sz+emOCDJSJUIun2AgAAIQgCAACewgIAAN5Mg Date: Tue, 2 Aug 2011 06:59:29 +0000 Message-ID: References: <4E36DC50.6000005@ericsson.com> <4E36E68D.80400@stpeter.im> <20110801181626.GB25560@1wt.eu> <4E370EC5.7080501@ericsson.com> In-Reply-To: <4E370EC5.7080501@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] minutes: HyBi meeting at IETF81 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, 02 Aug 2011 06:59:29 -0000 I was taking hasty notes. I registered "agreed" whenever the room agreed wi= th what we had on the slides. The slides read correctly that the call was t= o not include DNS SRV. The "use DNS SRV as part of the base spec" was just = shorthand to refer to that subject, and was not meant to represent the actu= al phrase being agreed upon. In general, the minutes register agreement or disagreement on the items as = they are spelled out in the slides (not in the minutes themselves). > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Salvatore Loreto > Sent: Monday, August 01, 2011 13:38 > To: Willy Tarreau > Cc: hybi@ietf.org > Subject: Re: [hybi] minutes: HyBi meeting at IETF81 >=20 > On 8/1/11 9:16 PM, Willy Tarreau wrote: > > On Mon, Aug 01, 2011 at 11:46:53AM -0600, Peter Saint-Andre wrote: > >> > >> > >> On 8/1/11 11:03 AM, Salvatore Loreto wrote: > >> > >>> - Use DNS SRV as part of the base spec --Agreed > >> Is that a typo? I thought there was consensus to *exclude* DNS SRV > >> from the base spec. > > That's what I heard too during the conf, but it is possible the notes > > were taken based on the final agreement not to change the spec (from > > what I recall hearing at the end of the discussion). >=20 > sorry it is a typo! > it should be >=20 > > - Use DNS SRV as part of the base spec --Rejected > I will change it immediately. >=20 >=20 > cheers > /Sal >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From salvatore.loreto@ericsson.com Tue Aug 2 03:51: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 3AF1321F8EEE for ; Tue, 2 Aug 2011 03:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.284 X-Spam-Level: X-Spam-Status: No, score=-106.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_55=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 Dmz0hxsqxJ0K for ; Tue, 2 Aug 2011 03:51:51 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id E551421F8ED0 for ; Tue, 2 Aug 2011 03:51:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-f6-4e37d6cdfba3 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 50.B6.09774.DC6D73E4; Tue, 2 Aug 2011 12:51:57 +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; Tue, 2 Aug 2011 12:51:57 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4FC942461 for ; Tue, 2 Aug 2011 13:51:57 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1650D51240 for ; Tue, 2 Aug 2011 13:51:57 +0300 (EEST) Received: from n211.nomadiclab.com (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B0AD251001 for ; Tue, 2 Aug 2011 13:51:56 +0300 (EEST) Message-ID: <4E37D6CC.6030006@ericsson.com> Date: Tue, 2 Aug 2011 13:51:56 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: hybi@ietf.org References: <4E36DC50.6000005@ericsson.com> In-Reply-To: <4E36DC50.6000005@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [hybi] minutes vers.2: HyBi meeting at IETF81 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, 02 Aug 2011 10:51:52 -0000 Hi there, here the version 2 of the minutes from HyBi meeting at IETF81. thanks to Peter and Willy to highlight the mistake/unclarity related to DNS-SRV decision. Please review the minutes and send any correction to the chairs by Monday August 25th, as the "proceeding submission cutoff" is Friday August 29th. Special thank to Li Kepeng and Gabriel Montenegro to collect the notes during the meetings. cheers /Sal --- Salvatore Loreto www.sloreto.com ============================ HyBi note from the meeting Thursday, July 26th, 2011 17:40 - 19:40 Afternoon Session II Note Taker : Li Kepeng, Gabriel Montenegro Slides at https://datatracker.ietf.org/meeting/81/materials.html#wg-hybi ============================ Administrative/Agenda bash (Chairs - 10m) ------------------------------------------------------------------------ Salvatore: almost time to start to work on a test suites Greg thinks his draft has some wrong ideas, better to restart from scratch Thread initiated on the subject here: http://www.ietf.org/mail-archive/web/hybi/current/msg07969.html Test suite proposal here: http://www.ietf.org/mail-archive/web/hybi/current/msg07975.html status and other business about the finalization of the main spec (Alexey Melnikov - 80m) ------------------------------------------------------------------------------------------------ (draft-ietf-hybi-thewebsocketprotocol-10) *Major Issues*: - Remove deflate-stream from the base spec --Agreed - Use DNS SRV as part of the base spec --Consensus to exclude DNS SRV from the base spec Richard barnes: agree Sal: we have spent a lot of time on being compliant with the existing infrastructure - Add ability to add max frame size announcement --Agreed -Richard Barnes to help with security review and wording in sec considerations Add HSTS, CSP, etc From jabber: kepeng_li\40jabber.org: please capture an action item for the chairs/editors to ask for double-checking of the URI schemes by the uri-review discussion list -Server "failing a websocket connection" and server dropping without telling the reason to the client -Two cases: either during the handshake or after it (once the connection is established) -Mechanisms exist, add clarification to the text -Editorial issue -Version in upgrade token? No. -Not required - Mark N ok with not doing this - X-namespace? No resolution yet. -the issue will be discussed on the HyBi mailing list -Perhaps. This is gaining steam in app-related discussions and the IESG will probably be looking out for this issue. -[Side discussion afterwards: check with appswg, and if this is gaining ground, we can go with it.] - Language tagging: optional tag NOT to be added. -Just clarify "MUST NOT be shown to users" and avoid tagging altogether - Major.minor version? ok -No minor -Just clarify that major ver change: no backward compat - Cookies -Just remove mention of cookies, let HTTP stand -[action item: editors to double-check other text that may be affected by the removal of any mention of cookies.] - Reconnection logic - OK -add some randomization to avoid synchronization -Ian: treat this as two separate cases: fail at connect (e.g., server overload) vs fail after connect - GET method? OK -Richard Barnes: seems like a handshake could be devised to not have masking -Again rathole on masking -We'll leave it as is - Masking: ok -but better description to avoid future ratholes and confusion - Large frames or messages and DoS security considerations -Document potential issues and mitigations § Frame size announcement to be added § Option for either side to terminate at any time -Need not be all buffered, could be a handle to a stream -API issue - Origin vs sec-websocket-origin, why both? -Need to double-check with Adam Barth -CoRS-like pre-flight check also being done? -"contact the server" to be clarified - Error code ranges: -4 or so currently -Have only 2? -Ian: Having more code ranges reduces probability of collisions -Alexey: weak argument -Ian: perhaps but it being imperfect still allows it to be useful -Resolution: reduce number to 2 (or 3) - HTTP allows both token and quoted-string (Julian Reschke) -Ian: No need for quoted-string § If want quoted-string, also suggest text -Julian Reschke: let's take this to the mailing list - The rest of the issues are minor or editorial or there is no change to be done. extensions and other options : (Ian Fette - 20m) --------------------------------------------------------------------------- -Good support for both Frame compression and multiplex -Timeout also mentioned, some support. Kepeng Li: it is useful for the request to indicate the request-timeout and connection-timeout Open Discussion (All - 10m) ---------------------------------------------------------------------- None From tyoshino@google.com Tue Aug 2 07:36: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 57CA611E8094 for ; Tue, 2 Aug 2011 07:36:38 -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 lRYsKtFX6G3N for ; Tue, 2 Aug 2011 07:36:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 978B011E808F for ; Tue, 2 Aug 2011 07:36:37 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p72EafHc006088 for ; Tue, 2 Aug 2011 07:36:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312295802; bh=xB8cIJIy3TMUiBSeqWzyzy3x+OY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=vHXqIA5qfoJuq3WtVnxphixai1E2XTJidcV9WzlCx+MbouNVvmSKyAAUU6wa1Fp+p gq8kmzhIQAKuumAJ81tyw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:content-type:x-system-of-record; b=URuShuNYpx3ILxIhne1YcQ1tatvOaE9n1JYT0zqCmQLZctErBzBsAPGiuk9/I9C50 tlSNwhL1Bx1Ejq6ca9W8Q== Received: from gyb11 (gyb11.prod.google.com [10.243.49.75]) by hpaq3.eem.corp.google.com with ESMTP id p72EaIxc002420 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 07:36:40 -0700 Received: by gyb11 with SMTP id 11so5977686gyb.35 for ; Tue, 02 Aug 2011 07:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=H5X/kGxPaEaw4tTawsHauT75XOZEmaPQzbX3xQJNZJU=; b=S0TWxbvPLQEbzU8BObUI+HFsZTp0bIGt34UMkhn95YCbAoNFXk1r9W0z+5VMp2IkY5 FskLY7wu9PV0Gt9DFJOA== Received: by 10.150.62.6 with SMTP id k6mr1805415yba.114.1312295800134; Tue, 02 Aug 2011 07:36:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Tue, 2 Aug 2011 07:36:20 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: Takeshi Yoshino Date: Tue, 2 Aug 2011 23:36:20 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd47baa01dcf904a986ad40 X-System-Of-Record: true 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, 02 Aug 2011 14:36:38 -0000 --000e0cd47baa01dcf904a986ad40 Content-Type: text/plain; charset=ISO-8859-1 Updated http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-02 - added COMP bit (not assigned yet) - added window_bits option - added no_context_takeover option - added examples - reorganized algorithm description - changed the token name to deflate-frame TODO: - add non normative section discussing recommended DEFLATE parameter - allocate reserved bit --000e0cd47baa01dcf904a986ad40 Content-Type: text/html; charset=ISO-8859-1
Updated
http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-02

- added COMP bit (not assigned yet)
- added window_bits option
- added no_context_takeover option
- added examples
- reorganized algorithm description
- changed the token name to deflate-frame

TODO:
- add non normative section discussing recommended DEFLATE parameter
- allocate reserved bit

--000e0cd47baa01dcf904a986ad40-- From tyoshino@google.com Tue Aug 2 23:01: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 7FC4221F8666 for ; Tue, 2 Aug 2011 23:01:03 -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 NPeMAmpJx8C6 for ; Tue, 2 Aug 2011 23:01:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id ED97C21F85FF for ; Tue, 2 Aug 2011 23:01:02 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p7360sCQ025824 for ; Tue, 2 Aug 2011 23:00:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312351257; bh=waJFBKT2GecPPhDpEjVoLRpp4y8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=kD7daymPCec/YPuDJtSkVXov5OgDV+WN7v4K5d1CoEcvIl0rp9dQ3QHypAdqJoaUn izvi0kMznvftLD32Bau6Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:content-type:x-system-of-record; b=PmDEP7IPoX+Vu6mBb6bEypjJw/2cDdwnr4Wg2DQVQyvtG3vCc12Uz00B7FXV3s9+x 3oF9AqM75LcraIRiOFvTQ== Received: from gxk9 (gxk9.prod.google.com [10.202.11.9]) by hpaq5.eem.corp.google.com with ESMTP id p7360qrq004980 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 2 Aug 2011 23:00:53 -0700 Received: by gxk9 with SMTP id 9so333969gxk.12 for ; Tue, 02 Aug 2011 23:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=qQPR0oxor0xSeICHU0n7u72G0FdL6Z2ZUVleuU6lMs4=; b=WNLAODce738+p/4dzrXenOvoYds/Z3P8rJVVXpvwHHWQ8bHdoesSzkTKlwn1Q8Qn3i JNOW22TwciHJhxo5mzGQ== Received: by 10.150.40.15 with SMTP id n15mr254960ybn.0.1312351252234; Tue, 02 Aug 2011 23:00:52 -0700 (PDT) Received: by 10.150.40.15 with SMTP id n15mr254957ybn.0.1312351252117; Tue, 02 Aug 2011 23:00:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Tue, 2 Aug 2011 23:00:32 -0700 (PDT) In-Reply-To: References: <4DB8D3B2.8090002@mozilla.com> From: Takeshi Yoshino Date: Wed, 3 Aug 2011 15:00:32 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=000e0cd5f2cc33f91b04a9939617 X-System-Of-Record: true 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: Wed, 03 Aug 2011 06:01:03 -0000 --000e0cd5f2cc33f91b04a9939617 Content-Type: text/plain; charset=ISO-8859-1 Hi, Here's version 03 of per-frame deflate extension. I have - fixed one bug in "Sending" section step 2 - added non-normative implementation note section - fixed extension registration section and added COMP bit registration section http://tools.ietf.org/rfcdiff?url2=draft-tyoshino-hybi-websocket-perframe-deflate-03 Thanks, Takeshi --000e0cd5f2cc33f91b04a9939617 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Here's version 03 of per-frame deflate extension= .

I have
- fixed one bug in "S= ending" section step 2
- added non-normative implement= ation note section
- fixed extension registration section and added COMP bit registration= section

Thanks,
Takeshi
--000e0cd5f2cc33f91b04a9939617-- From piotrku@microsoft.com Wed Aug 3 09:55: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 7BFB821F8B6F for ; Wed, 3 Aug 2011 09:55:48 -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 SClbDxnvzklS for ; Wed, 3 Aug 2011 09:55:47 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id D3FC221F8B6E for ; Wed, 3 Aug 2011 09:55:47 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 3 Aug 2011 09:55:59 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.211]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.007; Wed, 3 Aug 2011 09:55:59 -0700 From: Piotr Kulaga To: Greg Wilkins , Hybi Thread-Topic: [hybi] max frame size. was: consensus call on ability to announce max frame size Thread-Index: AQHMTxpTBSaDY9QPpkOCQOVe24dHRpULXE2w Date: Wed, 3 Aug 2011 16:55:58 +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.71] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 03 Aug 2011 16:55:48 -0000 Can you please explain why we may need a size limit on a frame? It does not= really makes sense to me - if a frame is too big for you for some reasons,= act as intermediary and split single frame into multiple ones (assuming yo= u understand extensions, which should be very common).=20 I see some benefits in having a limit on a message size i.e. you can easily= provide a message based APIs. However, as you mentioned stream APIs are a = norm in HTTP world and personally I do not see a reason for any limits on m= essage/frame size. Kind regards, Piotr -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gre= g Wilkins Sent: Saturday, July 30, 2011 5:40 PM To: Hybi Subject: [hybi] max frame size. was: consensus call on ability to announce = max frame size Changing topic to avoid debate in consensus call thread. On 30 July 2011 17:46, John Tamplin wrote: > I see no mention of maximum message size in this consensus call, only=20 > maximum frame size. Sorry if that muddied the water. But I just wanted to be crystal clear we a= re talking about frames not messages. On 30 July 2011 17:31, Willy Tarreau wrote: > I'd also argue that HTTP has been living for a decade with support for=20 > chunked encoding which does not set a limit on chunk size nor on=20 > message size and has not had any trouble with that. But HTTP also does not have a chunk-too-large error code. Implementations are forced to deal with large chunks. This is often no too difficult because stream APIs are the norm for HTTP. Large sizes are harder to handle in the datagram API of websocket. On 30 July 2011 23:34, Thomson, Martin wrote= : > Given that there is no constraint on message size, this capability is poi= ntless. =A0Any peer that receives this indication does not need to change t= heir behaviour in any meaningful way. =A0Messages of any size can be sent r= egardless of what frame size is supported. Note sure if you are talking about max message or max frame size? But a peer that does not respect a max frame indication and does not change= it's behaviour will then just receive frame-too-large errors in response. If we allow frame-too-large errors, then surely we need a way to communicate what is not too large. Also, while I think a max frame size should be optional to declare, I think= that once it is declared it should be mandatory for senders to respect tha= t limit. > That said, such a negotiation might be crucial to an effective multiplexi= ng scheme. =A0I suggest that this be deferred and included as part of the m= ultiplexing work. I think it is more than just MUX that needs this. Because of the datagram = style API of websockets, applications will not be stream based (blocked rea= ding content), but will be called back when frames and/or messages are rece= ived. Thus there will be implementations that have fixed buffer sizes and = will not work with large frames and/or messages. For large messages, there is not much the implementations can do to influence the applications, so I don't see a limi= t being worthwhile. But for a max frame size, it is pretty simple for impl= ementations to fragment messages to respect a limit. regards _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From ferg@caucho.com Wed Aug 3 10:18: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 7B14221F8B1B for ; Wed, 3 Aug 2011 10:18:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZyz1Yfe4e2A for ; Wed, 3 Aug 2011 10:18:34 -0700 (PDT) Received: from nm9.access.bullet.mail.mud.yahoo.com (nm9.access.bullet.mail.mud.yahoo.com [66.94.237.210]) by ietfa.amsl.com (Postfix) with SMTP id B1CA321F8AFA for ; Wed, 3 Aug 2011 10:18:34 -0700 (PDT) Received: from [66.94.237.197] by nm9.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Aug 2011 17:18:44 -0000 Received: from [98.139.221.43] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 03 Aug 2011 17:18:44 -0000 Received: from [127.0.0.1] by smtp105.biz.mail.bf1.yahoo.com with NNFMP; 03 Aug 2011 17:18:44 -0000 X-Yahoo-Newman-Id: 258744.22776.bm@smtp105.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: iDFnZuAVM1nAEpPFzhOO70CgIjkT98rGY6FBmcwacAGx0U8 KTdVltH97MtJ6dXyUeZvVXGNGZ3M9RKE0oO_9B6TCRI6TO7aQfjBK_c_DmcQ 85.C51pSNipE9tTLJEPcRloOEIPiKXvj6Y_2nAC6Zkn7NZsTyt7pytn0hXR_ WBT2OlXbGHu5.cMTB56yIAc7a4FkiCVUaE.qxfZsed9CMsCTROZfkfkpPzo_ 7uwkGhOF5te4FmJe1vzg5kBZMVb2wOcAUBRXZHHu69cQuha_DajMUiEG13C9 3_Q55izZSiuTbpn47IovIgTqe21rArdcvaCUmw1OiwKSR9VEIjvoxgHhb2p7 tvitYpzSe.s5azkVAuW.cYwf6LNSPeDNZojUcOdPBkVdFcNKCqjRl2rFnL9H UyU9QKKpmMvDl X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp105.biz.mail.bf1.yahoo.com with SMTP; 03 Aug 2011 10:18:43 -0700 PDT Message-ID: <4E3982F2.1080808@caucho.com> Date: Wed, 03 Aug 2011 10:18:42 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 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 Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 03 Aug 2011 17:18:35 -0000 On 08/03/2011 09:55 AM, Piotr Kulaga wrote: > Can you please explain why we may need a size limit on a frame? It does not really makes sense to me - if a frame is too big for you for some reasons, act as intermediary and split single frame into multiple ones (assuming you understand extensions, which should be very common). > > I see some benefits in having a limit on a message size i.e. you can easily provide a message based APIs. However, as you mentioned stream APIs are a norm in HTTP world and personally I do not see a reason for any limits on message/frame size. +1 Also, as was already pointed out, since any mux extension will need a max frame size, it will be better to defer frame-size limits to the mux discussion. Otherwise, there will be multiple frame-size limitations floating around: one that's properly designed for mux, and one that's half-baked. -- Scott > Kind regards, > Piotr > > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg Wilkins > Sent: Saturday, July 30, 2011 5:40 PM > To: Hybi > Subject: [hybi] max frame size. was: consensus call on ability to announce max frame size > > Changing topic to avoid debate in consensus call thread. > > > > > On 30 July 2011 17:46, John Tamplin wrote: >> I see no mention of maximum message size in this consensus call, only >> maximum frame size. > Sorry if that muddied the water. But I just wanted to be crystal clear we are talking about frames not messages. > > > On 30 July 2011 17:31, Willy Tarreau wrote: >> I'd also argue that HTTP has been living for a decade with support for >> chunked encoding which does not set a limit on chunk size nor on >> message size and has not had any trouble with that. > But HTTP also does not have a chunk-too-large error code. > Implementations are forced to deal with large chunks. This is often > no too difficult because stream APIs are the norm for HTTP. Large > sizes are harder to handle in the datagram API of websocket. > > > On 30 July 2011 23:34, Thomson, Martin wrote: >> Given that there is no constraint on message size, this capability is pointless. Any peer that receives this indication does not need to change their behaviour in any meaningful way. Messages of any size can be sent regardless of what frame size is supported. > Note sure if you are talking about max message or max frame size? > > But a peer that does not respect a max frame indication and does not change it's behaviour will then just receive frame-too-large errors in > response. If we allow frame-too-large errors, then surely we need a > way to communicate what is not too large. > > Also, while I think a max frame size should be optional to declare, I think that once it is declared it should be mandatory for senders to respect that limit. > > > >> That said, such a negotiation might be crucial to an effective multiplexing scheme. I suggest that this be deferred and included as part of the multiplexing work. > I think it is more than just MUX that needs this. Because of the datagram style API of websockets, applications will not be stream based (blocked reading content), but will be called back when frames and/or messages are received. Thus there will be implementations that have fixed buffer sizes and will not work with large frames and/or > messages. For large messages, there is not much the > implementations can do to influence the applications, so I don't see a limit being worthwhile. But for a max frame size, it is pretty simple for implementations to fragment messages to respect a limit. > > > regards > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > From pmcmanus@mozilla.com Wed Aug 3 13:27: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 C809C21F855B for ; Wed, 3 Aug 2011 13:27:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 m0fnx-onkc+U for ; Wed, 3 Aug 2011 13:27:28 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5629821F8506 for ; Wed, 3 Aug 2011 13:27:28 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 7A52810194; Wed, 3 Aug 2011 16:27:39 -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 2EE5210190 for ; Wed, 3 Aug 2011 16:27:36 -0400 (EDT) From: Patrick McManus To: Server-Initiated HTTP In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Wed, 03 Aug 2011 16:27:34 -0400 Message-ID: <1312403254.1816.23.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Subject: Re: [hybi] consensus call on removing deflate-stream 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, 03 Aug 2011 20:27:28 -0000 On Sat, 2011-07-30 at 03:40 +0000, Gabriel Montenegro wrote: > At the meeting and on the mailing list leading up to it, the chairs > saw consensus for the following action: > > > > Remove deflate-stream from the websocket protocol > specification. > > > > We’re confirming on the mailing list, and will declare this consensus > call final by next Friday Aug 5. > > I'm opposed. We shouldn't issue a protocol without a compression component and the one we have is valuable in a number of circumstances despite its obvious short comings. In my opinion it should not be removed without simultaneously publishing (perhaps in a separate document, perhaps not) a superior replacement. From tyoshino@google.com Wed Aug 3 23:51:36 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 75A4B21F8777 for ; Wed, 3 Aug 2011 23:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.476 X-Spam-Level: X-Spam-Status: No, score=-105.476 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_BACKHAIR_34=1, 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 AOFcJ11GnUt1 for ; Wed, 3 Aug 2011 23:51:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id D11F721F8760 for ; Wed, 3 Aug 2011 23:51:35 -0700 (PDT) Received: from kpbe18.cbf.corp.google.com (kpbe18.cbf.corp.google.com [172.25.105.82]) by smtp-out.google.com with ESMTP id p746pnv1002250 for ; Wed, 3 Aug 2011 23:51:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312440709; bh=gHR+VS5ldLLelH+EaAeDvKupW3c=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=J2BVfR+/PtZUhiGptUwUjRVhuIXVmJZ2iaY2m6HNV4UM17TOj1xMHKO1bW2rL+H1g iq1N21XOichkUQh+tD3og== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:from:date:message-id:subject:to: content-type:x-system-of-record; b=VKcdi8+Mjvv3Adc4O86I89NdfntRnDkb1dGNBISLMmJ67pu1Oq43QwDjNxRnIsYBy ycPba5eazaDe2wuxmhFXg== Received: from ywm39 (ywm39.prod.google.com [10.192.13.39]) by kpbe18.cbf.corp.google.com with ESMTP id p746pgR6018450 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 3 Aug 2011 23:51:48 -0700 Received: by ywm39 with SMTP id 39so1116043ywm.13 for ; Wed, 03 Aug 2011 23:51:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type; bh=/FUrPMJDxFC8FF9u/WbTpgezIRYIl0b+i4uZ+j8IR7s=; b=DHNukg32LjzXO+TuFzC3wgCb8HRagZ9hC9bTh8o/z/hEb0/IsSpG2sC15q8wH1Kk/N GD4BrpXMOeCxu55O4tOA== Received: by 10.150.62.6 with SMTP id k6mr1552210yba.114.1312440706081; Wed, 03 Aug 2011 23:51:46 -0700 (PDT) Received: by 10.150.62.6 with SMTP id k6mr1552186yba.114.1312440704105; Wed, 03 Aug 2011 23:51:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Wed, 3 Aug 2011 23:51:24 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 4 Aug 2011 15:51:24 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=000e0cd47baaf4fea104a9a86981 X-System-Of-Record: true Subject: [hybi] Per-frame compression extension proposal X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 06:51:36 -0000 --000e0cd47baaf4fea104a9a86981 Content-Type: text/plain; charset=ISO-8859-1 Hi, Creating a new thread to get attention. I've been working on per-frame compression extension spec based on Patrick's original onewith input from this thread in response to objections to deflate-stream we see on the list. Here's the latest draft of per-frame deflate compression extension for WebSocket. http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-04 Please take a look if you're interested in. We have working implementation of this proposal in pywebsocket. I'm glad if some other vendors/people have a try on this. Thanks, Takeshi --000e0cd47baaf4fea104a9a86981 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Creating a new thread to get attention.

I've been working on per-frame compression exte= nsion spec based on Patrick's original one with input from this t= hread=A0in response to objections to deflate-stream we see on the list.=

Here's the latest draft of per-frame deflate compre= ssion extension for WebSocket.
http://tools.ietf.org/htm= l/draft-tyoshino-hybi-websocket-perframe-deflate-04

Please take a look if you're interested in.
We have working implementation of this proposal in pywebsocket= . I'm glad if some other vendors/people have a try on this.

Thanks,
Takeshi
--000e0cd47baaf4fea104a9a86981-- From bruce@callenish.com Thu Aug 4 12:01: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 3086821F8BAE for ; Thu, 4 Aug 2011 12:01:18 -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 746cjwW0N8DL for ; Thu, 4 Aug 2011 12:01:17 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 6132B5E8022 for ; Thu, 4 Aug 2011 12:01:03 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qp3AT-0000f9-Pc; Thu, 04 Aug 2011 12:01:17 -0700 Message-ID: <4E3AEC8A.8070403@callenish.com> Date: Thu, 04 Aug 2011 12:01:30 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Ferguson References: <4E3982F2.1080808@caucho.com> In-Reply-To: <4E3982F2.1080808@caucho.com> 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] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:01:18 -0000 The proposal is not to have a maximum frame limit in Websockets. The proposal is to allow a Websockets implementation to announce the maximum frame size it is able to handle. An implementation that can handle any frame size does not need to make any announcement at all. This announcement would not only allow the other endpoint to modify the size of frames it can send, it would allow an intermediary to determine the maximum size it can coalesce into a single frame. I don't understand the statement that you can split the frame. If it is too big for the implementation to handle, then it is too big to handle and the behaviour will be to drop it and send back a "Frame too large" error message. Better to let the other end know ahead of time rather than waste time sending data that will be dropped on the ground. On 03/08/2011 10:18 AM, Scott Ferguson wrote: > On 08/03/2011 09:55 AM, Piotr Kulaga wrote: >> Can you please explain why we may need a size limit on a frame? It >> does not really makes sense to me - if a frame is too big for you for >> some reasons, act as intermediary and split single frame into >> multiple ones (assuming you understand extensions, which should be >> very common). >> >> I see some benefits in having a limit on a message size i.e. you can >> easily provide a message based APIs. However, as you mentioned stream >> APIs are a norm in HTTP world and personally I do not see a reason >> for any limits on message/frame size. > > +1 > > Also, as was already pointed out, since any mux extension will need a > max frame size, it will be better to defer frame-size limits to the > mux discussion. > > Otherwise, there will be multiple frame-size limitations floating > around: one that's properly designed for mux, and one that's half-baked. > From ferg@caucho.com Thu Aug 4 12:25: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 2647F21F874B for ; Thu, 4 Aug 2011 12:25:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11] 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 838I1Hoe5ZUT for ; Thu, 4 Aug 2011 12:25:12 -0700 (PDT) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by ietfa.amsl.com (Postfix) with SMTP id 87E3A21F8726 for ; Thu, 4 Aug 2011 12:25:12 -0700 (PDT) Received: from [98.139.91.61] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 04 Aug 2011 19:25:25 -0000 Received: from [98.139.91.18] by tm1.bullet.mail.sp2.yahoo.com with NNFMP; 04 Aug 2011 19:25:25 -0000 Received: from [127.0.0.1] by omp1018.mail.sp2.yahoo.com with NNFMP; 04 Aug 2011 19:25:25 -0000 X-Yahoo-Newman-Id: 401892.87723.bm@omp1018.mail.sp2.yahoo.com Received: (qmail 64046 invoked from network); 4 Aug 2011 19:25:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312485925; bh=/lN/l7Gm16oU4TqcPBTkhYs5SyXOMan0guiZr58PXaQ=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=tdobXtR86pgDdbWgFIwIMY1CEjPvstK22mxJCRLhs7T00qD+tkHFLcJxz38TcRFDMngZNoyCnpAGfhyr5cErNcagvUE0fnllmgbN4M1HoQO4SqmKnbaa5S/CWNIcDYzgtBU7IDA7OQ9jQAXePu6KTmBAJSHKb34PV5djp70k80M= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: FnrwZNUVM1lzXQVejWZ.aV0U5brHzudcPnfV7nDA0pwJhd0 lqdEiX.XZQg5ryrOTRI_YH0kic4KaLw6sOrmJtlwcsGn4oG8tAuNfLRSCr.d VTcQCmAVRrXvLg7SbQ5uYC_cW01P50E5ik37Gtahhknf8_48iZGB2aKs6RpG DwxJzaqTUamtjO4pBi9sMxP8f6nsPWmDRivXWgm2_KZJ7_DSxaepuvdgYG7T LmaSNGJUi8o78Et9BoJLYzlgYvERSj_AyeUNFuqOs_t4tnaCll2Sir37BbHk MS3wlVkE0L7_i6_TQAz6QuZZBSKtIWf2g2xLk6DhIFqQI.vriQRJ3_i69wkf 5WQgJnrbMtmTj6Lj_txJF8Th0EPbi30hJeP7sPPOgghVXck8Gvgno2eSz9vb BEstD__V6zChgElTKGnz8tFVXamwigu4- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.sp1.yahoo.com with SMTP; 04 Aug 2011 12:25:25 -0700 PDT Message-ID: <4E3AF224.20005@caucho.com> Date: Thu, 04 Aug 2011 12:25:24 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Atherton References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> In-Reply-To: <4E3AEC8A.8070403@callenish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:25:13 -0000 On 08/04/2011 12:01 PM, Bruce Atherton wrote: > The proposal is not to have a maximum frame limit in Websockets. The > proposal is to allow a Websockets implementation to announce the > maximum frame size it is able to handle. An implementation that can > handle any frame size does not need to make any announcement at all. > > This announcement would not only allow the other endpoint to modify > the size of frames it can send, it would allow an intermediary to > determine the maximum size it can coalesce into a single frame. This isn't an important distinction. Or, rather, it illustrates the problem with defining a max-frame-size concept now. Mux will need a max frame size for flow-control reasons. It's an unavoidable concept. If the base WebSockets defines a max-frame-size concept, that definition will either conflict with the mux definition (and confuse everyone), or constrain the mux definition, possibly in an unfortunate manner. This is a problem of premature specification. > > I don't understand the statement that you can split the frame. If it > is too big for the implementation to handle, then it is too big to > handle and the behaviour will be to drop it and send back a "Frame too > large" error message. Better to let the other end know ahead of time > rather than waste time sending data that will be dropped on the ground. Well, that wasn't my comment, but it should be easy to understand. If the receiver can only handle 8k frames because it has a goofy frame-based API, and the sender sends a 16k frame, the receiver can easily pass two 8k frames to the goofy frame-based API by reading the first 8k from the socket and passing the first frame, and then reading the second 8k from the socket and passing the second frame. Since there is no message limit, sending two frames within the 8k limit to the goofy frame-based API will never be too big to handle. -- Scott > > On 03/08/2011 10:18 AM, Scott Ferguson wrote: >> On 08/03/2011 09:55 AM, Piotr Kulaga wrote: >>> Can you please explain why we may need a size limit on a frame? It >>> does not really makes sense to me - if a frame is too big for you >>> for some reasons, act as intermediary and split single frame into >>> multiple ones (assuming you understand extensions, which should be >>> very common). >>> >>> I see some benefits in having a limit on a message size i.e. you can >>> easily provide a message based APIs. However, as you mentioned >>> stream APIs are a norm in HTTP world and personally I do not see a >>> reason for any limits on message/frame size. >> >> +1 >> >> Also, as was already pointed out, since any mux extension will need a >> max frame size, it will be better to defer frame-size limits to the >> mux discussion. >> >> Otherwise, there will be multiple frame-size limitations floating >> around: one that's properly designed for mux, and one that's half-baked. >> > > > > From w@1wt.eu Thu Aug 4 12:38: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 4EFAC21F875C for ; Thu, 4 Aug 2011 12:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.289 X-Spam-Level: X-Spam-Status: No, score=-4.289 tagged_above=-999 required=5 tests=[AWL=-2.246, 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 RDC-xmbULGVY for ; Thu, 4 Aug 2011 12:38:03 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 818E321F85CA for ; Thu, 4 Aug 2011 12:38:03 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p74Jc7dK010661; Thu, 4 Aug 2011 21:38:07 +0200 Date: Thu, 4 Aug 2011 21:38:07 +0200 From: Willy Tarreau To: Scott Ferguson Message-ID: <20110804193807.GB10638@1wt.eu> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3AF224.20005@caucho.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 19:38:04 -0000 Hi Scott, On Thu, Aug 04, 2011 at 12:25:24PM -0700, Scott Ferguson wrote: > On 08/04/2011 12:01 PM, Bruce Atherton wrote: > >The proposal is not to have a maximum frame limit in Websockets. The > >proposal is to allow a Websockets implementation to announce the > >maximum frame size it is able to handle. An implementation that can > >handle any frame size does not need to make any announcement at all. > > > >This announcement would not only allow the other endpoint to modify > >the size of frames it can send, it would allow an intermediary to > >determine the maximum size it can coalesce into a single frame. > > This isn't an important distinction. > > Or, rather, it illustrates the problem with defining a max-frame-size > concept now. > > Mux will need a max frame size for flow-control reasons. It's an > unavoidable concept. > > If the base WebSockets defines a max-frame-size concept, that definition > will either conflict with the mux definition (and confuse everyone), or > constrain the mux definition, possibly in an unfortunate manner. This is > a problem of premature specification. I would see it differently : if max-frame-size is not defined now, implementations will not even consider there may exist a limit and it will be harder to make them conform to future limits imposed by mux. That's why I think that we should add provisions for a max-frame-size in the spec and more importantly the adequate action to take when this frame size is abused. Regards, Willy From ferg@caucho.com Thu Aug 4 14:06: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 8C6F211E80AA for ; Thu, 4 Aug 2011 14:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 V82XSo8JHciv for ; Thu, 4 Aug 2011 14:06:39 -0700 (PDT) Received: from nm21.bullet.mail.bf1.yahoo.com (nm21.bullet.mail.bf1.yahoo.com [98.139.212.180]) by ietfa.amsl.com (Postfix) with SMTP id E585F11E8078 for ; Thu, 4 Aug 2011 14:06:38 -0700 (PDT) Received: from [98.139.212.150] by nm21.bullet.mail.bf1.yahoo.com with NNFMP; 04 Aug 2011 21:06:54 -0000 Received: from [98.139.212.228] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 04 Aug 2011 21:06:54 -0000 Received: from [127.0.0.1] by omp1037.mail.bf1.yahoo.com with NNFMP; 04 Aug 2011 21:06:54 -0000 X-Yahoo-Newman-Id: 344650.71909.bm@omp1037.mail.bf1.yahoo.com Received: (qmail 6304 invoked from network); 4 Aug 2011 21:06:54 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312492014; bh=Winf9R4r7oNeAPSioaZqq9gxdrZSUpzQbqyZRC++a/A=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Mi8UuKivhRJQMdEldF+0UHH0V9TIR44seYKiGK+UYiuKNbbUeBL52jXu1qJBkzqlnfbv9hq1Jmtg8LM1GvlZJOyy/pbj1u1ayqQwQH/kEM5Rw7ZkK6nJXFGNgzpzVlfOoB51ubnt2pHwoFwa1NG4dkZljYmFguubihlBQ1F4etc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BAYVz.MVM1mEUfL46a.i_LIHJn8Nm6BTc6ZTJRBvJi3nQO8 iG_.NfMpMgLhruND_IDr1jWJ5UuPikghqJQkv98_C2.4rkDEV29zPGDGhonu ylXGZPsn7ZDrSo8KHWR2YKhhmf8OerckPJCex6t_U92Z.RNOWLkpT5.6h32e sPGbu9sfDpZXV6zLql4MUhuC.q8nbOk0JgW3gE5Q8fkEXtT045OKg8Fh.bOu s.MePExH7o.n464zX4YIvXIN5ZEyHvZA1lfFLbRyyv5r4QS2442LW_GsBWtz VFuzqOBRPhhs7ICwuSjpk75WNK6WlYMCWCcv32bBTFkQRKdpGNM_TQgO2p_L YWWM4RQxUjGGAroWcvc9a1KLVdmNRsqEsLs0dcS2tX4zPoKA_9OxRlMTkzSg SNWlm6gXQDa6lOxS4VZfH9DlUmPQ7l08- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp112.biz.mail.mud.yahoo.com with SMTP; 04 Aug 2011 14:06:53 -0700 PDT Message-ID: <4E3B09ED.7090201@caucho.com> Date: Thu, 04 Aug 2011 14:06:53 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Willy Tarreau References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <20110804193807.GB10638@1wt.eu> In-Reply-To: <20110804193807.GB10638@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:06:39 -0000 On 08/04/2011 12:38 PM, Willy Tarreau wrote: > > I would see it differently : if max-frame-size is not defined now, > implementations will not even consider there may exist a limit and > it will be harder to make them conform to future limits imposed by > mux. That's why I think that we should add provisions for a max-frame-size > in the spec and more importantly the adequate action to take when > this frame size is abused. Since mux might decide a max-window-size is the appropriate concept and not care about a max-frame-size, that might not be helpful. Getting mux right will be hard enough without constraints from the base WebSocket protocol. I'd prefer to give the mux group the flexibility to do the right thing. At least on the server, a mux implementation will want to be tightly integrated with a lower level, if there is a distinct lower level. So I'm not sure that giving pre-mux hints to implementations will help much. Since I think I've made my point, I'll stop here. My main point is a speculative constraint (like helping mux before it's defined) tend to cause more trouble it they solve. So if there's no compelling need for a feature, it should be postponed until the problem is better understood. -- Scott > Regards, > Willy > > > > From piotrku@microsoft.com Thu Aug 4 14:16: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 C32EB21F87C7 for ; Thu, 4 Aug 2011 14:16:28 -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 JBu0DdWcq5y1 for ; Thu, 4 Aug 2011 14:16:28 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 476FC21F8753 for ; Thu, 4 Aug 2011 14:16:28 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Thu, 4 Aug 2011 14:16:43 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.211]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.007; Thu, 4 Aug 2011 14:16:43 -0700 From: Piotr Kulaga To: Scott Ferguson , Willy Tarreau Thread-Topic: [hybi] max frame size. was: consensus call on ability to announce max frame size Thread-Index: AQHMUupzvlg0+B68Hk6daxaE/Ok/15UNMHlg Date: Thu, 4 Aug 2011 21:16:43 +0000 Message-ID: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <20110804193807.GB10638@1wt.eu> <4E3B09ED.7090201@caucho.com> In-Reply-To: <4E3B09ED.7090201@caucho.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 21:16:28 -0000 I agree with Scott. So far the only explanation why we may need max-frame-s= ize is to help mux extension. I would really refrain from defining somethin= g that may (or may not) be used by future extensions - we will be bloating = the spec without any measurable benefit. -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Sco= tt Ferguson Sent: Thursday, August 04, 2011 2:07 PM To: Willy Tarreau Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to annou= nce max frame size On 08/04/2011 12:38 PM, Willy Tarreau wrote: > > I would see it differently : if max-frame-size is not defined now,=20 > implementations will not even consider there may exist a limit and it=20 > will be harder to make them conform to future limits imposed by mux.=20 > That's why I think that we should add provisions for a max-frame-size=20 > in the spec and more importantly the adequate action to take when this=20 > frame size is abused. Since mux might decide a max-window-size is the appropriate concept and not= care about a max-frame-size, that might not be helpful. Getting mux right will be hard enough without constraints from the base Web= Socket protocol. I'd prefer to give the mux group the flexibility to do the= right thing. At least on the server, a mux implementation will want to be tightly integr= ated with a lower level, if there is a distinct lower level. So I'm not sur= e that giving pre-mux hints to implementations will help much. Since I think I've made my point, I'll stop here. My main point is a specul= ative constraint (like helping mux before it's defined) tend to cause more = trouble it they solve. So if there's no compelling need for a feature, it s= hould be postponed until the problem is better understood. -- Scott > Regards, > Willy > > > > _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From Martin.Thomson@commscope.com Thu Aug 4 16: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 B833B21F86D0 for ; Thu, 4 Aug 2011 16:06:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 Y4GPQbuK0wAD for ; Thu, 4 Aug 2011 16:06:04 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 3AD7721F86C7 for ; Thu, 4 Aug 2011 16:06:04 -0700 (PDT) X-AuditID: 0a0404e8-b7cb4ae000004e51-b4-4e3b25f47efb Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id C8.33.20049.4F52B3E4; Thu, 4 Aug 2011 18:06:28 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Thu, 4 Aug 2011 18:06:15 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 5 Aug 2011 07:06:11 +0800 From: "Thomson, Martin" To: "hybi@ietf.org" Date: Fri, 5 Aug 2011 07:06:10 +0800 Thread-Topic: Handshake complexity Thread-Index: AcxS+xk9pbaVT/faQTquGHXAep7YRg== Message-ID: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [hybi] Handshake complexity X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2011 23:06:04 -0000 The purpose of the handshake in thewebsocketprotocol is to upgrade the prot= ocol with the maximum likelihood that the server and any intermediaries bot= h understood the request and support the protocol. Aside from the handshake, thewebsocketprotocol could be implemented using v= ery little software, apart from two pieces in the handshake: Base64 and SHA= -1. The only real requirement here is that the server does something predictabl= e to the response. The complexity of the handshake is unwarranted. This i= s especially true when the server is already providing a number of other in= dications that it understood the request. I therefore propose that a simpler approach be taken. A "sec-websocket-key" header contains a random 10 digit integer. (ABNF =3D= 1*10DIGIT). A server that understand the upgrade returns a "sec-websocket= -accept" header with the same value, plus 77 (ABNF =3D "1" 1*10DIGIT). From w@1wt.eu Thu Aug 4 22:23:36 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 4C9B421F875E for ; Thu, 4 Aug 2011 22:23:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.263 X-Spam-Level: X-Spam-Status: No, score=-4.263 tagged_above=-999 required=5 tests=[AWL=-2.220, 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 I+-JWBKQOrz8 for ; Thu, 4 Aug 2011 22:23:35 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 723D321F858D for ; Thu, 4 Aug 2011 22:23:34 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p755NhoV012499; Fri, 5 Aug 2011 07:23:43 +0200 Date: Fri, 5 Aug 2011 07:23:43 +0200 From: Willy Tarreau To: Piotr Kulaga Message-ID: <20110805052343.GD10638@1wt.eu> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <20110804193807.GB10638@1wt.eu> <4E3B09ED.7090201@caucho.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 05:23:36 -0000 On Thu, Aug 04, 2011 at 09:16:43PM +0000, Piotr Kulaga wrote: > I agree with Scott. So far the only explanation why we may need max-frame-size is to help mux extension. I would really refrain from defining something that may (or may not) be used by future extensions - we will be bloating the spec without any measurable benefit. I understand both of your points. At the very least we must ensure that we can define how a WS agent must react when it receives too large a frame or message, so that the other end is aware that its frame or message was rejected because it's too large. This is something important, because once we deploy mux, there will very likely be some trade-offs with minor but existing impacts on both ends. If we don't define *now* what type of abnormal condition might be encountered, it will be a lot harder to build something that does not break every assumption that was made before. With HTTP, we encounter implementation mistakes due to initially uncovered areas (eg: 1xx is followed by another response) which caused 101 to sometimes be mishandled. With WS, we took care for using a stricter definition of the protocol and even reserve bits for future use. Still some types of failures will happen and implementations must be ready to deal with them. Regards, Willy From ifette@google.com Thu Aug 4 22:54: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 B1F025E8003 for ; Thu, 4 Aug 2011 22:54:09 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 hGH9JuWnSYD3 for ; Thu, 4 Aug 2011 22:54: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 C3DE55E8002 for ; Thu, 4 Aug 2011 22:54:08 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p755sI3K016908 for ; Thu, 4 Aug 2011 22:54:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312523661; bh=CkY43WvUd28yVWbfR/xH9QFSqVI=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=Q+6TWgvaFamgRLiWNvUuNd5viTN0YwhcKx+6WFRNh74kdQBQCVgPUopYSQfViYxFs xru8uWIsLP9yxtvsgHQuw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=FIWkmbcagCYPgX2IHzlQ9sHsGIqaJZ7ZbmVDPQOIgt4Iwf9HBUWBfD6Q7ZnCAs39E wnqpciHenkiXWrJ7mfmUg== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by kpbe17.cbf.corp.google.com with ESMTP id p755sHHw009232 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 4 Aug 2011 22:54:17 -0700 Received: by qyk9 with SMTP id 9so1531459qyk.13 for ; Thu, 04 Aug 2011 22:54:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GVgAzC7p/JTKi/kDV5jafzUi2mFjEmeIVA4y+Gp8haE=; b=mwtUPM22aKBlnfnDmLQlvsGZxRYIIWTTNcqIxGQR2NOPSfgJUb+8nOKd/yIjCxdGoW bn0hR+eQdFG/RZdNxPvw== Received: by 10.229.136.10 with SMTP id p10mr1373848qct.143.1312523655547; Thu, 04 Aug 2011 22:54:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.136.10 with SMTP id p10mr1373845qct.143.1312523655356; Thu, 04 Aug 2011 22:54:15 -0700 (PDT) Received: by 10.229.137.137 with HTTP; Thu, 4 Aug 2011 22:54:15 -0700 (PDT) In-Reply-To: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> Date: Thu, 4 Aug 2011 22:54:15 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: "Thomson, Martin" Content-Type: multipart/alternative; boundary=00248c6a66463ca36904a9bbba17 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Handshake complexity X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 05:54:09 -0000 --00248c6a66463ca36904a9bbba17 Content-Type: text/plain; charset=UTF-8 We've already discussed this topic to death (please search the archive). In general people were concerned about simple computational methods (such as adding together two random numbers), and we reached consensus on using SHA-1. With all due respect you're not bringing any considerations to the table that are new (we have already discussed the complexity of SHA-1 and whether or not it creates an unacceptable barrier to implementation; the consensus was that it did not.) As such, I don't think we should re-open decisions that literally stalled this group for months, especially not when we are in last call and there is nothing new that is being raised. -Ian On Thu, Aug 4, 2011 at 4:06 PM, Thomson, Martin < Martin.Thomson@commscope.com> wrote: > The purpose of the handshake in thewebsocketprotocol is to upgrade the > protocol with the maximum likelihood that the server and any intermediaries > both understood the request and support the protocol. > > Aside from the handshake, thewebsocketprotocol could be implemented using > very little software, apart from two pieces in the handshake: Base64 and > SHA-1. > > The only real requirement here is that the server does something > predictable to the response. The complexity of the handshake is > unwarranted. This is especially true when the server is already providing a > number of other indications that it understood the request. > > I therefore propose that a simpler approach be taken. > > A "sec-websocket-key" header contains a random 10 digit integer. (ABNF = > 1*10DIGIT). A server that understand the upgrade returns a > "sec-websocket-accept" header with the same value, plus 77 (ABNF = "1" > 1*10DIGIT). > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --00248c6a66463ca36904a9bbba17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We've already discussed this topic to death (please search the archive)= . In general people were concerned about simple computational methods (such= as adding together two random numbers), and we reached consensus on using = SHA-1. With all due respect you're not bringing any considerations to t= he table that are new (we have already discussed the complexity of SHA-1 an= d whether or not it creates an unacceptable barrier to implementation; the = consensus was that it did not.) As such, I don't think we should re-ope= n decisions that literally stalled this group for months, especially not wh= en we are in last call and there is nothing new that is being raised.

-Ian

On Thu, Aug 4, 2011 a= t 4:06 PM, Thomson, Martin <Martin.Thomson@commscope.com> wrote:
The purpose of the handshake in thewebsocketprotocol is to upgrade the prot= ocol with the maximum likelihood that the server and any intermediaries bot= h understood the request and support the protocol.

Aside from the handshake, thewebsocketprotocol could be implemented using v= ery little software, apart from two pieces in the handshake: Base64 and SHA= -1.

The only real requirement here is that the server does something predictabl= e to the response. =C2=A0The complexity of the handshake is unwarranted. = =C2=A0This is especially true when the server is already providing a number= of other indications that it understood the request.

I therefore propose that a simpler approach be taken.

A "sec-websocket-key" header contains a random 10 digit integer. = =C2=A0(ABNF =3D 1*10DIGIT). =C2=A0A server that understand the upgrade retu= rns a "sec-websocket-accept" header with the same value, plus 77 = (ABNF =3D "1" 1*10DIGIT).




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

--00248c6a66463ca36904a9bbba17-- From w@1wt.eu Thu Aug 4 23:02: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 8D64421F884F for ; Thu, 4 Aug 2011 23:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.238 X-Spam-Level: X-Spam-Status: No, score=-4.238 tagged_above=-999 required=5 tests=[AWL=-2.195, 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 Qac3AfPAUdUO for ; Thu, 4 Aug 2011 23:02:14 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id C6B4321F884C for ; Thu, 4 Aug 2011 23:02:13 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p7562QNk012666; Fri, 5 Aug 2011 08:02:26 +0200 Date: Fri, 5 Aug 2011 08:02:26 +0200 From: Willy Tarreau To: "Ian Fette (????????????????????????)" Message-ID: <20110805060226.GE10638@1wt.eu> References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Handshake complexity 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, 05 Aug 2011 06:02:14 -0000 On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette (????????????????????????) wrote: > We've already discussed this topic to death (please search the archive). In > general people were concerned about simple computational methods (such as > adding together two random numbers), and we reached consensus on using > SHA-1. With all due respect you're not bringing any considerations to the > table that are new (we have already discussed the complexity of SHA-1 and > whether or not it creates an unacceptable barrier to implementation; the > consensus was that it did not.) As such, I don't think we should re-open > decisions that literally stalled this group for months, especially not when > we are in last call and there is nothing new that is being raised. I would honnestly say that the minor new element that came since this endless discussion is that at that time it was speculated that using a SHA-1 library in implementations should not be difficult since SHA-1 is freely available. Now we have some WS implementations and we should check if they encountered unexpected difficulties in using SHA-1. I don't think so and Martin's mail makes me think it's more a matter of discomfort caused by needless software dependencies. But if some implementers were bringing real implementation issues due to the use of SHA-1, we should try to find how to address them. My personal feeling has always been that this was a bit over-engineered but well, we managed to reach a consensus. Regards, Willy From ifette@google.com Thu Aug 4 23:04: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 B03155E8008 for ; Thu, 4 Aug 2011 23:04:16 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 jMk1ugEDnTgg for ; Thu, 4 Aug 2011 23:04:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 090475E8007 for ; Thu, 4 Aug 2011 23:04:15 -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 p7564W7V000443 for ; Thu, 4 Aug 2011 23:04:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312524272; bh=aLZZ9OKLJo2BHhUHybZYJX8obq0=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=M8BCl42K5mKgCGPePP9fu0RNDJVR72KvRGzz11aIagj5foZXx3LRT/mxrN6I7/rkI ymcyxaovC0tfLE7pC62MA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=oamsMP3scczJCAfzX8hlYMApSKHZ2Zs/q3gcKs7awV/04IiD0Tpg76p4Ul3D9xgeh qjjimEExrbP+ucEz8z9CQ== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by wpaz5.hot.corp.google.com with ESMTP id p7564CF0022951 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 4 Aug 2011 23:04:31 -0700 Received: by qyk9 with SMTP id 9so1534956qyk.13 for ; Thu, 04 Aug 2011 23:04:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=YJPCdqRkHGXFpBXH/oaao/bUn/Dx5ygZwwVhimPLhoA=; b=usBBr03l8jRz2E6qgur0FBAt9QG5mi02BX52e2PrqKCX2/IJ2dfLhyu3JQSdFMMWjZ 1ei3XJypIzRJWbySWVhg== Received: by 10.229.229.130 with SMTP id ji2mr1360581qcb.67.1312524271261; Thu, 04 Aug 2011 23:04:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.229.130 with SMTP id ji2mr1360576qcb.67.1312524271117; Thu, 04 Aug 2011 23:04:31 -0700 (PDT) Received: by 10.229.137.137 with HTTP; Thu, 4 Aug 2011 23:04:31 -0700 (PDT) In-Reply-To: <20110805060226.GE10638@1wt.eu> References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> <20110805060226.GE10638@1wt.eu> Date: Thu, 4 Aug 2011 23:04:31 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Willy Tarreau Content-Type: multipart/alternative; boundary=0016363b8e66f067b604a9bbdee7 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Handshake complexity X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 06:04:16 -0000 --0016363b8e66f067b604a9bbdee7 Content-Type: text/plain; charset=UTF-8 On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau wrote: > On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette > (????????????????????????) wrote: > > We've already discussed this topic to death (please search the archive). > In > > general people were concerned about simple computational methods (such as > > adding together two random numbers), and we reached consensus on using > > SHA-1. With all due respect you're not bringing any considerations to the > > table that are new (we have already discussed the complexity of SHA-1 and > > whether or not it creates an unacceptable barrier to implementation; the > > consensus was that it did not.) As such, I don't think we should re-open > > decisions that literally stalled this group for months, especially not > when > > we are in last call and there is nothing new that is being raised. > > I would honnestly say that the minor new element that came since this > endless discussion is that at that time it was speculated that using > a SHA-1 library in implementations should not be difficult since SHA-1 > is freely available. Now we have some WS implementations and we should > check if they encountered unexpected difficulties in using SHA-1. I don't > think so and Martin's mail makes me think it's more a matter of discomfort > caused by needless software dependencies. But if some implementers were > bringing real implementation issues due to the use of SHA-1, we should > try to find how to address them. My personal feeling has always been that > this was a bit over-engineered but well, we managed to reach a consensus. > We managed it in Chrome FWIW :) > > Regards, > Willy > > --0016363b8e66f067b604a9bbdee7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau <= span dir=3D"ltr"><w@1wt.eu> wr= ote:
On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette (????= ????????????????????) wrote:
> We've already discussed this topic to death (please search the arc= hive). In
> general people were concerned about simple computational methods (such= as
> adding together two random numbers), and we reached consensus on using=
> SHA-1. With all due respect you're not bringing any considerations= to the
> table that are new (we have already discussed the complexity of SHA-1 = and
> whether or not it creates an unacceptable barrier to implementation; t= he
> consensus was that it did not.) As such, I don't think we should r= e-open
> decisions that literally stalled this group for months, especially not= when
> we are in last call and there is nothing new that is being raised.

I would honnestly say that the minor new element that came since this=
endless discussion is that at that time it was speculated that using
a SHA-1 library in implementations should not be difficult since SHA-1
is freely available. Now we have some WS implementations and we should
check if they encountered unexpected difficulties in using SHA-1. I don'= ;t
think so and Martin's mail makes me think it's more a matter of dis= comfort
caused by needless software dependencies. But if some implementers were
bringing real implementation issues due to the use of SHA-1, we should
try to find how to address them. My personal feeling has always been that this was a bit over-engineered but well, we managed to reach a consensus.

We managed it in Chrome FWIW :)
=C2=A0

Regards,
Willy


--0016363b8e66f067b604a9bbdee7-- From w@1wt.eu Thu Aug 4 23:10: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 DF3095E8007 for ; Thu, 4 Aug 2011 23:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.214 X-Spam-Level: X-Spam-Status: No, score=-4.214 tagged_above=-999 required=5 tests=[AWL=-2.171, 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 zfvWF176OmlA for ; Thu, 4 Aug 2011 23:10:15 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 0983A5E800E for ; Thu, 4 Aug 2011 23:10:14 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p756ACLP012701; Fri, 5 Aug 2011 08:10:12 +0200 Date: Fri, 5 Aug 2011 08:10:12 +0200 From: Willy Tarreau To: "Ian Fette (????????????????????????)" Message-ID: <20110805061012.GF10638@1wt.eu> References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> <20110805060226.GE10638@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] Handshake complexity 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, 05 Aug 2011 06:10:16 -0000 On Thu, Aug 04, 2011 at 11:04:31PM -0700, Ian Fette (????????????????????????) wrote: > On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau wrote: > > > On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette > > (????????????????????????) wrote: > > > We've already discussed this topic to death (please search the archive). > > In > > > general people were concerned about simple computational methods (such as > > > adding together two random numbers), and we reached consensus on using > > > SHA-1. With all due respect you're not bringing any considerations to the > > > table that are new (we have already discussed the complexity of SHA-1 and > > > whether or not it creates an unacceptable barrier to implementation; the > > > consensus was that it did not.) As such, I don't think we should re-open > > > decisions that literally stalled this group for months, especially not > > when > > > we are in last call and there is nothing new that is being raised. > > > > I would honnestly say that the minor new element that came since this > > endless discussion is that at that time it was speculated that using > > a SHA-1 library in implementations should not be difficult since SHA-1 > > is freely available. Now we have some WS implementations and we should > > check if they encountered unexpected difficulties in using SHA-1. I don't > > think so and Martin's mail makes me think it's more a matter of discomfort > > caused by needless software dependencies. But if some implementers were > > bringing real implementation issues due to the use of SHA-1, we should > > try to find how to address them. My personal feeling has always been that > > this was a bit over-engineered but well, we managed to reach a consensus. > > > > We managed it in Chrome FWIW :) I'm not worried about the use of SHA-1 in browsers nor servers where crypto is already available. I'm thinking more about the small devices Hixie was targetting where SHA-1 would come with a big cost or with real implementation issues (eg: 16-bit devices for which there is no SHA-1 implementation). But I really don't believe that the same devices will use this protocol either. Regards, Willy From salvatore.loreto@ericsson.com Fri Aug 5 04:03: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 46AB521F8B54 for ; Fri, 5 Aug 2011 04:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.574 X-Spam-Level: X-Spam-Status: No, score=-106.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 Tb3IMbuTqJiq for ; Fri, 5 Aug 2011 04:03:13 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2B03C21F8B46 for ; Fri, 5 Aug 2011 04:03:12 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-3f-4e3bce007a41 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id CA.0D.09774.00ECB3E4; Fri, 5 Aug 2011 13:03:28 +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, 5 Aug 2011 13:03:28 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 46C0C24D8 for ; Fri, 5 Aug 2011 14:03:28 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 00DAB512C1 for ; Fri, 5 Aug 2011 14:03:28 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id EA70C512C0 for ; Fri, 5 Aug 2011 14:03:25 +0300 (EEST) Message-ID: <4E3BCDFB.8020006@ericsson.com> Date: Fri, 5 Aug 2011 14:03:23 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: hybi@ietf.org References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> <20110805060226.GE10638@1wt.eu> <20110805061012.GF10638@1wt.eu> In-Reply-To: <20110805061012.GF10638@1wt.eu> 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] Handshake complexity 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, 05 Aug 2011 11:03:17 -0000 (as individual) we agreed on the SHA-1 time ago after a long... discussion and honestly I don't see any new element worth enough to reopen it. We have already several implementations, browsers, servers, libraries etc and nobody of the people implementing the protocol has found particular difficulties on this particular aspect, as far as I know. cheers /Sal On 8/5/11 9:10 AM, Willy Tarreau wrote: > On Thu, Aug 04, 2011 at 11:04:31PM -0700, Ian Fette (????????????????????????) wrote: >> On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau wrote: >> >>> On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette >>> (????????????????????????) wrote: >>>> We've already discussed this topic to death (please search the archive). >>> In >>>> general people were concerned about simple computational methods (such as >>>> adding together two random numbers), and we reached consensus on using >>>> SHA-1. With all due respect you're not bringing any considerations to the >>>> table that are new (we have already discussed the complexity of SHA-1 and >>>> whether or not it creates an unacceptable barrier to implementation; the >>>> consensus was that it did not.) As such, I don't think we should re-open >>>> decisions that literally stalled this group for months, especially not >>> when >>>> we are in last call and there is nothing new that is being raised. >>> I would honnestly say that the minor new element that came since this >>> endless discussion is that at that time it was speculated that using >>> a SHA-1 library in implementations should not be difficult since SHA-1 >>> is freely available. Now we have some WS implementations and we should >>> check if they encountered unexpected difficulties in using SHA-1. I don't >>> think so and Martin's mail makes me think it's more a matter of discomfort >>> caused by needless software dependencies. But if some implementers were >>> bringing real implementation issues due to the use of SHA-1, we should >>> try to find how to address them. My personal feeling has always been that >>> this was a bit over-engineered but well, we managed to reach a consensus. >>> >> We managed it in Chrome FWIW :) > I'm not worried about the use of SHA-1 in browsers nor servers where crypto > is already available. I'm thinking more about the small devices Hixie was > targetting where SHA-1 would come with a big cost or with real implementation > issues (eg: 16-bit devices for which there is no SHA-1 implementation). But > I really don't believe that the same devices will use this protocol either. > > Regards, > Willy > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From salvatore.loreto@ericsson.com Fri Aug 5 04:07: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 7E86D21F8BB9 for ; Fri, 5 Aug 2011 04:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 QCsChdicVPBX for ; Fri, 5 Aug 2011 04:07:19 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0667B21F8BAD for ; Fri, 5 Aug 2011 04:07:18 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-ad-4e3bcef7b57e Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 9A.9D.09774.7FECB3E4; Fri, 5 Aug 2011 13:07:35 +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; Fri, 5 Aug 2011 13:07:34 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 2B19624D8 for ; Fri, 5 Aug 2011 14:07:35 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E8736512C1 for ; Fri, 5 Aug 2011 14:07:34 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9FBA6512C0 for ; Fri, 5 Aug 2011 14:07:31 +0300 (EEST) Message-ID: <4E3BCEF2.7030400@ericsson.com> Date: Fri, 5 Aug 2011 14:07:30 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 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-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] websocket test suite 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, 05 Aug 2011 11:07:23 -0000 On 7/29/11 3:02 AM, Greg Wilkins wrote: > So firstly, does anybody have suggestions of good tests suites > specified for other IETF efforts that we could use as a model to base > our tests on? Hi Greg and all, I asked Larry Masinter about some good link, and he told me that http://www.ietf.org/iesg/implementation-report.html has all of the IETF implementation reports, including the one for HTTP: http://www.ietf.org/iesg/implementation/report-http-v11-spec-rev.txt cheers /Sal -- Salvatore Loreto www.sloreto.com From bruce@callenish.com Fri Aug 5 08:13: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 596DA21F8B95 for ; Fri, 5 Aug 2011 08:13: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=[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 OCjRwN5kiwhQ for ; Fri, 5 Aug 2011 08:13:51 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id C278E21F8BB6 for ; Fri, 5 Aug 2011 08:13:51 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpM5q-0006L4-Nc; Fri, 05 Aug 2011 08:13:46 -0700 Message-ID: <4E3C08B8.50202@callenish.com> Date: Fri, 05 Aug 2011 08:14:00 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Ferguson References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> In-Reply-To: <4E3AF224.20005@caucho.com> 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] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 15:13:52 -0000 On 04/08/2011 12:25 PM, Scott Ferguson wrote: > On 08/04/2011 12:01 PM, Bruce Atherton wrote: >> The proposal is not to have a maximum frame limit in Websockets. The >> proposal is to allow a Websockets implementation to announce the >> maximum frame size it is able to handle. An implementation that can >> handle any frame size does not need to make any announcement at all. >> >> This announcement would not only allow the other endpoint to modify >> the size of frames it can send, it would allow an intermediary to >> determine the maximum size it can coalesce into a single frame. > > This isn't an important distinction. > > Or, rather, it illustrates the problem with defining a max-frame-size > concept now. > > Mux will need a max frame size for flow-control reasons. It's an > unavoidable concept. We seem to be talking past each other. I am not talking about the application layer or any extensions, I am talking about the core Websockets implementation. Pretend Mux will never exist. The core protocol still should allow implementations to communicate the limits they can handle for frame size rather than sending a bunch of data that will end up being wasted. What is the downside to allowing that? > > If the base WebSockets defines a max-frame-size concept, that > definition will either conflict with the mux definition (and confuse > everyone), or constrain the mux definition, possibly in an unfortunate > manner. This is a problem of premature specification. Base Websockets would NOT be defining a max-frame-size concept (other than the 63 bit payload length) for the protocol, it would just allow an implementation to specify it. It would be allowing implementations to communicate about limitations that might affect the other end before work is wasted. This is no different than other kinds of limitations that implementations might send each other, like what extensions they can handle or the version of the protocol they speak. Even if Mux ends up being defined to have a maximum frame size of 32K, an implementation that can only handle an 8K frame size can never work with a frame larger than that. > > If the receiver can only handle 8k frames because it has a goofy > frame-based API, and the sender sends a 16k frame, the receiver can > easily pass two 8k frames to the goofy frame-based API by reading the > first 8k from the socket and passing the first frame, and then reading > the second 8k from the socket and passing the second frame. Again, we are not talking about the application layer. There is no API in this discussion, goofy or not. We are talking about a Websockets implementation that chooses an 8K buffer size to accept frames, and chooses not to buffer multiple blocks for a frame because they do not want to allow the other side to launch a denial of service attack. How the server exposes the data in the buffer to the application is outside of the scope of this specification. Maybe it is a goofy frame API, maybe a stream, maybe through lazy messages. Whatever it is, it is not our problem. From gezelter@rlgsc.com Fri Aug 5 08:40: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 06C5921F8B4D for ; Fri, 5 Aug 2011 08:40: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 MWLRfi9n1D7W for ; Fri, 5 Aug 2011 08:40:00 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 389B921F8B14 for ; Fri, 5 Aug 2011 08:40:00 -0700 (PDT) Received: (qmail 5818 invoked from network); 5 Aug 2011 15:40:17 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 5 Aug 2011 15:40:17 -0000 Received: (qmail 29131 invoked by uid 99); 5 Aug 2011 15:40:17 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.216.115 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110805084016.ef1fc80126c74c6c202a919c41c7bb0b.0ff8b1dfff.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Fri, 05 Aug 2011 08:40:16 -0700 Mime-Version: 1.0 Subject: [hybi] Last Call Questions: Frame sizes, deflate, SRV records; Use of SHA-1 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, 05 Aug 2011 15:40:01 -0000 It would be useful if the WebSocket protocol contained a mechanism to=0Adec= lare (and verify) the maximum sizes of the frames in a channel. It=0Ashould= be noted that capping frame size is a function of all of the=0Aparties in = the protocol path, not just the protocol endpoints. As such,=0Ait needs to = be specified as the maximum that each link in the chain=0A(including proxie= s or other intermediaries that have visibility into the=0AWebSocket protoco= l) are willing and able to accommodate. =0A=0AThat said, the large frame si= zes are, IMHO, almost an irrelevancy. They=0Ado not significantly contribut= e to the efficiency of the channel, and=0Aincrease latency for other data. = The per-frame overhead is less than 16=0Abytes. For significant frame sizes= (e.g., tens of Kbytes), frame=0Aoverhead is simply not statistically signi= ficant. There is already no=0Acorrelation between the packet size of the un= derlying network, and the=0Aframe size. The WebSocket protocol is defined t= o run with an underlying=0Aprotocol that already provides an extremely low-= error, sequence assured,=0Abi-directional communications path (Note: I stat= e "low error", as the=0ATCP and IP checksums are known to be relatively wea= k).=0A=0AI have already noted that "deflate" is of limited utility when app= lied=0Ato already masked data, thus I support removing deflate from the=0AW= ebSocket protocol. IMHO, compression is properly a part of multiplexing=0As= cheme, which I believe will be needed. Compression schemes work well=0Awith= correlated data, which would correspond to the individual=0Amultiplexed su= b-channels.=0A=0AIdentification of service endpoints is one of the weaker a= reas of the=0AInternet ecosystem. Requiring clients to make appropriate que= ries, and=0Aleaving server managers the options and flexibility to utilize = those=0Aoptions is a low-impact choice in line with the "Generate strictly;= =0Aaccept liberally" gestalt that has often been successful in the Internet= =0Aspace. I see no great impact on requiring clients to check for relevant= =0ASRV records, and thus support the inclusion of SRV records resolution in= =0Athe WebSocket protocol.=0A=0AFinally, on the subject of SHA-1, I have no= objections. I am not sure=0Athat I with the reasoning behind the choice. M= y lack of agreement is=0Athat in today's environment, I am not sure that th= e process is a gain.=0AOn the subject of 16-bit implementations, speaking a= s a 30+ year systems=0Aprogrammer with corresponding expertise in both high= -level and=0Aassembler-level languages, I frankly to not see an issue for a= ll but the=0Asmallest of embedded micro-controllers, with the exception of = power=0Adepletion on portable, wireless devices. If anyone feels that the= =0Aimplementation of SHA-1 on less than a 32-bit processor is a significant= =0Aproblem, I will invite them to contact me off list.=0A=0AI previously di= scussed some issues relating to the above points a blog=0Aarticle entitled = ""The WebSocket Protocol: Past Travails Are To Be=0AAvoided" (see http://rl= gsc.com/r/20110323.html).=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From piotrku@microsoft.com Fri Aug 5 09: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 5E6F821F8C1E for ; Fri, 5 Aug 2011 09:02:34 -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 61vEFVVwMR2x for ; Fri, 5 Aug 2011 09:02:33 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id BB41121F8C13 for ; Fri, 5 Aug 2011 09:02:33 -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; Fri, 5 Aug 2011 09:02:51 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.211]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 09:02:51 -0700 From: Piotr Kulaga To: Bruce Atherton , Scott Ferguson Thread-Topic: [hybi] max frame size. was: consensus call on ability to announce max frame size Thread-Index: AQHMUgFuOPxTLDTN3ky3QhFkiNmippUNgywAgAAGrQCAAUwYAP//lBxg Date: Fri, 5 Aug 2011 16:02:50 +0000 Message-ID: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> In-Reply-To: <4E3C08B8.50202@callenish.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:02:34 -0000 I do not understand your argument. Assuming that there is no goofy API laye= r, why would you like to buffer anything? If you are not buffering, then yo= u do not care if the frame is 8K or 8M. Exposing frame boundaries to the up= per layer does not make sense, as the boundaries can be changed by intermed= iaries, so they do not carry any information for upper layers (as opposed t= o messages, which boundaries must be preserved). -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Bru= ce Atherton Sent: Friday, August 05, 2011 8:14 AM To: Scott Ferguson Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to annou= nce max frame size On 04/08/2011 12:25 PM, Scott Ferguson wrote: > On 08/04/2011 12:01 PM, Bruce Atherton wrote: >> The proposal is not to have a maximum frame limit in Websockets. The=20 >> proposal is to allow a Websockets implementation to announce the=20 >> maximum frame size it is able to handle. An implementation that can=20 >> handle any frame size does not need to make any announcement at all. >> >> This announcement would not only allow the other endpoint to modify=20 >> the size of frames it can send, it would allow an intermediary to=20 >> determine the maximum size it can coalesce into a single frame. > > This isn't an important distinction. > > Or, rather, it illustrates the problem with defining a max-frame-size=20 > concept now. > > Mux will need a max frame size for flow-control reasons. It's an=20 > unavoidable concept. We seem to be talking past each other. I am not talking about the applicati= on layer or any extensions, I am talking about the core Websockets implemen= tation. Pretend Mux will never exist. The core protocol still should allow = implementations to communicate the limits they can handle for frame size ra= ther than sending a bunch of data that will end up being wasted. What is the downside to allowing that? > > If the base WebSockets defines a max-frame-size concept, that=20 > definition will either conflict with the mux definition (and confuse=20 > everyone), or constrain the mux definition, possibly in an unfortunate=20 > manner. This is a problem of premature specification. Base Websockets would NOT be defining a max-frame-size concept (other than = the 63 bit payload length) for the protocol, it would just allow an impleme= ntation to specify it. It would be allowing implementations to communicate = about limitations that might affect the other end before work is wasted. Th= is is no different than other kinds of limitations that implementations mig= ht send each other, like what extensions they can handle or the version of = the protocol they speak. Even if Mux ends up being defined to have a maximum frame size of 32K, an i= mplementation that can only handle an 8K frame size can never work with a f= rame larger than that. > > If the receiver can only handle 8k frames because it has a goofy=20 > frame-based API, and the sender sends a 16k frame, the receiver can=20 > easily pass two 8k frames to the goofy frame-based API by reading the=20 > first 8k from the socket and passing the first frame, and then reading=20 > the second 8k from the socket and passing the second frame. Again, we are not talking about the application layer. There is no API=20 in this discussion, goofy or not. We are talking about a Websockets=20 implementation that chooses an 8K buffer size to accept frames, and=20 chooses not to buffer multiple blocks for a frame because they do not=20 want to allow the other side to launch a denial of service attack. How the server exposes the data in the buffer to the application is=20 outside of the scope of this specification. Maybe it is a goofy frame=20 API, maybe a stream, maybe through lazy messages. Whatever it is, it is=20 not our problem. _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From piotrku@microsoft.com Fri Aug 5 09:12: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 B653C21F8BF0 for ; Fri, 5 Aug 2011 09:12:02 -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 EwxzSl6PqqBP for ; Fri, 5 Aug 2011 09:12:02 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1D39521F8BEF for ; Fri, 5 Aug 2011 09:12:02 -0700 (PDT) Received: from TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 5 Aug 2011 09:12:16 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.211]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 09:12:14 -0700 From: Piotr Kulaga To: Diogo Pereira , Tobias Oberstein Thread-Topic: [hybi] consensus call on ability to announce max frame size Thread-Index: AcxQjXH+LjBnbdrvSmyIJDjwYFubbQAR9ecAAK0HgyA= Date: Fri, 5 Aug 2011 16:12:13 +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.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 05 Aug 2011 16:12:02 -0000 -1.50 for announcing frame size. So far no one (in my opinion) posted any = reasonable justification for this behavior. In my opinion this will just co= mplicate implementations instead of simplifying them (every intermediary wi= ll have to obey this limits) and bloat the spec. -0.25 for announcing message size. I see some benefits of it, but I think w= e should discuss this before moving forward. -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Dio= go Pereira Sent: Monday, August 01, 2011 3:30 PM To: Tobias Oberstein Cc: hybi@ietf.org Subject: Re: [hybi] consensus call on ability to announce max frame size On Mon, Aug 1, 2011 at 21:56, Tobias Oberstein wrote: > Why is there a need for max. frame size anyway? Good question. If the API is messaged based then the implementation has to buffer the enti= re message. A frame size limit does not help. If the API is stream based there is no buffering problem at all. If the API is frame based (and it shouldn't be), the implementation can sti= ll fairly easily perform local fragmentation. -- Diogo _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From w@1wt.eu Fri Aug 5 09:19: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 593EC21F8A7D for ; Fri, 5 Aug 2011 09:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[AWL=-2.147, 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 QVd694PVCUVI for ; Fri, 5 Aug 2011 09:19:42 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8822021F8A51 for ; Fri, 5 Aug 2011 09:19:40 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p75GJoQA015484; Fri, 5 Aug 2011 18:19:50 +0200 Date: Fri, 5 Aug 2011 18:19:50 +0200 From: Willy Tarreau To: Piotr Kulaga Message-ID: <20110805161950.GD14452@1wt.eu> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:19:42 -0000 On Fri, Aug 05, 2011 at 04:02:50PM +0000, Piotr Kulaga wrote: > I do not understand your argument. Assuming that there is no goofy API layer, why would you like to buffer anything? If you are not buffering, then you do not care if the frame is 8K or 8M. Exposing frame boundaries to the upper layer does not make sense, as the boundaries can be changed by intermediaries, so they do not carry any information for upper layers (as opposed to messages, which boundaries must be preserved). There may be a few reasons to buffer a bit when some transformation are added later (eg: for deflate-frame). But I agree that in the general case, there will be more uses of message buffering than of frame buffering. Maybe we should try to determine usefulness the other way around : assuming that there is no frame limit, any client, server or intermediary will be subject to very large frames. What type of issues could we face ? I'm currently excluding the mux case since we've all identified it and some people think that it the max-frame-size will probably not help there (though I don't necessarily agree). That way if we find some valid cases we'll know why we need max-frame-size, and if we find no valid case, let's forget about it. Regards, Willy From bruce@callenish.com Fri Aug 5 09:21:36 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 0153121F8B78 for ; Fri, 5 Aug 2011 09:21:36 -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 DLXP86+lOs3Q for ; Fri, 5 Aug 2011 09:21:35 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 8917D21F8B71 for ; Fri, 5 Aug 2011 09:21:35 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpN9j-0001kQ-HB; Fri, 05 Aug 2011 09:21:51 -0700 Message-ID: <4E3C18AE.2090603@callenish.com> Date: Fri, 05 Aug 2011 09:22:06 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Piotr Kulaga References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@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] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:21:36 -0000 On 05/08/2011 9:02 AM, Piotr Kulaga wrote: > I do not understand your argument. Assuming that there is no goofy API layer, why would you like to buffer anything? If you are not buffering, then you do not care if the frame is 8K or 8M. Exposing frame boundaries to the upper layer does not make sense, as the boundaries can be changed by intermediaries, so they do not carry any information for upper layers (as opposed to messages, which boundaries must be preserved). A stream API is still an API. I am not saying that there is no API, I am saying that what it is is not the business of this spec. From ferg@caucho.com Fri Aug 5 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 7A9E821F8ADC for ; Fri, 5 Aug 2011 09:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185] 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 NdNXpkK-fA4g for ; Fri, 5 Aug 2011 09:27:54 -0700 (PDT) Received: from nm2-vm0.bullet.mail.sp2.yahoo.com (nm2-vm0.bullet.mail.sp2.yahoo.com [98.139.91.248]) by ietfa.amsl.com (Postfix) with SMTP id A4F1A21F8ABD for ; Fri, 5 Aug 2011 09:27:53 -0700 (PDT) Received: from [98.139.91.66] by nm2.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 16:28:09 -0000 Received: from [98.139.91.45] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 16:28:09 -0000 Received: from [127.0.0.1] by omp1045.mail.sp2.yahoo.com with NNFMP; 05 Aug 2011 16:28:09 -0000 X-Yahoo-Newman-Id: 184409.72404.bm@omp1045.mail.sp2.yahoo.com Received: (qmail 58404 invoked from network); 5 Aug 2011 16:28:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312561689; bh=+vGIB3rUnzDtB17y4cjgckufnvezMXxyWPIlLhwzc3w=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=20Iqtna/ZWCeqpYor3ugnC2gYlkAjrKSeZCHmzJ9ai8WwhJKGJS0o7rb5FPhavj6Lc4hNn3SWrV7g+CyBVlG+Kq1Fp1m5TGdHutoJ29AHVAxUsG46V0pl0zAbAu/BsaUCA0/uRAcaypTUXRqaziqfwcxks17mJPE7A9oHp79LfM= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: LMt3Qd4VM1mWMqlnOq6Dg3kyZ0BsYPGQRPUI5hyuBEQyJZv Do.2IxDsPoP.MyCHH5.zwJcbR1GlZu9lwRTCb98hxkGf9YUeBp69rI0b3qkL BDDrZR00mEwvphB8mQqnGPNdj2ug00D93EWNdMC2KuYyZ7ozZu3xOcezuMXu lBeS93tsOBBJlVJuMrwEzahriPRW.Kd1A_zgNTovzVnBQuFxMmXkMr5msNgc MwXrMGYAhg5MSBP7fnXKWLGngbWbFdJQ2ElnD2ymbiiWfOBJ1.Sn9UtljgRD bbqlYnXRg9n6n5r5ARfWDFuehi5Z7C3208Ynaswmw78XOb0sqBQihb4IlzJZ ZHWwiuyZ_yqWwepeM40nU95Ht.AuuWM4FHBehI8jGOMdbsFCMZNWxvgdPROV UZjSMZfvK0aVgyUo719_Qz2R7Cgwss.k- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 05 Aug 2011 09:28:08 -0700 PDT Message-ID: <4E3C1A18.1010308@caucho.com> Date: Fri, 05 Aug 2011 09:28:08 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Bruce Atherton References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> In-Reply-To: <4E3C08B8.50202@callenish.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:27:54 -0000 On 08/05/2011 08:14 AM, Bruce Atherton wrote: > Again, we are not talking about the application layer. There is no API > in this discussion, goofy or not. We are talking about a Websockets > implementation that chooses an 8K buffer size to accept frames, and > chooses not to buffer multiple blocks for a frame because they do not > want to allow the other side to launch a denial of service attack. > > How the server exposes the data in the buffer to the application is > outside of the scope of this specification. Maybe it is a goofy frame > API, maybe a stream, maybe through lazy messages. Whatever it is, it > is not our problem. A stream based receiver can use a fixed 8k buffer to implement arbitrary-length messages and frames without the need for max-frame-size. That's how streams work. There's no unlimited buffering required. The implementation processes the message one 8k chunk at a time. If a frame is 64k, the implementation processes the data as 8 8k chunks. -- Scott From gregl.msp@gmail.com Fri Aug 5 09:36: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 74CF221F8B8D for ; Fri, 5 Aug 2011 09:36:37 -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 S03I4C7ecxF6 for ; Fri, 5 Aug 2011 09:36:37 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0ACD821F8C13 for ; Fri, 5 Aug 2011 09:36:36 -0700 (PDT) Received: by yxp4 with SMTP id 4so2146926yxp.31 for ; Fri, 05 Aug 2011 09:36:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=FR2o+pO81Dy3BugAPIwWtwDjmg9oMA41N5yK30GFCxA=; b=M3cJc7tGSlRZ4/egqKwjctTmRSGC1/UGn91Gk/HfmkWi1ES/7j/+bRlQFMS9ivoZP7 N3yE0TotFbaYJYzXmHw1QTLJsMn5BjchCtsgXLpRB1jl4AT9YeXm6x6kEOOmSVwRLf5J 1T1g/WsbSwCQDTA3sOn5kwKWJ8sXR7ikxa1zw= Received: by 10.236.155.65 with SMTP id i41mr3219552yhk.165.1312562213974; Fri, 05 Aug 2011 09:36:53 -0700 (PDT) Received: from GJL8710w (office1.championent.net [216.160.45.68]) by mx.google.com with ESMTPS id z28sm3016412yhn.49.2011.08.05.09.36.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Aug 2011 09:36:53 -0700 (PDT) From: Greg Longtin To: "hybi" References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> <20110805060226.GE10638@1wt.eu> In-Reply-To: Date: Fri, 5 Aug 2011 11:36:51 -0500 Message-ID: <4e3c1c25.a8c8ec0a.74a2.ffffd072@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcxTNY686PhMQuLyTsqiry0O2uKkjwAV/dlw Content-Language: en-us Subject: Re: [hybi] Handshake complexity - off topic 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, 05 Aug 2011 16:36:37 -0000 Speaking of Android... Greg Longtin From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of = Ian Fette (????????) Sent: Friday, August 05, 2011 01:05 A To: Willy Tarreau Cc: hybi@ietf.org Subject: Re: [hybi] Handshake complexity We managed it in Chrome FWIW :) From diogo.pereira@ist.utl.pt Fri Aug 5 09:43: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 742A521F85B2 for ; Fri, 5 Aug 2011 09:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 7U+DCZBf60Q0 for ; Fri, 5 Aug 2011 09:43:50 -0700 (PDT) Received: from smtp1.ist.utl.pt (smtp1.ist.utl.pt [IPv6:2001:690:2100:1::15]) by ietfa.amsl.com (Postfix) with ESMTP id 56DD821F850E for ; Fri, 5 Aug 2011 09:43:49 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ist.utl.pt (Postfix) with ESMTP id AB2CB70003D2 for ; Fri, 5 Aug 2011 17:44:05 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp1.ist.utl.pt ([127.0.0.1]) by localhost (smtp1.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id EQM3nupc0bpG for ; Fri, 5 Aug 2011 17:44:05 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 967E670003CD for ; Fri, 5 Aug 2011 17:44:05 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id D204A2008AF6 for ; Fri, 5 Aug 2011 17:44:04 +0100 (WEST) Received: by iye1 with SMTP id 1so3577314iye.27 for ; Fri, 05 Aug 2011 09:44:03 -0700 (PDT) Received: by 10.42.153.7 with SMTP id k7mr1894061icw.457.1312562643148; Fri, 05 Aug 2011 09:44:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Fri, 5 Aug 2011 09:43:33 -0700 (PDT) In-Reply-To: <4E3C08B8.50202@callenish.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> From: Diogo Pereira Date: Fri, 5 Aug 2011 17:43:33 +0100 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:43:50 -0000 On Fri, Aug 5, 2011 at 16:14, Bruce Atherton wrote: > We seem to be talking past each other. I am not talking about the > application layer or any extensions, I am talking about the core Websockets > implementation. Pretend Mux will never exist. The core protocol still should > allow implementations to communicate the limits they can handle for frame > size rather than sending a bunch of data that will end up being wasted. But why would an implementation be unable to handle a large frame? Again, an implementation does not have to buffer the entire frame, unless it needs to buffer the entire message, in which case the max-frame-size limit does not help. > Again, we are not talking about the application layer. There is no API in > this discussion, goofy or not. We are talking about a Websockets > implementation that chooses an 8K buffer size to accept frames, and chooses > not to buffer multiple blocks for a frame because they do not want to allow > the other side to launch a denial of service attack. If you don't want to buffer more than 8K at a time, read 8K at a time and pretend (creating a new header if needed) that those 8K are a single, complete frame. What exactly is wrong with this? -- Diogo From bruce@callenish.com Fri Aug 5 09:51:32 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 636D221F8C19 for ; Fri, 5 Aug 2011 09:51:32 -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 tEbbsRso8O3f for ; Fri, 5 Aug 2011 09:51:31 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFB721F8C10 for ; Fri, 5 Aug 2011 09:51:31 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpNci-00020s-GN; Fri, 05 Aug 2011 09:51:48 -0700 Message-ID: <4E3C1FB3.4090903@callenish.com> Date: Fri, 05 Aug 2011 09:52:03 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Ferguson References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C1A18.1010308@caucho.com> In-Reply-To: <4E3C1A18.1010308@caucho.com> 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] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:51:32 -0000 On 05/08/2011 9:28 AM, Scott Ferguson wrote: > On 08/05/2011 08:14 AM, Bruce Atherton wrote: >> Again, we are not talking about the application layer. There is no >> API in this discussion, goofy or not. We are talking about a >> Websockets implementation that chooses an 8K buffer size to accept >> frames, and chooses not to buffer multiple blocks for a frame because >> they do not want to allow the other side to launch a denial of >> service attack. >> >> How the server exposes the data in the buffer to the application is >> outside of the scope of this specification. Maybe it is a goofy frame >> API, maybe a stream, maybe through lazy messages. Whatever it is, it >> is not our problem. > > A stream based receiver can use a fixed 8k buffer to implement > arbitrary-length messages and frames without the need for > max-frame-size. That's how streams work. > > There's no unlimited buffering required. The implementation processes > the message one 8k chunk at a time. If a frame is 64k, the > implementation processes the data as 8 8k chunks. And if the frame size is 16TB and the implementation doesn't provide a stream-based API? Again we are talking past each other. My point is that if someone wants to write a client or server that can only handle frames that are no more than some arbitrary length, that should be a choice that they get to make. Why do you want to limit what an implementer can do? From jat@google.com Fri Aug 5 09:58: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 1653221F8B8E for ; Fri, 5 Aug 2011 09:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.953 X-Spam-Level: X-Spam-Status: No, score=-105.953 tagged_above=-999 required=5 tests=[AWL=0.023, 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 xE+-yh1CEo9J for ; Fri, 5 Aug 2011 09:58:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 36EFB21F8B8B for ; Fri, 5 Aug 2011 09:58:49 -0700 (PDT) Received: from kpbe20.cbf.corp.google.com (kpbe20.cbf.corp.google.com [172.25.105.84]) by smtp-out.google.com with ESMTP id p75Gx4ZH027590 for ; Fri, 5 Aug 2011 09:59:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312563545; bh=PHSVoAV4f76Jut+WWgpfbs+qOwc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tN2MhFrW/evgEuUqD62sIbU398zyyNRPcINysKKle08AV+GlwZDZrA+H0ndFx+g2N P0B0nSKGbMfErq2E7FWhQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=E2POwVD7+8z3j0W51OH58QZ5YrzLoDO2S5a/Ta5H1CJNe/ldLANM07+Sz0O2dzbu5 R5Y3iPQsMYHaKx4H7xHhw== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by kpbe20.cbf.corp.google.com with ESMTP id p75Gx0BC023832 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 5 Aug 2011 09:59:03 -0700 Received: by gxk8 with SMTP id 8so994497gxk.37 for ; Fri, 05 Aug 2011 09:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ojDHslzh22fY3DfVRVJxRaRCAdgynTicBJ6YCw4lbDg=; b=glO8GAWnioJBYnAO6/wRD9as7zWhCQ/WmI+w0iPzq8KjeSJqQuPkpihzKY4lzmyxpf ZIjSpgmVq2Nbi6wKCzNQ== Received: by 10.150.253.9 with SMTP id a9mr3396563ybi.230.1312563543315; Fri, 05 Aug 2011 09:59:03 -0700 (PDT) Received: by 10.150.253.9 with SMTP id a9mr3396551ybi.230.1312563543123; Fri, 05 Aug 2011 09:59:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Fri, 5 Aug 2011 09:58:43 -0700 (PDT) In-Reply-To: <4E3C1FB3.4090903@callenish.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C1A18.1010308@caucho.com> <4E3C1FB3.4090903@callenish.com> From: John Tamplin Date: Fri, 5 Aug 2011 12:58:43 -0400 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=001517475c92bba68904a9c5034a X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 16:58:50 -0000 --001517475c92bba68904a9c5034a Content-Type: text/plain; charset=UTF-8 On Fri, Aug 5, 2011 at 12:52 PM, Bruce Atherton wrote: > And if the frame size is 16TB and the implementation doesn't provide a > stream-based API? > Then they are going to have to buffer the entire message, whether it is sent in a 16TB frame or tons of 1-byte frames. Either they are providing a steam-based API to their clients in which case they can fragment it as they read it or they are providing just a message-based API to their clients, in which case they have to buffer the message anyway and can simple store the received frame data into the message as it is received. > Again we are talking past each other. My point is that if someone wants to > write a client or server that can only handle frames that are no more than > some arbitrary length, that should be a choice that they get to make. > They can right now, and if they get a frame larger than they like they return a "frame too large" error. > Why do you want to limit what an implementer can do? It increases complexity of senders -- every sender has to be prepared to throttle down the size of what it sends to an arbitrary value. You could argue they are going to have to be able to do that when MUX is added anyway and having them code their apps for it now will improve the ability to deploy MUX, but is it a good idea to speculatively add it to the spec? -- John A. Tamplin Software Engineer (GWT), Google --001517475c92bba68904a9c5034a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 5, 2011 at 12:52 PM, Bruce Atherton = <bruce@callenis= h.com> wrote:
And if the frame size is 16TB and the implementation does= n't provide a stream-based API?

T= hen they are going to have to buffer the entire message, whether it is sent= in a 16TB frame or tons of 1-byte frames. =C2=A0Either they are providing = a steam-based API to their clients in which case they can fragment it as th= ey read it or they are providing just a message-based API to their clients,= in which case they have to buffer the message anyway and can simple store = the received frame data into the message as it is received.
=C2=A0
Again we are talking past each other. My point is that if someone wants to = write a client or server that can only handle frames that are no more than = some arbitrary length, that should be a choice that they get to make.

They can right now, and if they get a fram= e larger than they like they return a "frame too large" error.
=C2=A0
Why do you want to limit what an implementer can do?

<= /div>
It increases complexity of senders -- every sender has to be prep= ared to throttle down the size of what it sends to an arbitrary value. =C2= =A0You could argue they are going to have to be able to do that when MUX is= added anyway and having them code their apps for it now will improve the a= bility to deploy MUX, but is it a good idea to speculatively add it to the = spec?

--
John A. Tamplin
Software Engineer (GWT), Google
--001517475c92bba68904a9c5034a-- From john.fallows@kaazing.com Fri Aug 5 10:11: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 DF5B621F8C69 for ; Fri, 5 Aug 2011 10:11:46 -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 OJYeC7kTdGAk for ; Fri, 5 Aug 2011 10:11:46 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C63321F8B80 for ; Fri, 5 Aug 2011 10:11:46 -0700 (PDT) Received: by pzk33 with SMTP id 33so10437369pzk.18 for ; Fri, 05 Aug 2011 10:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.143.67.7 with SMTP id u7mr2289175wfk.339.1312564324215; Fri, 05 Aug 2011 10:12:04 -0700 (PDT) Received: by 10.68.65.162 with HTTP; Fri, 5 Aug 2011 10:12:04 -0700 (PDT) X-Originating-IP: [64.71.23.250] In-Reply-To: References: Date: Fri, 5 Aug 2011 10:12:04 -0700 Message-ID: From: John Fallows To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=000e0cd29a264a2c2e04a9c532ba Cc: Server-Initiated HTTP Subject: Re: [hybi] consensus call on removing deflate-stream 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, 05 Aug 2011 17:11:47 -0000 --000e0cd29a264a2c2e04a9c532ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed. Regards, John Fallows On Fri, Jul 29, 2011 at 8:40 PM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > At the meeting and on the mailing list leading up to it, the chairs saw > consensus for the following action:**** > > ** ** > > Remove deflate-stream from the websocket protocol > specification.**** > > ** ** > > We=E2=80=99re confirming on the mailing list, and will declare this conse= nsus call > final by next Friday Aug 5.**** > > ** ** > > Thanks,**** > > ** ** > > Gabriel and Salvatore**** > > HyBi co-chairs**** > > ** ** > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --=20 >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 444 Castro St, Suite 1100 | Mountain View, CA 94041, USA --000e0cd29a264a2c2e04a9c532ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed.

Regards,
John Fallows

On Fri, Jul 29, 2011 at 8:40 PM, Gabriel Montenegro <Gabrie= l.Montenegro@microsoft.com> wrote:

At the meeting and on the mailing list leading up to= it, the chairs saw consensus for the following action:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Remove deflate-stream from the webs= ocket protocol specification.

=C2=A0

We=E2=80=99re confirming on the mailing list, and wi= ll declare this consensus call final by next Friday Aug 5.

=C2=A0

Thanks,

=C2=A0

Gabriel and Salvatore

HyBi co-chairs

=C2=A0


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




--
>|< Kaazing C= orporation >|<
John Fallows | CTO | +1.650.960.8148
444 Castro= St, Suite 1100=C2=A0| Mountain View, CA 94041, USA

--000e0cd29a264a2c2e04a9c532ba-- From bruce@callenish.com Fri Aug 5 10:31: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 3CA6C21F8C56 for ; Fri, 5 Aug 2011 10:31:17 -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 VqPo5DdOsnGj for ; Fri, 5 Aug 2011 10:31:16 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id ADDD621F8C52 for ; Fri, 5 Aug 2011 10:31:16 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpOFB-0001CL-V4; Fri, 05 Aug 2011 10:31:34 -0700 Message-ID: <4E3C2904.5000801@callenish.com> Date: Fri, 05 Aug 2011 10:31:48 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Diogo Pereira References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 17:31:17 -0000 On 05/08/2011 9:43 AM, Diogo Pereira wrote: > On Fri, Aug 5, 2011 at 16:14, Bruce Atherton wrote: >> We seem to be talking past each other. I am not talking about the >> application layer or any extensions, I am talking about the core Websockets >> implementation. Pretend Mux will never exist. The core protocol still should >> allow implementations to communicate the limits they can handle for frame >> size rather than sending a bunch of data that will end up being wasted. > But why would an implementation be unable to handle a large frame? > Again, an implementation does not have to buffer the entire frame, > unless it needs to buffer the entire message, in which case the > max-frame-size limit does not help. I don't know why. But I can make stuff up if you like. Maybe I write a server designed to create messages that have data that is not constant. I might have a message of effectively infinite length that buffers the last 8 frames worth of data and the application displays it as a rolling graph. Or maybe I use Websockets for sending a huge amount of data out of which I pull only a few tidbits (using an extension) that goes into my message. Or maybe I am marshalling and unmarshalling domain objects and can deal with the fact that only a portion of the object is initialized at a time. Or maybe a whole lot of things I can't think of right now. Please don't argue with these individual examples. The point is that there may be good reasons that people want to write a Websockets implementation that does not conform with what you are imagining. > If you don't want to buffer more than 8K at a time, read 8K at a time > and pretend (creating a new header if needed) that those 8K are a > single, complete frame. What exactly is wrong with this? -- Diogo It forces an implementation never to do things across an entire frame. That rules out a lot of potential extensions. Perhaps it would help if I gave an example of my implementation architecture. In it, frames are the domain of the client and server, and messages are the domain of the application. The class used for implementing messages is linked to the protocol as defined by the Sec-Websocket-Protocol line and if it is anything other than the default (empty) protocol the application provides the class. The client and server get the frame, run it through any frame-based extensions, and pass it into the message class. Whether the message class buffers the whole thing, parses it, or just counts how many characters are present is unknown to the Websockets implementation. That is an application-level concern. Now, you may not like my architecture. You may think it is stupid. But why on earth are you trying to forbid me to have it if I want to? From bruce@callenish.com Fri Aug 5 10:44: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 9AE9321F8C36 for ; Fri, 5 Aug 2011 10:44:51 -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=[AWL=-0.000, 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 j9qEZ2chY9T2 for ; Fri, 5 Aug 2011 10:44:51 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id EA8D321F8B86 for ; Fri, 5 Aug 2011 10:44:50 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpOSI-0004dV-Sn; Fri, 05 Aug 2011 10:45:07 -0700 Message-ID: <4E3C2C31.1080505@callenish.com> Date: Fri, 05 Aug 2011 10:45:21 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: John Tamplin References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C1A18.1010308@caucho.com> <4E3C1FB3.4090903@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090505030204080801060008" 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] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 17:44:51 -0000 This is a multi-part message in MIME format. --------------090505030204080801060008 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 05/08/2011 9:58 AM, John Tamplin wrote: > On Fri, Aug 5, 2011 at 12:52 PM, Bruce Atherton > wrote: > > And if the frame size is 16TB and the implementation doesn't > provide a stream-based API? > > > Then they are going to have to buffer the entire message, whether it > is sent in a 16TB frame or tons of 1-byte frames. Either they are > providing a steam-based API to their clients in which case they can > fragment it as they read it or they are providing just a message-based > API to their clients, in which case they have to buffer the message > anyway and can simple store the received frame data into the message > as it is received. Or the server can simply return an error message that says that the frame is too large. Or the server can let the other end know ahead of time not to send any frames that are bigger than a certain maximum. > Again we are talking past each other. My point is that if someone > wants to write a client or server that can only handle frames that > are no more than some arbitrary length, that should be a choice > that they get to make. > > > They can right now, and if they get a frame larger than they like they > return a "frame too large" error. Exactly. And that is wasted effort sending data that will never be used. >From my understanding, cell phone networks go to heroic lengths to avoid sending more than they have to, such as resending TCP fragments to avoid resending a whole packet. So why not make it easy for everyone to avoid dropping data on the ground? > Why do you want to limit what an implementer can do? > > > It increases complexity of senders -- every sender has to be prepared > to throttle down the size of what it sends to an arbitrary value. You > could argue they are going to have to be able to do that when MUX is > added anyway and having them code their apps for it now will improve > the ability to deploy MUX, but is it a good idea to speculatively add > it to the spec? They have to do that anyway if they receive a frame too large error and still want to communicate. The only difference is that they will have to guess at what the right size frame might be, and may try several times before they get it right. --------------090505030204080801060008 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/08/2011 9:58 AM, John Tamplin wrote:
On Fri, Aug 5, 2011 at 12:52 PM, Bruce Atherton <bruce@callenish.com> wrote:
And if the frame size is 16TB and the implementation doesn't provide a stream-based API?

Then they are going to have to buffer the entire message, whether it is sent in a 16TB frame or tons of 1-byte frames.  Either they are providing a steam-based API to their clients in which case they can fragment it as they read it or they are providing just a message-based API to their clients, in which case they have to buffer the message anyway and can simple store the received frame data into the message as it is received.

Or the server can simply return an error message that says that the frame is too large. Or the server can let the other end know ahead of time not to send any frames that are bigger than a certain maximum.

 
Again we are talking past each other. My point is that if someone wants to write a client or server that can only handle frames that are no more than some arbitrary length, that should be a choice that they get to make.

They can right now, and if they get a frame larger than they like they return a "frame too large" error.

Exactly. And that is wasted effort sending data that will never be used. From my understanding,  cell phone networks go to heroic lengths to avoid sending more than they have to, such as resending TCP fragments to avoid resending a whole packet. So why not make it easy for everyone to avoid dropping data on the ground?

 
Why do you want to limit what an implementer can do?

It increases complexity of senders -- every sender has to be prepared to throttle down the size of what it sends to an arbitrary value.  You could argue they are going to have to be able to do that when MUX is added anyway and having them code their apps for it now will improve the ability to deploy MUX, but is it a good idea to speculatively add it to the spec?

They have to do that anyway if they receive a frame too large error and still want to communicate. The only difference is that they will have to guess at what the right size frame might be, and may try several times before they get it right.

--------------090505030204080801060008-- From john.fallows@kaazing.com Fri Aug 5 11:16:47 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 0F6A421F8B73 for ; Fri, 5 Aug 2011 11:16:47 -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 D4SbqnKnDppk for ; Fri, 5 Aug 2011 11:16:46 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C95C21F8B72 for ; Fri, 5 Aug 2011 11:16:46 -0700 (PDT) Received: by ywm21 with SMTP id 21so2117231ywm.31 for ; Fri, 05 Aug 2011 11:17:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.170.15 with SMTP id s15mr2370147wfe.168.1312568223538; Fri, 05 Aug 2011 11:17:03 -0700 (PDT) Received: by 10.68.65.162 with HTTP; Fri, 5 Aug 2011 11:17:03 -0700 (PDT) X-Originating-IP: [64.71.23.250] In-Reply-To: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C1A18.1010308@caucho.com> <4E3C1FB3.4090903@callenish.com> Date: Fri, 5 Aug 2011 11:17:03 -0700 Message-ID: From: John Fallows To: John Tamplin Content-Type: multipart/alternative; boundary=000e0cd32d1eb51fe404a9c61a37 Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 18:16:47 -0000 --000e0cd32d1eb51fe404a9c61a37 Content-Type: text/plain; charset=UTF-8 Limiting message size would implicitly limit frame size but not the converse, so introducing a way to announce an upper bound on acceptable frame size doesn't prevent sending large messages. If the message is expected to be delivered as a whole to the endpoint, then frame size would seem to irrelevant to the amount of memory being allocated to buffer all frames composing the message. If the message is being considered part of a stream, such that message boundaries are not deemed significant to the protocol running over WebSocket, then limiting the frame size still doesn't seem that much more useful than limiting the message size. However, this is all largely from the perspective of the WebSocket endpoints. From the perspective of WebSocket intermediaries, there may be an equivalent need to specify maximum frame size so that resources at the intermediary can be managed effectively without interfering with the message size observed by the WebSocket endpoints. In short, we can probably benefit from the ability to announce max-frame-size for intermediaries and max-message-size for the endpoints. Kind Regards, John Fallows On Fri, Aug 5, 2011 at 9:58 AM, John Tamplin wrote: > On Fri, Aug 5, 2011 at 12:52 PM, Bruce Atherton wrote: > >> And if the frame size is 16TB and the implementation doesn't provide a >> stream-based API? >> > > Then they are going to have to buffer the entire message, whether it is > sent in a 16TB frame or tons of 1-byte frames. Either they are providing a > steam-based API to their clients in which case they can fragment it as they > read it or they are providing just a message-based API to their clients, in > which case they have to buffer the message anyway and can simple store the > received frame data into the message as it is received. > > >> Again we are talking past each other. My point is that if someone wants to >> write a client or server that can only handle frames that are no more than >> some arbitrary length, that should be a choice that they get to make. >> > > They can right now, and if they get a frame larger than they like they > return a "frame too large" error. > > >> Why do you want to limit what an implementer can do? > > > It increases complexity of senders -- every sender has to be prepared to > throttle down the size of what it sends to an arbitrary value. You could > argue they are going to have to be able to do that when MUX is added anyway > and having them code their apps for it now will improve the ability to > deploy MUX, but is it a good idea to speculatively add it to the spec? > > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > -- >|< Kaazing Corporation >|< John Fallows | CTO | +1.650.960.8148 444 Castro St, Suite 1100 | Mountain View, CA 94041, USA --000e0cd32d1eb51fe404a9c61a37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Limiting message size would implicitly limit frame size but not the convers= e, so introducing a way to announce an upper bound on acceptable frame size= doesn't prevent sending large messages.

If the mess= age is expected to be delivered as a whole to the endpoint, then frame size= would seem to irrelevant to the amount of memory being allocated to buffer= all frames composing the message.

If the message is being considered part of a stream, su= ch that message boundaries are not deemed significant to the protocol runni= ng over WebSocket, then limiting the frame size still doesn't seem that= much more useful than limiting the message size.

However, this is all largely from the perspective of th= e WebSocket endpoints. =C2=A0From the perspective of WebSocket intermediari= es, there may be an equivalent need to specify maximum frame size so that r= esources at the intermediary can be managed effectively without interfering= with the message size observed by the WebSocket endpoints.

In short, we can probably benefit from the ability to a= nnounce max-frame-size for intermediaries and max-message-size for the endp= oints.

Kind Regards,
John Fallows

On Fri, Aug 5, 2011 at 9:58 AM, John Tamplin= <= jat@google.com> wrote:
On Fri, Aug 5, 2011 at 12:52 PM, Bruce Athe= rton <bruce@callenish.com> wrote:
And if the frame size is 16TB and the implementation doesn't provi= de a stream-based API?

Then the= y are going to have to buffer the entire message, whether it is sent in a 1= 6TB frame or tons of 1-byte frames. =C2=A0Either they are providing a steam= -based API to their clients in which case they can fragment it as they read= it or they are providing just a message-based API to their clients, in whi= ch case they have to buffer the message anyway and can simple store the rec= eived frame data into the message as it is received.
=C2=A0
Again we are talking past each other. My point is that if someone wants to = write a client or server that can only handle frames that are no more than = some arbitrary length, that should be a choice that they get to make.

They can right now, and if they get = a frame larger than they like they return a "frame too large" err= or.
=C2=A0
Why do you want to limit what an implementer can do?

<= /div>
It increases complexity of senders -- every sender has to b= e prepared to throttle down the size of what it sends to an arbitrary value= . =C2=A0You could argue they are going to have to be able to do that when M= UX is added anyway and having them code their apps for it now will improve = the ability to deploy MUX, but is it a good idea to speculatively add it to= the spec?

--
John A. Tamplin
Software Engine= er (GWT), Google

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




--
>|< Kaazing C= orporation >|<
John Fallows | CTO | +1.650.960.8148
444 Ca= stro St, Suite 1100=C2=A0| Mountain View, CA 94041, USA

--000e0cd32d1eb51fe404a9c61a37-- From piotrku@microsoft.com Fri Aug 5 12:00: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 8034E1F0C40 for ; Fri, 5 Aug 2011 12:00:57 -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=[AWL=-0.000, 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 VTgY+tol3Bo7 for ; Fri, 5 Aug 2011 12:00:57 -0700 (PDT) Received: from smtp.microsoft.com (mailb.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id D2CEF1F0C44 for ; Fri, 5 Aug 2011 12:00:48 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 5 Aug 2011 12:01:03 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.211]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 12:01:00 -0700 From: Piotr Kulaga To: John Fallows , Gabriel Montenegro Thread-Topic: [hybi] consensus call on removing deflate-stream Thread-Index: AcxOaKuv70ih/eLjTUK9sH+c6yH32gFZMywAAArhpuA= Date: Fri, 5 Aug 2011 19:00:59 +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.70] Content-Type: multipart/alternative; boundary="_000_ED13A76FCE9E96498B049688227AEA29389825D5TK5EX14MBXC206r_" MIME-Version: 1.0 Cc: Server-Initiated HTTP Subject: Re: [hybi] consensus call on removing deflate-stream 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, 05 Aug 2011 19:00:57 -0000 --_000_ED13A76FCE9E96498B049688227AEA29389825D5TK5EX14MBXC206r_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gcmVtb3ZpbmcgZGVmbGF0ZS1zdHJlYW0gZnJvbSB0aGUgc3BlYy4NCg0KRnJvbTogaHli aS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSm9obiBGYWxsb3dzDQpTZW50OiBGcmlkYXksIEF1Z3VzdCAwNSwgMjAxMSAxMDoxMiBB TQ0KVG86IEdhYnJpZWwgTW9udGVuZWdybw0KQ2M6IFNlcnZlci1Jbml0aWF0ZWQgSFRUUA0KU3Vi amVjdDogUmU6IFtoeWJpXSBjb25zZW5zdXMgY2FsbCBvbiByZW1vdmluZyBkZWZsYXRlLXN0cmVh bQ0KDQpBZ3JlZWQuDQoNClJlZ2FyZHMsDQpKb2huIEZhbGxvd3MNCk9uIEZyaSwgSnVsIDI5LCAy MDExIGF0IDg6NDAgUE0sIEdhYnJpZWwgTW9udGVuZWdybyA8R2FicmllbC5Nb250ZW5lZ3JvQG1p Y3Jvc29mdC5jb208bWFpbHRvOkdhYnJpZWwuTW9udGVuZWdyb0BtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpBdCB0aGUgbWVldGluZyBhbmQgb24gdGhlIG1haWxpbmcgbGlzdCBsZWFkaW5nIHVwIHRv IGl0LCB0aGUgY2hhaXJzIHNhdyBjb25zZW5zdXMgZm9yIHRoZSBmb2xsb3dpbmcgYWN0aW9uOg0K DQogICAgICAgICAgICAgICAgUmVtb3ZlIGRlZmxhdGUtc3RyZWFtIGZyb20gdGhlIHdlYnNvY2tl dCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLg0KDQpXZeKAmXJlIGNvbmZpcm1pbmcgb24gdGhlIG1h aWxpbmcgbGlzdCwgYW5kIHdpbGwgZGVjbGFyZSB0aGlzIGNvbnNlbnN1cyBjYWxsIGZpbmFsIGJ5 IG5leHQgRnJpZGF5IEF1ZyA1Lg0KDQpUaGFua3MsDQoNCkdhYnJpZWwgYW5kIFNhbHZhdG9yZQ0K SHlCaSBjby1jaGFpcnMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KaHliaSBtYWlsaW5nIGxpc3QNCmh5YmlAaWV0Zi5vcmc8bWFpbHRvOmh5YmlA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkNCg0K DQoNCi0tDQo+fDwgS2FhemluZyBDb3Jwb3JhdGlvbiA+fDwNCkpvaG4gRmFsbG93cyB8IENUTyB8 ICsxLjY1MC45NjAuODE0OA0KNDQ0IENhc3RybyBTdCwgU3VpdGUgMTEwMCB8IE1vdW50YWluIFZp ZXcsIENBIDk0MDQxLCBVU0ENCg0K --_000_ED13A76FCE9E96498B049688227AEA29389825D5TK5EX14MBXC206r_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4u RW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiYjNDM7MSBvbiByZW1vdmluZyBkZWZsYXRlLXN0cmVhbSBmcm9tIHRoZSBzcGVjLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gaHliaS1ib3VuY2VzQGlldGYu b3JnIFttYWlsdG86aHliaS1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5K b2huIEZhbGxvd3M8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBBdWd1c3QgMDUsIDIwMTEgMTA6 MTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEdhYnJpZWwgTW9udGVuZWdybzxicj4NCjxiPkNjOjwvYj4g U2VydmVyLUluaXRpYXRlZCBIVFRQPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gY29u c2Vuc3VzIGNhbGwgb24gcmVtb3ZpbmcgZGVmbGF0ZS1zdHJlYW08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkFncmVlZC48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkpvaG4gRmFsbG93czxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgSnVsIDI5 LCAyMDExIGF0IDg6NDAgUE0sIEdhYnJpZWwgTW9udGVuZWdybyAmbHQ7PGEgaHJlZj0ibWFpbHRv OkdhYnJpZWwuTW9udGVuZWdyb0BtaWNyb3NvZnQuY29tIj5HYWJyaWVsLk1vbnRlbmVncm9AbWlj cm9zb2Z0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkF0IHRoZSBtZWV0aW5nIGFuZCBvbiB0aGUgbWFpbGluZyBs aXN0IGxlYWRpbmcgdXAgdG8gaXQsIHRoZSBjaGFpcnMgc2F3IGNvbnNlbnN1cyBmb3IgdGhlIGZv bGxvd2luZyBhY3Rpb246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgUmVtb3ZlIGRlZmxhdGUtc3RyZWFtIGZyb20gdGhlIHdlYnNv Y2tldCBwcm90b2NvbCBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ V2XigJlyZSBjb25maXJtaW5nIG9uIHRoZSBtYWlsaW5nIGxpc3QsIGFuZCB3aWxsIGRlY2xhcmUg dGhpcyBjb25zZW5zdXMgY2FsbCBmaW5hbCBieSBuZXh0IEZyaWRheSBBdWcgNS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkdh YnJpZWwgYW5kIFNhbHZhdG9yZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5IeUJpIGNvLWNoYWlyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KaHliaSBtYWlsaW5nIGxpc3Q8YnI+DQo8 YSBocmVmPSJtYWlsdG86aHliaUBpZXRmLm9yZyI+aHliaUBpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5YmkiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2h5Ymk8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVh cj0iYWxsIj4NCjxicj4NCi0tIDxicj4NCiZndDt8Jmx0OyBLYWF6aW5nIENvcnBvcmF0aW9uICZn dDt8Jmx0Ozxicj4NCkpvaG4gRmFsbG93cyB8IENUTyB8ICYjNDM7MS42NTAuOTYwLjgxNDg8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj40NDQgQ2FzdHJvIFN0LCBT dWl0ZSAxMTAwJm5ic3A7fCBNb3VudGFpbiBWaWV3LCBDQSA5NDA0MSwgVVNBPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ED13A76FCE9E96498B049688227AEA29389825D5TK5EX14MBXC206r_-- From paul@colomiets.name Fri Aug 5 12:24: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 4CC9021F8B3C for ; Fri, 5 Aug 2011 12:24:44 -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=[AWL=-0.000, 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 gXF479lnsVp8 for ; Fri, 5 Aug 2011 12:24:43 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 73FDD21F8B10 for ; Fri, 5 Aug 2011 12:24:43 -0700 (PDT) Received: by wyg8 with SMTP id 8so1551044wyg.31 for ; Fri, 05 Aug 2011 12:25:00 -0700 (PDT) Received: by 10.216.237.233 with SMTP id y83mr1059177weq.9.1312572300104; Fri, 05 Aug 2011 12:25:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.36.20 with HTTP; Fri, 5 Aug 2011 12:24:40 -0700 (PDT) X-Originating-IP: [91.203.48.31] In-Reply-To: <4E370C3E.3050608@callenish.com> References: <4E35539B.3090406@gmx.de> <4E3556C1.2090300@gmx.de> <4E370C3E.3050608@callenish.com> From: Paul Colomiets Date: Fri, 5 Aug 2011 22:24:40 +0300 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: Server-Initiated HTTP Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 05 Aug 2011 19:24:44 -0000 Hi Bruce, On Mon, Aug 1, 2011 at 11:27 PM, Bruce Atherton wrote: >This makes no sense to me. The application controls both the client > and the server portions of the messages being sent. Why would >anyone need a maximum message size? If you don't want them to >be bigger than a certain maximum, then just don't send any that are larger. Not everywhere applications are controlled well at both sides. There are large number of open-source or otherwise duplicate installations for the same application, with different infrastructure and network configuration (e.g. switch from apache to nginx or to lighttpd and you will have another kinds of limits, switch from one hosting provider to another, and again you have another limits). This is where max-message-size comes handy. Yes, it would be unfortunate if intermediaries could affect max-message-size. But given that a lot of intermediaries will need to inspect content (for fraud control, or something like that). They would probably implement buffering of whole message, just to have implementaion of inspection routines simpler (which in turn means stronger). So probably they will also limit thier max message size. And it's better to be aware of that. Otherwise intermediary getting to big message can do only one thing: drop a connection. Which would be pain both for users and for application writers to debug. > I don't understand what you mean about lazy programmers setting buffer size > to maximum frame size. If my Websockets implementation broadcasts that it > can handle a maximum frame size of 8K, then it probably will have buffers > that are 8K. That only makes sense. > The problem is slightly wider. If implementation broadcasts maximum frame size of 1Mb or 1Gb do you still allocate buffer to this size? No. So don't forget to limit it's maximum value. If most of your message sizes are 512 bytes and other party set a limit of 1K, will you have a buffer of 1K. If your message volume is very low, then yes. But probably no, you will set it to 8K or 16K and will read/write several messages at once. Then, how many applications would have to buffer whole message? I think about 90%. Based on the similar experience with http (Yes, really most of http frontends buffer whole http request before sending to a backend). -- Paul From diogo.pereira@ist.utl.pt Fri Aug 5 12:45: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 D904621F85AA for ; Fri, 5 Aug 2011 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 oRkUAbYFuWkN for ; Fri, 5 Aug 2011 12:45:07 -0700 (PDT) Received: from smtp2.ist.utl.pt (smtp2.ist.utl.pt [IPv6:2001:690:2100:1::16]) by ietfa.amsl.com (Postfix) with ESMTP id 26B5121F85A4 for ; Fri, 5 Aug 2011 12:45:06 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 791E070003F7 for ; Fri, 5 Aug 2011 20:45:20 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id CBj9m6qhIUHc for ; Fri, 5 Aug 2011 20:45:20 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 13C7B70003F5 for ; Fri, 5 Aug 2011 20:45:19 +0100 (WEST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 699AA2003FDB for ; Fri, 5 Aug 2011 20:45:19 +0100 (WEST) Received: by yie12 with SMTP id 12so279518yie.31 for ; Fri, 05 Aug 2011 12:45:18 -0700 (PDT) Received: by 10.42.146.197 with SMTP id k5mr2311361icv.524.1312573518109; Fri, 05 Aug 2011 12:45:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Fri, 5 Aug 2011 12:44:48 -0700 (PDT) In-Reply-To: <4E3C2904.5000801@callenish.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> From: Diogo Pereira Date: Fri, 5 Aug 2011 20:44:48 +0100 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 19:45:08 -0000 Bruce, Intermediaries can change the fragmentation of a message. An endpoint can act as an intermediary and do the same. It's not that complicated! If your implementation or application depends on the fragmentation surviving intact from one endpoint to the other, you are doing it wrong. An extension can negotiate a maximum frame size if it needs to, so this doesn't rule anything out. For what it's worth, I don't see any problem with your implementation. Just remember to fragment frames that are too large. -- Diogo On Fri, Aug 5, 2011 at 18:31, Bruce Atherton wrote: > On 05/08/2011 9:43 AM, Diogo Pereira wrote: >> >> On Fri, Aug 5, 2011 at 16:14, Bruce Atherton =C2=A0= wrote: >>> >>> We seem to be talking past each other. I am not talking about the >>> application layer or any extensions, I am talking about the core >>> Websockets >>> implementation. Pretend Mux will never exist. The core protocol still >>> should >>> allow implementations to communicate the limits they can handle for fra= me >>> size rather than sending a bunch of data that will end up being wasted. >> >> But why would an implementation be unable to handle a large frame? >> Again, an implementation does not have to buffer the entire frame, >> unless it needs to buffer the entire message, in which case the >> max-frame-size limit does not help. > > I don't know why. But I can make stuff up if you like. > > Maybe I write a server designed to create messages that have data that is > not constant. I might have a message of effectively infinite length that > buffers the last 8 frames worth of data and the application displays it a= s a > rolling graph. Or maybe I use Websockets for sending a huge amount of dat= a > out of which I pull only a few tidbits (using an extension) that goes int= o > my message. Or maybe I am marshalling and unmarshalling domain objects an= d > can deal with the fact that only a portion of the object is initialized a= t a > time. Or maybe a whole lot of things I can't think of right now. > > Please don't argue with these individual examples. The point is that ther= e > may be good reasons that people want to write a Websockets implementation > that does not conform with what you are imagining. > >> If you don't want to buffer more than 8K at a time, read 8K at a time an= d >> pretend (creating a new header if needed) that those 8K are a single, >> complete frame. What exactly is wrong with this? -- Diogo > > It forces an implementation never to do things across an entire frame. Th= at > rules out a lot of potential extensions. > > Perhaps it would help if I gave an example of my implementation > architecture. In it, frames are the domain of the client and server, and > messages are the domain of the application. The class used for implementi= ng > messages is linked to the protocol as defined by the Sec-Websocket-Protoc= ol > line and if it is anything other than the default (empty) protocol the > application provides the class. =C2=A0The client and server get the frame= , run it > through any frame-based extensions, and pass it into the message class. > Whether the message class buffers the whole thing, parses it, or just cou= nts > how many characters are present is unknown to the Websockets implementati= on. > That is an application-level concern. > > Now, you may not like my architecture. You may think it is stupid. But wh= y > on earth are you trying to forbid me to have it if I want to? > From w@1wt.eu Fri Aug 5 13:08: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 0E3065E8005 for ; Fri, 5 Aug 2011 13:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.167 X-Spam-Level: X-Spam-Status: No, score=-4.167 tagged_above=-999 required=5 tests=[AWL=-2.124, 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 XLccdrAJGRaM for ; Fri, 5 Aug 2011 13:08:51 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 4A0BC21F8B59 for ; Fri, 5 Aug 2011 13:08:50 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p75K90Ek016378; Fri, 5 Aug 2011 22:09:00 +0200 Date: Fri, 5 Aug 2011 22:08:59 +0200 From: Willy Tarreau To: Diogo Pereira Message-ID: <20110805200859.GE14452@1wt.eu> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 20:08:52 -0000 On Fri, Aug 05, 2011 at 08:44:48PM +0100, Diogo Pereira wrote: > Bruce, > > Intermediaries can change the fragmentation of a message. An endpoint > can act as an intermediary and do the same. It's not that complicated! > > If your implementation or application depends on the fragmentation > surviving intact from one endpoint to the other, you are doing it > wrong. > > An extension can negotiate a maximum frame size if it needs to, so > this doesn't rule anything out. > > For what it's worth, I don't see any problem with your implementation. > Just remember to fragment frames that are too large. Reading all this, I remembered a use case that was evocated when working on masking. At one point it was proposed to have the mask at the end of the frame. While this proposal was not acceptable, the same principle might apply to future extensions. For instance, an extension might require that each frames are digitally signed. For obvious streaming reasons, the signature would lie at the end of the frame. And intermediary or server might then be configured to only deliver the frame if the signature is valid. And intermediaries would probably be required not to fragment such frames. That said, as time passes, I'm thinking that once 1.0 is shipped, we'll have a broader amount of users with many new expectations, and that a version 1.1 will come soon after to help interoperability and to stop geniuses everywhere from inventing square wheels. This 1.1 could very well introduce new features that depend on new extensions, and it will likely be adopted quickly. All this to say that if we can't agree on the max-frame-size for 1.0, it might not be too late to introduce it with a real use in 1.1 because we can expect users to upgrade. Regards, Willy From bruce@callenish.com Fri Aug 5 13:11: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 7607F21F8B67 for ; Fri, 5 Aug 2011 13:11:49 -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 zLNZxDUVDQUr for ; Fri, 5 Aug 2011 13:11:49 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0237E21F8B5D for ; Fri, 5 Aug 2011 13:11:49 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpQkY-000471-95; Fri, 05 Aug 2011 13:12:06 -0700 Message-ID: <4E3C4EA5.6080108@callenish.com> Date: Fri, 05 Aug 2011 13:12:21 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Diogo Pereira References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 20:11:49 -0000 On 05/08/2011 12:44 PM, Diogo Pereira wrote: > Bruce, > > Intermediaries can change the fragmentation of a message. An intermediary cannot do so unless it understands all of the extensions. If one of the extensions requires the intermediary to buffer an entire frame, then that limits the size of frame that the intermediary can operate on. > It's not that complicated! It is perhaps a bit more complicated than you realize. > If your implementation or application depends on the fragmentation > surviving intact from one endpoint to the other, you are doing it > wrong. It would if I relied on that. Thankfully I don't. But I do rely on the extensions being applied correctly on any refragmentation of a message that is sent. Fortunately the protocol allows me to rely on that. Note that I do not claim that it is a requirement that a max frame size make it all the way from one end point to another. If an intermediary wants to consume it, fine. If they want to replace it with one of their own, that is fine too. So long as the frame size that I can handle is followed on the hop from that intermediary to me, I'm good. > For what it's worth, I don't see any problem with your implementation. > Just remember to fragment frames that are too large. > On outgoing frames I can control that. Incoming frame size is controlled by whoever wrote the implementation that is sending them. I have no control over that. From theturtle32@gmail.com Fri Aug 5 13:14: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 C567F11E80A6 for ; Fri, 5 Aug 2011 13:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] 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 QgAOKWNNHra8 for ; Fri, 5 Aug 2011 13:14:17 -0700 (PDT) Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by ietfa.amsl.com (Postfix) with ESMTP id 9E6E821F8B2A for ; Fri, 5 Aug 2011 13:14:16 -0700 (PDT) Received: by eyx24 with SMTP id 24so1544256eyx.19 for ; Fri, 05 Aug 2011 13:14:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ciyQj1cI0pxQAMoENyHcfEoELpAD80tve+LJv/aFbV0=; b=OQSzjjyU9nVlINu1WKt5SUsqk+oifSjevwkNtJNtQOZxmsAaOXUaOwj/0HHhB4ott7 MbumdakRlKXMFcclCpT1IsO7ToA1yWnVuYND9u6vU901TUDIcCap6E8LkNr7ugPqo7y0 wMOPmzKKq6qFtq8FVpAkqSQy2429mrK6H7vwU= MIME-Version: 1.0 Received: by 10.204.14.147 with SMTP id g19mr838895bka.101.1312575270210; Fri, 05 Aug 2011 13:14:30 -0700 (PDT) Received: by 10.204.67.19 with HTTP; Fri, 5 Aug 2011 13:14:30 -0700 (PDT) In-Reply-To: <4E3BCDFB.8020006@ericsson.com> References: <61674598C4E6924984E2CCB5C2D1F28E041B8B18D4@SISPE7MB1.commscope.com> <20110805060226.GE10638@1wt.eu> <20110805061012.GF10638@1wt.eu> <4E3BCDFB.8020006@ericsson.com> Date: Fri, 5 Aug 2011 13:14:30 -0700 Message-ID: From: Brian To: Salvatore Loreto Content-Type: multipart/alternative; boundary=00032555bd4eb8ce8f04a9c7be37 Cc: hybi@ietf.org Subject: Re: [hybi] Handshake complexity 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, 05 Aug 2011 20:14:17 -0000 --00032555bd4eb8ce8f04a9c7be37 Content-Type: text/plain; charset=ISO-8859-1 I didn't have any issue implementing this even in ActionScript 3 -- there were multiple SHA-1 libraries in AS3 readily available. SHA-1 is not an onerous requirement. It's readily available in pretty much every language, and the code that implements it is not particularly long. Even in a C implementation for an embedded device, the code to implement the rest of the WebSocket protocol would absolutely dwarf the tiny bit of code to deal with SHA-1. Brian On Fri, Aug 5, 2011 at 4:03 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > (as individual) > > we agreed on the SHA-1 time ago after a long... discussion > and honestly I don't see any new element worth enough to reopen it. > > We have already several implementations, browsers, servers, libraries etc > and nobody of the people implementing the protocol has found particular > difficulties > on this particular aspect, as far as I know. > > cheers > /Sal > > > > On 8/5/11 9:10 AM, Willy Tarreau wrote: > >> On Thu, Aug 04, 2011 at 11:04:31PM -0700, Ian Fette >> (????????????????????????) wrote: >> >>> On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau wrote: >>> >>> On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette >>>> (????????????????????????) wrote: >>>> >>>>> We've already discussed this topic to death (please search the >>>>> archive). >>>>> >>>> In >>>> >>>>> general people were concerned about simple computational methods (such >>>>> as >>>>> adding together two random numbers), and we reached consensus on using >>>>> SHA-1. With all due respect you're not bringing any considerations to >>>>> the >>>>> table that are new (we have already discussed the complexity of SHA-1 >>>>> and >>>>> whether or not it creates an unacceptable barrier to implementation; >>>>> the >>>>> consensus was that it did not.) As such, I don't think we should >>>>> re-open >>>>> decisions that literally stalled this group for months, especially not >>>>> >>>> when >>>> >>>>> we are in last call and there is nothing new that is being raised. >>>>> >>>> I would honnestly say that the minor new element that came since this >>>> endless discussion is that at that time it was speculated that using >>>> a SHA-1 library in implementations should not be difficult since SHA-1 >>>> is freely available. Now we have some WS implementations and we should >>>> check if they encountered unexpected difficulties in using SHA-1. I >>>> don't >>>> think so and Martin's mail makes me think it's more a matter of >>>> discomfort >>>> caused by needless software dependencies. But if some implementers were >>>> bringing real implementation issues due to the use of SHA-1, we should >>>> try to find how to address them. My personal feeling has always been >>>> that >>>> this was a bit over-engineered but well, we managed to reach a >>>> consensus. >>>> >>>> We managed it in Chrome FWIW :) >>> >> I'm not worried about the use of SHA-1 in browsers nor servers where >> crypto >> is already available. I'm thinking more about the small devices Hixie was >> targetting where SHA-1 would come with a big cost or with real >> implementation >> issues (eg: 16-bit devices for which there is no SHA-1 implementation). >> But >> I really don't believe that the same devices will use this protocol >> either. >> >> Regards, >> Willy >> >> ______________________________**_________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/**listinfo/hybi >> > > > ______________________________**_________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/**listinfo/hybi > --00032555bd4eb8ce8f04a9c7be37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I didn't have any issue implementing this even in ActionScript 3 -- the= re were multiple SHA-1 libraries in AS3 readily available. =A0SHA-1 is not = an onerous requirement. =A0It's readily available in pretty much every = language, and the code that implements it is not particularly long. =A0Even= in a C implementation for an embedded device, the code to implement the re= st of the WebSocket protocol would absolutely dwarf the tiny bit of code to= deal with SHA-1.

Brian


= On Fri, Aug 5, 2011 at 4:03 AM, Salvatore Loreto <salvatore.loreto@ericsson.com<= /a>> wrote:
(as individual)

we agreed on the SHA-1 time ago after a long... discussion
and honestly I don't see any =A0new element worth enough to reopen it.<= br>
We have already several implementations, browsers, servers, libraries etc and nobody of the people implementing the protocol has found particular dif= ficulties
on this particular aspect, as far as I know.

cheers
/Sal



On 8/5/11 9:10 AM, Willy Tarreau wrote:
On Thu, Aug 04, 2011 at 11:04:31PM -0700, Ian Fette (??????????????????????= ??) wrote:
On Thu, Aug 4, 2011 at 11:02 PM, Willy Tarreau<w@1wt.eu> =A0wrote:

On Thu, Aug 04, 2011 at 10:54:15PM -0700, Ian Fette
(????????????????????????) wrote:
We've already discussed this topic to death (please search the archive)= .
In
general people were concerned about simple computational methods (such as adding together two random numbers), and we reached consensus on using
SHA-1. With all due respect you're not bringing any considerations to t= he
table that are new (we have already discussed the complexity of SHA-1 and whether or not it creates an unacceptable barrier to implementation; the consensus was that it did not.) As such, I don't think we should re-ope= n
decisions that literally stalled this group for months, especially not
when
we are in last call and there is nothing new that is being raised.
I would honnestly say that the minor new element that came since this
endless discussion is that at that time it was speculated that using
a SHA-1 library in implementations should not be difficult since SHA-1
is freely available. Now we have some WS implementations and we should
check if they encountered unexpected difficulties in using SHA-1. I don'= ;t
think so and Martin's mail makes me think it's more a matter of dis= comfort
caused by needless software dependencies. But if some implementers were
bringing real implementation issues due to the use of SHA-1, we should
try to find how to address them. My personal feeling has always been that this was a bit over-engineered but well, we managed to reach a consensus.
We managed it in Chrome FWIW :)
I'm not worried about the use of SHA-1 in browsers nor servers where cr= ypto
is already available. I'm thinking more about the small devices Hixie w= as
targetting where SHA-1 would come with a big cost or with real implementati= on
issues (eg: 16-bit devices for which there is no SHA-1 implementation). But=
I really don't believe that the same devices will use this protocol eit= her.

Regards,
Willy

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


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

--00032555bd4eb8ce8f04a9c7be37-- From diogo.pereira@ist.utl.pt Fri Aug 5 14:17: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 551F721F87D9 for ; Fri, 5 Aug 2011 14:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 gH7kSDlphdt3 for ; Fri, 5 Aug 2011 14:17:30 -0700 (PDT) Received: from smtp2.ist.utl.pt (smtp2.ist.utl.pt [IPv6:2001:690:2100:1::16]) by ietfa.amsl.com (Postfix) with ESMTP id 34A8D21F87C6 for ; Fri, 5 Aug 2011 14:17:29 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id A04A370003FA for ; Fri, 5 Aug 2011 22:17:39 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id qUA-FmpgB755 for ; Fri, 5 Aug 2011 22:17:39 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 8BC8A70003DC for ; Fri, 5 Aug 2011 22:17:38 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 8B4C32008AF4 for ; Fri, 5 Aug 2011 22:17:38 +0100 (WEST) Received: by iye1 with SMTP id 1so3919733iye.27 for ; Fri, 05 Aug 2011 14:17:37 -0700 (PDT) Received: by 10.42.154.193 with SMTP id r1mr2479756icw.55.1312579057143; Fri, 05 Aug 2011 14:17:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Fri, 5 Aug 2011 14:17:07 -0700 (PDT) In-Reply-To: <4E3C4EA5.6080108@callenish.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> From: Diogo Pereira Date: Fri, 5 Aug 2011 22:17:07 +0100 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 05 Aug 2011 21:17:31 -0000 On Fri, Aug 5, 2011 at 21:12, Bruce Atherton wrote: > An intermediary cannot do so unless it understands all of the extensions. If > one of the extensions requires the intermediary to buffer an entire frame, > then that limits the size of frame that the intermediary can operate on. If an extension requires an intermediary to do the impossible then that is a problem with the extension. I don't understand all this talk about extensions. Extensions can have a mechanism for negotiating max-frame-size, or anything else that they might need. > On outgoing frames I can control that. Incoming frame size is controlled by > whoever wrote the implementation that is sending them. I have no control > over that. If you're receiving a frame you must understand the extensions, so you can probably control fragmentation. If the extension does not allow for this (e.g. Willy's example) and also does not have a mechanism for negotiating maximum frame size, then I would argue that that is, again, a problem with the extension. -- Diogo From tobias.oberstein@tavendo.de Fri Aug 5 14:22: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 4E44221F89B8 for ; Fri, 5 Aug 2011 14:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.47 X-Spam-Level: X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 EHTbl8cN13fY for ; Fri, 5 Aug 2011 14:22:34 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD9B21F89A7 for ; Fri, 5 Aug 2011 14:22:34 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Fri, 5 Aug 2011 14:22:52 -0700 From: Tobias Oberstein To: Piotr Kulaga , Diogo Pereira Date: Fri, 5 Aug 2011 14:22:51 -0700 Thread-Topic: [hybi] consensus call on ability to announce max frame size Thread-Index: AcxQjXH+LjBnbdrvSmyIJDjwYFubbQAR9ecAAK0HgyAACxtEyg== Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 05 Aug 2011 21:22:35 -0000 -1 for announcing max. frame size -1 for announcing max. message size =3D=3D=3D >From my experience, which is limited to endpoint development: when I'm a) outside the browser, and b) not limited by dubious network restrictions, I prefer TCP and do my own/whatever stuff. The whole attraction for me of WebSockets is with browser as run-time and network limitations, like all kinds of fancy firewalls/proxies/content inspection systems. I can't see how limits/negotiation on frame/message size helps in browsers. However, everything which increases the chances/adoption/support of WebSockets across those intermediaries is worth considering. Are there people from vendors/packages related to intermediaries on this list, which might have an opinion on frame/message size limits/negotiation? On 05.08.11 18:12, "Piotr Kulaga" wrote: > -1.50 for announcing frame size. So far no one (in my opinion) posted an= y > reasonable justification for this behavior. In my opinion this will just > complicate implementations instead of simplifying them (every intermediar= y > will have to obey this limits) and bloat the spec. > -0.25 for announcing message size. I see some benefits of it, but I think= we > should discuss this before moving forward. >=20 > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of D= iogo > Pereira > Sent: Monday, August 01, 2011 3:30 PM > To: Tobias Oberstein > Cc: hybi@ietf.org > Subject: Re: [hybi] consensus call on ability to announce max frame size >=20 > On Mon, Aug 1, 2011 at 21:56, Tobias Oberstein > wrote: >> Why is there a need for max. frame size anyway? >=20 > Good question. >=20 > If the API is messaged based then the implementation has to buffer the en= tire > message. A frame size limit does not help. >=20 > If the API is stream based there is no buffering problem at all. >=20 > If the API is frame based (and it shouldn't be), the implementation can s= till > fairly easily perform local fragmentation. >=20 >=20 > -- > Diogo > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi >=20 >=20 From Gabriel.Montenegro@microsoft.com Fri Aug 5 14:42:32 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 00B5121F8B67 for ; Fri, 5 Aug 2011 14:42:32 -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=[AWL=-0.000, 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 UdIFdxkCOhMQ for ; Fri, 5 Aug 2011 14:42:31 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 1654821F8B59 for ; Fri, 5 Aug 2011 14:42:31 -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; Fri, 5 Aug 2011 14:42:49 -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.323.7; Fri, 5 Aug 2011 14:42:49 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.79]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 14:42:49 -0700 From: Gabriel Montenegro To: Server-Initiated HTTP Thread-Topic: [hybi] consensus call on removing deflate-stream Thread-Index: AcxOaKuv70ih/eLjTUK9sH+c6yH32gFTw3rA Date: Fri, 5 Aug 2011 21:42:48 +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.43] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28DCTK5EX14MBXW602w_" MIME-Version: 1.0 Subject: Re: [hybi] consensus call on removing deflate-stream 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, 05 Aug 2011 21:42:32 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28DCTK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We're confirming consensus on this point, namely: Remove deflate-stream from the websocket protocol specifica= tion. We note that there are separate efforts (currently in an individual draft) = on compression, and encourage their continuation. Thanks, chairs From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gab= riel Montenegro Sent: Friday, July 29, 2011 23:40 To: Server-Initiated HTTP Subject: [hybi] consensus call on removing deflate-stream At the meeting and on the mailing list leading up to it, the chairs saw con= sensus for the following action: Remove deflate-stream from the websocket protocol specifica= tion. We're confirming on the mailing list, and will declare this consensus call = final by next Friday Aug 5. Thanks, Gabriel and Salvatore HyBi co-chairs --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28DCTK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

We’re confirming= consensus on this point, namely:

 

   &nbs= p;            Remove= deflate-stream from the websocket protocol specification.

 

We note that there are= separate efforts (currently in an individual draft) on compression, and en= courage their continuation.

 

Thanks,

 

chairs

 

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gabriel Montenegro
Sent: Friday, July 29, 2011 23:40
To: Server-Initiated HTTP
Subject: [hybi] consensus call on removing deflate-stream=

 

At the meeting and on the mailing list leading up to= it, the chairs saw consensus for the following action:

 

        &nbs= p;       Remove deflate-stream from the webso= cket protocol specification.

 

We’re confirming on the mailing list, and will= declare this consensus call final by next Friday Aug 5.

 

Thanks,

 

Gabriel and Salvatore

HyBi co-chairs

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28DCTK5EX14MBXW602w_-- From Gabriel.Montenegro@microsoft.com Fri Aug 5 14:42: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 0990821F8593 for ; Fri, 5 Aug 2011 14:42:38 -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=[AWL=-0.000, 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 GwMFo80+bUe8 for ; Fri, 5 Aug 2011 14:42:37 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 3182F21F8510 for ; Fri, 5 Aug 2011 14:42:37 -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; Fri, 5 Aug 2011 14:42:55 -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.323.7; Fri, 5 Aug 2011 14:42:55 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.79]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 14:42:55 -0700 From: Gabriel Montenegro To: Server-Initiated HTTP Thread-Topic: consensus call on not specifying DNS SRV as mandatory to implement Thread-Index: AcxOaQ6e5IrwdEjuTs6E1aKsqnlfUAFTz5nw Date: Fri, 5 Aug 2011 21:42:54 +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.43] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28E3TK5EX14MBXW602w_" MIME-Version: 1.0 Subject: Re: [hybi] consensus call on not specifying DNS SRV as mandatory to implement 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, 05 Aug 2011 21:42:38 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28E3TK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We're confirming this point, namely: Lack of consensus to specify DNS SRV as mandatory to implem= ent in the websocket protocol specification. Thanks, Chairs From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gab= riel Montenegro Sent: Friday, July 29, 2011 23:40 To: Server-Initiated HTTP Subject: [hybi] consensus call on not specifying DNS SRV as mandatory to im= plement At the meeting and on the mailing list leading up to it, the chairs did not= see consensus for the following action: Specify DNS SRV as mandatory to implement in the websocket = protocol specification. We're confirming on the mailing list, and will declare this consensus call = final by next Friday Aug 5. Thanks, Gabriel and Salvatore HyBi co-chairs --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28E3TK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

We’re confirming= this point, namely:

 

   &nbs= p;            Lack o= f consensus to specify DNS SRV as mandatory to implement in the websocket p= rotocol specification.

 

Thanks,

 

Chairs

 

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gabriel Montenegro
Sent: Friday, July 29, 2011 23:40
To: Server-Initiated HTTP
Subject: [hybi] consensus call on not specifying DNS SRV as mandator= y to implement

 

At the meeting and on the mailing list leading up to= it, the chairs did not see consensus for the following action:<= /p>

 

        &nbs= p;       Specify DNS SRV as mandatory to impl= ement in the websocket protocol specification.

 

We’re confirming on the mailing list, and will= declare this consensus call final by next Friday Aug 5.

 

Thanks,

 

Gabriel and Salvatore

HyBi co-chairs

 

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E28E3TK5EX14MBXW602w_-- From Gabriel.Montenegro@microsoft.com Fri Aug 5 14:46: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 D6B8021F8B23 for ; Fri, 5 Aug 2011 14:46:04 -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=[AWL=-0.000, 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 w6tLrddQcyVw for ; Fri, 5 Aug 2011 14:46:03 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 71AE121F8B20 for ; Fri, 5 Aug 2011 14:46:03 -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; Fri, 5 Aug 2011 14:46:21 -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.323.7; Fri, 5 Aug 2011 14:46:21 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.79]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Fri, 5 Aug 2011 14:46:21 -0700 From: Gabriel Montenegro To: Server-Initiated HTTP Thread-Topic: consensus call on ability to announce max frame size Thread-Index: AcxOaVuHLjBnbdrvSmyIJDjwYFubbQFT7RMw Date: Fri, 5 Aug 2011 21:46:20 +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.43] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E290CTK5EX14MBXW602w_" MIME-Version: 1.0 Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 05 Aug 2011 21:46:04 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E290CTK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We're still deliberating on this point, but hope to declare a final consens= us shortly (within a few days). Chairs From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gab= riel Montenegro Sent: Friday, July 29, 2011 23:33 To: Server-Initiated HTTP Subject: [hybi] consensus call on ability to announce max frame size At the meeting and on the mailing list leading up to it, the chairs saw con= sensus for the following action: Add ability to announce max frame size by both client and = server We're confirming on the mailing list, and will declare this consensus call = final by next Friday Aug 5. Thanks, Gabriel and Salvatore HyBi co-chairs --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E290CTK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,<= /p>

 

We’re still deli= berating on this point, but hope to declare a final consensus shortly (with= in a few days).

 

Chairs

 

 

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gabriel Montenegro
Sent: Friday, July 29, 2011 23:33
To: Server-Initiated HTTP
Subject: [hybi] consensus call on ability to announce max frame size=

 

At the meeting and on the mailing list leading up to= it, the chairs saw consensus for the following action:

 

        &nbs= p;       Add ability to announce max frame si= ze by  both client and server

 

We’re confirming on the mailing list, and will= declare this consensus call final by next Friday Aug 5.

 

Thanks,

 

Gabriel and Salvatore

HyBi co-chairs

 

 

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11403E290CTK5EX14MBXW602w_-- From bruce@callenish.com Fri Aug 5 17:13: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 26EEA21F8AD8 for ; Fri, 5 Aug 2011 17:13:25 -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 8C52MEGBhrBm for ; Fri, 5 Aug 2011 17:13:25 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 0436421F874C for ; Fri, 5 Aug 2011 17:09:32 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpUSU-00016H-BB; Fri, 05 Aug 2011 17:09:42 -0700 Message-ID: <4E3C8655.1070802@callenish.com> Date: Fri, 05 Aug 2011 17:09:57 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Diogo Pereira References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 00:13:25 -0000 On 05/08/2011 2:17 PM, Diogo Pereira wrote: > On Fri, Aug 5, 2011 at 21:12, Bruce Atherton wrote: >> An intermediary cannot do so unless it understands all of the extensions. If >> one of the extensions requires the intermediary to buffer an entire frame, >> then that limits the size of frame that the intermediary can operate on. > If an extension requires an intermediary to do the impossible then > that is a problem with the extension. I don't understand all this talk > about extensions. Extensions can have a mechanism for negotiating > max-frame-size, or anything else that they might need. Huh? Who said an intermediary had to do anything impossible? And I've never discussed anything about extensions needing a maximum frame size. I think you've missed the point of what I have been saying. Let me try again. I have shown how my architecture passes frames into a Message object that processes it in some way, perhaps buffering the data or perhaps discarding it or perhaps doing something in between. You have suggested I could just pass in buffer-sized blocks to the Message object regardless of frame size. Doing that would rule out any extension that operates on an entire frame, since such an extension would need the entire frame in memory at the same time. Just to be clear since this seems to be confusing, the extension does not have a maximum size of frame it can handle, the core Websockets implementation does. Is the ability to indicate in a header the maximum frame size that I can handle really so awful for you that you don't want to let me work with frames? I really don't get the intensity of the opposition. This seems so trivially easy to support and is an easy win for some scenarios. I don't get the downside. > If you're receiving a frame you must understand the extensions, so you > can probably control fragmentation. ??? You've completely lost me here. I can't control the incoming fragmentation without being able to let someone know what size I can handle. > If the extension does not allow for this (e.g. Willy's example) and > also does not have a mechanism for negotiating maximum frame size, > then I would argue that that is, again, a problem with the extension. > -- Diogo From bruce@callenish.com Fri Aug 5 18:28: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 2E5D621F8793 for ; Fri, 5 Aug 2011 18:28:02 -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 m+fQJWWpaMWM for ; Fri, 5 Aug 2011 18:28:01 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 8AC6321F877D for ; Fri, 5 Aug 2011 18:28:01 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpVgV-0000uZ-3d for hybi@ietf.org; Fri, 05 Aug 2011 18:28:15 -0700 Message-ID: <4E3C98BF.9030605@callenish.com> Date: Fri, 05 Aug 2011 18:28:31 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: "hybi@ietf.org" 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: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 01:28:02 -0000 I don't seem to be getting anywhere with my appeal about why I need an optional max-frame-size header, so I thought I would try another approach. There is a "Frame too large" error code defined in the spec, which means that any compliant Websocket endpoint needs to be able to handle it. Note that there is no "Message too large" error code, so compliant Websocket endpoints do not need to deal with that. You probably want to handle a "Frame too large" error in one of two ways: 1) Your frame size is FIXED, so you close a connection if the other end can't handle it. 2) Your frame size is DYNAMIC, so you adjust it until you stop getting "Frame too large" errors. Let's see what happens with and without information from the other end about the frame size it can handle. A. Other end sends you the maximum frame size it can handle: FIXED) As soon as you get the Max-Frame-Size header when upgrading the connection, you see it is less than your fixed frame size and so you fail fast by closing the connection. DYNAMIC) As soon as you get the Max-Frame-Size header when upgrading the connection, if it is less than your current frame size you adjust your frame size to match the size the other end can handle. Your first and all subsequent frames are sent with that size. B. The other end has no way to indicate the maximum frame size it can handle: FIXED) You upgrade the connection and it appears to work. You may receive a few messages from the other end. But when you send out your first frame you get back a "Frame too large" error. At that point you close the connection. DYNAMIC) You upgrade the connection and it appears to work. You may receive a few messages from the other end. But when you send out your first frame you get back a "Frame too large" error. You cut your frame size (perhaps in half) and try sending your frame again. You may get another "Frame too large" error. Your code must continue sending out frames with progressively smaller sizes until it stops getting that error. You then use the resulting frame size for the duration of the connection. So there you have it. You have to choose A or B to implement if you want to be compliant. Note that you have to implement this no matter how you personally deal with large frame sizes, whether you do streaming or not, because you can't control how the other end is implemented. Now honestly, which is more sensible, A or B? I choose A every time. From tobias.oberstein@tavendo.de Fri Aug 5 22:17: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 3BFF721F881C for ; Fri, 5 Aug 2011 22:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.486 X-Spam-Level: X-Spam-Status: No, score=-2.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 NgL7EBwTXzPS for ; Fri, 5 Aug 2011 22:17:28 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6C21F8802 for ; Fri, 5 Aug 2011 22:17:27 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Fri, 5 Aug 2011 22:17:46 -0700 From: Tobias Oberstein To: Bruce Atherton , "hybi@ietf.org" Date: Fri, 5 Aug 2011 22:17:45 -0700 Thread-Topic: [hybi] "Frame too large" error with and without max frame size Thread-Index: AcxT2CYlrBW2KMsaSVa9YzwNCFpeugAIAZT/ Message-ID: In-Reply-To: <4E3C98BF.9030605@callenish.com> Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 05:17:29 -0000 > There is a "Frame too large" error code defined in the spec, which means > that any compliant Websocket endpoint needs to be able to handle it. A status code can only appear in a CLOSE frame, upon receiving the draft says what to do: send back a CLOSE (unless you sent one before), after which the original sender of CLOSE is supposed to close the TCP connection. In the absence of a protocol implied or announced/negotiated max. frame size, IMHO it would be consequent to remove the predefined status code "frame too large" from the draft. From w@1wt.eu Fri Aug 5 22:31: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 43F5811E8080 for ; Fri, 5 Aug 2011 22:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.144 X-Spam-Level: X-Spam-Status: No, score=-4.144 tagged_above=-999 required=5 tests=[AWL=-2.101, 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 HN2S0H74Y-ZY for ; Fri, 5 Aug 2011 22:31:50 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 1244911E807C for ; Fri, 5 Aug 2011 22:31:49 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p765VwIr019062; Sat, 6 Aug 2011 07:31:58 +0200 Date: Sat, 6 Aug 2011 07:31:58 +0200 From: Willy Tarreau To: Bruce Atherton Message-ID: <20110806053158.GA16978@1wt.eu> References: <4E3C98BF.9030605@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E3C98BF.9030605@callenish.com> User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 05:31:51 -0000 On Fri, Aug 05, 2011 at 06:28:31PM -0700, Bruce Atherton wrote: > I don't seem to be getting anywhere with my appeal about why I need an > optional max-frame-size header, so I thought I would try another approach. > > There is a "Frame too large" error code defined in the spec, which means > that any compliant Websocket endpoint needs to be able to handle it. > Note that there is no "Message too large" error code, so compliant > Websocket endpoints do not need to deal with that. > > You probably want to handle a "Frame too large" error in one of two ways: > > 1) Your frame size is FIXED, so you close a connection if the other end > can't handle it. > > 2) Your frame size is DYNAMIC, so you adjust it until you stop getting > "Frame too large" errors. > > Let's see what happens with and without information from the other end > about the frame size it can handle. > > A. Other end sends you the maximum frame size it can handle: > > FIXED) As soon as you get the Max-Frame-Size header when upgrading > the connection, you see it is less than your fixed frame size and so you > fail fast by closing the connection. > > DYNAMIC) As soon as you get the Max-Frame-Size header when upgrading > the connection, if it is less than your current frame size you adjust > your frame size to match the size the other end can handle. Your first > and all subsequent frames are sent with that size. > > B. The other end has no way to indicate the maximum frame size it can > handle: > > FIXED) You upgrade the connection and it appears to work. You may > receive a few messages from the other end. But when you send out your > first frame you get back a "Frame too large" error. At that point you > close the connection. > > DYNAMIC) You upgrade the connection and it appears to work. You may > receive a few messages from the other end. But when you send out your > first frame you get back a "Frame too large" error. You cut your frame > size (perhaps in half) and try sending your frame again. You may get > another "Frame too large" error. Your code must continue sending out > frames with progressively smaller sizes until it stops getting that > error. You then use the resulting frame size for the duration of the > connection. > > So there you have it. You have to choose A or B to implement if you want > to be compliant. Note that you have to implement this no matter how you > personally deal with large frame sizes, whether you do streaming or not, > because you can't control how the other end is implemented. > > Now honestly, which is more sensible, A or B? > > I choose A every time. I agree with you Bruce. In fact, we've had a comparable issue with TCP years ago : the MSS was exchanged between both endpoints with no way for intermediaries (routers) to indicate whay they support, so in practice a path MTU discovery protocol was invented for that, consisting in attempts to send large packets and expect an ICMP message in return. The problem is, ICMP does not pass everywhere so the PMTU mechanism is not reliable over the net these days. This has resulted in everyone assuming that an MTU or 1500 was necessarily fine over the net since many routers have ethernet connectivity, which led to many issues with ADSL lines using PPPoE for several years because of the PPPoE encapsulation header. In the end, since nobody was able to tell if 1500 bytes frames would pass or not, many sites have deliberately reduced their MSS in the hope that ADSL users will not have connectivity issues. And the Net is now supposed to have a 1500 MTU. If the IP protocol had supported an MTU field from start, or if TCP headers had been mangled by routers so that each one would adjust the advertised MSS to set its supported value, there would never have been such an issue and right now it would still be possible to work beyond 1500 between capable endpoints. Now back to WebSocket, what I fear without a max-frame-size parameter is that once we discover *at least* one very common product with limitations, whether it's a server, browser, or worse and intermediary, we'll quickly have a static max-frame-size tunable in various agents in order to fit the limited component's capabilities. And this value will become the "well known" frame size, with nobody daring to send anything larger due to lack of reliability. And my suspicions go directly to the content inspection gateways which will inevitably appear. Most likely they will work on whole frames first because it's easier for them, just as pattern lookups in TCP is often performed on packets within many network components, with no consideration for packet boundaries, ordering nor fragmentation. If such stupid components have no way to advertise a size limit, surely they'll enforce one, resulting in bad experience for users and/or static setting in many agents. For this reason I think that the max-frame-size is a safe long-term choice now. Regards, Willy From tobias.oberstein@tavendo.de Fri Aug 5 23:43: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 BDA4421F8680 for ; Fri, 5 Aug 2011 23:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 uFniidTCMNen for ; Fri, 5 Aug 2011 23:43:03 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 3642621F867F for ; Fri, 5 Aug 2011 23:43:02 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Fri, 5 Aug 2011 23:43:21 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Fri, 5 Aug 2011 23:43:20 -0700 Thread-Topic: outbound HTTPS inspection Thread-Index: AcxUBCErhgO0525jPE6qH1P737s63g== Message-ID: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] outbound HTTPS inspection X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 06:43:03 -0000 In the presence of explicit or transparent http proxies, a WebSocket connection is more likely to work when done over wss. However, what about https intermediaries breaking up the "end-to-end" secur= e connection, acting as a man-in-the-middle? Today, such systems often will buffer until a complete http response has been received, then inspect, then forward to client. They also often fail the request whenever response body size (or request body size for other direction) exceeds some network admin defined limits. How does WebSockets address this problem? Will it only work, when those systems are fully WebSockets aware and friendly? What would those intermediaries likely (want to) do? Buffer a WS frame, inspect, forward? Buffer a complete WS message, inspect and forward? Fail on frame/message too large? From w@1wt.eu Sat Aug 6 00:27: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 6D65E21F86EE for ; Sat, 6 Aug 2011 00:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.121 X-Spam-Level: X-Spam-Status: No, score=-4.121 tagged_above=-999 required=5 tests=[AWL=-2.078, 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 BbXQ36+dNs3a for ; Sat, 6 Aug 2011 00:27:01 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 70C5421F86E0 for ; Sat, 6 Aug 2011 00:26:59 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p767RIXO019255; Sat, 6 Aug 2011 09:27:18 +0200 Date: Sat, 6 Aug 2011 09:27:18 +0200 From: Willy Tarreau To: Tobias Oberstein Message-ID: <20110806072718.GB16978@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] outbound HTTPS inspection X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 07:27:01 -0000 On Fri, Aug 05, 2011 at 11:43:20PM -0700, Tobias Oberstein wrote: > In the presence of explicit or transparent http proxies, a WebSocket > connection is more likely to work when done over wss. > > However, what about https intermediaries breaking up the "end-to-end" secure > connection, acting as a man-in-the-middle? > > Today, such systems often will buffer until a complete http response has > been received, then inspect, then forward to client. They also often fail > the request whenever response body size (or request body size for other > direction) exceeds some network admin defined limits. It depends. Some of them look at the beginning of contents and let streams pass through (eg: video). > How does WebSockets address this problem? Will it only work, when those > systems are fully WebSockets aware and friendly? WebSocket makes use of the HTTP Upgrade mechanism, by which an intermediary will see HTTP/1.1 101 in the response, and will know how to act accordingly. Quite frankly, a number of them will break at the beginning, for the very same reasons that some proxies will break when they don't implement 101. But since it's a standard HTTP mechanism, they will eventually get fixed for that. > What would those intermediaries likely (want to) do? Buffer a WS frame, > inspect, forward? Buffer a complete WS message, inspect and forward? > Fail on frame/message too large? Several failure modes are known to be possible : - ignore the status code and consider that 101 is equivalent to 2xx or 3xx and take it as a valid response. These ones will then try to analyse the contents and might do anything, such as wait for more data, wait for the close (now I remember why I wanted to advertise "content-length: 0" in the response), not recognize any wrong pattern and let everything pass through, or break the connection. - fail on the response because 101 is an unknown status code. They could possibly either break the connection or return a 5xx status code. - consider 101 as a 1xx status and wait for a second status code which will not come. Instead, WS frames will be considered as garbage where a second HTTP response is expected, and a 5xx status should be returned - let the 101 pass but remove the Upgrade header. That way the client will immediately know it went through a non-compliant proxy and will break the connection. My bet is that browsers will come with a configurable websocket proxy and that admins will quickly open a new port on their proxies to bypass the HTTP content analysis for WS. We should probably emit recommendations on ways to safely distinguish WS from HTTP on a proxy so that the deployed rules do not open ways to easily bypass URL or content filtering. In parallel, bug reports will be emitted for broken intermediaries and some of them will be fixed, other ones will wait for a new major version to announce a shiny new WS feature. But I think it can happen very quickly due to end user pressure. Regards, Willy From diogo.pereira@ist.utl.pt Sat Aug 6 07:54: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 311FD21F8764 for ; Sat, 6 Aug 2011 07:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 0GgChO0b8zY1 for ; Sat, 6 Aug 2011 07:54:30 -0700 (PDT) Received: from smtp1.ist.utl.pt (smtp1.ist.utl.pt [IPv6:2001:690:2100:1::15]) by ietfa.amsl.com (Postfix) with ESMTP id 24F4521F8754 for ; Sat, 6 Aug 2011 07:54:30 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 368AE7000437 for ; Sat, 6 Aug 2011 15:54:48 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp1.ist.utl.pt ([127.0.0.1]) by localhost (smtp1.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id BaBB6FQ+zF1y for ; Sat, 6 Aug 2011 15:54:48 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 21D637000432 for ; Sat, 6 Aug 2011 15:54:46 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 9785220010DC for ; Sat, 6 Aug 2011 15:54:46 +0100 (WEST) Received: by iye1 with SMTP id 1so5253985iye.27 for ; Sat, 06 Aug 2011 07:54:45 -0700 (PDT) Received: by 10.231.4.92 with SMTP id 28mr1507321ibq.33.1312642485208; Sat, 06 Aug 2011 07:54:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Sat, 6 Aug 2011 07:54:15 -0700 (PDT) In-Reply-To: <4E3C8655.1070802@callenish.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> From: Diogo Pereira Date: Sat, 6 Aug 2011 15:54:15 +0100 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 14:54:31 -0000 On Sat, Aug 6, 2011 at 01:09, Bruce Atherton wrote: > I have shown how my architecture passes frames into a Message object that > processes it in some way, perhaps buffering the data or perhaps discarding > it or perhaps doing something in between. You have suggested I could just > pass in buffer-sized blocks to the Message object regardless of frame size. > Doing that would rule out any extension that operates on an entire frame, > since such an extension would need the entire frame in memory at the same > time. No, I'm suggesting you pass buffer-sized *frames*. If no extensions have been negotiated, you can simply read an arbitrary amount of payload, create a new frame header with the correct payload length, and you end up with a frame, an entire frame. A frame that you can handle exactly as you would handle any other frame. If extensions have been negotiated, this may not be possible because of some extension requirement. That is a problem that should be solved by that extension, either by providing a way for endpoints to announce a maximum frame size, or, if possible, by redesigning the extension in a way that facilitates fragmentation. The base protocol does not have this limitation, and that is why it does not need max-frame-size. It's not awful, it's just unnecessary, and I think there is already enough unnecessary complexity in the protocol. -- Diogo From paul@colomiets.name Sat Aug 6 09:25: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 E3A5421F863A for ; Sat, 6 Aug 2011 09:25:16 -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 Dg8vrqAQWm2K for ; Sat, 6 Aug 2011 09:25:16 -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 2125121F85BB for ; Sat, 6 Aug 2011 09:25:15 -0700 (PDT) Received: by wwf5 with SMTP id 5so249586wwf.13 for ; Sat, 06 Aug 2011 09:25:36 -0700 (PDT) Received: by 10.216.65.203 with SMTP id f53mr1764090wed.54.1312647936133; Sat, 06 Aug 2011 09:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.36.20 with HTTP; Sat, 6 Aug 2011 09:25:16 -0700 (PDT) X-Originating-IP: [91.203.48.31] In-Reply-To: <20110806053158.GA16978@1wt.eu> References: <4E3C98BF.9030605@callenish.com> <20110806053158.GA16978@1wt.eu> From: Paul Colomiets Date: Sat, 6 Aug 2011 19:25:16 +0300 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 16:25:17 -0000 Hi Willy, On Sat, Aug 6, 2011 at 8:31 AM, Willy Tarreau wrote: > And my suspicions go directly to the content inspection gateways which will > inevitably appear. Most likely they will work on whole frames first because > it's easier for them, just as pattern lookups in TCP is often performed on > packets within many network components, with no consideration for packet > boundaries, ordering nor fragmentation. If such stupid components have no > way to advertise a size limit, surely they'll enforce one, resulting in bad > experience for users and/or static setting in many agents. > I have a similar thoughts. But inspection of content by frames means that malicious sites will try to split frames arbitrarily to skip those gateways. Also if new gateways will need to reconstruct tcp stream to decode frames, they probably can be smart enought to join frames into a message. -- Paul From w@1wt.eu Sat Aug 6 09:31: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 6F63021F85BB for ; Sat, 6 Aug 2011 09:31:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.799 X-Spam-Level: X-Spam-Status: No, score=-3.799 tagged_above=-999 required=5 tests=[AWL=-2.356, BAYES_00=-2.599, HELO_IS_SMALL6=0.556, J_CHICKENPOX_24=0.6] 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 TcHi8L5ynscF for ; Sat, 6 Aug 2011 09:31:55 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA9E21F856A for ; Sat, 6 Aug 2011 09:31:52 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p76GW2i1020324; Sat, 6 Aug 2011 18:32:02 +0200 Date: Sat, 6 Aug 2011 18:32:02 +0200 From: Willy Tarreau To: Paul Colomiets Message-ID: <20110806163202.GF16978@1wt.eu> References: <4E3C98BF.9030605@callenish.com> <20110806053158.GA16978@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 16:31:55 -0000 Hi Paul, On Sat, Aug 06, 2011 at 07:25:16PM +0300, Paul Colomiets wrote: > Hi Willy, > > On Sat, Aug 6, 2011 at 8:31 AM, Willy Tarreau wrote: > > And my suspicions go directly to the content inspection gateways which will > > inevitably appear. Most likely they will work on whole frames first because > > it's easier for them, just as pattern lookups in TCP is often performed on > > packets within many network components, with no consideration for packet > > boundaries, ordering nor fragmentation. If such stupid components have no > > way to advertise a size limit, surely they'll enforce one, resulting in bad > > experience for users and/or static setting in many agents. > > > I have a similar thoughts. But inspection of content by frames means that > malicious sites will try to split frames arbitrarily to skip those gateways. Indeed, but that is not our problem. We're aiming for interoperability, not for helping lazy developers make their products better. > Also if new gateways will need to reconstruct tcp stream to decode frames, > they probably can be smart enought to join frames into a message. Reconstructing a TCP stream is trivial, you just need to transparently bind to an IP:port and you receive it. Inspecting a stream is slightly more complex, especially when it comes to pattern matching across buffer boundaries. IDS/IPS have been fooled that way for a long time, and history repeats itself. And my guess is that in order to limit issues, such products will simply enforce limits and move the problem somewhere else. Regards, Willy From bruce@callenish.com Sat Aug 6 10:08: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 8063F21F85FE for ; Sat, 6 Aug 2011 10:08:34 -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 H2eeA0kitP5Y for ; Sat, 6 Aug 2011 10:08:34 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 2019821F85E3 for ; Sat, 6 Aug 2011 10:08:34 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QpkMl-0001EX-Vj; Sat, 06 Aug 2011 10:08:52 -0700 Message-ID: <4E3D7535.6090906@callenish.com> Date: Sat, 06 Aug 2011 10:09:09 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Diogo Pereira References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] max frame size. was: consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 17:08:34 -0000 On 06/08/2011 7:54 AM, Diogo Pereira wrote: > On Sat, Aug 6, 2011 at 01:09, Bruce Atherton wrote: >> I have shown how my architecture passes frames into a Message object that >> processes it in some way, perhaps buffering the data or perhaps discarding >> it or perhaps doing something in between. You have suggested I could just >> pass in buffer-sized blocks to the Message object regardless of frame size. >> Doing that would rule out any extension that operates on an entire frame, >> since such an extension would need the entire frame in memory at the same >> time. > No, I'm suggesting you pass buffer-sized *frames*. It's the same thing. I'm not bothered about whether I handle Frame objects or a buffer and a bit of state. Look, I'm tired of this conversation. Here's the thing. Unless you can convince every implementer of Websockets to do things your way, then it just doesn't matter. There will be frame size limits in some implementations, which means that everyone has to deal with it. Good luck with the lectures, because you haven't convinced me to change my implementation. From paul@colomiets.name Sat Aug 6 11:59: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 B1F3521F866A for ; Sat, 6 Aug 2011 11:59:54 -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=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, 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 BtvncnklVOIp for ; Sat, 6 Aug 2011 11:59:54 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 011FD21F8665 for ; Sat, 6 Aug 2011 11:59:53 -0700 (PDT) Received: by wyg8 with SMTP id 8so2041995wyg.31 for ; Sat, 06 Aug 2011 12:00:14 -0700 (PDT) Received: by 10.216.9.18 with SMTP id 18mr3292686wes.54.1312657214071; Sat, 06 Aug 2011 12:00:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.36.20 with HTTP; Sat, 6 Aug 2011 11:59:53 -0700 (PDT) X-Originating-IP: [91.203.48.31] In-Reply-To: <20110806163202.GF16978@1wt.eu> References: <4E3C98BF.9030605@callenish.com> <20110806053158.GA16978@1wt.eu> <20110806163202.GF16978@1wt.eu> From: Paul Colomiets Date: Sat, 6 Aug 2011 21:59:53 +0300 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 18:59:54 -0000 Hi Willy, On Sat, Aug 6, 2011 at 7:32 PM, Willy Tarreau wrote: >> I have a similar thoughts. But inspection of content by frames means that >> malicious sites will try to split frames arbitrarily to skip those gateways. > > Indeed, but that is not our problem. We're aiming for interoperability, > not for helping lazy developers make their products better. > Wow! So why we have that stupid masking and handshake? Ok, thats rhetorical question :) >> Also if new gateways will need to reconstruct tcp stream to decode frames, >> they probably can be smart enought to join frames into a message. > > Reconstructing a TCP stream is trivial, you just need to transparently > bind to an IP:port and you receive it. Inspecting a stream is slightly > more complex, especially when it comes to pattern matching across buffer > boundaries. IDS/IPS have been fooled that way for a long time, and > history repeats itself. And my guess is that in order to limit issues, > such products will simply enforce limits and move the problem somewhere > else. That's roughly my point. I just think that limit will be for message size. Like with http: there could be a limit for file size in multipart body. But usually servers limit maximum body size. And there are several methods to signal that to browser, e.g. Expect header or MAX_POST_SIZE (don't exacly remember spelling) form field. Since I expect more users will use websockets with small messages (and use http for big down/uploads), this kind of limit might be very useful. -- Paul From bruce@callenish.com Sat Aug 6 12:33: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 F27A521F8669 for ; Sat, 6 Aug 2011 12:33: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=[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 gKdiwRCp2gtU for ; Sat, 6 Aug 2011 12:33:19 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 6B48221F8663 for ; Sat, 6 Aug 2011 12:33:19 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qpmct-0005CC-Bm; Sat, 06 Aug 2011 12:33:39 -0700 Message-ID: <4E3D9725.50109@callenish.com> Date: Sat, 06 Aug 2011 12:33:57 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Colomiets References: <4E35539B.3090406@gmx.de> <4E3556C1.2090300@gmx.de> <4E370C3E.3050608@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: Server-Initiated HTTP Subject: Re: [hybi] consensus call on ability to announce max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 19:33:20 -0000 On 05/08/2011 12:24 PM, Paul Colomiets wrote: > Hi Bruce, > > On Mon, Aug 1, 2011 at 11:27 PM, Bruce Atherton wrote: >> This makes no sense to me. The application controls both the client >> and the server portions of the messages being sent. Why would >> anyone need a maximum message size? If you don't want them to >> be bigger than a certain maximum, then just don't send any that are larger. > Not everywhere applications are controlled well at both sides. There are > large number of open-source or otherwise duplicate installations for the > same application, with different infrastructure and network configuration > (e.g. switch from apache to nginx or to lighttpd and you will have another > kinds of limits, switch from one hosting provider to another, and again > you have another limits). This is where max-message-size comes handy. I understand what you are saying, but this is still an application-level specific issue. If someone purchases an HTML WYSIWYG editor with a Websockets interface and plops it into their web page, then the author of the component cannot control that the server sends it only messages that it can understand. But if it never expects to receive messages larger than, say, 100 bytes, it can send a "Message too large" message if one arrives that is larger than that. Having said that, I appreciate that for an empty subprotocol the implementation probably does need to worry about how it buffers the data in messages since it likely has to provide the default message implementation. I think that issue is what is causing people to believe that "Frame too large" makes no sense without "Message too large". The difference is that a Websockets implementation can do somethng about the former, but the latter requires application intervention. >> I don't understand what you mean about lazy programmers setting buffer size >> to maximum frame size. If my Websockets implementation broadcasts that it >> can handle a maximum frame size of 8K, then it probably will have buffers >> that are 8K. That only makes sense. >> > The problem is slightly wider. If implementation broadcasts maximum frame size > of 1Mb or 1Gb do you still allocate buffer to this size? No. Maybe you don't. My point was not that you have to do it, but that matching buffer size and maximum frame size is a legitimate thing to do. > If most of your message sizes are 512 bytes and other party > set a limit of 1K, will you have a buffer of 1K. If your message > volume is very low, > then yes. But probably no, you will set it to 8K or 16K and will > read/write several > messages at once. Absolutely. > Then, how many applications would have to buffer whole > message? I think about 90%. Based on the similar experience with http (Yes, > really most of http frontends buffer whole http request before sending to a > backend). > > You are probably right, but when you are working at the application level you can decide whether that is a sensible decision to make or not. From bruce@callenish.com Sat Aug 6 12:38: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 ADC5521F8569 for ; Sat, 6 Aug 2011 12:38:25 -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 m9If7PWr1BcX for ; Sat, 6 Aug 2011 12:38:25 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 46EA821F8586 for ; Sat, 6 Aug 2011 12:38:25 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qpmhp-0000fW-1c; Sat, 06 Aug 2011 12:38:45 -0700 Message-ID: <4E3D9857.4050703@callenish.com> Date: Sat, 06 Aug 2011 12:39:03 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein 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 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2011 19:38:25 -0000 On 05/08/2011 10:17 PM, Tobias Oberstein wrote: >> There is a "Frame too large" error code defined in the spec, which means >> that any compliant Websocket endpoint needs to be able to handle it. > A status code can only appear in a CLOSE frame, upon receiving the draft > says what to do: send back a CLOSE (unless you sent one before), > after which the original sender of CLOSE is supposed to close the TCP > connection. Right, but what you do after is the important thing. Do you just leave things at that, or do you retry the connection with a smaller frame size? Those were the two scenarios I was illustrating. > In the absence of a protocol implied or announced/negotiated max. frame > size, IMHO it would be consequent to remove the predefined status code > "frame too large" from the draft. Exactly. And since "frame too large" is a sensible reason that an implementation may want to close the connection, and since the knowledge about that reason can enable the other end to take corrective action, it makes no sense to drop it. There is no way people are going to agree to a protocol specific maximum (see the payload length field discussion) so an announced/negotiated maximum is the only one that makes sense. This shows why announcing maximum message size makes no sense at the Websockets level (though it may well at the application level). There is nothing that the Websockets implementation can do to retry a message that is too large. From tobias.oberstein@tavendo.de Sun Aug 7 01:03: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 776A221F871E for ; Sun, 7 Aug 2011 01:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_42=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g79-9l81J5l2 for ; Sun, 7 Aug 2011 01:03:41 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 61FA121F869D for ; Sun, 7 Aug 2011 01:03:41 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Sun, 7 Aug 2011 01:04:02 -0700 From: Tobias Oberstein To: Bruce Atherton Date: Sun, 7 Aug 2011 01:04:00 -0700 Thread-Topic: [hybi] "Frame too large" error with and without max frame size Thread-Index: AcxUcHfJOmMN7+eMRiq0wpJeG2+/YwAaBioI Message-ID: In-Reply-To: <4E3D9857.4050703@callenish.com> Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 07 Aug 2011 08:03:42 -0000 >> In the absence of a protocol implied or announced/negotiated max. frame >> size, IMHO it would be consequent to remove the predefined status code >> "frame too large" from the draft. >=20 > Exactly. And since "frame too large" is a sensible reason that an > implementation may want to close the connection, and since the knowledge I don't agree. An implementation incapable of processing frames above some size is bogus: The spec allows intermediaries to further fragment or coalesce (data) frame= s as it likes. Thus, endpoints must be capable of processing frames of any size. A further consequence is that frame boundaries can't carry any semantics. Thus it is always valid for endpoints to fragment/coalesce frames themselves. =3D=3D So, if for any reason you don't want to process frames above some size, jus= t fragment them as you receive them, and always send frames small enough. Given that, there should be no close reason "frame too large", and a peer will not want to retry, since there is no corrective action it can take. Th= e corrective action is fix the bogus implementation. -1: announcing/negotiating max. frame size in core protocol +1: removing close frame status code "frame too large" from spec > about that reason can enable the other end to take corrective action, it > makes no sense to drop it. There is no way people are going to agree to > a protocol specific maximum (see the payload length field discussion) so > an announced/negotiated maximum is the only one that makes sense. >=20 > This shows why announcing maximum message size makes no sense at the > Websockets level (though it may well at the application level). There is > nothing that the Websockets implementation can do to retry a message > that is too large. Agreed. In general, when an endpoint is operating under constraints originating outside the WebSockets protocol, those constraints must be deal= t with above the WebSocket protocol level. However, even then, "dealt with" may not always involve "announce" or "negotiate". For example, the current JavaScript API for WebSockets in browsers is message based, not frame-based, and not streaming. This is a constraint external to the WebSockets protocol. A consequence of this constraint is that a browser will have to buffer received frames that make up a received message. A browser could: a) Just go ahead. It'll allocate more and more memory, and some point swapping will kick in, and at some point the system will halt. The TCP will be dropped. b) Have some hard-coded, implementation defined, or user setting for max. message size. c) Determine a sane max. message size based on system RAM. d) Buffer the message to disk, and fire an event not with ArrayBuffer but some BFile d) could only kick in, when a defined threshold for buffered frames for a message is crossed. i.e. buffer data frames up to 1M in memory, then flush to disk and subsequently buffer to disk. when message is complete, fire appropriate event. d) could also work by memory-mapping the temp file buffering the message, which might allow to create an ArrayBuffer based event from the mmap'ed fil= e I'd probably prefer d). No need to announce/negotiate max. message size .. From w@1wt.eu Sun Aug 7 02:20: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 6418421F86BC for ; Sun, 7 Aug 2011 02:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.075 X-Spam-Level: X-Spam-Status: No, score=-4.075 tagged_above=-999 required=5 tests=[AWL=-2.032, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a-EY5I1WiWAg for ; Sun, 7 Aug 2011 02:20:02 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 7018421F85BB for ; Sun, 7 Aug 2011 02:20:00 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p779K7YT021799; Sun, 7 Aug 2011 11:20:07 +0200 Date: Sun, 7 Aug 2011 11:20:07 +0200 From: Willy Tarreau To: Tobias Oberstein Message-ID: <20110807092007.GN16978@1wt.eu> References: <4E3D9857.4050703@callenish.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 07 Aug 2011 09:20:02 -0000 On Sun, Aug 07, 2011 at 01:04:00AM -0700, Tobias Oberstein wrote: > >> In the absence of a protocol implied or announced/negotiated max. frame > >> size, IMHO it would be consequent to remove the predefined status code > >> "frame too large" from the draft. > > > > Exactly. And since "frame too large" is a sensible reason that an > > implementation may want to close the connection, and since the knowledge > > I don't agree. An implementation incapable of processing frames above > some size is bogus: > > The spec allows intermediaries to further fragment or coalesce (data) frames > as it likes. > > Thus, endpoints must be capable of processing frames of any size. > > A further consequence is that frame boundaries can't carry any semantics. > > Thus it is always valid for endpoints to fragment/coalesce frames > themselves. I think you did not read the examples that were given about frame-based compression, signature or any other extension that intermediaries are not allowed to refragment, and which would require to buffer a whole frame. Then it makes sense to be able to advertise a limit. Regards, Willy From tobias.oberstein@tavendo.de Sun Aug 7 02:39: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 DF35521F8588 for ; Sun, 7 Aug 2011 02:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wo6cZ3IQvx3d for ; Sun, 7 Aug 2011 02:39:21 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3B21F8586 for ; Sun, 7 Aug 2011 02:39:21 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Sun, 7 Aug 2011 02:39:43 -0700 From: Tobias Oberstein To: Willy Tarreau Date: Sun, 7 Aug 2011 02:39:13 -0700 Thread-Topic: [hybi] "Frame too large" error with and without max frame size Thread-Index: AcxU40BcERwnA2kDRZKAKaoq4JX80AAAQLEw Message-ID: <634914A010D0B943A035D226786325D422BFA1183D@EXVMBX020-12.exch020.serverdata.net> References: <4E3D9857.4050703@callenish.com> <20110807092007.GN16978@1wt.eu> In-Reply-To: <20110807092007.GN16978@1wt.eu> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 07 Aug 2011 09:39:22 -0000 > > I don't agree. An implementation incapable of processing frames above > > some size is bogus: > > > > The spec allows intermediaries to further fragment or coalesce (data) > > frames as it likes. > > > > Thus, endpoints must be capable of processing frames of any size. > > > > A further consequence is that frame boundaries can't carry any semantic= s. > > > > Thus it is always valid for endpoints to fragment/coalesce frames > > themselves. >=20 > I think you did not read the examples that were given about frame-based > compression, signature or any other extension that intermediaries are not > allowed to refragment, and which would require to buffer a whole frame. > Then it makes sense to be able to advertise a limit. Well, I did. I was referring to the base WebSockets protocol, the case when no extension= is active and RSV =3D 0. The draft spec says: """ A sender MAY create fragments of any size for non-control messages. An intermediary MUST NOT change the fragmentation of a message if any reserved bit values are used and the meaning of these values is not known to the intermediary. An intermediary MUST NOT change the fragmentation of any message in the context of a connection where extensions have been negotiated and the intermediary is not aware of the semantics of the negotiated extensions. """ So everything I said above I still hold on to. What is done outside the base WebSockets protocol, be it with extensions or application level, should not creap into the base protocol spec. It's their= business. From godjonez@codepad.info Sun Aug 7 07:35:32 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 5A83621F86C7 for ; Sun, 7 Aug 2011 07:35:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBr-Bdi24DDY for ; Sun, 7 Aug 2011 07:35:31 -0700 (PDT) Received: from smtpout.kotinet.com (smtpout.kotinet.com [212.50.215.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9748421F86BC for ; Sun, 7 Aug 2011 07:35:31 -0700 (PDT) Received: from codepad.info (codepad.info [62.240.71.135]) by smtpout.kotinet.com (Postfix) with ESMTP id A9D19E2583 for ; Sun, 7 Aug 2011 17:35:51 +0300 (EEST) Received: from overwatchnexus.combinet (overwatchnexus.combinet [192.168.2.7]) by codepad.info (Postfix) with ESMTPSA id F37E46402C0 for ; Sun, 7 Aug 2011 17:35:52 +0300 (EEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "hybi@ietf.org" Date: Sun, 07 Aug 2011 17:35:55 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Joonas Lehtolahti" Message-ID: User-Agent: Opera Mail/12.00 (Win32) Subject: [hybi] Server-side requirements in draft 10 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, 07 Aug 2011 14:35:32 -0000 In draft-ietf-hybi-thewebsocketprotocol-10 in Server-side Requirements (section 5.2.), and more specifically subsection 5.2.1. Reading the Client's Opening Handshake, I noticed that the requirements do not list that the client's handshake must contain the upgrade headers (Upgrade: websocket, Connection: upgrade). Based on that, even though it is required for the client to send those headers, it is not necessary for the server to see those headers to still consider the connection attempt as a valid WebSocket handshake as long as it has the other required parts such as Sec-WebSocket-Protocol. This would allow the server to complete the handshake and ask for protocol upgrade without the client requesting for upgrade. In other words even if the client violated the spec for handshake, the server would still accept it. Is this an oversight or actually intentional? As far as I understood from RFC2616 (HTTP/1.1) the Upgrade header from server can only be sent in response to client indicating willingness to upgrade protocols. Therefore accepting a HTTP request without Upgrade headers as a valid WebSocket handshake and then responding with server handshake including the Upgrade headers would be violating the idea behind the headers in my opinion (I did not see the HTTP spec actually forbidding server from sending Upgrade headers without client requesting it, but it seems implicit it should not happen). From paul@colomiets.name Sun Aug 7 09:24: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 310DA21F86AB for ; Sun, 7 Aug 2011 09:24:12 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JKKH5evFteg1 for ; Sun, 7 Aug 2011 09:24:11 -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 7058C21F86AA for ; Sun, 7 Aug 2011 09:24:11 -0700 (PDT) Received: by wwf5 with SMTP id 5so661277wwf.13 for ; Sun, 07 Aug 2011 09:24:34 -0700 (PDT) Received: by 10.216.9.18 with SMTP id 18mr4027274wes.54.1312734274107; Sun, 07 Aug 2011 09:24:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.221.18 with HTTP; Sun, 7 Aug 2011 09:24:14 -0700 (PDT) X-Originating-IP: [91.203.48.31] In-Reply-To: <4E3D9857.4050703@callenish.com> References: <4E3D9857.4050703@callenish.com> From: Paul Colomiets Date: Sun, 7 Aug 2011 19:24:14 +0300 Message-ID: To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 07 Aug 2011 16:24:12 -0000 Hi Bruce, On Sat, Aug 6, 2011 at 10:39 PM, Bruce Atherton wrote: > This shows why announcing maximum message size makes no sense at the > Websockets level (though it may well at the application level). There is > nothing that the Websockets implementation can do to retry a message that is > too large. > You are partially right. But you don't learning from HTTP. In HTTP there usually is a frontend server which buffers the whole HTTP request. Then forwards it throught another protocol to a backend (so it's not exactly intermediary). Frontend has a limit for sure (or otherwise it is very vulnerable to DOS attacks). But backend has no reliable way to determine that limit. So the problem of handling message size is an application level problem. But the only thing that frontend server can do is close connection. (And Yes, I don't think that streaming big messages to backend is a viable solution. In HTTP world streaming is going only for big file uploads, and I believe that big file uploads will stay out of websockets in future for lots of reasons). So it would be better if javascript could just have an exception when trying to send something too big. Then application can handle that. All that means, that some bigger companies will have no troubles (they control all ifrastructure). And most smaller projects will appear unreliable with websockets (while tiny bit of them will use some strange heuristics to determine message size or will try to always use very small ones). -- Paul From bruce@callenish.com Sun Aug 7 13:10: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 5905321F86EC for ; Sun, 7 Aug 2011 13:10:22 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xX9zSKcBNEUV for ; Sun, 7 Aug 2011 13:10:21 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id BEDC121F86D7 for ; Sun, 7 Aug 2011 13:10:21 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qq9g4-00050Y-D3; Sun, 07 Aug 2011 13:10:28 -0700 Message-ID: <4E3EF149.6090504@callenish.com> Date: Sun, 07 Aug 2011 13:10:49 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein 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 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 07 Aug 2011 20:10:22 -0000 On 07/08/2011 1:04 AM, Tobias Oberstein wrote: >>> In the absence of a protocol implied or announced/negotiated max. frame >>> size, IMHO it would be consequent to remove the predefined status code >>> "frame too large" from the draft. >> Exactly. And since "frame too large" is a sensible reason that an >> implementation may want to close the connection, and since the knowledge > I don't agree. An implementation incapable of processing frames above > some size is bogus: Prepare for a number of bogus implementations, then, mine among them. Because I think you are just plain wrong. It is perfectly reasonable to have a maximum frame size, particularly when extensions may need to operate on an entire frame of data at once. > The spec allows intermediaries to further fragment or coalesce (data) frames > as it likes. > > Thus, endpoints must be capable of processing frames of any size. Intermediaries can fragment and coalesce frames, you are right. But that doesn't mean the other end has to accept whatever they coalesce the frames in to. Whether the other end can close the connection with a "Frame too large error" or must use a generic error code, it still gets to close the connection. Losing the specific error code just means that the sending side cannot recover. > A further consequence is that frame boundaries can't carry any semantics. > > Thus it is always valid for endpoints to fragment/coalesce frames > themselves. Frame boundaries can contain semantics for extensions. That is why intermediaries are required to understand all extensions before they can alter frame boundaries. >> about that reason can enable the other end to take corrective action, it >> makes no sense to drop it. There is no way people are going to agree to >> a protocol specific maximum (see the payload length field discussion) so >> an announced/negotiated maximum is the only one that makes sense. >> >> This shows why announcing maximum message size makes no sense at the >> Websockets level (though it may well at the application level). There is >> nothing that the Websockets implementation can do to retry a message >> that is too large. > Agreed. In general, when an endpoint is operating under constraints > originating outside the WebSockets protocol, those constraints must be dealt > with above the WebSocket protocol level. > > However, even then, "dealt with" may not always involve "announce" or > "negotiate". Right. Websockets has no business defining how an application with a message size that is too large deals with that issue. It is application specific. As you say, the implementation can decide how it communicates the problem to the application. It may just close the connection, It may call a specific callback, it may return an error code, it may throw an exception up to the application, it may consume memory until it fails, whatever. From sh@defuze.org Mon Aug 8 13:47: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 7489811E809A for ; Mon, 8 Aug 2011 13:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxSD2lzFmXLa for ; Mon, 8 Aug 2011 13:47:02 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id BC0B711E8092 for ; Mon, 8 Aug 2011 13:47:00 -0700 (PDT) Received: by pzk33 with SMTP id 33so2258793pzk.18 for ; Mon, 08 Aug 2011 13:47:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.249.21 with SMTP id w21mr3581461wfh.145.1312836446869; Mon, 08 Aug 2011 13:47:26 -0700 (PDT) Received: by 10.142.202.4 with HTTP; Mon, 8 Aug 2011 13:47:26 -0700 (PDT) X-Originating-IP: [82.229.61.197] Date: Mon, 8 Aug 2011 22:47:26 +0200 Message-ID: From: Sylvain Hellegouarch To: Server-Initiated HTTP Content-Type: multipart/alternative; boundary=00504502ce5d1058d304aa048e78 Subject: [hybi] WebSocket browser support status X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 20:47:03 -0000 --00504502ce5d1058d304aa048e78 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I've not had the chance to follow closely what happened around WebSocket lately and thus, I've been wondering what was the browser support status of the protocol. Could anyone shed a light on this for me? Thanks, -- - Sylvain http://www.defuze.org http://twitter.com/lawouach --00504502ce5d1058d304aa048e78 Content-Type: text/html; charset=ISO-8859-1 Hi all,

I've not had the chance to follow closely what happened around WebSocket lately and thus, I've been wondering what was the browser support status of the protocol. Could anyone shed a light on this for me?

--00504502ce5d1058d304aa048e78-- From tobias.oberstein@tavendo.de Mon Aug 8 13:53: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 56D6E21F8A7E for ; Mon, 8 Aug 2011 13:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRxWtPjY-CyW for ; Mon, 8 Aug 2011 13:53:53 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4963C11E80B0 for ; Mon, 8 Aug 2011 13:53:52 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Mon, 8 Aug 2011 13:54:12 -0700 From: Tobias Oberstein To: Sylvain Hellegouarch , "hybi@ietf.org" Date: Mon, 8 Aug 2011 13:54:10 -0700 Thread-Topic: [hybi] WebSocket browser support status Thread-Index: AcxWDGqqbN6e5CVPQ+mRLYpIHdaY/QAAOeD3 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_CA6619924711tobiasobersteintavendode_" MIME-Version: 1.0 Subject: Re: [hybi] WebSocket browser support status X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 20:53:57 -0000 --_000_CA6619924711tobiasobersteintavendode_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Protocol 8 (draft spec 10) is - as far as I know - currently only supported= by Chrome 14 and Firefox 7/8 You can have a look at the test results from a little test suite covering c= onformance to detailed specifics of the spec: http://www.tavendo.de/autobahn/testsuite/report/ Description is here: http://www.tavendo.de/autobahn/testsuite.html Rest of the site is pretty much a work in progress .. On 08.08.11 22:47, "Sylvain Hellegouarch" wrote: Hi all, I've not had the chance to follow closely what happened around WebSocket la= tely and thus, I've been wondering what was the browser support status of t= he protocol. Could anyone shed a light on this for me? Thanks, --_000_CA6619924711tobiasobersteintavendode_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [hybi] WebSocket browser support status Protocol 8 (draft spec 10) is - as far as I know - currently only sup= ported by Chrome 14 and Firefox 7/8

You can have a look at the test results from a little test suite covering c= onformance to detailed specifics
of the spec:

http://www.tav= endo.de/autobahn/testsuite/report/

Description is here:

http://www.tavend= o.de/autobahn/testsuite.html

Rest of the site is pretty much a work in progress ..

On 08.08.11 22:47, "Sylvain Hellegouarch" <sh@defuze.org> wrote:

Hi all,

I've not had the chance to follow closely what happened around WebSocket la= tely and thus, I've been wondering what was the browser support status of t= he protocol. Could anyone shed a light on this for me?

Thanks,
--_000_CA6619924711tobiasobersteintavendode_-- From sh@defuze.org Mon Aug 8 13:59: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 758B911E80B5 for ; Mon, 8 Aug 2011 13:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LvFIXafZFrPa for ; Mon, 8 Aug 2011 13:59:53 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 81BF911E80AE for ; Mon, 8 Aug 2011 13:59:53 -0700 (PDT) Received: by pzk33 with SMTP id 33so2292391pzk.18 for ; Mon, 08 Aug 2011 14:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.126.1 with SMTP id y1mr6288209wfc.202.1312837220238; Mon, 08 Aug 2011 14:00:20 -0700 (PDT) Received: by 10.142.202.4 with HTTP; Mon, 8 Aug 2011 14:00:20 -0700 (PDT) X-Originating-IP: [82.229.61.197] In-Reply-To: References: Date: Mon, 8 Aug 2011 23:00:20 +0200 Message-ID: From: Sylvain Hellegouarch To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd30a922906a504aa04bc0f Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSocket browser support status X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Aug 2011 20:59:54 -0000 --000e0cd30a922906a504aa04bc0f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 8, 2011 at 10:54 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Protocol 8 (draft spec 10) is - as far as I know - currently only > supported by Chrome 14 and Firefox 7/8 > > You can have a look at the test results from a little test suite covering > conformance to detailed specifics > of the spec: > > http://www.tavendo.de/autobahn/testsuite/report/ > > Description is here: > > http://www.tavendo.de/autobahn/testsuite.html > > Rest of the site is pretty much a work in progress .. > > Brilliant. Cheers. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach --000e0cd30a922906a504aa04bc0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 8, 2011 at 10:54 PM, Tobias = Oberstein <tobias.oberstein@tavendo.de> wrote:
Protocol 8 (draft spec 10) is - as far as I know - currently only sup= ported by Chrome 14 and Firefox 7/8

You can have a look at the test results from a little test suite covering c= onformance to detailed specifics
of the spec:

http://www.tavendo.de/autobahn/testsuite/report/

Description is here:

http://www.tavendo.de/autobahn/testsuite.html

Rest of the site is pretty much a work in progress ..

=


B= rilliant. Cheers.=A0

--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach
--000e0cd30a922906a504aa04bc0f-- From bruce@callenish.com Mon Aug 8 17:06:05 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 3E3AC21F8BDE for ; Mon, 8 Aug 2011 17:06:05 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yDc0sAA-IjPr for ; Mon, 8 Aug 2011 17:06:04 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id B2E6321F8BE7 for ; Mon, 8 Aug 2011 17:06:04 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QqZq3-0002Lp-8B; Mon, 08 Aug 2011 17:06:31 -0700 Message-ID: <4E407A1E.2060501@callenish.com> Date: Mon, 08 Aug 2011 17:06:54 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Paul Colomiets References: <4E3D9857.4050703@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] "Frame too large" error with and without max frame size 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, 09 Aug 2011 00:06:05 -0000 On 07/08/2011 9:24 AM, Paul Colomiets wrote: > So it would be better if javascript could just have an exception when > trying to send something too big. Then application can handle that. I believe I understand why people want a maximum message size header. While messages are an application layer concern, there is a layer of the Websockets implementation that may have to concern itself with how much buffering is done by the message if the Websockets implementation actually provides the message implementation and not just the interface. That means that a message that is a reasonable size for both sides of the application as well as one end of the Websockets channel may be rejected by the other end due to limitations in the WS layer. In such cases, the application cannot know what limits the underlying Websockets implementation places on message size unless the implementation signals that limit to the application, and it has to do so at both client and server ends to prevent data from being sent needlessly. Provided the API has some mechanism to signal to the application that the message will fail to be delivered because it is too large, the application can be given a chance to rejig a message before it is actually sent on the wire. I don't find the argument as compelling as the one for max-frame-size, but I get that there is an argument to be made. As for our apparent impasse on max-frame-size, perhaps we could all reach a compromise. How about we allow that an endpoint MAY send a max-frame-size and the other end SHOULD adjust its maximum sending frame size downward. That way if you find this adds too much complexity to your implementation, you can completely ignore it. Your implementation can act as if the max-frame-size header does not exist in the spec and is never sent, and still remain completely compatible. Would that move us forward? From gregw@intalio.com Mon Aug 8 18:01: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 04C7B21F8B9D for ; Mon, 8 Aug 2011 18:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.891 X-Spam-Level: X-Spam-Status: No, score=-2.891 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XQPyjnfbOn1 for ; Mon, 8 Aug 2011 18:01:42 -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 68FB021F8BA9 for ; Mon, 8 Aug 2011 18:01:42 -0700 (PDT) Received: by vxi29 with SMTP id 29so2055971vxi.31 for ; Mon, 08 Aug 2011 18:02:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr6452797vdg.296.1312851701194; Mon, 08 Aug 2011 18:01:41 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Mon, 8 Aug 2011 18:01:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 9 Aug 2011 11:01:41 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 09 Aug 2011 01:01:43 -0000 On 2 August 2011 06:56, Tobias Oberstein wrote: > > Or is some path MTU discovery for frame length the idea? I believe that intermediaries should be allowed to change the declared frame size headers. In fact the frame size header should probably be listed in Connection and be a hop by hop header as each leg may have different frame size. regards From gregw@intalio.com Mon Aug 8 18:22: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 B86B221F8596 for ; Mon, 8 Aug 2011 18:22:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.894 X-Spam-Level: X-Spam-Status: No, score=-2.894 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Gh06A7gGQ9F for ; Mon, 8 Aug 2011 18:22:14 -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 CFB9121F8593 for ; Mon, 8 Aug 2011 18:22:13 -0700 (PDT) Received: by vws12 with SMTP id 12so4181204vws.31 for ; Mon, 08 Aug 2011 18:22:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr6089115vdb.95.1312852960919; Mon, 08 Aug 2011 18:22:40 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Mon, 8 Aug 2011 18:22:40 -0700 (PDT) In-Reply-To: <4E3C98BF.9030605@callenish.com> References: <4E3C98BF.9030605@callenish.com> Date: Tue, 9 Aug 2011 11:22:40 +1000 Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 01:22:14 -0000 Bruce, I think your post is a good way to look at it. Since we have a frame too large error, we have to deal with it. If a sender is not prepared to adjust the sizes they send in response, then we will have interoperability failures with some implementations unable to to communicate. So senders will have to adjust the size of frames they send. Which leaves us with 2 choices - guessing the size or using passed value. I think guessing is a poor choice. The only alternative is to not have a frame too large error - which will force all implementations to have to handle indefinite lengths of both frames and messages. In reality, few implementations will actually be written to handle both infinite frame and message sizes and almost all will actually have a size limit of some kind. They will just not have a way to communicate this limit. Let's also consider the flip side. What is the harm of declaring a max-frame-size? If there are implementations that really can handle 2^64 frames, then they can declare that size and we've wasted a few bytes in the handshake - or they can just not declare and no bytes are wasted. I can see why some with good implementations might see that a declaration is not useful, but I can't see why anybody could consider it harmful. cheers On 6 August 2011 11:28, Bruce Atherton wrote: > I don't seem to be getting anywhere with my appeal about why I need an > optional max-frame-size header, so I thought I would try another approach= . > > There is a "Frame too large" error code defined in the spec, which means > that any compliant Websocket endpoint needs to be able to handle it. Note > that there is no "Message too large" error code, so compliant Websocket > endpoints do not need to deal with that. > > You probably want to handle a "Frame too large" error in one of two ways: > > 1) Your frame size is FIXED, so you close a connection if the other end > can't handle it. > > 2) Your frame size is DYNAMIC, so you adjust it until you stop getting > "Frame too large" errors. > > Let's see what happens with and without information from the other end ab= out > the frame size it can handle. > > A. Other end sends you the maximum frame size it can handle: > > =A0FIXED) As soon as you get the Max-Frame-Size header when upgrading the > connection, you see it is less than your fixed frame size and so you fail > fast by closing the connection. > > =A0DYNAMIC) As soon as you get the Max-Frame-Size header when upgrading t= he > connection, if it is less than your current frame size you adjust your fr= ame > size to match the size the other end can handle. Your first and all > subsequent frames are sent with that size. > > B. The other end has no way to indicate the maximum frame size it can > handle: > > =A0FIXED) You upgrade the connection and it appears to work. You may rece= ive a > few messages from the other end. But when you send out your first frame y= ou > get back a "Frame too large" error. At that point you close the connectio= n. > > =A0DYNAMIC) You upgrade the connection and it appears to work. You may re= ceive > a few messages from the other end. But when you send out your first frame > you get back a "Frame too large" error. You cut your frame size (perhaps = in > half) and try sending your frame again. You may get another "Frame too > large" error. Your code must continue sending out frames with progressive= ly > smaller sizes until it stops getting that error. You then use the resulti= ng > frame size for the duration of the connection. > > So there you have it. You have to choose A or B to implement if you want = to > be compliant. Note that you have to implement this no matter how you > personally deal with large frame sizes, whether you do streaming or not, > because you can't control how the other end is implemented. > > Now honestly, which is more sensible, A or B? > > I choose A every time. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From jat@google.com Mon Aug 8 18:25:32 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 4AC5721F87D6 for ; Mon, 8 Aug 2011 18:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.955 X-Spam-Level: X-Spam-Status: No, score=-105.955 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lioNkhGwIMUz for ; Mon, 8 Aug 2011 18:25:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 47C6921F85EC for ; Mon, 8 Aug 2011 18:25:31 -0700 (PDT) Received: from kpbe17.cbf.corp.google.com (kpbe17.cbf.corp.google.com [172.25.105.81]) by smtp-out.google.com with ESMTP id p791PvpK009834 for ; Mon, 8 Aug 2011 18:25:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312853158; bh=0hU9D92h/6BCU/4xJGFd4nbKOuU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=rzdpw7ONaJJAWLrmxrJVuRgLXwhV1V2aVRZCbIUMS9CdZDkDk5xUH0929iMuVRzxj Xqo7j4IDmlv66jC9Y/AHQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=w0P6V++9iLxjcg/ts9UiLE/W3apeGxqPdqTQvs1NpKdckLWa/QQP/waENiGthYS5F GOktGQYToUOTbROnqQvsA== Received: from qwi2 (qwi2.prod.google.com [10.241.195.2]) by kpbe17.cbf.corp.google.com with ESMTP id p791PQsJ019969 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 8 Aug 2011 18:25:56 -0700 Received: by qwi2 with SMTP id 2so3421750qwi.8 for ; Mon, 08 Aug 2011 18:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aCukS+hokrzu7HzXLaSCaK1mfcokpmMtum9/N8gVUK4=; b=QPWDHrFtALKAJ+nDuh7UmqQGxp8ecvzZUviEJfDvFA9AW3e4andg+qFhqQp326O7va 1LYIw2T6U8ZvlxPKu8hg== Received: by 10.229.228.1 with SMTP id jc1mr4742481qcb.227.1312853156251; Mon, 08 Aug 2011 18:25:56 -0700 (PDT) Received: by 10.229.228.1 with SMTP id jc1mr4742477qcb.227.1312853156096; Mon, 08 Aug 2011 18:25:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.84.11 with HTTP; Mon, 8 Aug 2011 18:25:36 -0700 (PDT) In-Reply-To: <4E407A1E.2060501@callenish.com> References: <4E3D9857.4050703@callenish.com> <4E407A1E.2060501@callenish.com> From: John Tamplin Date: Mon, 8 Aug 2011 21:25:36 -0400 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=0016363b80b802ebc904aa08724e X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 01:25:32 -0000 --0016363b80b802ebc904aa08724e Content-Type: text/plain; charset=UTF-8 On Mon, Aug 8, 2011 at 8:06 PM, Bruce Atherton wrote: > As for our apparent impasse on max-frame-size, perhaps we could all reach a > compromise. How about we allow that an endpoint MAY send a max-frame-size > and the other end SHOULD adjust its maximum sending frame size downward. > That way if you find this adds too much complexity to your implementation, > you can completely ignore it. Your implementation can act as if the > max-frame-size header does not exist in the spec and is never sent, and > still remain completely compatible. > > Would that move us forward? +1 -- John A. Tamplin Software Engineer (GWT), Google --0016363b80b802ebc904aa08724e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 8, 2011 at 8:06 PM, Bruce Atherton <= span dir=3D"ltr"><bruce@callenish= .com> wrote:
As for our apparent impasse on max-frame-size, perhaps we= could all reach a compromise. How about we allow that an endpoint MAY send= a max-frame-size and the other end SHOULD adjust its maximum sending frame= size downward. That way if you find this adds too much complexity to your = implementation, you can completely ignore it. Your implementation can act a= s if the max-frame-size header does not exist in the spec and is never sent= , and still remain completely compatible.

Would that move us forward?

+1

--
John A. Tamplin
Software Engineer (GWT), Google
--0016363b80b802ebc904aa08724e-- From ferg@caucho.com Mon Aug 8 19:32: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 E258A21F8581 for ; Mon, 8 Aug 2011 19:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[AWL=-0.812, BAYES_50=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LylgYOL9JSfS for ; Mon, 8 Aug 2011 19:32:41 -0700 (PDT) Received: from nm14.bullet.mail.sp2.yahoo.com (nm14.bullet.mail.sp2.yahoo.com [98.139.91.84]) by ietfa.amsl.com (Postfix) with SMTP id 7F1EB21F8556 for ; Mon, 8 Aug 2011 19:32:41 -0700 (PDT) Received: from [98.139.91.67] by nm14.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 02:33:06 -0000 Received: from [98.139.91.34] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 02:33:06 -0000 Received: from [127.0.0.1] by omp1034.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 02:33:05 -0000 X-Yahoo-Newman-Id: 815676.66310.bm@omp1034.mail.sp2.yahoo.com Received: (qmail 77105 invoked from network); 9 Aug 2011 02:33:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312857185; bh=ZNMJwjWooJYbEeRqXUwTZEjZDFp2YOweB3iDAeSNlBU=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nXIiUYmGNM8G+JbggxWLoxlS973QwbTwtFGta7CKcAhfJ7JnGE8RW419bDNBR/lkZBmw1X9MUJm6kfjkmgAVe6Jz8p/EfoS8JFF7PkOZ5z4TTqegNR0Enp9uG6WxwWSQOy1QaTjzOJuMeOCtc5TDqo5+jhuxnBWPgaOrHIaQJr8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: d_c5Ea8VM1kpXpPc5ppYSe.GuBTO1xrzCvCNrLAAzF_3i4F bnxQv1mOqC0ozjaYxnuBXt1mzGjOY0UZEc8fGKvWuCiV9KYUPnu4vRHC5oDT K3FyuORnQKdCun56yWaOeeoC9EWfIEqVkAe.JqUgtHcCn0DZoqAqHb0rv906 aQmM8WglXNxkqxFXu30UdCuyL991ms32HPyh8FGip.fdv6XIRJQPn9aL.tp1 pdd2WORYlQy2Cjd._EI.c7XVC2Iu99IAhcMKcHRNBbA4g9.ps3_tv641wuq9 0AuRghanTkD8PgDpGKcOC0PrwsVLwMmc5INgbSCphJQ78hnIvBY1FZ7QmIyr ztRHdgqA4x7tbFia4dVFoh1fCEae3TP_L31SVAVbLqyCL_IgApaXuJyWlKFw bmh6ce.a6Dt2igGCkPJsE6dSpy2r_5Mjw_M33xmRvYsk- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 08 Aug 2011 19:33:05 -0700 PDT Message-ID: <4E409C60.6010007@caucho.com> Date: Mon, 08 Aug 2011 19:33:04 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E3C98BF.9030605@callenish.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 02:32:42 -0000 On 08/08/2011 06:22 PM, Greg Wilkins wrote: > I can see why some with good implementations might see that > a declaration is not useful, but I can't see why anybody could > consider it harmful. Unnecessary complexity is always harmful. It's a tax on every implementation and it's an additional source of interoperability failures. A simpler spec allows for simpler implementations. That's always a win. -- Scott From gregw@intalio.com Mon Aug 8 20:10: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 2372521F8ABE for ; Mon, 8 Aug 2011 20:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.896 X-Spam-Level: X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rtxq6OBTqSQ5 for ; Mon, 8 Aug 2011 20:10:51 -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 4C2CD21F884F for ; Mon, 8 Aug 2011 20:10:51 -0700 (PDT) Received: by vws12 with SMTP id 12so4243028vws.31 for ; Mon, 08 Aug 2011 20:11:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.139 with SMTP id dc11mr4348942vdb.28.1312859478575; Mon, 08 Aug 2011 20:11:18 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Mon, 8 Aug 2011 20:11:18 -0700 (PDT) In-Reply-To: <4E409C60.6010007@caucho.com> References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> Date: Tue, 9 Aug 2011 13:11:18 +1000 Message-ID: From: Greg Wilkins To: Scott Ferguson Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 03:10:52 -0000 On 9 August 2011 12:33, Scott Ferguson wrote: > It's a tax on every implementation and it's an additional source of > interoperability failures. I don't understand how this can be seen as a tax on every implementation because I have not seen a suggestion of an alternative that results in a less complex or more interoperable solution. If we have no max frame size, then we could pretend that all implementations will handle 2^64 frame sizes. But in reality, few implementations will be able or allowed to handle such huge frames. Even spooled to disk such frames represent significant resources that many implementations might not have or be prepared to allocate to a single connection. So either implementations will have to be complex enough to deal with effectively infinite frames, or there is a secret unknown interoperability failure point. If we just allow implementations to have secret max frame sizes, that just shifts the complexity to the other end, which either has to guess the acceptable frame size or will just be non interoperable. If an implementation wants to assume acceptable frame sizes, then it is free to ignore max frame sizes and not declare itself - there is no tax. > ... and it's an additional source of interoperability failures. What interoperability failures are created with a declared max frame size? Or are you saying that the problem comes from a max frame size (even if not declared). If so, do you really think all implementations MUST accept 2^64 frames? regards From gregw@intalio.com Mon Aug 8 20:49: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 5D80011E8093 for ; Mon, 8 Aug 2011 20:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.898 X-Spam-Level: X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o+kdAl0r1LiJ for ; Mon, 8 Aug 2011 20:49:53 -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 C5AB011E8091 for ; Mon, 8 Aug 2011 20:49:53 -0700 (PDT) Received: by vws12 with SMTP id 12so4263368vws.31 for ; Mon, 08 Aug 2011 20:50:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr6573714vdg.296.1312861821037; Mon, 08 Aug 2011 20:50:21 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Mon, 8 Aug 2011 20:50:20 -0700 (PDT) In-Reply-To: <4E3D7535.6090906@callenish.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> Date: Tue, 9 Aug 2011 13:50:20 +1000 Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 03:49:54 -0000 On 7 August 2011 03:09, Bruce Atherton wrote: > There will be frame size limits in some implementations, Exactly! This is a choice between have a frame size limit or not. All implementations will have a frame size limit declared or not. There might even conceivably be implementations that can handle 2^64 frames - but that will not be in a browser running on your i-phone any time soon! So the choice is not between having a limit and not having a limit. The choice is between declaring what your limit is or keeping it a secret. cheers From diogo.pereira@ist.utl.pt Mon Aug 8 22:47: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 3321A11E8084 for ; Mon, 8 Aug 2011 22:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L+w4xngI83Lk for ; Mon, 8 Aug 2011 22:47:38 -0700 (PDT) Received: from smtp1.ist.utl.pt (smtp1.ist.utl.pt [IPv6:2001:690:2100:1::15]) by ietfa.amsl.com (Postfix) with ESMTP id 5C97411E807C for ; Mon, 8 Aug 2011 22:47:37 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 7891D7000443 for ; Tue, 9 Aug 2011 06:48:00 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp1.ist.utl.pt ([127.0.0.1]) by localhost (smtp1.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id K2NbX2+yFBWQ for ; Tue, 9 Aug 2011 06:48:00 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 3D7167000433 for ; Tue, 9 Aug 2011 06:47:58 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id EB4A52005429 for ; Tue, 9 Aug 2011 06:47:57 +0100 (WEST) Received: by iye1 with SMTP id 1so10028558iye.27 for ; Mon, 08 Aug 2011 22:47:56 -0700 (PDT) Received: by 10.231.4.92 with SMTP id 28mr1788518ibq.33.1312868876166; Mon, 08 Aug 2011 22:47:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Mon, 8 Aug 2011 22:47:26 -0700 (PDT) In-Reply-To: References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> From: Diogo Pereira Date: Tue, 9 Aug 2011 06:47:26 +0100 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 05:47:39 -0000 On Tue, Aug 9, 2011 at 04:11, Greg Wilkins wrote: > If we have no max frame size, then we could pretend that all > implementations will handle 2^64 frame sizes. =C2=A0 But in reality, few > implementations will be able or allowed to handle such huge frames. > Even spooled to disk such frames represent significant resources that > many implementations might not have or be prepared to allocate to a > single connection. =C2=A0 =C2=A0So either implementations will have to be > complex enough to deal with effectively infinite frames, or there is a > secret unknown interoperability failure point. Browsers will have to buffer the whole message, so I don't think anyone expects them to handle 2^64 byte messages. As a consequence, they won't be expected to handle 2^64 byte frames. If an implementation can handle 2^64 byte messages, however, I would certainly expect it to be able to handle a 2^64 byte frame. This is not complex at all, and it can be done with only a few hundred bytes of memory. -- Diogo From gregw@intalio.com Mon Aug 8 23:44:27 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 6AD0511E8093 for ; Mon, 8 Aug 2011 23:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDZIOAeMxm-U for ; Mon, 8 Aug 2011 23:44:27 -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 D6D5511E808A for ; Mon, 8 Aug 2011 23:44:26 -0700 (PDT) Received: by vws12 with SMTP id 12so4353567vws.31 for ; Mon, 08 Aug 2011 23:44:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.163 with SMTP id dl3mr6271829vdb.229.1312872293542; Mon, 08 Aug 2011 23:44:53 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Mon, 8 Aug 2011 23:44:53 -0700 (PDT) In-Reply-To: References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> Date: Tue, 9 Aug 2011 16:44:53 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 06:44:27 -0000 On 9 August 2011 15:47, Diogo Pereira wrote: > If an implementation can handle 2^64 byte messages, however, I would > certainly expect it to be able to handle a 2^64 byte frame. This is > not complex at all, and it can be done with only a few hundred bytes > of memory. This is not an issue about the complexity of handling large frames. This is an issue not handling large frames and what to do if a sender is talking to a receiver that has a limit. It is perfectly valid for implementations to have a limit on the size of frame they are prepared to handle and almost all implementations will have a limit < 2^64. When a sender wants to send a frame to a receiver that has a frame size limit, then the choices are: a) not deal with it. The sender and receiver are just not interoperable above a certain sizes. This will mostly work as many applications will exchange only small messages and I'd expect to see lots of implementation get away with default limits of 8k. But as applications that need large messages are developed, they will then start hitting problems and the result will either be applications doing their own fragmentation or implementations assuming some defacto max frame size limit. b) deal with it by the sender guessing a smaller and smaller fragment size until the connection works. c) deal with it by having a declared size. Is there an option that I'm missing. From tobias.oberstein@tavendo.de Tue Aug 9 00:34: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 0A2AD21F89BE for ; Tue, 9 Aug 2011 00:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bb0g-OBwi7Qv for ; Tue, 9 Aug 2011 00:34:48 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 65D1321F89B8 for ; Tue, 9 Aug 2011 00:34:47 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Tue, 9 Aug 2011 00:35:15 -0700 From: Tobias Oberstein To: Greg Wilkins Date: Tue, 9 Aug 2011 00:34:44 -0700 Thread-Topic: [hybi] consensus call on ability to announce max frame size Thread-Index: AcxWL/lL9QYRDelsQ1SOUV0QeYknYQAM9IhA Message-ID: <634914A010D0B943A035D226786325D422BFA11D80@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 09 Aug 2011 07:34:49 -0000 > > Or is some path MTU discovery for frame length the idea? >=20 > I believe that intermediaries should be allowed to change the declared fr= ame decrease only, or increase also? > size headers. In fact the frame size header should probably be listed in > Connection and be a hop by hop header as each leg may have different > frame size. I'm glad you bring back the question of intermediaries in this discussion about announcing max. frame size, since I think it should be the tie breake= r. the reason I think so is: the two competitors of WebSockets are 1) raw TCP: ++ simple (to use), efficient -- not compatible (by Web measures) 2) plain old HTTP (some long poll, Comet, Bosh whatever) ++ compatible (with infrastructure) -- not simple, not efficient So, does "max. frame size" make WebSockets any simpler or more efficient? I guess not. Does "max. frame size" make WebSockets more compatible (with intermediaries= )? I don't know. It may make it less compatible, since it imposes more logic onto intermedar= ies that they have to deal with, without helping them. It may make it more compatible, since it might help intermediaries doing th= e stuff they want to do. I.e. when a content inspection systems wants to do it's inspection on a per= frame basis, a max. frame size might help. If it wants to do that on a per message basis= , it won't be sufficient. From tobias.oberstein@tavendo.de Tue Aug 9 00:40: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 C342021F8A35 for ; Tue, 9 Aug 2011 00:40:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqAZrmg85yeI for ; Tue, 9 Aug 2011 00:40:23 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3624021F89CC for ; Tue, 9 Aug 2011 00:40:23 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 9 Aug 2011 00:40:50 -0700 From: Tobias Oberstein To: Greg Wilkins , Bruce Atherton Date: Tue, 9 Aug 2011 00:40:20 -0700 Thread-Topic: [hybi] max frame size. was: consensus call on ability to announce max frame size Thread-Index: AcxWR3vqpl2U05ozQuqCCMG9kkPJLwAH3Mbw Message-ID: <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 07:40:23 -0000 > > There will be frame size limits in some implementations, >=20 > Exactly! This is a choice between have a frame size limit or not. > All implementations will have a frame size limit declared or not. > There might even conceivably be implementations that can handle 2^64 > frames - but that will not be in a browser running on your i-phone any ti= me > soon! You seem to suggest that having max. frame size would help browsers, but it= won't. Since the current JS API for WebSockets is message based, and a message can= be composed of an infinite number of frames, even a max. frame size won't help= . Either you have max. _message_ size negotiated or have a streaming API. I am certainly not advocating for max. message size ... but then, the quest= ion of ws browser API is out of scope wrt to the ws _protocol_. From andy@warmcat.com Tue Aug 9 01:00: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 C5BC321F8B76 for ; Tue, 9 Aug 2011 01:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hOkRf3CIY6Hx for ; Tue, 9 Aug 2011 01:00:01 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1496D21F8AF7 for ; Tue, 9 Aug 2011 01:00:01 -0700 (PDT) Message-ID: <4E40E91B.8050508@warmcat.com> Date: Tue, 09 Aug 2011 09:00:27 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 08:00:01 -0000 On 08/09/2011 07:44 AM, Somebody in the thread at some point said: Hi - >> If an implementation can handle 2^64 byte messages, however, I would >> certainly expect it to be able to handle a 2^64 byte frame. This is >> not complex at all, and it can be done with only a few hundred bytes >> of memory. > > This is not an issue about the complexity of handling large frames. > > This is an issue not handling large frames and what to do if a sender > is talking to a receiver that has a limit. > > It is perfectly valid for implementations to have a limit on the size > of frame they are prepared to handle and almost all implementations A peer with a frame size limit is BROKEN. Adding a "Frame MTU" and all the business around that is just trying to help the irretrievably broken by adding more complexity and useless stuff to implement. Since nobody can mandate correctness in the real world, broken implementations should just defiantly glory in their shame of not working properly until they're fixed or deprecated for stuff that is written better and actually works. The spec itself is deranged in this and encouraging this kind of breakage by pretending huge frame sizes have any meaning or use. -Andy From tobias.oberstein@tavendo.de Tue Aug 9 01:18: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 F1AE021F8AF7 for ; Tue, 9 Aug 2011 01:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CoMgUYtp73Z for ; Tue, 9 Aug 2011 01:18:37 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4F2CD21F8AF6 for ; Tue, 9 Aug 2011 01:18:37 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 9 Aug 2011 01:19:04 -0700 From: Tobias Oberstein To: =?iso-2022-jp?B?IkFuZHkgR3JlZW4gKBskQk5TMEJXLxsoQiki?= , Greg Wilkins Date: Tue, 9 Aug 2011 01:18:35 -0700 Thread-Topic: [hybi] "Frame too large" error / frame size limit == BROKEN Thread-Index: AcxWam2RZxbIkJF4Qhe6BLOcm5w4zwAAXzgg Message-ID: <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> In-Reply-To: <4E40E91B.8050508@warmcat.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 08:18:38 -0000 > > It is perfectly valid for implementations to have a limit on the size > > of frame they are prepared to handle and almost all implementations >=20 > A peer with a frame size limit is BROKEN. +1 And consequently, the "frame too large" close error code 1004 should be rem= oved from the spec, since it suggests the wrong, namely that it would be accepta= ble for a peer to deny processing of frames above some size, and by that impose= the burden of it's brokenness onto the others. Rather the spec should make it explicit: a peer MUST be capable of processing frames of any size. From asoliman@microsoft.com Tue Aug 9 02:44: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 B005121F8B56 for ; Tue, 9 Aug 2011 02:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9vB0sE3eR80 for ; Tue, 9 Aug 2011 02:44:42 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id F067D21F8678 for ; Tue, 9 Aug 2011 02:44:41 -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, 9 Aug 2011 02:45:10 -0700 Received: from TK5EX14MBXC133.redmond.corp.microsoft.com ([169.254.2.120]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0323.007; Tue, 9 Aug 2011 02:45:10 -0700 From: Ahmed Soliman To: Greg Wilkins , Hybi Thread-Topic: [hybi] websocket test suite Thread-Index: AQHMTYLTnPwMA5ROPUezUY2S/9CJVJUC93AAgAAeXwCAESfEIA== Date: Tue, 9 Aug 2011 09:45:09 +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.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] websocket test suite 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, 09 Aug 2011 09:44:42 -0000 Greg, I have the following comments: 1. Scenario to add: * Receive/send control frames (e.g. close frame) within a fragmented messa= ge. Verify that client/server responds with a close frame. 2. Focusing on interoperability testing: Shouldn't we narrow the tests bel= ow to focus on interoperability testing? I think some of the negative test= s below fit better in functional testing rather than interoperability test= ing? What do you think?=20 3. Standard process/test implementation: I think this will make it easier t= o share test implementations and verify interoperability between different = protocol implementations. Any thoughts around this? (e.g. cre ating server endpoints per scenario for server implementation, u= sing sub-protocol to select between fragmented message/non-fragmented messa= ge, .... etc) Thanks, Ahmed -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gre= g Wilkins Sent: Thursday, July 28, 2011 8:15 PM To: Hybi Subject: Re: [hybi] websocket test suite Here is a first cut at a list of tests for section 4 of the spec. Are thes= e the kinds of tests people were thinking about? If so, then I'm happy to go the next step of detail and start providing mor= e detail for each test. Obviously some implementation are not going to be able to send some of the = invalid frames or force fragmentation, so some suites will have to record s= ome tests as skipped, or only testing in one direction etc. 4.2 Base Framing Tests ---------------------- * 7 bit length: send/receive frames of length 0-125 * 16 bit length: send/receive frames of length 126-128, 65536 * 63 bit length: send/receive frames of length 65537 * Non zero RSV: send frames with non zero reserved bits and no extension. V= erify connection is failed. * Known Opcodes: send/receive frames with text,binary,ping,pong opcodes (co= ntinuation & close tested separately). * Unknown Opcodes: send frames with unknown opcodes 3-7, B-F. Verify connec= tion is failed. 4.3 Client to Server Masking ---------------------------- ??? 4.4 Fragmentation ----------------- * 1 fragment message: send/receive message in 1 fragment * 2 fragment message: send/receive message in 2 fragments * 3 fragment message: send/receive message in 3 fragments * Injected control: send/receive 2 fragment message with unsolicited pong m= essage between frames * Fragmented control: send fragmented ping. Verify that connection is faile= d. * Interleaved fragments: send a fragment with FIN set and Continuation opco= de. Verify that connection is failed. * Handled control: send/receive 2 fragment message with ping message betwee= n frames and last frame delayed. Verify pong is received before last frame = is sent. * 7 bit fragment: send/receive message with initial/middle/final fragments = of sizes 0-125 * 16 bit fragment: send/receive message with initial/middle/final fragments= of sizes 126-128,65536 * 64 bit fragment: send/receive message with initial/middle/finalfragments = of size 65537 4.5.1 Close Frames ------------------ * Orderly Close: On an idle connection, send a close and receive a close. * Busy Close: send a close to an endpoint that has sent the first fragment = of a message. * Simultaneous Close: send a close on both ends of a connection. * Message after close: attempt to send a message after a close. Verify mess= age is not received. * Idle close: ?? * Error Close: ?? 4.5.2 Ping ---------- * Empty ping: Send an empty ping, verify pong is received. * Non empty ping: Send a non empty ping, verify pong is received. 4.5.3 Pong ---------- * Empty pong: Send an empty ping, verify pong is received and is empty. * Non empty pong: Send a non empty ping, verify pong is received and has ma= tching content. * Outstanding ping: Send two pings with different content, reply with conte= nt for only the second. Verify connection stays open. * Unsolicited pong: Send/recv unsolicited pong. 4.5.4 Data Frames ----------------- * UTF-8 Text 0000-007f: Send/receive text message with characters in code p= oint range U+0000 to U+007F * UTF-8 Text 0080-07ff: Send/receive text message with characters in code p= oint range U+0080 to U+07FF * UTF-8 Text 0800-ffff: Send/receive text message with characters in code p= oint range U+0800 to U+FFFF * UTF-8 Text 010000-10ffff: Send/receive text message with characters in co= de point range U+010000 to U+10FFFF * Illegal bytes UTF-8: Send message with invalid UTF-8 byte sequence. Verify message is not received. * Illegal codes UTF-8: Send message with invalid UTF-8 code points. Verify message is not received. * Binary frames: Send/receive message containing illegal UTF-8 bytes sequen= ces and code points as binary message. _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From salvatore.loreto@ericsson.com Tue Aug 9 03:03: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 72DB321F8AEA for ; Tue, 9 Aug 2011 03:03:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.575 X-Spam-Level: X-Spam-Status: No, score=-106.575 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdgZxD2tqJoQ for ; Tue, 9 Aug 2011 03:03:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1525621F8AE9 for ; Tue, 9 Aug 2011 03:03:28 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-a1-4e41060c233f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DD.B3.20773.C06014E4; Tue, 9 Aug 2011 12:03:56 +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; Tue, 9 Aug 2011 12:03:56 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 04D6B245F for ; Tue, 9 Aug 2011 13:03:56 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BFCFA50DC6 for ; Tue, 9 Aug 2011 13:03:55 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0103F50832 for ; Tue, 9 Aug 2011 13:03:54 +0300 (EEST) Message-ID: <4E410607.7070006@ericsson.com> Date: Tue, 9 Aug 2011 13:03:51 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------040804080904070900020603" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] WebSocket browser support status 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, 09 Aug 2011 10:03:30 -0000 --------------040804080904070900020603 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Hi Tobias, thanks a lot for sharing the test results, they are really interesting. It would be a great for all the community if you can team up with Greg, Justin and the other people that have showed interest in the test suite to produce and submit an Internet draft describing the test suite cheers /Sal -- Salvatore Loreto www.sloreto.com On 8/8/11 11:54 PM, Tobias Oberstein wrote: > Protocol 8 (draft spec 10) is - as far as I know - currently only > supported by Chrome 14 and Firefox 7/8 > > You can have a look at the test results from a little test suite > covering conformance to detailed specifics > of the spec: > > http://www.tavendo.de/autobahn/testsuite/report/ > > Description is here: > > http://www.tavendo.de/autobahn/testsuite.html > > Rest of the site is pretty much a work in progress .. > > On 08.08.11 22:47, "Sylvain Hellegouarch" wrote: > > Hi all, > > I've not had the chance to follow closely what happened around > WebSocket lately and thus, I've been wondering what was the > browser support status of the protocol. Could anyone shed a light > on this for me? > > Thanks, > --------------040804080904070900020603 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Hi Tobias,

thanks a lot for sharing the test results, they are really interesting.

It would be a great for all the community
if you can team up with Greg, Justin and the other people that have showed interest in the test suite
to produce and submit an Internet draft describing the test suite

cheers
/Sal
-- 
Salvatore Loreto
www.sloreto.com


On 8/8/11 11:54 PM, Tobias Oberstein wrote:
Re: [hybi] WebSocket browser support status Protocol 8 (draft spec 10) is - as far as I know - currently only supported by Chrome 14 and Firefox 7/8

You can have a look at the test results from a little test suite covering conformance to detailed specifics
of the spec:

http://www.tavendo.de/autobahn/testsuite/report/

Description is here:

http://www.tavendo.de/autobahn/testsuite.html

Rest of the site is pretty much a work in progress ..

On 08.08.11 22:47, "Sylvain Hellegouarch" <sh@defuze.org> wrote:
Hi all,

I've not had the chance to follow closely what happened around WebSocket lately and thus, I've been wondering what was the browser support status of the protocol. Could anyone shed a light on this for me?

Thanks,


--------------040804080904070900020603-- From tobias.oberstein@tavendo.de Tue Aug 9 04:14: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 38B6721F8B4A for ; Tue, 9 Aug 2011 04:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JxQ7-74sLZPu for ; Tue, 9 Aug 2011 04:14:02 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 06C3221F8AF9 for ; Tue, 9 Aug 2011 04:14:01 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Tue, 9 Aug 2011 04:14:22 -0700 From: Tobias Oberstein To: Salvatore Loreto , "hybi@ietf.org" Date: Tue, 9 Aug 2011 04:13:52 -0700 Thread-Topic: [hybi] WebSocket browser support status Thread-Index: AcxWe61obQm6gpcrREOOt6Q34tzhewABeuig Message-ID: <634914A010D0B943A035D226786325D422BFA11D8B@EXVMBX020-12.exch020.serverdata.net> References: <4E410607.7070006@ericsson.com> In-Reply-To: <4E410607.7070006@ericsson.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D422BFA11D8BEXVMBX02012ex_" MIME-Version: 1.0 Subject: Re: [hybi] WebSocket browser support status 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, 09 Aug 2011 11:14:03 -0000 --_000_634914A010D0B943A035D226786325D422BFA11D8BEXVMBX02012ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Sal, thanks for noticing. If Greg, Justin and others would see benefit in producing a formal document= , I'd be on the boat. Only when collaborating though, since I never produced = such a document and also my time is quite limited. In any case, I certainly will extend the test coverage further - both with = regard to cases and implementations. Waiting for IE/Opera;) When others see test cases missing, drop me a line .. or even better, submi= t a test case class, which is quite easy .. it's all open-source and on GitHub. cheers, Tobias Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von Sa= lvatore Loreto Gesendet: Dienstag, 9. August 2011 12:04 An: hybi@ietf.org Betreff: Re: [hybi] WebSocket browser support status Hi Tobias, thanks a lot for sharing the test results, they are really interesting. It would be a great for all the community if you can team up with Greg, Justin and the other people that have showed = interest in the test suite to produce and submit an Internet draft describing the test suite cheers /Sal -- Salvatore Loreto www.sloreto.com On 8/8/11 11:54 PM, Tobias Oberstein wrote: Protocol 8 (draft spec 10) is - as far as I know - currently only supported= by Chrome 14 and Firefox 7/8 You can have a look at the test results from a little test suite covering c= onformance to detailed specifics of the spec: http://www.tavendo.de/autobahn/testsuite/report/ Description is here: http://www.tavendo.de/autobahn/testsuite.html Rest of the site is pretty much a work in progress .. On 08.08.11 22:47, "Sylvain Hellegouarch" wrote: Hi all, I've not had the chance to follow closely what happened around WebSocket la= tely and thus, I've been wondering what was the browser support status of t= he protocol. Could anyone shed a light on this for me? Thanks, --_000_634914A010D0B943A035D226786325D422BFA11D8BEXVMBX02012ex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [hybi] WebSocket browser support = status

Hello Sal,=

 

thanks for noticing.

 <= /o:p>

If Greg, Justin and others would see benef= it in producing a formal document,

I'= d be on the boat. Only when collaborating though, since I never produced su= ch a

document and also my time is qui= te limited.

 

In any case, I certainly will extend the test coverage = further - both with regard to cases

a= nd implementations. Waiting for IE/Opera;)

 

When others see test cas= es missing, drop me a line .. or even better, submit a test case=

class, which is quite easy .. it's all open-sou= rce and on GitHub.

 <= /p>

cheers,

To= bias

 

Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im A= uftrag von Salvatore Loreto

Gesendet:= Dienstag, 9. August 2011 12:04

An: h= ybi@ietf.org

Betreff: Re: [hybi] WebS= ocket browser support status

&nb= sp;

Hi Tobias,

 

thanks a lot for sh= aring the test results, they are really interesting.

 

It would be a = great for all the community

if you ca= n team up with Greg, Justin and the other people that have showed interest = in the test suite

to produce and sub= mit an Internet draft describing the test suite

 

cheers

/Sal

&= nbsp;

--

Salvatore Loreto

www.sloreto.co= m

 

 

On 8/8/11 11:54 PM, = Tobias Oberstein wrote:

Protocol 8 (= draft spec 10) is - as far as I know - currently only supported by Chrome 1= 4 and Firefox 7/8

 

You can have a look at the test results from a li= ttle test suite covering conformance to detailed specifics

of the spec:

 

http://www.tavendo.de/autobahn/t= estsuite/report/

 

Description is here:

 

http://www.tavendo.de= /autobahn/testsuite.html

 <= /o:p>

Rest of the site is pretty much a work in = progress ..

 

On 08.08.11 22:47, "Sylvain Hellegouarch" <= ;sh@defuze.org> wrote:

Hi all,

 

I've not had the chance to follow closely what happened around WebSock= et lately and thus, I've been wondering what was the browser support status= of the protocol. Could anyone shed a light on this for me?

<= p class=3DMsoPlainText> 

Thanks,=

 

= --_000_634914A010D0B943A035D226786325D422BFA11D8BEXVMBX02012ex_-- From alexey.melnikov@isode.com Tue Aug 9 04:16: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 0D85121F8B5D for ; Tue, 9 Aug 2011 04:16:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bYqLoadxTUT for ; Tue, 9 Aug 2011 04:16:33 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4026421F8AD2 for ; Tue, 9 Aug 2011 04:16:33 -0700 (PDT) Received: from [188.28.117.11] (188.28.117.11.threembb.co.uk [188.28.117.11]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 12:16:59 +0100 Message-ID: <4E411736.3030707@isode.com> Date: Tue, 09 Aug 2011 12:17:10 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Greg Wilkins References: <4E3C98BF.9030605@callenish.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 11:16:34 -0000 Greg Wilkins wrote: > Bruce, > > I think your post is a good way to look at it. Since we have a frame > too large error, we have to deal with it. If a sender is not prepared > to adjust the sizes they send in response, then we will have > interoperability failures with some implementations unable to to > communicate. So senders will have to adjust the size of frames they > send. Which leaves us with 2 choices - guessing the size or using > passed value. I think guessing is a poor choice. > > The only alternative is to not have a frame too large error - which > will force all implementations to have to handle indefinite lengths of > both frames and messages. In reality, few implementations will > actually be written to handle both infinite frame and message sizes > and almost all will actually have a size limit of some kind. They > will just not have a way to communicate this limit. > Agreed. > Let's also consider the flip side. What is the harm of declaring a > max-frame-size? If there are implementations that really can handle > 2^64 frames, then they can declare that size and we've wasted a few > bytes in the handshake - or they can just not declare and no bytes are > wasted. I can see why some with good implementations might see that > a declaration is not useful, but I can't see why anybody could > consider it harmful. > +1 From andy@warmcat.com Tue Aug 9 05:42: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 4863021F8AA9 for ; Tue, 9 Aug 2011 05:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEUEIqk5pbSg for ; Tue, 9 Aug 2011 05:42:28 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id B5B1121F875E for ; Tue, 9 Aug 2011 05:42:28 -0700 (PDT) Message-ID: <4E412B4D.6090909@warmcat.com> Date: Tue, 09 Aug 2011 13:42:53 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Alexey Melnikov References: <4E3C98BF.9030605@callenish.com> <4E411736.3030707@isode.com> In-Reply-To: <4E411736.3030707@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] "Frame too large" error / also broken 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, 09 Aug 2011 12:42:29 -0000 On 08/09/2011 12:17 PM, Somebody in the thread at some point said: > Greg Wilkins wrote: >> Bruce, >> >> I think your post is a good way to look at it. Since we have a frame >> too large error, we have to deal with it. If a sender is not prepared >> to adjust the sizes they send in response, then we will have >> interoperability failures with some implementations unable to to >> communicate. So senders will have to adjust the size of frames they >> send. Which leaves us with 2 choices - guessing the size or using >> passed value. I think guessing is a poor choice. >> >> The only alternative is to not have a frame too large error - which >> will force all implementations to have to handle indefinite lengths of >> both frames and messages. In reality, few implementations will >> actually be written to handle both infinite frame and message sizes >> and almost all will actually have a size limit of some kind. They >> will just not have a way to communicate this limit. > Agreed. >> Let's also consider the flip side. What is the harm of declaring a >> max-frame-size? If there are implementations that really can handle >> 2^64 frames, then they can declare that size and we've wasted a few >> bytes in the handshake - or they can just not declare and no bytes are >> wasted. I can see why some with good implementations might see that >> a declaration is not useful, but I can't see why anybody could >> consider it harmful. > +1 This is already on top of a reliable transport protocol with ordering of out-of-order packets and workable streaming in the form of TCP/IP. It already has stuff like path mtu discovery at the lower level. There is no benefit in recreating in a higher level protocol the same mtu restrictions and then workarounds that's already handled to give us the ability to stream endlessly how we like. It actually is harmful to write up this in the spec because it encourages people to understand they should be writing broken peers buffering frames instead of peers dealing with streams of bytes and the frame sizes only useful to find where the next frame header is coming. -Andy From diogo.pereira@ist.utl.pt Tue Aug 9 06:54: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 6D3CF21F8BDE for ; Tue, 9 Aug 2011 06:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Blph19u6xIT for ; Tue, 9 Aug 2011 06:54:53 -0700 (PDT) Received: from smtp2.ist.utl.pt (smtp2.ist.utl.pt [IPv6:2001:690:2100:1::16]) by ietfa.amsl.com (Postfix) with ESMTP id BC6CA21F86D7 for ; Tue, 9 Aug 2011 06:54:52 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 7BFA370003D2 for ; Tue, 9 Aug 2011 14:55:20 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id COUTZG3DV8Tc for ; Tue, 9 Aug 2011 14:55:20 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 64433700044F for ; Tue, 9 Aug 2011 14:55:16 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 65B05201330A for ; Tue, 9 Aug 2011 14:55:16 +0100 (WEST) Received: by iye1 with SMTP id 1so11395iye.27 for ; Tue, 09 Aug 2011 06:55:15 -0700 (PDT) Received: by 10.231.35.73 with SMTP id o9mr7855271ibd.46.1312898115114; Tue, 09 Aug 2011 06:55:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Tue, 9 Aug 2011 06:54:45 -0700 (PDT) In-Reply-To: References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> From: Diogo Pereira Date: Tue, 9 Aug 2011 14:54:45 +0100 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 13:54:53 -0000 On Tue, Aug 9, 2011 at 07:44, Greg Wilkins wrote: > This is not an issue about the complexity of handling large frames. Well, if handling large frames is as easy as handling small frames, then what is the reason for having a frame size limit? > It is perfectly valid for implementations to have a limit on the size > of frame they are prepared to handle and almost all implementations > will have a limit < 2^64. It is only valid in the sense that it is allowed. There is no valid reason for it, so it should not be encouraged. -- Diogo From alexey.melnikov@isode.com Tue Aug 9 06:56: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 6126221F87C9 for ; Tue, 9 Aug 2011 06:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.419 X-Spam-Level: X-Spam-Status: No, score=-102.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQ08Badq3OHL for ; Tue, 9 Aug 2011 06:56:04 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id CD95421F86D7 for ; Tue, 9 Aug 2011 06:56:03 -0700 (PDT) Received: from [188.28.117.11] (188.28.117.11.threembb.co.uk [188.28.117.11]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 14:56:31 +0100 Message-ID: <4E413C9B.4000103@isode.com> Date: Tue, 09 Aug 2011 14:56:43 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> In-Reply-To: <4E40E91B.8050508@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 13:56:04 -0000 Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8) wrote: > On 08/09/2011 07:44 AM, Somebody in the thread at some point said: > > Hi - >>> If an implementation can handle 2^64 byte messages, however, I would >>> certainly expect it to be able to handle a 2^64 byte frame. This is >>> not complex at all, and it can be done with only a few hundred bytes >>> of memory. >> This is not an issue about the complexity of handling large frames. >> >> This is an issue not handling large frames and what to do if a sender >> is talking to a receiver that has a limit. >> >> It is perfectly valid for implementations to have a limit on the size >> of frame they are prepared to handle and almost all implementations > A peer with a frame size limit is BROKEN. No. It can be running on a device with very little memory. Not every=20 client is a web browser running on a desktop. As a side note, this feature is already present in other places such as=20 SASL (RFC 4422). But anyway, I think we should agree to disagree and move on. I don't see=20 many people changing opinions after discussing this thread. From gezelter@rlgsc.com Tue Aug 9 07:43: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 C387421F87C9 for ; Tue, 9 Aug 2011 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvYOKLV0jDZr for ; Tue, 9 Aug 2011 07:43:24 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 1206421F87C3 for ; Tue, 9 Aug 2011 07:43:23 -0700 (PDT) Received: (qmail 26486 invoked from network); 9 Aug 2011 14:43:52 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 9 Aug 2011 14:43:52 -0000 Received: (qmail 6751 invoked by uid 99); 9 Aug 2011 14:43:52 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.160.228.119 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110809074351.ef1fc80126c74c6c202a919c41c7bb0b.0d555883e0.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Tue, 09 Aug 2011 07:43:51 -0700 Mime-Version: 1.0 Cc: tobias.oberstein@tassvendo.de, gregw@intalio.com, diego.pereira@ist.utl.pt Subject: [hybi] Frame Size Declaration 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, 09 Aug 2011 14:43:24 -0000 Everyone,=0A=0AFrame size, message size, and the run-time object interface = are, or had=0Abetter be as close to mutually orthogonal as can be achieved.= If not,=0Athe WebSocket protocol will have problems in the field as it is = adopted,=0Aboth for anticipated uses and for those uses that we as a group = have not=0Ayet considered.=0A=0AWhile the present run-time interface seems = to require message buffering,=0Athis is not an immutable decision. As I not= ed previously, other network=0Astacks provide examples of streamed or segme= nted interfaces for=0Asupporting applications that feel the need for messag= es longer than that=0Asupported by the underlying software/hardware infrast= ructure.=0A=0AVery large frame sizes are another issue entirely. They "redi= scover" all=0Aof the challenges that gave rise to the ARPAnet design decisi= on to use=0Apacket switching over the more familiar message switching. Even= though=0Atoday's speeds are far higher, the challenges of message switchin= g vs.=0Apacket switching remain relevant. Frames are an issue that are=0Aef= fectively invisible to the user, except insofar as the incremental=0Aoverhe= ad and possible extra per frame processing, both of which should=0Anot be s= ignificant for frame sizes measured in thousands of bytes (Note:=0Ait is im= portant to remember that the WebSocket protocol is not a bare=0Awire protoc= ol, and is always operating over an underlying sequenced,=0Avery-low error = pipe, e.g., TCP). =0A=0AThe main user perceived issue is latency for contro= l messages (and=0Alatency impacts on multiplexed streams, when they are int= egrated into=0Athe protocol). I cannot see a significant benefit to very la= rge (e.g., >=0A2**16) frames.=0A=0AAs has been said, there will be limits i= n any infrastructure. I see no=0Areason why a control regime that states th= at proxies in the path may=0Areduce maximum frame size at session establish= ment will give rise to any=0Aproblems.=0A=0AFrame level integrity controls = would need to be recomputed by such=0Aproxies upon frame fragmentation. Ove= rall message integrity controls are=0Abest done at the message level, and t= hus would be unaffected by frame=0Alevel issues.=0A=0AIn summary, maximum f= rame size should be negotiated on a=0Aconnection-by-connection basis (and o= n a sub-channel basis in any=0Amultiplexing scheme). Intermediaries should = be free to further reduce=0Aframe sizes. Frame size should not affect any u= ser level interfaces.=0AFrame size, message size, and user API should be mu= tually orthogonal=0Aissues. As a footnote, techniques for processing very l= arge messages=0Awithout the need for entire message to be stored have been = well-studied=0Asince at least the Second World War, and are suitable for ma= ny, if not=0Aall applications creating extremely large messages.=0A=0A- Bob= Gezelter, http://www.rlgsc.com=0A From andy@warmcat.com Tue Aug 9 08:43:27 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 877EE21F8B6F for ; Tue, 9 Aug 2011 08:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi6mDMXV0Moo for ; Tue, 9 Aug 2011 08:43:27 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 037C621F8A1A for ; Tue, 9 Aug 2011 08:43:26 -0700 (PDT) Message-ID: <4E4155B8.6020708@warmcat.com> Date: Tue, 09 Aug 2011 16:43:52 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Alexey Melnikov References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <4E413C9B.4000103@isode.com> In-Reply-To: <4E413C9B.4000103@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 15:43:27 -0000 On 08/09/2011 02:56 PM, Somebody in the thread at some point said: > Andy Green (林安廸) wrote: >> On 08/09/2011 07:44 AM, Somebody in the thread at some point said: >> >> Hi - >>>> If an implementation can handle 2^64 byte messages, however, I would >>>> certainly expect it to be able to handle a 2^64 byte frame. This is >>>> not complex at all, and it can be done with only a few hundred bytes >>>> of memory. >>> This is not an issue about the complexity of handling large frames. >>> >>> This is an issue not handling large frames and what to do if a sender >>> is talking to a receiver that has a limit. >>> >>> It is perfectly valid for implementations to have a limit on the size >>> of frame they are prepared to handle and almost all implementations >> A peer with a frame size limit is BROKEN. > No. It can be running on a device with very little memory. Not every > client is a web browser running on a desktop. Right, I wrote libwebsockets for exactly that case. > As a side note, this feature is already present in other places such as > SASL (RFC 4422). > > But anyway, I think we should agree to disagree and move on. I don't see > many people changing opinions after discussing this thread. Maybe so, but in fact there was a thread about exactly this some months ago which did usefully change some peoples' opinions about how to architect a websocket parser. If you treat it as a byte stream and pass on whatever payload you can buffer to upper layers as it comes in, you do not need to get into the mindset of "buffering frames" and then your code is freed from limits around frame size. -Andy From ferg@caucho.com Tue Aug 9 08:45: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 7CF8921F8A35 for ; Tue, 9 Aug 2011 08:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[AWL=-0.279, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nKTfNNzT1bw for ; Tue, 9 Aug 2011 08:45:03 -0700 (PDT) Received: from nm24.bullet.mail.sp2.yahoo.com (nm24.bullet.mail.sp2.yahoo.com [98.139.91.94]) by ietfa.amsl.com (Postfix) with SMTP id E4D3321F8A1A for ; Tue, 9 Aug 2011 08:45:03 -0700 (PDT) Received: from [98.139.91.69] by nm24.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 15:45:31 -0000 Received: from [98.139.91.56] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 15:45:31 -0000 Received: from [127.0.0.1] by omp1056.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 15:45:31 -0000 X-Yahoo-Newman-Id: 62624.97691.bm@omp1056.mail.sp2.yahoo.com Received: (qmail 66269 invoked from network); 9 Aug 2011 15:45:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312904731; bh=HkGvHODjQXBbvzjOcgGovmljayBIDG1GL9BWT/LIBJk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=IA+FIaRXK4LM/cIN67XvLjbKl2mujBQFYcLHjWWNolWk/eC8S2h9CliB3XguEXrw50DoUwh9McawdOZSxrWHJ34JJEE77TemicKAeyqqIiNO2FyuLU796O3+YO2+j6eHqk6NaTYvZzN+jr8gQn35jqO5pWhqOPHJ8dBcUfea8JU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: DIbm5zQVM1mfNazNxv7ez1kLVT4jzA_12NDpHOw87RB2Dhv RiTOn2m2QnT0nfOo78jQMfv9WSGShJSVB3dlKy_IoxEGwxvTyGp7gGpR9c2p KjDikYvosLF4I75932lHnYv7Ae6dKp6cPr7vWNdiio_lO.Ka_tkhSbgCcIgp 7JrRtcFV6D81_57.mEitsRYxx3srEe6Ie5T7jOPnOGkggIyWBt7mHy9lTmYA S6YrQHyOVwWKEBWsQZEVuuF9HfhaNpSid2gJYuWKlUeZArOPzyQZisN.mr3Q Erv6_UKOn3llE9il5a6lxQb_P.4_rEcW2zaoCl40uhwnOAOSe5HnDh8loQrV .StvDd87nfLLZIEXoViHVgeu0PBqxWf9PJLugIFJpQAmumy2X5o6suGRTN0y h0oudedjxeVKrJo7ZXptn9LAe X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 09 Aug 2011 08:45:30 -0700 PDT Message-ID: <4E415615.9080409@caucho.com> Date: Tue, 09 Aug 2011 08:45:25 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 15:45:04 -0000 On 08/09/2011 01:18 AM, Tobias Oberstein wrote: >>> It is perfectly valid for implementations to have a limit on the size >>> of frame they are prepared to handle and almost all implementations >> A peer with a frame size limit is BROKEN. > +1 > > And consequently, the "frame too large" close error code 1004 should be removed > from the spec, since it suggests the wrong, namely that it would be acceptable > for a peer to deny processing of frames above some size, and by that impose the > burden of it's brokenness onto the others. > > Rather the spec should make it explicit: > a peer MUST be capable of processing frames of any size. +1 Specifications shouldn't add complexity to work around broken implementations. -- Scott From ferg@caucho.com Tue Aug 9 08:48: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 F14E421F876A for ; Tue, 9 Aug 2011 08:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLRAME-VAQjJ for ; Tue, 9 Aug 2011 08:48:49 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ne1.yahoo.com (nm12-vm0.bullet.mail.ne1.yahoo.com [98.138.91.51]) by ietfa.amsl.com (Postfix) with SMTP id 71ECF21F875C for ; Tue, 9 Aug 2011 08:48:49 -0700 (PDT) Received: from [98.138.90.56] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2011 15:49:18 -0000 Received: from [98.138.89.169] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 09 Aug 2011 15:49:18 -0000 Received: from [127.0.0.1] by omp1025.mail.ne1.yahoo.com with NNFMP; 09 Aug 2011 15:49:18 -0000 X-Yahoo-Newman-Id: 418914.88475.bm@omp1025.mail.ne1.yahoo.com Received: (qmail 79692 invoked from network); 9 Aug 2011 15:49:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312904958; bh=4R+Nz9zCtAfJdKPPQyUAoGfI8oB8sJbavPNCbFYVmzI=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pcNklkTd+dZgFrNLQDLfIbH7ACAu61n7hcwAGErLfw8qSk1oXv2a9SxMdUJzmWfhs9zkVap5pjJlterXyVTgWl4Re98z7peLg66YfWic4zQwSMM+jfaeI1KwD5XcJaEG+P6xwVLZYsMwt76+UtWTmwSt9e2uW2vupxfJF5na+UI= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O6BNH00VM1mj0YgJVx93VBeH7iI_ARqhCMcsoaWTfwInXJx i27c5.yzXOFu.ntT1LUNqEEcAKlaREYGMrGxdyv_4isOuzOCtlVE6n5h.mcL ggqA0Z8losNg_EhwBzlrne6.LdoVFBb0eMjMjW0IevJNkGuQidQoj1HlMV1W gnx0C6wXcxgoh83NuEaiSN9KN9FfRb4yh3J4ct09Kbl1.IAH1XVCZBzCo6gG Uis4lCjrF_gK34bNSl0JnXIlzq9lPc9wkmaJu6aZ_3mvwtA9ivLrNGLHC2BE iIrlNO46oe_CC0fDtHsmLW6zei.nNdKgKY8AV48GGMAUlFf9Z5fOHSLJZny5 wvGePAPNd2_GZ2Bjgv6R7Efw9Z96pcGzEmkTggvdISTgYRygbfavTiLac4AP Jojm8tVw8.7h47ejJMUXGtFymAGLK6wgc9l7f9S_OnX38 X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.mud.yahoo.com with SMTP; 09 Aug 2011 08:49:17 -0700 PDT Message-ID: <4E4156FD.70102@caucho.com> Date: Tue, 09 Aug 2011 08:49:17 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <4E413C9B.4000103@isode.com> In-Reply-To: <4E413C9B.4000103@isode.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 15:48:50 -0000 On 08/09/2011 06:56 AM, Alexey Melnikov wrote: > Andy Green (林安廸) wrote: >> On 08/09/2011 07:44 AM, Somebody in the thread at some point said: >>> It is perfectly valid for implementations to have a limit on the size >>> of frame they are prepared to handle and almost all implementations >> A peer with a frame size limit is BROKEN. > No. It can be running on a device with very little memory. Not every > client is a web browser running on a desktop. No. A small fixed-size buffer is sufficient to handle arbitrary frame and message sizes in the WebSocket layer. You're assuming a broken WebSocket layer :) Application-layer limitations are outside the scope of the WebSocket spec. > > But anyway, I think we should agree to disagree and move on. I don't > see many people changing opinions after discussing this thread. Since we're wrapping up, "moving on" would mean dropping the proposed spec addition. -- Scott From ferg@caucho.com Tue Aug 9 08:59: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 7310D21F8C1A for ; Tue, 9 Aug 2011 08:59:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQZqhpbxcZmL for ; Tue, 9 Aug 2011 08:59:26 -0700 (PDT) Received: from nm11-vm0.bullet.mail.sp2.yahoo.com (nm11-vm0.bullet.mail.sp2.yahoo.com [98.139.91.240]) by ietfa.amsl.com (Postfix) with SMTP id F00F821F8B81 for ; Tue, 9 Aug 2011 08:59:25 -0700 (PDT) Received: from [98.139.91.67] by nm11.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 15:59:52 -0000 Received: from [98.139.91.30] by tm7.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 15:59:52 -0000 Received: from [127.0.0.1] by omp1030.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 15:59:52 -0000 X-Yahoo-Newman-Id: 661190.55938.bm@omp1030.mail.sp2.yahoo.com Received: (qmail 25909 invoked from network); 9 Aug 2011 15:59:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312905592; bh=Di91pY4QXEnFRYSSgOrxKs0XvhnYmI3wUZ+HyLu5pr4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=VeFJEoj8jBSAVEb2WLfWq6WesfBAa5RbuSFx50aOXB2b4nw+Xj+BMAqY2+u3R6PKZWGLAFqNQ7b+4SUq/eYq/wZc+SKSImtF/EuC7Fg0J8bU268RAWEZf3RgsGJ003+wL1/ZqxzBQy7nKDcgJ/nAPp9jE+INSlt4bwU2Qeufm+8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .6daxSMVM1mywEhFtBPIbdWmFZQs6IjfsCPSqp3VaLxUT3E niP.ffbcQOLZFIW2I5gPB_XWmGa1DLRNu09BO_yt4Uo2WJFbnTzEIcJ_DJHf xz0plZbuMzRACpPFeWkPvnx9Ik6xyLhmoPtml0lcsoabOt0nq7Ldgei3lENt rSIW5B5dMBSppTiqySURyxZFZ3zDVAi0DI1d2NFdjQyGRPt0RPKrG6z2YSI2 _M9sExgHYToNmE4u3V.fjRbk5R79KZrntcIwz1TiMxI4Q5d2SSIg6qUQO_Kt qQ3m4xRNqGuwTq4OtbnR6mcu_.yIIWWKojPyppyuWsKQJTifmqa2ZpZm6zOq NnBzW6a2ENbtmTkbNHh5ZR2FqV24Tm5Tbnmp6DG6rPCuZ47to.IEMI3UOTV3 BRUgVSvnb1WYYAoBtZQxPFiyzMIV5PYxWd296OjNVQ58- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp113.biz.mail.sp1.yahoo.com with SMTP; 09 Aug 2011 08:59:52 -0700 PDT Message-ID: <4E415978.3040305@caucho.com> Date: Tue, 09 Aug 2011 08:59:52 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Greg Wilkins References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 15:59:26 -0000 On 08/08/2011 08:11 PM, Greg Wilkins wrote: > On 9 August 2011 12:33, Scott Ferguson wrote: >> It's a tax on every implementation and it's an additional source of >> interoperability failures. > I don't understand how this can be seen as a tax on every > implementation because I have not seen a suggestion of an alternative > that results in a less complex or more interoperable solution. > > If we have no max frame size, then we could pretend that all > implementations will handle 2^64 frame sizes. But in reality, few > implementations will be able or allowed to handle such huge frames. Nope. Since it's easy to support arbitrary frame sizes, most implementations will do so. The ones which don't are broken. In HTTP, if a big chunk breaks POST handling, the web server is broken. In WebSockets, if a big frame breaks message handling, the WebSockets implementation is broken. > Even spooled to disk such frames represent significant resources that > many implementations might not have or be prepared to allocate to a > single connection. So either implementations will have to be > complex enough to deal with effectively infinite frames, or there is a > secret unknown interoperability failure point. What are you talking about? Streams aren't "complex". They don't require disk spooling. They only need a small, fixed buffer. I know you know how to implement streams, because you've implemented POST chunk reading, and I can't imagine that you buffer each chunk. > If an implementation wants to assume acceptable frame sizes, then it > is free to ignore max frame sizes and not declare itself - there is no > tax. Of course there's a tax. Every implementation would need to limit frames to the max-frame-size, plus the code for the negotiation, plus the QA to test the requirement. >> ... and it's an additional source of interoperability failures. > What interoperability failures are created with a declared max frame > size? Or are you saying that the problem comes from a max frame size (even if not declared). If so, do you really think all implementations MUST accept 2^64 frames? Yes. All implementations MUST accept 2^64 frames. It's not hard to implement. -- Scott From ibc@aliax.net Tue Aug 9 09:11: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 01BD221F8C9B for ; Tue, 9 Aug 2011 09:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hATaAMDY+kiL for ; Tue, 9 Aug 2011 09:11: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 2552821F8C9A for ; Tue, 9 Aug 2011 09:11:39 -0700 (PDT) Received: by qyk34 with SMTP id 34so2258921qyk.10 for ; Tue, 09 Aug 2011 09:12:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.241.205 with SMTP id lf13mr5275745qcb.292.1312906327821; Tue, 09 Aug 2011 09:12:07 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Tue, 9 Aug 2011 09:12:07 -0700 (PDT) In-Reply-To: <20110809074351.ef1fc80126c74c6c202a919c41c7bb0b.0d555883e0.wbe@email03.secureserver.net> References: <20110809074351.ef1fc80126c74c6c202a919c41c7bb0b.0d555883e0.wbe@email03.secureserver.net> Date: Tue, 9 Aug 2011 18:12:07 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, tobias.oberstein@tassvendo.de, diego.pereira@ist.utl.pt, gregw@intalio.com Subject: Re: [hybi] Frame Size Declaration 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, 09 Aug 2011 16:11:40 -0000 2011/8/9 Bob Gezelter : > In summary, maximum frame size should be negotiated on a > connection-by-connection basis (and on a sub-channel basis in any > multiplexing scheme). Intermediaries should be free to further reduce > frame sizes. Frame size should not affect any user level interfaces. 100% agreed! I hope WS authors would take it into consideration. Don't mix layers, please. OSI layers are there for being studied even if never applied XD Frames size should never affect to user/client layer. That's a MUST in every Internet protocol (and WS is already "special" enough by breaking the rule of "one TCP port =3D> one protocol/service", please don't break more). > Frame size, message size, and user API should be mutually orthogonal > issues. As a footnote, techniques for processing very large messages > without the need for entire message to be stored have been well-studied > since at least the Second World War, and are suitable for many, if not > all applications creating extremely large messages. 200% agreed. --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Tue Aug 9 09:20: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 9C3B821F8CB5 for ; Tue, 9 Aug 2011 09:20:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M79RhInQPKlV for ; Tue, 9 Aug 2011 09:20:51 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 2C87F21F8C99 for ; Tue, 9 Aug 2011 09:20:51 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qqp3O-00037k-QN; Tue, 09 Aug 2011 09:21:18 -0700 Message-ID: <4E415E99.9080609@callenish.com> Date: Tue, 09 Aug 2011 09:21:45 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins 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 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 09 Aug 2011 16:20:51 -0000 On 08/08/2011 6:01 PM, Greg Wilkins wrote: > On 2 August 2011 06:56, Tobias Oberstein wrote: >> Or is some path MTU discovery for frame length the idea? > I believe that intermediaries should be allowed to change the declared > frame size headers. In fact the frame size header should probably be > listed in Connection and be a hop by hop header as each leg may have > different frame size. > > How about this: If an intermediary does not wish to declare its maximum frame size, it MUST pass through any max-frame-size header unaltered. If it wishes to declare a maximum frame size and it is not going to refragment the frames, then it MUST send downstream a max-frame-size header that is the lesser of the two values for its own maximum frame size and the received max-frame-size header. If it wishes to declare a maximum frame size and it plans on reframing (implying that it understands all extensions in the stream), then it MAY send its own maximum frame size downstream regardless of the received maximum frame size, but it MUST refragment to frames that are no larger than the received maximum frame size. From piotrku@microsoft.com Tue Aug 9 09:22: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 7923521F871E for ; Tue, 9 Aug 2011 09:22:19 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id icBtKcmD3xdk for ; Tue, 9 Aug 2011 09:22:18 -0700 (PDT) Received: from smtp.microsoft.com (mailc.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 95EF221F867A for ; Tue, 9 Aug 2011 09:22:18 -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, 9 Aug 2011 09:22:47 -0700 Received: from TK5EX14MBXC206.redmond.corp.microsoft.com ([169.254.4.211]) by TK5EX14MLTC103.redmond.corp.microsoft.com ([157.54.79.174]) with mapi id 14.01.0323.007; Tue, 9 Aug 2011 09:22:47 -0700 From: Piotr Kulaga To: Alexey Melnikov , Greg Wilkins Thread-Topic: [hybi] "Frame too large" error with and without max frame size Thread-Index: AQHMU9gnp23hf1ZESEagd1yZwlEk5JUUM1EAgACmGgD//97BkA== Date: Tue, 9 Aug 2011 16:22:47 +0000 Message-ID: References: <4E3C98BF.9030605@callenish.com> <4E411736.3030707@isode.com> In-Reply-To: <4E411736.3030707@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 16:22:19 -0000 -1 If there are no extensions, handling 2^64 frames is easy. If there are extensions that cannot be handled in a streamed way, than the = extension itself is broken. If it can be handled in a streamed way, handlin= g 2^64 frames should be fairly easy. -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Ale= xey Melnikov Sent: Tuesday, August 09, 2011 4:17 AM To: Greg Wilkins Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size Greg Wilkins wrote: > Bruce, > > I think your post is a good way to look at it. Since we have a frame > too large error, we have to deal with it. If a sender is not prepared=20 > to adjust the sizes they send in response, then we will have=20 > interoperability failures with some implementations unable to to > communicate. So senders will have to adjust the size of frames they > send. Which leaves us with 2 choices - guessing the size or using > passed value. I think guessing is a poor choice. > > The only alternative is to not have a frame too large error - which=20 > will force all implementations to have to handle indefinite lengths of > both frames and messages. In reality, few implementations will > actually be written to handle both infinite frame and message sizes=20 > and almost all will actually have a size limit of some kind. They=20 > will just not have a way to communicate this limit. > =20 Agreed. > Let's also consider the flip side. What is the harm of declaring a > max-frame-size? If there are implementations that really can handle > 2^64 frames, then they can declare that size and we've wasted a few=20 > bytes in the handshake - or they can just not declare and no bytes are > wasted. I can see why some with good implementations might see that > a declaration is not useful, but I can't see why anybody could=20 > consider it harmful. > =20 +1 _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From diogo.pereira@ist.utl.pt Tue Aug 9 09: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 07C1821F8CB0 for ; Tue, 9 Aug 2011 09:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruakG2KXlvGj for ; Tue, 9 Aug 2011 09:31:47 -0700 (PDT) Received: from smtp1.ist.utl.pt (smtp1.ist.utl.pt [IPv6:2001:690:2100:1::15]) by ietfa.amsl.com (Postfix) with ESMTP id 846F721F8CA4 for ; Tue, 9 Aug 2011 09:31:47 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.ist.utl.pt (Postfix) with ESMTP id 1CB2F7000452 for ; Tue, 9 Aug 2011 17:32:16 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp1.ist.utl.pt ([127.0.0.1]) by localhost (smtp1.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 5uIIrPE5WQcU for ; Tue, 9 Aug 2011 17:32:15 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp1.ist.utl.pt (Postfix) with ESMTP id E0AF67000433 for ; Tue, 9 Aug 2011 17:32:15 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 9847C201330D for ; Tue, 9 Aug 2011 17:32:15 +0100 (WEST) Received: by iye1 with SMTP id 1so227249iye.27 for ; Tue, 09 Aug 2011 09:32:14 -0700 (PDT) Received: by 10.231.169.130 with SMTP id z2mr2442707iby.20.1312907534097; Tue, 09 Aug 2011 09:32:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Tue, 9 Aug 2011 09:31:44 -0700 (PDT) In-Reply-To: <4E415978.3040305@caucho.com> References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E415978.3040305@caucho.com> From: Diogo Pereira Date: Tue, 9 Aug 2011 17:31:44 +0100 Message-ID: To: Scott Ferguson Content-Type: text/plain; charset=UTF-8 Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 16:31:48 -0000 On Tue, Aug 9, 2011 at 16:59, Scott Ferguson wrote: > Yes. All implementations MUST accept 2^64 frames. Browsers need to buffer the entire message, so that doesn't really work. Whether an implementation accepts a message or not should not depend on the fragmentation, though. -- Diogo From tobias.oberstein@tavendo.de Tue Aug 9 10:21: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 7ED1F21F8CD8 for ; Tue, 9 Aug 2011 10:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3ItLZIvgaJw for ; Tue, 9 Aug 2011 10:21:53 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id D551021F8CD6 for ; Tue, 9 Aug 2011 10:21:52 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Tue, 9 Aug 2011 10:22:21 -0700 From: Tobias Oberstein To: Diogo Pereira , Scott Ferguson Date: Tue, 9 Aug 2011 10:21:51 -0700 Thread-Topic: [hybi] "Frame too large" error with and without max frame size Thread-Index: AcxWsetwV9Q37JTETTO/GLwh/Dml3QABP6kQ Message-ID: <634914A010D0B943A035D226786325D422BFA11FDA@EXVMBX020-12.exch020.serverdata.net> References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E415978.3040305@caucho.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 17:21:53 -0000 > > Yes. All implementations MUST accept 2^64 frames. >=20 > Browsers need to buffer the entire message, so that doesn't really work. that is consequence of the limited API offered in the current WS JS browser= object there only is WebSocket.onmessage would there be additionally WebSocket.onmessage_begin WebSocket.onmessage_data WebSocket.onmessage_end to override, one could use streaming in JS. the browser could still provide default implementations of those, which jus= t do internal buffering, in which case you would override the WebSocket.onmessage as today. when you override one of the streaming hooks, the browser internal bufferin= g is disabled. you can have it both. From bruce@callenish.com Tue Aug 9 10:40: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 137BF21F8CD2 for ; Tue, 9 Aug 2011 10:40:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1nBTOw-Hjpm for ; Tue, 9 Aug 2011 10:40:33 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [173.247.251.126]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED9021F8CD0 for ; Tue, 9 Aug 2011 10:40:33 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QqqIY-0007Uh-Cq; Tue, 09 Aug 2011 10:41:02 -0700 Message-ID: <4E417147.7000902@callenish.com> Date: Tue, 09 Aug 2011 10:41:27 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Ferguson References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> <4E415615.9080409@caucho.com> In-Reply-To: <4E415615.9080409@caucho.com> 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] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 17:40:34 -0000 All three of you are wrong. Plain and simple. But I understand the idea that is leading you astray. The benefit to making the interfaces between layers streamy is that you can handle extremely large frames. That's great if you actually need it. If you don't, though, it is a complete waste of time. Yes, the protocol allows you to define an extremely large frame size. That is because a few people had some edge cases where they thought it would be useful. Nobody ever said that every implementation had to support frame sizes up to 2^63. If they had, I imagine the outcry against allowing that size would have been huge. There are benefits to NOT using a streaming interface. It allows you to match your implementation to the protocol spec in a much cleaner way. This makes it easier to initially implement, find bugs, and upgrade to new versions of the protocol. It also allows you to use extensions that work with a full frame of data. I've seen claims that if an extension requires that then it is broken, but that is nonsense. This is circular logic based on the mistaken notion that all implementations are required to handle enormous frame sizes. The bottom line is you don't get to decide what tradeoffs I make in my design, I do, so long as I remain within the spec. If you want to require that my implementation can handle 2^63 sized frames then get that requirement explicit in the spec. And no, the current payload length field does not make that requirement. On 09/08/2011 8:45 AM, Scott Ferguson wrote: > On 08/09/2011 01:18 AM, Tobias Oberstein wrote: >>>> It is perfectly valid for implementations to have a limit on the size >>>> of frame they are prepared to handle and almost all implementations >>> A peer with a frame size limit is BROKEN. >> +1 >> >> And consequently, the "frame too large" close error code 1004 should >> be removed >> from the spec, since it suggests the wrong, namely that it would be >> acceptable >> for a peer to deny processing of frames above some size, and by that >> impose the >> burden of it's brokenness onto the others. >> >> Rather the spec should make it explicit: >> a peer MUST be capable of processing frames of any size. > > +1 > > Specifications shouldn't add complexity to work around broken > implementations. > > -- Scott > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From alexey.melnikov@isode.com Tue Aug 9 11:41: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 3B5C821F8C78 for ; Tue, 9 Aug 2011 11:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.029 X-Spam-Level: X-Spam-Status: No, score=-102.029 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCro9CUpamsi for ; Tue, 9 Aug 2011 11:41:38 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7B1DD21F8C6C for ; Tue, 9 Aug 2011 11:41:38 -0700 (PDT) Received: from [188.28.162.80] (188.28.162.80.threembb.co.uk [188.28.162.80]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 19:42:06 +0100 Message-ID: <4E410908.5070807@isode.com> Date: Tue, 09 Aug 2011 11:16:40 +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: Diogo Pereira References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.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] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 18:41:39 -0000 Diogo Pereira wrote: >On Sat, Aug 6, 2011 at 01:09, Bruce Atherton wrote: > > >>I have shown how my architecture passes frames into a Message object that >>processes it in some way, perhaps buffering the data or perhaps discarding >>it or perhaps doing something in between. You have suggested I could just >>pass in buffer-sized blocks to the Message object regardless of frame size. >>Doing that would rule out any extension that operates on an entire frame, >>since such an extension would need the entire frame in memory at the same >>time. >> >> >No, I'm suggesting you pass buffer-sized *frames*. If no extensions >have been negotiated, you can simply read an arbitrary amount of >payload, create a new frame header with the correct payload length, >and you end up with a frame, an entire frame. A frame that you can >handle exactly as you would handle any other frame. > >If extensions have been negotiated, this may not be possible because >of some extension requirement. That is a problem that should be solved >by that extension, either by providing a way for endpoints to announce >a maximum frame size, or, if possible, by redesigning the extension in >a way that facilitates fragmentation. > > You are advocating that the problem is solved for each extension. This is not a good design, IMHO. >The base protocol does not have this limitation, and that is why it >does not need max-frame-size. It's not awful, it's just unnecessary, >and I think there is already enough unnecessary complexity in the >protocol. > > From alexey.melnikov@isode.com Tue Aug 9 11:41: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 0A34D21F8C82 for ; Tue, 9 Aug 2011 11:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.009 X-Spam-Level: X-Spam-Status: No, score=-102.009 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xlpzhLmxxZD for ; Tue, 9 Aug 2011 11:41:53 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7889121F8C7F for ; Tue, 9 Aug 2011 11:41:53 -0700 (PDT) Received: from [188.28.162.80] (188.28.162.80.threembb.co.uk [188.28.162.80]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 19:42:21 +0100 Message-ID: <4E410AE5.4060702@isode.com> Date: Tue, 09 Aug 2011 11:24:37 +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: Scott Ferguson References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C1A18.1010308@caucho.com> In-Reply-To: <4E3C1A18.1010308@caucho.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 18:41:54 -0000 Scott Ferguson wrote: > On 08/05/2011 08:14 AM, Bruce Atherton wrote: > >> Again, we are not talking about the application layer. There is no >> API in this discussion, goofy or not. We are talking about a >> Websockets implementation that chooses an 8K buffer size to accept >> frames, and chooses not to buffer multiple blocks for a frame because >> they do not want to allow the other side to launch a denial of >> service attack. >> >> How the server exposes the data in the buffer to the application is >> outside of the scope of this specification. Maybe it is a goofy frame >> API, maybe a stream, maybe through lazy messages. Whatever it is, it >> is not our problem. > > A stream based receiver can use a fixed 8k buffer to implement > arbitrary-length messages and frames without the need for > max-frame-size. That's how streams work. I don't think this is true, especially in presence of extensions like per frame compression. > There's no unlimited buffering required. The implementation processes > the message one 8k chunk at a time. If a frame is 64k, the > implementation processes the data as 8 8k chunks. From alexey.melnikov@isode.com Tue Aug 9 11:43:36 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 EB1C221F8B1B for ; Tue, 9 Aug 2011 11:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.991 X-Spam-Level: X-Spam-Status: No, score=-101.991 tagged_above=-999 required=5 tests=[AWL=-0.461, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqsZr64i52QP for ; Tue, 9 Aug 2011 11:43:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3B92121F8B08 for ; Tue, 9 Aug 2011 11:43:36 -0700 (PDT) Received: from [188.28.162.80] (188.28.162.80.threembb.co.uk [188.28.162.80]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 19:42:32 +0100 Message-ID: <4E410C41.4090400@isode.com> Date: Tue, 09 Aug 2011 11:30:25 +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: Diogo Pereira References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.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] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 18:43:37 -0000 Diogo Pereira wrote: >On Fri, Aug 5, 2011 at 16:14, Bruce Atherton wrote: > > >>We seem to be talking past each other. I am not talking about the >>application layer or any extensions, I am talking about the core Websockets >>implementation. Pretend Mux will never exist. The core protocol still should >>allow implementations to communicate the limits they can handle for frame >>size rather than sending a bunch of data that will end up being wasted. >> >> >But why would an implementation be unable to handle a large frame? > > Because it might be running on a device with limited memory, such as a cell phone. >Again, an implementation does not have to buffer the entire frame, >unless it needs to buffer the entire message, > That is incorrect. For cases where a frame needs to be unencrypted, decompressed, etc, it is very likely that the whole frame is needed to perform the operation. >in which case the >max-frame-size limit does not help. > > >>Again, we are not talking about the application layer. There is no API in >>this discussion, goofy or not. We are talking about a Websockets >>implementation that chooses an 8K buffer size to accept frames, and chooses >>not to buffer multiple blocks for a frame because they do not want to allow >>the other side to launch a denial of service attack. >> >> > >If you don't want to buffer more than 8K at a time, read 8K at a time >and pretend (creating a new header if needed) that those 8K are a >single, complete frame. What exactly is wrong with this? > > This only works in absence of any extension. We already have written down extensions which violate that. From alexey.melnikov@isode.com Tue Aug 9 11:43: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 0593521F8B08 for ; Tue, 9 Aug 2011 11:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YAZSsEnF7mx for ; Tue, 9 Aug 2011 11:43:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 3C53121F8B13 for ; Tue, 9 Aug 2011 11:43:36 -0700 (PDT) Received: from [188.28.162.80] (188.28.162.80.threembb.co.uk [188.28.162.80]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 9 Aug 2011 19:42:41 +0100 Message-ID: <4E410C70.7070702@isode.com> Date: Tue, 09 Aug 2011 11:31:12 +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: Bruce Atherton References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C1A18.1010308@caucho.com> <4E3C1FB3.4090903@callenish.com> <4E3C2C31.1080505@callenish.com> In-Reply-To: <4E3C2C31.1080505@callenish.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 18:43:37 -0000 Bruce Atherton wrote: > On 05/08/2011 9:58 AM, John Tamplin wrote: > >> On Fri, Aug 5, 2011 at 12:52 PM, Bruce Atherton >> wrote: >> >> And if the frame size is 16TB and the implementation doesn't >> provide a stream-based API? >> >> >> Then they are going to have to buffer the entire message, whether it >> is sent in a 16TB frame or tons of 1-byte frames. Either they are >> providing a steam-based API to their clients in which case they can >> fragment it as they read it or they are providing just a >> message-based API to their clients, in which case they have to buffer >> the message anyway and can simple store the received frame data into >> the message as it is received. > > Or the server can simply return an error message that says that the > frame is too large. Or the server can let the other end know ahead of > time not to send any frames that are bigger than a certain maximum. Exactly. >> Again we are talking past each other. My point is that if someone >> wants to write a client or server that can only handle frames >> that are no more than some arbitrary length, that should be a >> choice that they get to make. >> >> >> They can right now, and if they get a frame larger than they like >> they return a "frame too large" error. > > Exactly. And that is wasted effort sending data that will never be used. +1. > From my understanding, cell phone networks go to heroic lengths to > avoid sending more than they have to, such as resending TCP fragments > to avoid resending a whole packet. So why not make it easy for > everyone to avoid dropping data on the ground? > >> Why do you want to limit what an implementer can do? >> >> >> It increases complexity of senders -- every sender has to be prepared >> to throttle down the size of what it sends to an arbitrary value. >> You could argue they are going to have to be able to do that when >> MUX is added anyway and having them code their apps for it now will >> improve the ability to deploy MUX, but is it a good idea to >> speculatively add it to the spec? > > They have to do that anyway if they receive a frame too large error > and still want to communicate. The only difference is that they will > have to guess at what the right size frame might be, and may try > several times before they get it right. Agreed. From jat@google.com Tue Aug 9 11:48: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 37A6221F8B79 for ; Tue, 9 Aug 2011 11:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.956 X-Spam-Level: X-Spam-Status: No, score=-105.956 tagged_above=-999 required=5 tests=[AWL=0.020, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4TmBbghCfyj for ; Tue, 9 Aug 2011 11:48:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8094C21F8B76 for ; Tue, 9 Aug 2011 11:48:27 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p79ImuLk012464 for ; Tue, 9 Aug 2011 11:48:56 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312915736; bh=tHFn7jDc3csMDEEARV3gaMuIzx0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lCMZXPmAxgXTZe/MRfyi53KwlYl69GTyw6J70wawVNTLHvT4j8KNFYyN1ikonOUR/ HPTroKW/OJLApfdwRSKVg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=r8bGw914HvsJK4ecDCZJ1/FXu3BlBSdc/3gkmTDGUQ8VVvswnSa/HtE7iGm5VGjzQ nXiEaBsywJkdI59wv8Omg== Received: from ywb5 (ywb5.prod.google.com [10.192.2.5]) by wpaz1.hot.corp.google.com with ESMTP id p79ImtWZ001998 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 9 Aug 2011 11:48:55 -0700 Received: by ywb5 with SMTP id 5so30783ywb.12 for ; Tue, 09 Aug 2011 11:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=UKzGVW+q4WtM0VJQvhFEnUtZ5hEmz+mx/bgbwZWhDdg=; b=GEWs/3fr/QFl9NWS4j7mAejQwf9IvV2dTwywPgZXemt3e+LIWv0RXfMJsDvXHyMOQS Gd0HD0s7ME9aKGVgYrxw== Received: by 10.150.150.34 with SMTP id x34mr7590830ybd.59.1312915735307; Tue, 09 Aug 2011 11:48:55 -0700 (PDT) Received: by 10.150.150.34 with SMTP id x34mr7590824ybd.59.1312915735139; Tue, 09 Aug 2011 11:48:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 9 Aug 2011 11:48:35 -0700 (PDT) In-Reply-To: <4E410C41.4090400@isode.com> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> From: John Tamplin Date: Tue, 9 Aug 2011 14:48:35 -0400 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=000e0cd6d02e03546404aa1704f7 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 18:48:28 -0000 --000e0cd6d02e03546404aa1704f7 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 9, 2011 at 6:30 AM, Alexey Melnikov wrote: > That is incorrect. For cases where a frame needs to be unencrypted, > decompressed, etc, it is very likely that the whole frame is needed to > perform the operation. > Typically, these APIs are stream-oriented already. For example, zlib takes some chunk of input data and when its output buffer is full you write it out. You can use whatever buffer size is convenient for you, and it certainly doesn't have to be the entire size of the frame or message. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6d02e03546404aa1704f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 9, 2011 at 6:30 AM, Alexey Melnikov = <alexey.m= elnikov@isode.com> wrote:
That is incorrect. For cases where a frame needs to be un= encrypted, decompressed, etc, it is very likely that the whole frame is nee= ded to perform the operation.

Typical= ly, these APIs are stream-oriented already. =C2=A0For example, zlib takes s= ome chunk of input data and when its output buffer is full you write it out= . =C2=A0You can use whatever buffer size is convenient for you, and it cert= ainly doesn't have to be the entire size of the frame or message.=C2=A0=

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd6d02e03546404aa1704f7-- From tobias.oberstein@tavendo.de Tue Aug 9 11:52:11 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 BE2CD21F8A7D for ; Tue, 9 Aug 2011 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j8ZFrqX7r3eR for ; Tue, 9 Aug 2011 11:52:11 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id E097421F8AB9 for ; Tue, 9 Aug 2011 11:52:05 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 9 Aug 2011 11:52:34 -0700 From: Tobias Oberstein To: Alexey Melnikov , Diogo Pereira Date: Tue, 9 Aug 2011 11:52:04 -0700 Thread-Topic: [hybi] max frame size. was: consensus call on ability to announce max frame size Thread-Index: AcxWxFVxB0MMRB3hQh+yuzATQdGBhAAANovw Message-ID: <634914A010D0B943A035D226786325D422BFA1205C@EXVMBX020-12.exch020.serverdata.net> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> In-Reply-To: <4E410C41.4090400@isode.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 09 Aug 2011 18:52:11 -0000 >>But why would an implementation be unable to handle a large frame? >> =20 >> > Because it might be running on a device with limited memory, such as a ce= ll > phone. where is the problem? >=20 > >Again, an implementation does not have to buffer the entire frame, > >unless it needs to buffer the entire message, > > > That is incorrect. For cases where a frame needs to be unencrypted, > decompressed, etc, it is very likely that the whole frame is needed to > perform the operation. for crypto, use a stream cipher .. i.e. AES-CTR From andy@warmcat.com Tue Aug 9 11:55: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 2BD7621F8B75 for ; Tue, 9 Aug 2011 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KEYgz8jLDR8B for ; Tue, 9 Aug 2011 11:55:56 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 89CA621F88A0 for ; Tue, 9 Aug 2011 11:55:56 -0700 (PDT) Message-ID: <4E4182D8.10905@warmcat.com> Date: Tue, 09 Aug 2011 19:56:24 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> <4E415615.9080409@caucho.com> <4E417147.7000902@callenish.com> In-Reply-To: <4E417147.7000902@callenish.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 09 Aug 2011 18:55:57 -0000 On 08/09/2011 06:41 PM, Somebody in the thread at some point said: > All three of you are wrong. Plain and simple. But I understand the idea > that is leading you astray. Well, it's nice that things are simple for you ^^ > The benefit to making the interfaces between layers streamy is that you > can handle extremely large frames. That's great if you actually need it. > If you don't, though, it is a complete waste of time. Frames in websockets are pretty much the same deal as packets in regular TCP/IP traffic. They contain payload but how big they are, how often they come, how fragmented they got needs to be immaterial to the content they're containing. In particular the information about the packet, other than telling you how much more payload just arrived to add to the pile, is not only meaningless but dangerous to depend on. > Yes, the protocol allows you to define an extremely large frame size. > That is because a few people had some edge cases where they thought it > would be useful. Nobody ever said that every implementation had to Months ago there was a thread examining this from the angle of two or three generations of best Ethernet bandwidth possible and 2^63 was still taking many years. The best explanation I was given was that 2^63 was wanted as a practically unreachable goal to enforce the code to support in fact arbitrary frame lengths! That's exactly what's being violated by wanting to introduce frame mtu concept - 2^63 is then perfectly pointless. > support frame sizes up to 2^63. If they had, I imagine the outcry > against allowing that size would have been huge. Hm. Well, believe me you shouldn't take from the fact it's in this spec that there was no huge outcry against it. > There are benefits to NOT using a streaming interface. It allows you to > match your implementation to the protocol spec in a much cleaner way. > This makes it easier to initially implement, find bugs, and upgrade to > new versions of the protocol. > > It also allows you to use extensions that work with a full frame of > data. I've seen claims that if an extension requires that then it is > broken, but that is nonsense. This is circular logic based on the > mistaken notion that all implementations are required to handle enormous > frame sizes. > > The bottom line is you don't get to decide what tradeoffs I make in my > design, I do, so long as I remain within the spec. If you want to This is not about chest-beating but arriving at agreement about what should be in the spec. In particular the two camps about this issue seem to fall into people who think a frame is meaningful in itself and those that understand it as am immediately discarded wrapper for "some more payload" which must then be parsed according to the payload protocol and without expectation of clean boundaries. -Andy From phil127@gmail.com Tue Aug 9 12:57:47 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 06A495E8006 for ; Tue, 9 Aug 2011 12:57:47 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BskPgjvtYLUS for ; Tue, 9 Aug 2011 12:57:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 997CD5E8003 for ; Tue, 9 Aug 2011 12:57:43 -0700 (PDT) Received: by fxe6 with SMTP id 6so405156fxe.31 for ; Tue, 09 Aug 2011 12:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=3igbfvBRSgHELGYjqCsjk8mKacz1I9ScEi7ufK9UxcA=; b=WvhLs+Tblj7qCgd1Vo7z7oRnemk3K9BwogoXhDhnxBcrGtloqVxXA+3iteuVjUAKug zmbpqH8J1yUzatXNXiQz3HYAniwassa48eV66ntZ0QdB8+vHlNSbJF06yIKjgZWJXyTX U0qDA3AvI4oi6DLWgT9FEcigvL3fFCvzoMU9U= Received: by 10.204.42.70 with SMTP id r6mr2149873bke.225.1312919892472; Tue, 09 Aug 2011 12:58:12 -0700 (PDT) Received: from [212.201.73.238] (pptp-212-201-73-238.pptp.stw-bonn.de [212.201.73.238]) by mx.google.com with ESMTPS id s2sm32049bkd.22.2011.08.09.12.58.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 12:58:11 -0700 (PDT) Message-ID: <4E419151.8000305@gmail.com> Date: Tue, 09 Aug 2011 21:58:09 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Hybi X-Enigmail-Version: 1.2 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: [hybi] Message (not frame) sizes and the JavaScript API 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, 09 Aug 2011 19:57:47 -0000 Hello everyone, recently there has been much discussion about both maximum lengths for frames and for messages. If I understand it correctly, the main argument against maximum lengths is that WS implementations could easily pass on data to the application layer chunk-wise, via a streaming API. However, right now, for the client side, the HTML5 websocket API mandates that browsers that act as WS clients must buffer the whole message and pass it on to the scripting layer only after it has been fully received. >From a web developer perspective, I think a message-based API is both a lot easier to use and a lot more secure than a streaming API, therefore it shouldn't be given up lightly. However, consider e.g. a malicious website that sends an infinite stream of fragments but never actually completes the message. I would like to ask how a robust, conforming browser implementation is supposed to behave in such a case, apart from consuming all available memory and crashing. In order to implement a message-based API like the HTML5 JS API, wouldn't you actually need a maximum message size? Regards From ferg@caucho.com Tue Aug 9 13:11: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 D647821F8C50 for ; Tue, 9 Aug 2011 13:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[AWL=0.597, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfk0qja5uQiR for ; Tue, 9 Aug 2011 13:11:30 -0700 (PDT) Received: from nm18.bullet.mail.sp2.yahoo.com (nm18.bullet.mail.sp2.yahoo.com [98.139.91.88]) by ietfa.amsl.com (Postfix) with SMTP id 4C3C521F8BB6 for ; Tue, 9 Aug 2011 13:11:30 -0700 (PDT) Received: from [98.139.91.69] by nm18.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 20:12:00 -0000 Received: from [98.139.91.59] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 20:12:00 -0000 Received: from [127.0.0.1] by omp1059.mail.sp2.yahoo.com with NNFMP; 09 Aug 2011 20:12:00 -0000 X-Yahoo-Newman-Id: 41280.3750.bm@omp1059.mail.sp2.yahoo.com Received: (qmail 22727 invoked from network); 9 Aug 2011 20:12:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1312920720; bh=QGjlyXz+yPxK08zubgjyJ8BLP4JE5yq6pGaO1xVJUjo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=j30GGGr7MKVWQLKCacZEG/NgpssStLjlJPRlIZAaS+q0FKr7kDVS4X1rZkBaxrRLbEmbVNQhF115aiuUZ0kdHBu1PBUFMrSY13CNepx8n3QFT6F2pbuM8SCZDLF/zFgP6mqoTTR3mXWQtuyX4QtjVURwLvQrroXDpVDmfrSwdu0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: UgSZUd8VM1l1eu0E183Os8QaMCocUUeNvYQl69A8cJZeL2y M4FhHJv3zo6vC.H7TubiWeHmaLo8tRlm.5MgPcDUcEKqeRcl8n83FXRt4qQn .tPtCoB3hPBejyKM2wjskucpQCAahrMTDCJkwttvSSebYWobFA3VeXZeJIFO EHEIAdPrSlCNx3N7TtLJVOYBw_pq7ccbIUak0uWnsgkTyREMR27NxfsZLE3F O29pxbJwN7q1ajIncZZm1j0pbLcM0Qo45ZS_Iv983V5qcn_XJ_TmE0ydulEj decSkSGUGr8VY8baqWr6ADwjlzKiratkSaoU53Gv7Z4L9UZf21HrLTfq36hf crO6Kz_95VbTWPJfGsXpXpyAwDlZ37Fwl1oUX4qSGZQN8dtx9Y7.cv_v1D0l xztdwgM5uwdepqyAV27INGAOsw6sSB9c- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 09 Aug 2011 13:11:59 -0700 PDT Message-ID: <4E41948F.1010308@caucho.com> Date: Tue, 09 Aug 2011 13:11:59 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: Diogo Pereira References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E415978.3040305@caucho.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 09 Aug 2011 20:11:31 -0000 On 08/09/2011 09:31 AM, Diogo Pereira wrote: > On Tue, Aug 9, 2011 at 16:59, Scott Ferguson wrote: >> Yes. All implementations MUST accept 2^64 frames. > Browsers need to buffer the entire message, so that doesn't really work. Ok, more precisely, if an implementation can accept a message of size N, it must accept that message as a single frame of size N (where N < 2^63). > Whether an implementation accepts a message or not should not depend > on the fragmentation, though. Exactly. -- Scott > -- > Diogo > > > From paul@colomiets.name Tue Aug 9 15:24: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 BFAC021F8C19 for ; Tue, 9 Aug 2011 15:24:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCpV2gB9MQhA for ; Tue, 9 Aug 2011 15:23:59 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2EC21F8C13 for ; Tue, 9 Aug 2011 15:23:57 -0700 (PDT) Received: by wyg8 with SMTP id 8so347736wyg.31 for ; Tue, 09 Aug 2011 15:24:27 -0700 (PDT) Received: by 10.216.65.203 with SMTP id f53mr5118104wed.54.1312928667170; Tue, 09 Aug 2011 15:24:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.221.18 with HTTP; Tue, 9 Aug 2011 15:24:07 -0700 (PDT) X-Originating-IP: [91.203.48.31] From: Paul Colomiets Date: Wed, 10 Aug 2011 01:24:07 +0300 Message-ID: To: Server-Initiated HTTP Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Maximum frame size as a security issue 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, 09 Aug 2011 22:24:00 -0000 Hi, There is a security problem with maximum frame size. If we allow to announce this value then we expect all implementations to be able to obey as small frames as specified. So specifying maximum frame size of 1 byte could increase the chance of successful DOS attack. Because small frame size means that not only traffic and memory usage will be higher, but also for lots of implementations it probably means that each frame will be another TCP packet. This restriction does not apply to maximum message size, as messages with lower size are expected to not to be sent as opposed to be broken into pieces. Thoughts? -- Paul From gregw@intalio.com Tue Aug 9 17:08: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 29FFA21F8C1D for ; Tue, 9 Aug 2011 17:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.903 X-Spam-Level: X-Spam-Status: No, score=-2.903 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48xjMq64Niap for ; Tue, 9 Aug 2011 17:08: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 8D2EA21F8C1B for ; Tue, 9 Aug 2011 17:08:54 -0700 (PDT) Received: by vxi29 with SMTP id 29so542235vxi.31 for ; Tue, 09 Aug 2011 17:09:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.139 with SMTP id dc11mr5513905vdb.28.1312934964238; Tue, 09 Aug 2011 17:09:24 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Tue, 9 Aug 2011 17:09:24 -0700 (PDT) In-Reply-To: References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> Date: Wed, 10 Aug 2011 10:09:24 +1000 Message-ID: From: Greg Wilkins To: Diogo Pereira Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 10 Aug 2011 00:08:55 -0000 On 9 August 2011 23:54, Diogo Pereira wrote: > Well, if handling large frames is as easy as handling small frames, > then what is the reason for having a frame size limit? On 10 August 2011 01:59, Scott Ferguson wrote: > Since it's easy to support arbitrary frame sizes, most implementations will > do so. The ones which don't are broken. There are many reasons to not support 2^64 frames is not because of simple/broken implementations. Not the least to avoid DOS attacks. In HTTP there is not protocol limit to the length of the URL, header fields or form content body, but in practise all servers implement size limits on all of these. Unfortunately these limits are not disclosed so applications have to guess what they are - typically settling for lowest commonly know values. Worse still, many applications are deployed without any knowledge that such limits exist and then fail in production as user data gets bigger and blows out one limit or the other. Implementations are not going to handle 2^64 frames not because they don't know how, or because the implementers are lazy, stupid or both. Frame sizes will be limited for good resource allocation reasons. This will also apply to implementations that do support dynamic growing buffers for frames. Are there any implementations out there today that can really accept a 2^64 frame without blowing memory or filling up their hard disk? From gregw@intalio.com Tue Aug 9 17:13: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 A263A21F8C54 for ; Tue, 9 Aug 2011 17:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.904 X-Spam-Level: X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1RSop5JIYTU for ; Tue, 9 Aug 2011 17:13:32 -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 94E8D21F8C53 for ; Tue, 9 Aug 2011 17:13:31 -0700 (PDT) Received: by vxi29 with SMTP id 29so544896vxi.31 for ; Tue, 09 Aug 2011 17:14:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.139 with SMTP id dc11mr5516695vdb.28.1312935241233; Tue, 09 Aug 2011 17:14:01 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Tue, 9 Aug 2011 17:14:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Aug 2011 10:14:01 +1000 Message-ID: From: Greg Wilkins To: Server-Initiated HTTP Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Maximum frame size as a security issue 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, 10 Aug 2011 00:13:33 -0000 On 10 August 2011 08:24, Paul Colomiets wrote: > Hi, > > There is a security problem with maximum frame size. If we allow to > announce this value then we expect all implementations to be able to > obey as small frames as specified. So specifying maximum frame size of > 1 byte could increase the chance of successful DOS attack. Because > small frame size means that not only traffic and memory usage will be > higher, but also for lots of implementations it probably means that > each frame will be another TCP packet. > > This restriction does not apply to maximum message size, as messages > with lower size are expected to not to be sent as opposed to be broken > into pieces. > > Thoughts? Servers are unlikely to specify a max frame size that will cause a DOS attack on themselves, so the attack vector of concern is a client saying that it will only accept 1 byte frames and thus causing the server to do more work to send it each message. Servers are under no obligation to accept connections and could simply reject connections attempted with trivially small frame sizes. We could even say that max frame size MUST be greater or equal to the 126 byte small frame size. cheers From gregw@intalio.com Tue Aug 9 17:18: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 0B9EA11E80CE for ; Tue, 9 Aug 2011 17:18:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDjz1vKWW4T5 for ; Tue, 9 Aug 2011 17:18:14 -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 7862B11E80BB for ; Tue, 9 Aug 2011 17:18:14 -0700 (PDT) Received: by vws12 with SMTP id 12so535079vws.31 for ; Tue, 09 Aug 2011 17:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr7832879vdg.296.1312935524189; Tue, 09 Aug 2011 17:18:44 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Tue, 9 Aug 2011 17:18:44 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFA11D80@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFA11D80@EXVMBX020-12.exch020.serverdata.net> Date: Wed, 10 Aug 2011 10:18:44 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] consensus call on ability to announce max frame size 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, 10 Aug 2011 00:18:15 -0000 On 9 August 2011 17:34, Tobias Oberstein wrote: > So, does "max. frame size" make WebSockets any simpler or more efficient? > I guess not. > > Does "max. frame size" make WebSockets more compatible (with intermediaries)? > I don't know. Remember this is not about having a max frame size or not. Every implementation will have a max frame size - even if that is 2^64 or imposed by the amount of free disk space. This is a question about knowing what that limit is or not. Does having an unknown limit make any implementation simpler or more efficient? Maybe by ignoring the fact that such a limit exists, but the price is that you become more fragile and will fail necessarily if that limit is exceeded. cheers From gregw@intalio.com Tue Aug 9 17:36: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 A238221F8C75 for ; Tue, 9 Aug 2011 17:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.758 X-Spam-Level: X-Spam-Status: No, score=-2.758 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7rZvu9QhHijq for ; Tue, 9 Aug 2011 17:36:52 -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 19E3D21F8C70 for ; Tue, 9 Aug 2011 17:36:51 -0700 (PDT) Received: by vxi29 with SMTP id 29so556862vxi.31 for ; Tue, 09 Aug 2011 17:37:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr7845576vdg.296.1312936641827; Tue, 09 Aug 2011 17:37:21 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Tue, 9 Aug 2011 17:37:21 -0700 (PDT) In-Reply-To: <4E4182D8.10905@warmcat.com> References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> <4E415615.9080409@caucho.com> <4E417147.7000902@callenish.com> <4E4182D8.10905@warmcat.com> Date: Wed, 10 Aug 2011 10:37:21 +1000 Message-ID: From: Greg Wilkins To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 10 Aug 2011 00:36:52 -0000 On 10 August 2011 04:56, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" wrote: > In particular the two camps about this issue seem to fall into people who > think a frame is meaningful in itself and those that understand it as am > immediately discarded wrapper for "some more payload" which must then be > parsed according to the payload protocol and without expectation of clean > boundaries. Andy, you have misrepresented the case for a declared frame size limit, so I'm guessing you are not understanding it. So last attempt to express it then I'll rest on this one.... ALL implementations will have a frame size limit. For some that might be imposed by a fixed buffer size, for others that might be from a memory allocation policy; yet some might be constrained by available disk space; and a few cases it might even be able to handle 2^64 frames. But it is an indisputable fact that frames are of limited size - either by protocol, by policy, by deployment or by implementation. Thus give that limits exist, this is only a question of cost/benefit in providing a standard mechanism of disclosing what that limit is. There have been numerous benefits described of a disclosed limit. I accept that these benefits are not universal, but I do believe they exist in a significant number of cases. I have seen no substantial costs. Perhaps one could argue that a disclosed limit will force more implementation to support fragmentation of sends - but lack of disclosed limits will only make implementations without fragmented sends inoperable with implementations that have frame limits. A declared limit will at least give an implementation the option of avoiding such a failure. regards From gregw@intalio.com Tue Aug 9 17:51: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 C635022800E for ; Tue, 9 Aug 2011 17:51:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.906 X-Spam-Level: X-Spam-Status: No, score=-2.906 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XsiuzMNDlTpR for ; Tue, 9 Aug 2011 17:51: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 3EB8021F8C13 for ; Tue, 9 Aug 2011 17:51:16 -0700 (PDT) Received: by vws12 with SMTP id 12so552495vws.31 for ; Tue, 09 Aug 2011 17:51:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.88.2 with SMTP id bc2mr4497864vdb.162.1312937503796; Tue, 09 Aug 2011 17:51:43 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Tue, 9 Aug 2011 17:51:43 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> Date: Wed, 10 Aug 2011 10:51:43 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 00:51:16 -0000 On 9 August 2011 17:40, Tobias Oberstein wrot= e: >> > =A0There will be frame size limits in some implementations, >> >> Exactly! =A0This is a choice between have a frame size limit or not. >> All implementations will have a frame size limit declared or not. >> There might even conceivably be implementations that can handle 2^64 >> frames - but that will not be in a browser running on your i-phone any t= ime >> soon! > > You seem to suggest that having max. frame size would help browsers, but = it won't. It is not about "having" a max frame size. All implementation will have a max frame size even if that is 2^64. This is about knowing what the max frame size is. > Since the current JS API for WebSockets is message based, and a message c= an be > composed of an infinite number of frames, even a max. frame size won't he= lp. This does not solve the problem of too large messages. That is a separate issue. > Either you have max. _message_ size negotiated or have a streaming API. Streaming does not help as frame boundaries can be arbitrary. In the simplest case, what is a JS application going to do with 3 bytes of a 6 byte UTF-8 character? An extra layer of buffering? What if there is an extension that puts a digital signature on every frame, so that data can be integral but not confidential. Data in such a frame cannot be streamed to an application until the entire frame is received and the signature verified. regards From ferg@caucho.com Tue Aug 9 18:07:47 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 4611E21F8AE1 for ; Tue, 9 Aug 2011 18:07:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.076 X-Spam-Level: X-Spam-Status: No, score=-2.076 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMhLkZ1YlpO8 for ; Tue, 9 Aug 2011 18:07:46 -0700 (PDT) Received: from nm2.access.bullet.mail.mud.yahoo.com (nm2.access.bullet.mail.mud.yahoo.com [66.94.237.203]) by ietfa.amsl.com (Postfix) with SMTP id C321E21F8ADC for ; Tue, 9 Aug 2011 18:07:46 -0700 (PDT) Received: from [66.94.237.197] by nm2.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Aug 2011 01:08:14 -0000 Received: from [98.139.221.61] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 10 Aug 2011 01:08:14 -0000 Received: from [127.0.0.1] by smtp102.biz.mail.bf1.yahoo.com with NNFMP; 10 Aug 2011 01:08:14 -0000 X-Yahoo-Newman-Id: 93627.42687.bm@smtp102.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: W4Gg7VQVM1lwYsCsuR7kiLXgmTQXtoL2BIqHdJZ1xR0um0D tOBUTdXXgNAcIQhLO0y43PfXkITVl0AAMPdjA_hpgZh1MB9q9SHGa.Cqi53e lqNiTsQFWlRupzF.XWNMD02srvs7BbzdiTUhgqQi4kVT0e2Wwgpg30qw5sjp 0YZBiLiWCx79efej1is39OAV7KZO9N4p69gcPHrglIedceDqZCpePL6eIefJ KtjvnoRT87EjhpbXDMHuShI4X0t2y1vrmCgmNyBEHAmfO8tX9aQdGAvNXAcU 5X9dToBguUF5gT134ebwG5TNgHImY8ZSOHVWgak4EN1kJSRi28Lfxp1gKuaM 6gWoWhyrrq74bn0.v_P7j.RmaQqZM_IK2MDgiJnJtEg7bDerICeqAJd0rGoh X3wcHCKu4gSj1oQ-- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp102.biz.mail.bf1.yahoo.com with SMTP; 09 Aug 2011 18:08:13 -0700 PDT Message-ID: <4E41D9FC.5000407@caucho.com> Date: Tue, 09 Aug 2011 18:08:12 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 10 Aug 2011 01:07:47 -0000 On 08/09/2011 05:09 PM, Greg Wilkins wrote: > Are there any implementations out there today that can really accept a > 2^64 frame without blowing memory or filling up their hard disk? Of course there are. You don't even need a buffer; you can pass-through data reads to underlying socket stream and use the caller's buffer. In fact, if the application was a /dev/null or a hash generator or an echo service, the application could handle that message without needing any extra memory. (Granted, the Sun would burn out first, but it wouldn't require any memory.) There's no need for infinite memory or disk space. A small fixed buffer on top of the raw socket can be useful for efficiency, but even that isn't strictly necessary. -- Scott From gregw@intalio.com Tue Aug 9 19:18: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 5E13A11E807D for ; Tue, 9 Aug 2011 19:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opxw5wxOSuPx for ; Tue, 9 Aug 2011 19:18:22 -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 C334311E8070 for ; Tue, 9 Aug 2011 19:18:22 -0700 (PDT) Received: by vxi29 with SMTP id 29so613574vxi.31 for ; Tue, 09 Aug 2011 19:18:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.27.36 with SMTP id q4mr7912589vdg.296.1312942732781; Tue, 09 Aug 2011 19:18:52 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Tue, 9 Aug 2011 19:18:52 -0700 (PDT) In-Reply-To: <4E41D9FC.5000407@caucho.com> References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E41D9FC.5000407@caucho.com> Date: Wed, 10 Aug 2011 12:18:52 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 10 Aug 2011 02:18:23 -0000 On 10 August 2011 11:08, Scott Ferguson wrote: > On 08/09/2011 05:09 PM, Greg Wilkins wrote: >> >> Are there any implementations out there today that can really accept a >> 2^64 frame without blowing memory or filling up their hard disk? > > Of course there are. > > You don't even need a buffer; you can pass-through data reads to underlying > socket stream and use the caller's buffer. > > In fact, if the application was a /dev/null or a hash generator or an echo > service, the application could handle that message without needing any extra > memory. (Granted, the Sun would burn out first, but it wouldn't require any > memory.) So you say that there are implementations out there (or a likely to be written) that provide a streaming interface and are running application that are /dev/null, hash generator or echo. Let's assume that such beasties do actually exist - they still have a max frame size! it is 2^64. How are such implementations adversely impacted by the ability to declare that they can handle full sized frames? I would posit that such implementations are going to be SO rare that they would indeed benefit from being able to declare their ability to handle full size frames: WebSocket-Max-Frame-Size: 18446744070000000000 So that any other implementation that could possibly send such a frame would know that it had connected with an implementation that could handle it. Without the ability to declare the ability to handle such huge frames, no sane sender will ever attempt to actually send such a frame. regards From w@1wt.eu Tue Aug 9 23:21: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 6709B21F857D for ; Tue, 9 Aug 2011 23:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.054 X-Spam-Level: X-Spam-Status: No, score=-4.054 tagged_above=-999 required=5 tests=[AWL=-2.011, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWrpPQTodWM9 for ; Tue, 9 Aug 2011 23:21:14 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 8A20421F856C for ; Tue, 9 Aug 2011 23:21:12 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p7A6LZM3001816; Wed, 10 Aug 2011 08:21:35 +0200 Date: Wed, 10 Aug 2011 08:21:35 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110810062135.GH31746@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP Subject: Re: [hybi] Maximum frame size as a security issue 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, 10 Aug 2011 06:21:14 -0000 On Wed, Aug 10, 2011 at 10:14:01AM +1000, Greg Wilkins wrote: > Servers are unlikely to specify a max frame size that will cause a DOS > attack on themselves, so the attack vector of concern is a client > saying that it will only accept 1 byte frames and thus causing the > server to do more work to send it each message. > > Servers are under no obligation to accept connections and could simply > reject connections attempted with trivially small frame sizes. We > could even say that max frame size MUST be greater or equal to the 126 > byte small frame size. I think that this value of 126 is a good idea. It could be the default when no frame size is specified, making it easier to build small implementations (no FS negociation, only one-byte length). 126 is also friendly to overloaded intermediaries that have to shrink their buffers to save memory. And enforcing a minimum supported frame size is comparable to what's done with TCP : any IP implementation must support at least 576 bytes, so a TCP stack must always be prepared to receive up to 536 bytes. So I think we should add the following to the spec : Any recipient must be prepared to receive frames of up to 126 bytes. And if we achieve consensus on max-frame-size, we could add something like this : Larger frames may be sent if the recipient indicates its support using the max-frame-size option. Frames larger than this value will lead to undefined behaviour, they may randomly be accepted, dropped, or cause the connection to be closed. A WS agent MUST NOT send frames larger than the indicated max-frame-size, or 126 bytes is no max-frame-size is announced. Thoughts ? Willy From andy@warmcat.com Tue Aug 9 23:34: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 DC04A11E807E for ; Tue, 9 Aug 2011 23:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jkh6gBI6RtaA for ; Tue, 9 Aug 2011 23:34:29 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9D211E807D for ; Tue, 9 Aug 2011 23:34:28 -0700 (PDT) Message-ID: <4E42268C.50306@warmcat.com> Date: Wed, 10 Aug 2011 07:34:52 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> <4E40E91B.8050508@warmcat.com> <634914A010D0B943A035D226786325D422BFA11D85@EXVMBX020-12.exch020.serverdata.net> <4E415615.9080409@caucho.com> <4E417147.7000902@callenish.com> <4E4182D8.10905@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error / frame size limit == BROKEN 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, 10 Aug 2011 06:34:30 -0000 On 08/10/2011 01:37 AM, Somebody in the thread at some point said: > On 10 August 2011 04:56, "Andy Green (林安廸)" wrote: >> In particular the two camps about this issue seem to fall into people who >> think a frame is meaningful in itself and those that understand it as am >> immediately discarded wrapper for "some more payload" which must then be >> parsed according to the payload protocol and without expectation of clean >> boundaries. > > Andy, > > you have misrepresented the case for a declared frame size limit, so Actually I believe I have captured the underlying problem in the quote above. > I'm guessing you are not understanding it. So last attempt to express > it then I'll rest on this one.... Having implemented this, and now reading what you have written, I believe I understand it better than your good self. > ALL implementations will have a frame size limit. For some that > might be imposed by a fixed buffer size, for others that might be from > a memory allocation policy; yet some might be constrained by available > disk space; and a few cases it might even be able to handle 2^64 > frames. Above you first say "ALL" implementations have a frame size limit, then admit that the limit may be 2^64 (you mean 2^63) which is "no limit" since it's the biggest the protocol can deploy. What are you even trying to say? You are confusing message size limit with frame size limit? libwebsockets (and it's nothing special about that, just the parsing architecture it has) has no frame size limit except the biggest size that can be told by websocket itself. Neither "fixed buffer size", nor "memory allocation policy" nor "available disk space". What you have written above is wrong. If you view a "frame" as nothing more important than an "immediately discarded wrapper for some more payload", just there to tell you how many bytes to skip to find the next frame header, your mind is freed from this focus on dealing with frames as atomic entities. You can take in as much of the payload as convenient (1 byte at a time if you like, or 256 bytes or whatever) and pass it up to whatever will consume it, and keep doing that until all the frame payload is all used. The frame comes to you in TCP/IP packets, so you can play that game the moment the first packet comes without waiting for any more let alone the whole frame. > But it is an indisputable fact that frames are of limited size - > either by protocol, by policy, by deployment or by implementation. I not only dispute it but have code showing that is wrong. > Thus give that limits exist, this is only a question of cost/benefit > in providing a standard mechanism of disclosing what that limit is. MESSAGES may have to be held atomically, as in the browser / javascript API case. FRAME size limit does nothing for that. I can burst my message buffer by setting the frame limit at 2/3 the message buffer and sending two frames. What have you achieved with a "frame limit"? > There have been numerous benefits described of a disclosed limit. I The is one legit pressure to limit size of frames, and that is latency for the next, possibly control message. So somebody sends a PING, you decided to issue a gigabyte frame and before there is no chance to issue the PONG frame before the other side timed out. But that's different from frame size negotiation which I did not hear one good reason for yet -- feel free to enumerate these "numerous benefits". For the latency reason, 2^63 (a frame takes many years to transmit even at Ethernet two generations ahead) frames are not useful. > accept that these benefits are not universal, but I do believe they > exist in a significant number of cases. > > I have seen no substantial costs. Perhaps one could argue that a Come on man, that's not an argument it's just blather. -Andy From ibc@aliax.net Wed Aug 10 01:03: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 0C9D021F86C0 for ; Wed, 10 Aug 2011 01:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cA9RxUlq-X4T for ; Wed, 10 Aug 2011 01:03:00 -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 6E55E21F8639 for ; Wed, 10 Aug 2011 01:03:00 -0700 (PDT) Received: by qyk34 with SMTP id 34so2621543qyk.10 for ; Wed, 10 Aug 2011 01:03:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr5795782qci.254.1312963410701; Wed, 10 Aug 2011 01:03:30 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Wed, 10 Aug 2011 01:03:30 -0700 (PDT) In-Reply-To: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> Date: Wed, 10 Aug 2011 10:03:30 +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] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 08:03:02 -0000 2011/8/10 Greg Wilkins : >> Either you have max. _message_ size negotiated or have a streaming API. > > Streaming does not help as frame boundaries can be arbitrary. =C2=A0In th= e > simplest case, what is a JS application going to do with 3 bytes of a > 6 byte UTF-8 character? An extra layer of buffering? > > What if there is an extension that puts a digital signature on every > frame, so that data can be integral but not confidential. =C2=A0 =C2=A0Da= ta in > such a frame cannot be streamed to an application until the entire > frame is received and the signature verified. All this stuff seems a design aberration for me. Layers separations are not clear. Frames should occur at "transport level" (whichever that is being already in application layer), while data arriving to the application (the WebSocket user) should be an entire message (if the design is message-oriented). WS user should not be disturbed with framing stuff. Please confirm me the following: When a WS client receives a frame (containing a fragment of a message): a) would such frame be sent to the JS API? (In this case JavaScript could receive even non valid UTF-8 bytes, and of course, the JS code would not know how to handle such incomplete data. b) or would the WS client wait until the last frame (bit "more_frames=3D0" or whatever) arrives to send the entire message to the JS API? I assume b) is correct (in any case?). Thanks. --=20 I=C3=B1aki Baz Castillo From paul@colomiets.name Wed Aug 10 01:06: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 44D2921F8715 for ; Wed, 10 Aug 2011 01:06:33 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYXyzu+LmCka for ; Wed, 10 Aug 2011 01:06:32 -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 221F621F8748 for ; Wed, 10 Aug 2011 01:06:31 -0700 (PDT) Received: by wwf5 with SMTP id 5so582828wwf.13 for ; Wed, 10 Aug 2011 01:07:02 -0700 (PDT) Received: by 10.216.237.233 with SMTP id y83mr350626weq.9.1312963622149; Wed, 10 Aug 2011 01:07:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.221.18 with HTTP; Wed, 10 Aug 2011 01:06:42 -0700 (PDT) X-Originating-IP: [91.203.48.31] In-Reply-To: <20110810062135.GH31746@1wt.eu> References: <20110810062135.GH31746@1wt.eu> From: Paul Colomiets Date: Wed, 10 Aug 2011 11:06:42 +0300 Message-ID: To: Willy Tarreau Content-Type: text/plain; charset=ISO-8859-1 Cc: Server-Initiated HTTP , Greg Wilkins Subject: Re: [hybi] Maximum frame size as a security issue 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, 10 Aug 2011 08:06:33 -0000 Hi, On Wed, Aug 10, 2011 at 9:21 AM, Willy Tarreau wrote: > I think that this value of 126 is a good idea. It could be the default > when no frame size is specified, making it easier to build small > implementations (no FS negociation, only one-byte length). 126 is also > friendly to overloaded intermediaries that have to shrink their buffers > to save memory. > I don't think default value should be less than MTU. It will be waste of traffic and processing power. I do think that 90% of implementations should never split messages into frames unless absolutely required (as long as about 90% of implementations will deal with short messages, but short doesn't mean126 bytes it's something closer to kilobytes). -- Paul From jat@google.com Wed Aug 10 01:13:47 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 2C0B621F8788 for ; Wed, 10 Aug 2011 01:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.807 X-Spam-Level: X-Spam-Status: No, score=-105.807 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrjiSBknUu1O for ; Wed, 10 Aug 2011 01:13:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6582121F85F2 for ; Wed, 10 Aug 2011 01:13:46 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7A8EG8F025604 for ; Wed, 10 Aug 2011 01:14:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1312964057; bh=hPn2Ailr/VFX+s4lkI4YcJnUqBE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ezyaqQWZaHvDg1AfU4/0osXGf7VY7OolRKs5+/QBxWk/XHLEKuliwHCL4UdJtFBiT SOd9hpU6IACzlpLZshqdg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=HWd1UazTqK5HXY9NEsa6NMNgGafzQPuxQEYBT+cJ10iV88yTvZfnKONfF/s0zB2F+ Co4z2ovifUXhRO0dBP3ow== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by wpaz1.hot.corp.google.com with ESMTP id p7A8EFsX003673 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 10 Aug 2011 01:14:15 -0700 Received: by ywo7 with SMTP id 7so768893ywo.11 for ; Wed, 10 Aug 2011 01:14:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Ec86vnsuAB7CDjlSe4ZhLh+GkqEecljFsv0bbQY4iX8=; b=tOsE8Y86RNBXLeR71HwK3K5xe2slSNHfr1p+hYTEPgGJPz1/rBdFb2wiTpLFYyG/Q+ mt7TlqbZnPqFLtCxG26A== Received: by 10.151.118.20 with SMTP id v20mr3386452ybm.401.1312964055458; Wed, 10 Aug 2011 01:14:15 -0700 (PDT) Received: by 10.151.118.20 with SMTP id v20mr3386441ybm.401.1312964055204; Wed, 10 Aug 2011 01:14:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Wed, 10 Aug 2011 01:13:55 -0700 (PDT) In-Reply-To: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Wed, 10 Aug 2011 04:13:55 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001e680f09fc1d053904aa2244ca X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 08:13:47 -0000 --001e680f09fc1d053904aa2244ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 10, 2011 at 4:03 AM, I=C3=B1aki Baz Castillo wr= ote: > All this stuff seems a design aberration for me. Layers separations > are not clear. Frames should occur at "transport level" (whichever > that is being already in application layer), while data arriving to > the application (the WebSocket user) should be an entire message (if > the design is message-oriented). WS user should not be disturbed with > framing stuff. > > Please confirm me the following: > > When a WS client receives a frame (containing a fragment of a message): > > a) would such frame be sent to the JS API? (In this case JavaScript > could receive even non valid UTF-8 bytes, and of course, the JS code > would not know how to handle such incomplete data. b) or would the WS client wait until the last frame (bit > "more_frames=3D0" or whatever) arrives to send the entire message to the > JS API? > > I assume b) is correct (in any case?). > The current JS API, which is discussed in WHATWG not here, only exposes a message-oriented API that deals with complete messages. If there is demand= , I suspect a streaming API will be added but initially it will always be cas= e b. Many other implementations do provide a streaming API, and are intended for use in the server or in non-browser clients. In any case, the design of an API for WebSockets is not in the scope of this WG, though of course implementation considerations may inform choices made in the wire protocol. --=20 John A. Tamplin Software Engineer (GWT), Google --001e680f09fc1d053904aa2244ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 10, 2011 at 4:03 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
All this stuff seems a design aberration for me. Layers separations
are not clear. Frames should occur at "transport level" (whicheve= r
that is being already in application layer), while data arriving to
the application (the WebSocket user) should be an entire message (if
the design is message-oriented). WS user should not be disturbed with
framing stuff.

Please confirm me the following:

When a WS client receives a frame (containing a fragment of a message):

a) would such frame be sent to the JS API? (In this case JavaScript
could receive even non valid UTF-8 bytes, and of course, the JS code
would not know how to handle such incomplete data.=C2=A0
=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--001e680f09fc1d053904aa2244ca-- From w@1wt.eu Wed Aug 10 01:27: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 1E68421F84E6 for ; Wed, 10 Aug 2011 01:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.033 X-Spam-Level: X-Spam-Status: No, score=-4.033 tagged_above=-999 required=5 tests=[AWL=-1.990, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBckgwv2tYYc for ; Wed, 10 Aug 2011 01:27:17 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3585021F84E1 for ; Wed, 10 Aug 2011 01:27:17 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p7A8RiAN002214; Wed, 10 Aug 2011 10:27:44 +0200 Date: Wed, 10 Aug 2011 10:27:44 +0200 From: Willy Tarreau To: Paul Colomiets Message-ID: <20110810082744.GL31746@1wt.eu> References: <20110810062135.GH31746@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Server-Initiated HTTP , Greg Wilkins Subject: Re: [hybi] Maximum frame size as a security issue 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, 10 Aug 2011 08:27:18 -0000 On Wed, Aug 10, 2011 at 11:06:42AM +0300, Paul Colomiets wrote: > Hi, > > On Wed, Aug 10, 2011 at 9:21 AM, Willy Tarreau wrote: > > I think that this value of 126 is a good idea. It could be the default > > when no frame size is specified, making it easier to build small > > implementations (no FS negociation, only one-byte length). 126 is also > > friendly to overloaded intermediaries that have to shrink their buffers > > to save memory. > > > I don't think default value should be less than MTU. It will be waste of > traffic and processing power. A path MTU is the hardest thing to find from an application point of view. People accessing the net over PPP over modem are used to 576 bytes MTU. Many others are used to 1500. Some others are still at 1492 due to PPPoE headers, others are around 1380 due to VPN, etc... It's not *that* much of a waste however, as you must not forget that this is sent over TCP, not over plain IP. You can send 10kB in 126 bytes frames, and the real overhead is around 80 times the WS frame header, which is 2 bytes in the absence of masking, or 6 bytes with masking enabled. The overhead is then either 1.6 or 4.8%, which is still fairly low. > I do think that 90% of implementations should never split messages > into frames unless absolutely required (as long as about 90% of > implementations will deal with short messages, but short doesn't > mean126 bytes it's something closer to kilobytes). I agree with the lack of need for splitting most of the time, especially given that most messages will be small. Still, it makes sense to have a default small value that must be enforced and have those supporting larger values announce it. Regards, Willy From ibc@aliax.net Wed Aug 10 01:39: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 8B65C21F8784 for ; Wed, 10 Aug 2011 01:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjvAxOJ+HASv for ; Wed, 10 Aug 2011 01:39:15 -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 0D49121F86C0 for ; Wed, 10 Aug 2011 01:39:14 -0700 (PDT) Received: by qwc23 with SMTP id 23so520464qwc.31 for ; Wed, 10 Aug 2011 01:39:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.241.205 with SMTP id lf13mr5951958qcb.292.1312965585711; Wed, 10 Aug 2011 01:39:45 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Wed, 10 Aug 2011 01:39:45 -0700 (PDT) In-Reply-To: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> Date: Wed, 10 Aug 2011 10:39:45 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 08:39:15 -0000 2011/8/10 John Tamplin : > The current JS API, which is discussed in WHATWG not here, only exposes a > message-oriented API that deals with complete messages. =C2=A0If there is= demand, > I suspect a streaming API will be added but initially it will always be c= ase > b. > Many other implementations do provide a streaming API, and are intended f= or > use in the server or in non-browser clients. =C2=A0In any case, the desig= n of an > API for WebSockets is not in the scope of this WG, though of course > implementation considerations may inform choices made in the wire protoco= l. I understand, thanks. Just a question please: in case of a streaming API, how will be indicated the end of a full message? amybe by sending a special control sequence to the API consumer after the full message has been sent to it? --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Wed Aug 10 02:48: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 6EEE321F8559 for ; Wed, 10 Aug 2011 02:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WraXnhsGA5Mk for ; Wed, 10 Aug 2011 02:48:09 -0700 (PDT) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by ietfa.amsl.com (Postfix) with SMTP id C33C721F8557 for ; Wed, 10 Aug 2011 02:48:09 -0700 (PDT) Received: (qmail 2743 invoked from network); 10 Aug 2011 09:48:39 -0000 Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 10 Aug 2011 09:48:39 -0000 Received: (qmail 9267 invoked by uid 99); 10 Aug 2011 09:48:39 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.160.228.119 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110810024838.ef1fc80126c74c6c202a919c41c7bb0b.8e1b7e484e.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Wed, 10 Aug 2011 02:48:38 -0700 Mime-Version: 1.0 Subject: [hybi] WebSocket Frame Size and latency 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, 10 Aug 2011 09:48:10 -0000 Andy,=0A=0AIndeed. As I noted in my comment yesterday, the only absolute im= pact of=0Aframe size is on the latency of what can come after a frame.=0ARe= alistically speaking, not interfering with PING/PONG and other=0Aadministra= tive traffic requires a latency measured in fractions of a=0Asecond. This t= ranslates into frame sizes of order 10**4 on present day=0ALAN interconnect= s, more like 10**3 on lower speed interconnections.=0A=0AMultiplexing exten= sions, which I would prefer not to be extensions, but=0Apart of the base sp= ecification, extend this problem in the context of=0Aproviding a degree of = fairness to the different channels (e.g., an=0Aextremely long frame, >10**8= bytes, does not create an effective,=0Anon-removable blockage in the chann= el.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From andy@warmcat.com Wed Aug 10 03:01: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 47D5421F85EC for ; Wed, 10 Aug 2011 03:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T9ViiGrZLbDK for ; Wed, 10 Aug 2011 03:01:51 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8B21F85DE for ; Wed, 10 Aug 2011 03:01:51 -0700 (PDT) Message-ID: <4E42572A.4060302@warmcat.com> Date: Wed, 10 Aug 2011 11:02:18 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110810024838.ef1fc80126c74c6c202a919c41c7bb0b.8e1b7e484e.wbe@email03.secureserver.net> In-Reply-To: <20110810024838.ef1fc80126c74c6c202a919c41c7bb0b.8e1b7e484e.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket Frame Size and latency 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, 10 Aug 2011 10:01:52 -0000 On 08/10/2011 10:48 AM, Somebody in the thread at some point said: Hi - > Indeed. As I noted in my comment yesterday, the only absolute impact of > frame size is on the latency of what can come after a frame. > Realistically speaking, not interfering with PING/PONG and other > administrative traffic requires a latency measured in fractions of a > second. This translates into frame sizes of order 10**4 on present day > LAN interconnects, more like 10**3 on lower speed interconnections. Right. I agree that sounds reasonable at the moment. There was a thread a few months ago where I recall proposing much smaller max frame size for that reason, the bigger frame sizes are worthless. After some to-ing and fro-ing and calculation about what next-gen Ethernet would consider OK 2^24 or 2^32 seemed future-proof enough. We can actually send and test 2^32 byte frames in a minute or two on real hardware today; nobody can test the max frame size as it stands. But there was no reaction (no defense of 2^63 either) and 2^63 is still sitting there in the spec. > Multiplexing extensions, which I would prefer not to be extensions, but > part of the base specification, extend this problem in the context of > providing a degree of fairness to the different channels (e.g., an > extremely long frame,>10**8 bytes, does not create an effective, > non-removable blockage in the channel. Yeah that boggles my mind. There will be a lot of additional traffic doing the work of "TCP ACK" for each subchannel. I can see why you think it should be in the base spec and don't disagree, but it's so difficult to get traction here I fear we will be into 2015 before it's actually agreed that way and it's better to take what we have to the bank now. -Andy From diogo.pereira@ist.utl.pt Wed Aug 10 03:47: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 19E6221F85E3 for ; Wed, 10 Aug 2011 03:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.961 X-Spam-Level: X-Spam-Status: No, score=-1.961 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjpfGmM5-pFr for ; Wed, 10 Aug 2011 03:47:56 -0700 (PDT) Received: from smtp2.ist.utl.pt (smtp2.ist.utl.pt [IPv6:2001:690:2100:1::16]) by ietfa.amsl.com (Postfix) with ESMTP id 426F821F85B9 for ; Wed, 10 Aug 2011 03:47:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 713F270003FC for ; Wed, 10 Aug 2011 11:48:26 +0100 (WEST) X-Virus-Scanned: by amavisd-new-2.6.4 (20090625) (Debian) at ist.utl.pt Received: from smtp2.ist.utl.pt ([127.0.0.1]) by localhost (smtp2.ist.utl.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id 79c+hMXuC6hg for ; Wed, 10 Aug 2011 11:48:26 +0100 (WEST) Received: from mail2.ist.utl.pt (mail.ist.utl.pt [IPv6:2001:690:2100:1::8]) by smtp2.ist.utl.pt (Postfix) with ESMTP id 255547000450 for ; Wed, 10 Aug 2011 11:48:25 +0100 (WEST) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) (Authenticated sender: ist158122) by mail2.ist.utl.pt (Postfix) with ESMTPSA id 9BEA420089A0 for ; Wed, 10 Aug 2011 11:48:25 +0100 (WEST) Received: by iye1 with SMTP id 1so936751iye.27 for ; Wed, 10 Aug 2011 03:48:24 -0700 (PDT) Received: by 10.231.169.130 with SMTP id z2mr4107192iby.20.1312973304087; Wed, 10 Aug 2011 03:48:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.33.140 with HTTP; Wed, 10 Aug 2011 03:47:54 -0700 (PDT) In-Reply-To: References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> From: Diogo Pereira Date: Wed, 10 Aug 2011 11:47:54 +0100 Message-ID: To: Greg Wilkins Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 10 Aug 2011 10:47:57 -0000 On Wed, Aug 10, 2011 at 01:09, Greg Wilkins wrote: > There are many reasons to not support 2^64 frames is not because of > simple/broken implementations. =C2=A0 =C2=A0 Not the least to avoid DOS a= ttacks. How is sending a 2^63 frame worse than sending an infinite number of 125 byte frames? > In HTTP there is not protocol limit to the length of the URL, header > fields or form content body, but in practise all servers implement > size limits on all of these. =C2=A0 Unfortunately these limits are not > disclosed so applications have to guess what they are - typically > settling for lowest commonly know values. =C2=A0 Worse still, many > applications are deployed without any knowledge that such limits exist > and then fail in production as user data gets bigger and blows out one > limit or the other. The reason those limits exist is that the HTTP server needs to parse those fields. A WebSocket server only needs to parse the frame header (and there is already a limit for that: 14 bytes), and pass the payload to the application. The application might have a limit, but that will be a message size limit, not a frame size limit. Frames don't matter. > Implementations are not going to handle 2^64 frames not because they > don't know how, or because the implementers are lazy, stupid or both. > =C2=A0Frame sizes will be limited for good resource =C2=A0allocation reas= ons. > This will also apply to implementations that do support dynamic > growing buffers for frames. For the nth time, large frames don't use more resources. In fact, they help you use less. When you receive a frame with FIN=3D0, you have no way of knowing how large the message will be. If you need to buffer the message (as browsers do), then you can: a) Allocate just enough memory for the frame; b) Allocate enough memory for your maximum message size; c) Guess. Even if you're very good at guessing, you'll probably never do as well as if you knew from the start how large a buffer you were going to need. Another related problem is if you send a large message in small frames, the (message-buffering) receiver cannot close the connection immediately if the message is larger than the maximum it can handle. For example, if you try to send a 20 MB message to Firefox in 8 KB fragments, Firefox will close the connection after it receives 16 MB. If instead you send a single 20 MB frame, it will close immediately. Large frames let you plan ahead, resulting in fewer wasted resources. -- Diogo From tobias.oberstein@tavendo.de Wed Aug 10 07:29: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 0ACF121F8ADC for ; Wed, 10 Aug 2011 07:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjWKTpr+UHJ5 for ; Wed, 10 Aug 2011 07:29:44 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 32A6F21F8AD3 for ; Wed, 10 Aug 2011 07:29:44 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Wed, 10 Aug 2011 07:30:15 -0700 From: Tobias Oberstein To: Salvatore Loreto , "hybi@ietf.org" Date: Wed, 10 Aug 2011 07:29:43 -0700 Thread-Topic: [hybi] WebSocket browser support status Thread-Index: AcxWe61obQm6gpcrREOOt6Q34tzhewA7DegA Message-ID: <634914A010D0B943A035D226786325D422BFA12318@EXVMBX020-12.exch020.serverdata.net> References: <4E410607.7070006@ericsson.com> In-Reply-To: <4E410607.7070006@ericsson.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] WebSocket browser support status 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, 10 Aug 2011 14:29:45 -0000 For those interested, I've updated the reports: * the fixes for Firefox have landed on FF8 ("Nightly") .. it now passed _al= l_ test cases * Chrome fixes are still moving * the performance/limits detail reports now contain octet/frame statistics http://www.tavendo.de/autobahn/testsuite/report/ PS: The one red case for FF 8 shows the point where it bails out on message/fra= me size .. somewhere above 8MB. Also, all clients currently send unfragmented messages in all cases. The yellow cases for FF 8 are formally passes. Those test cases do this: First, something valid, then something breaking the protocol. The spec only requires to "fail the connection immediately". The spec does not say what to do with the stuff up to the protocol violatio= n. Chrome/Autobahn process everything up to the point of violation. FF discards everything buffered, but not yet processed, when it encounters = a violation in buffered. The latter means, the result is somehow indeterministic, since it depends o= n the buffered amount at the point of violation. =3D=3D Unrelated to test suite: I've gotten the performance of the Autobahn Python= client approaching that of FF and often exceeding that of Chrome;) Btw: the performance limiti= ng factor (in my=20 setup .. fast machine, loopback) is the masking .. Cheers From tobias.oberstein@tavendo.de Wed Aug 10 12:12: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 97D1F11E8085 for ; Wed, 10 Aug 2011 12:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.538 X-Spam-Level: X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90GUhvII4sqj for ; Wed, 10 Aug 2011 12:12:30 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 10BE311E8081 for ; Wed, 10 Aug 2011 12:12:29 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Wed, 10 Aug 2011 12:13:00 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Wed, 10 Aug 2011 12:12:59 -0700 Thread-Topic: mux extension document? Thread-Index: AcxXkYRl44clzXz9sU+kzLzOOhTJrQ== Message-ID: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_CA68A4DB477Btobiasobersteintavendode_" MIME-Version: 1.0 Subject: [hybi] mux extension document? 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, 10 Aug 2011 19:12:30 -0000 --_000_CA68A4DB477Btobiasobersteintavendode_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable could s.o. give me a pointer where to find info on x-google-mux? thanks --_000_CA68A4DB477Btobiasobersteintavendode_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable mux extension document? could s.o. give me a pointer where to find info on x-google-mux?

thanks --_000_CA68A4DB477Btobiasobersteintavendode_-- From alexey.melnikov@isode.com Wed Aug 10 12:44: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 DE5E721F8B6C for ; Wed, 10 Aug 2011 12:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE15BY0HTGVS for ; Wed, 10 Aug 2011 12:44:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 19A6C21F86D0 for ; Wed, 10 Aug 2011 12:44:44 -0700 (PDT) Received: from [188.28.209.3] (188.28.209.3.threembb.co.uk [188.28.209.3]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 10 Aug 2011 20:45:14 +0100 Message-ID: <4E42DC7C.90600@isode.com> Date: Wed, 10 Aug 2011 20:31:08 +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: Tobias Oberstein References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> <634914A010D0B943A035D226786325D422BFA1205C@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422BFA1205C@EXVMBX020-12.exch020.serverdata.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 19:44:45 -0000 Tobias Oberstein wrote: >>>But why would an implementation be unable to handle a large frame? >>> >>Because it might be running on a device with limited memory, such as a cell >>phone. >> >> >where is the problem? > > Because in a presence of an extension a frame might have to be consumed in its entirety before any payload data can be extracted from it. Which means that the the receiver needs to have enough memory for the whole frame. >>>Again, an implementation does not have to buffer the entire frame, >>>unless it needs to buffer the entire message, >>> >>> >>That is incorrect. For cases where a frame needs to be unencrypted, >>decompressed, etc, it is very likely that the whole frame is needed to >>perform the operation. >> >> >for crypto, use a stream cipher .. i.e. AES-CTR > > I think you are making assumptions that that would always be the case. There is no such restriction in revision 10 at the moment. From alexey.melnikov@isode.com Wed Aug 10 12:44: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 78C3121F8B7A for ; Wed, 10 Aug 2011 12:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMaLbaXGk2Hm for ; Wed, 10 Aug 2011 12:44:59 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DEB4F21F8B67 for ; Wed, 10 Aug 2011 12:44:58 -0700 (PDT) Received: from [188.28.209.3] (188.28.209.3.threembb.co.uk [188.28.209.3]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 10 Aug 2011 20:45:29 +0100 Message-ID: <4E42DE18.2080802@isode.com> Date: Wed, 10 Aug 2011 20:38:00 +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: John Tamplin References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 19:44:59 -0000 John Tamplin wrote: > On Tue, Aug 9, 2011 at 6:30 AM, Alexey Melnikov > wrote: > > That is incorrect. For cases where a frame needs to be > unencrypted, decompressed, etc, it is very likely that the whole > frame is needed to perform the operation. > > Typically, these APIs are stream-oriented already. For example, zlib > takes some chunk of input data and when its output buffer is full you > write it out. You can use whatever buffer size is convenient for you, > and it certainly doesn't have to be the entire size of the frame or > message. Ok, this might work for the per-frame compression, but there is currently no requirement that all extensions must support streaming. Greg's example of an extension with digital signature is a good one. The data is not even valid until the signature can be verified. If the signature fails to verify, what to do with the data which was already delivered to the application? A requirement to work with partial frames would put additional restrictions on the design of future extensions. Either way, this needs to be clarified in the draft. From jat@google.com Wed Aug 10 13:10: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 83B0121F8B0C for ; Wed, 10 Aug 2011 13:10:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.8 X-Spam-Level: X-Spam-Status: No, score=-105.8 tagged_above=-999 required=5 tests=[AWL=-0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pt4Y1lU8iRw for ; Wed, 10 Aug 2011 13:10:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E15FE21F8A55 for ; Wed, 10 Aug 2011 13:10:48 -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 p7AKBCjC008674 for ; Wed, 10 Aug 2011 13:11:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313007072; bh=KqzMsQb9fE6ylVXxzLA/atElER8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hNS6dkOqTz6uWmFpDW5ATH/5huVACcm+9PwzITwms2LxFXnAgqYG8wLY/ogj/AYYU k76NK14Lo5WJu57G3trLw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=NcMxyLEoTYCgYCnQUiKyl+G/d27iTSPCGJVrL+18nrDFX9XOTR1bwO1s9gYTW9u9k DMCr4g79ukuMqBzSqIBzw== Received: from yxm8 (yxm8.prod.google.com [10.190.4.8]) by hpaq1.eem.corp.google.com with ESMTP id p7AKAToD000893 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 10 Aug 2011 13:11:10 -0700 Received: by yxm8 with SMTP id 8so1024149yxm.37 for ; Wed, 10 Aug 2011 13:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=AWRw0OFezgmegvtH0ItVIdGc47FERFT1AZo8WgFmJZM=; b=Rt9q/iZYBn6qmv2TcmgSMiqIdV6P3KD6P7023/qFCMu6f0U9DptB+iXBv2X0z48E1X RRzwd+jlzIsrhQ6F1DoQ== Received: by 10.151.114.20 with SMTP id r20mr8964296ybm.2.1313007065339; Wed, 10 Aug 2011 13:11:05 -0700 (PDT) Received: by 10.151.114.20 with SMTP id r20mr8964287ybm.2.1313007065166; Wed, 10 Aug 2011 13:11:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Wed, 10 Aug 2011 13:10:45 -0700 (PDT) In-Reply-To: References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E3C2904.5000801@callenish.com> <4E3C4EA5.6080108@callenish.com> <4E3C8655.1070802@callenish.com> <4E3D7535.6090906@callenish.com> <634914A010D0B943A035D226786325D422BFA11D81@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Wed, 10 Aug 2011 16:10:45 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00151750e554b4f2e404aa2c477c X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 20:10:49 -0000 --00151750e554b4f2e404aa2c477c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 10, 2011 at 4:39 AM, I=C3=B1aki Baz Castillo wr= ote: > Just a question please: in case of a streaming API, how will be > indicated the end of a full message? amybe by sending a special > control sequence to the API consumer after the full message has been > sent to it? > That will be up to the API. One I know of in Java gives an InputStream (or Reader for text messages) to the client that signals EOF on the end of the message. --=20 John A. Tamplin Software Engineer (GWT), Google --00151750e554b4f2e404aa2c477c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 10, 2011 at 4:39 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
Just a question please: in case of a streaming API, how will be
indicated the end of a full message? amybe by sending a special
control sequence to the API consumer after the full message has been
sent to it?

That will be up to the API. =C2=A0One I kno= w of in Java gives an InputStream (or Reader for text messages) to the clie= nt that signals EOF on the end of the message.

--
John A. Tamplin
Software Engineer (GWT), Google
--00151750e554b4f2e404aa2c477c-- From bruce@callenish.com Wed Aug 10 15:19: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 4B64211E80CA for ; Wed, 10 Aug 2011 15:19:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJH8o9ifuWx1 for ; Wed, 10 Aug 2011 15:19:19 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5211E80C9 for ; Wed, 10 Aug 2011 15:19:19 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrH7v-00036m-5b; Wed, 10 Aug 2011 15:19:51 -0700 Message-ID: <4E430406.7030901@callenish.com> Date: Wed, 10 Aug 2011 15:19:50 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Alexey Melnikov References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> <4E42DE18.2080802@isode.com> In-Reply-To: <4E42DE18.2080802@isode.com> 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] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 22:19:20 -0000 On 10/08/2011 12:38 PM, Alexey Melnikov wrote: > John Tamplin wrote: > >> On Tue, Aug 9, 2011 at 6:30 AM, Alexey Melnikov >> wrote: >> >> That is incorrect. For cases where a frame needs to be >> unencrypted, decompressed, etc, it is very likely that the whole >> frame is needed to perform the operation. >> >> Typically, these APIs are stream-oriented already. For example, zlib >> takes some chunk of input data and when its output buffer is full you >> write it out. You can use whatever buffer size is convenient for >> you, and it certainly doesn't have to be the entire size of the frame >> or message. > > Ok, this might work for the per-frame compression, but there is > currently no requirement that all extensions must support streaming. > Greg's example of an extension with digital signature is a good one. > The data is not even valid until the signature can be verified. If the > signature fails to verify, what to do with the data which was already > delivered to the application? Or an extension that detects whether a frame payload is plain ASCII or binary by checking for the high bit being set on every byte, and modifying the opcode as a result. I'm sure there are many other examples where a stream interface would not be appropriate. From ferg@caucho.com Wed Aug 10 15:32:36 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 C7E3321F8B4E for ; Wed, 10 Aug 2011 15:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8XJW2DxGTTP for ; Wed, 10 Aug 2011 15:32:36 -0700 (PDT) Received: from nm34-vm4.bullet.mail.bf1.yahoo.com (nm34-vm4.bullet.mail.bf1.yahoo.com [72.30.239.76]) by ietfa.amsl.com (Postfix) with SMTP id 369B221F86FF for ; Wed, 10 Aug 2011 15:32:36 -0700 (PDT) Received: from [98.139.212.150] by nm34.bullet.mail.bf1.yahoo.com with NNFMP; 10 Aug 2011 22:33:04 -0000 Received: from [98.139.212.195] by tm7.bullet.mail.bf1.yahoo.com with NNFMP; 10 Aug 2011 22:33:04 -0000 Received: from [127.0.0.1] by omp1004.mail.bf1.yahoo.com with NNFMP; 10 Aug 2011 22:33:04 -0000 X-Yahoo-Newman-Id: 953490.64782.bm@omp1004.mail.bf1.yahoo.com Received: (qmail 19784 invoked from network); 10 Aug 2011 22:33:04 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313015584; bh=H5O5qWJ28XPde3eQm3lGmUY1DdwPY7ut9ENzFYktxjA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=34l0naWOUAFSC/U6qSl0ZG6MkuTWkiOgFGAS4gVmXn/zlNBLYumsGT85tJEuF4u3I1oxc/7oiy2JL+PIWf+GJ3gU5hPo5thLCwL0r0+AiZphDEZ7vmrclzmgyWjRRw/hOmTfRA/A2veJudze40U5HpDL97Y300mj9a7SYZ543cA= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 6Tq7p08VM1mYM1R1p52eFoHjTAiWBvaaqRWeYWxFbhx5wIa C2kYvVt_RdlShQqkHZ6Xu8848mAYeHhhtInkDXtpSftUyBQL7GJlr22ETVdF GcuHTet_erzOX2MbLliK2nN_Zl4mPfwly6zjfYLYswyLsgHTf_2PzlspSxmc T9SQ3x_hwzd.cZVRL8QJvY4QlcOEG69H00R0gef_U_g8Yf1HCTSFqgWH.a7g sRg9zSe2nL4uO1IJQB_lQCujcgD5hehQDi7Jo1gO.YpfU__fsZm3l4htH2lw QgE.o0qBMdQVgjaGZVghJAFsEqnMSjxDgp9VoeS10q7gU.rpba7IEiR6NQK_ juoh9CEbBrF7QOvy3AV7A.RNT9fEvW_p1WU5PXvRGqPBt3eiD0vf68Oj3PMS j7oLIs2XeEzGgQlCGreM4fggIzO1Co8g- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.mud.yahoo.com with SMTP; 10 Aug 2011 15:33:04 -0700 PDT Message-ID: <4E43071F.20101@caucho.com> Date: Wed, 10 Aug 2011 15:33:03 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> <4E42DE18.2080802@isode.com> In-Reply-To: <4E42DE18.2080802@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 10 Aug 2011 22:32:36 -0000 On 08/10/2011 12:38 PM, Alexey Melnikov wrote: > > Ok, this might work for the per-frame compression, but there is > currently no requirement that all extensions must support streaming. > Greg's example of an extension with digital signature is a good one. > The data is not even valid until the signature can be verified. If the > signature fails to verify, what to do with the data which was already > delivered to the application? Those hypothetical extensions need to negotiate their own limits. Frame-size isn't the only resource limitation an extension might have. Even extensions that have frame-size limits might have different notions of the limit, like hop-to-hop vs end-to-end, or dynamic MTU-discovery, or windowing limits, or whatever complicated flow-control MUX ends up requiring. If the extension negotiates itself, it can define the right frame-size limit. If the base spec defines the limit, the extension is stuck. A one-size-fits-all frame-size limit in the WebSocket spec isn't going to be the right answer for extensions. -- Scott From gregw@intalio.com Wed Aug 10 16:26: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 2FBAA11E8094 for ; Wed, 10 Aug 2011 16:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UY7pra78ncsd for ; Wed, 10 Aug 2011 16:26:24 -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 8E58711E808A for ; Wed, 10 Aug 2011 16:26:24 -0700 (PDT) Received: by vws12 with SMTP id 12so1589393vws.31 for ; Wed, 10 Aug 2011 16:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.163 with SMTP id dl3mr8674282vdb.229.1313018816864; Wed, 10 Aug 2011 16:26:56 -0700 (PDT) Received: by 10.52.114.228 with HTTP; Wed, 10 Aug 2011 16:26:56 -0700 (PDT) In-Reply-To: References: <4E3C98BF.9030605@callenish.com> <4E409C60.6010007@caucho.com> Date: Thu, 11 Aug 2011 09:26:56 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] "Frame too large" error with and without max frame size 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, 10 Aug 2011 23:26:25 -0000 On 10 August 2011 20:47, Diogo Pereira wrote: > For the nth time, large frames don't use more resources. In fact, they > help you use less. And for the Nth time I'm saying that resource limits may be applied for good reasons other than lazy programmers who don't know how to parse large frames with small buffers. > Another related problem is if you send a large message in small > frames, the (message-buffering) receiver cannot close the connection > immediately if the message is larger than the maximum it can handle. > For example, if you try to send a 20 MB message to Firefox in 8 KB > fragments, Firefox will close the connection after it receives 16 MB. > If instead you send a single 20 MB frame, it will close immediately. > > Large frames let you plan ahead, resulting in fewer wasted resources. I am not arguing against sending large frames. Indeed I believe that declaring a frame size limit will facilitate large frames being sent. Without knowledge of any limit that may apply, implementations may assume lowest common denominator frame sizes and needlessly fragment. regards From tyoshino@google.com Wed Aug 10 17:55: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 0DCF711E8094 for ; Wed, 10 Aug 2011 17:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.913 X-Spam-Level: X-Spam-Status: No, score=-105.913 tagged_above=-999 required=5 tests=[AWL=0.062, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M7XvIdLkgJDu for ; Wed, 10 Aug 2011 17:55: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 236A911E8092 for ; Wed, 10 Aug 2011 17:55:29 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p7B0u119015715 for ; Wed, 10 Aug 2011 17:56:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313024162; bh=Pq9l2YuGEyRkXRx9uMMlgn4i+tg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=pgMjYnBERUC9XTM4K7to+dRqHupiMPQMmVv1EXrXntVX+vHgN71shhZi7ffshRyS4 vXsXrWr0oMNNvF4WLCYSw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=eaJ84Q50noo7xVyX8MauVHWu20lNiXiK23ymO4H85swIAF19CDAqeocIDjR5Fkwo+ upWxjqOIBHYXBZj6qIJvQ== Received: from yxi11 (yxi11.prod.google.com [10.190.3.11]) by hpaq2.eem.corp.google.com with ESMTP id p7B0txQd014017 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 10 Aug 2011 17:56:00 -0700 Received: by yxi11 with SMTP id 11so2391397yxi.25 for ; Wed, 10 Aug 2011 17:55:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Nx7YqLTYTSXlZ/UT49oSOaXwWSQPgHBDeKzISpkkMFc=; b=yH3IE6awvZidud0++dAGHw2nViWzT+jvfZQW497QZZ2OaiwvPSxWMai3VYC/47AB2N CzBFeIx8qeB1eSAE/0Kg== Received: by 10.150.40.15 with SMTP id n15mr28591ybn.0.1313024159344; Wed, 10 Aug 2011 17:55:59 -0700 (PDT) Received: by 10.150.40.15 with SMTP id n15mr28586ybn.0.1313024159169; Wed, 10 Aug 2011 17:55:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Wed, 10 Aug 2011 17:55:39 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 11 Aug 2011 09:55:39 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd5f2cc96bcd604aa304241 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] mux extension document? 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, 11 Aug 2011 00:55:31 -0000 --000e0cd5f2cc96bcd604aa304241 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 11, 2011 at 04:12, Tobias Oberstein wrote: > could s.o. give me a pointer where to find info on x-google-mux? > Here https://docs.google.com/a/google.com/document/d/14DYRxmRTPVhV1GbVXlxg8KVrS1SEq4UhCNq6q8iNOws/view --000e0cd5f2cc96bcd604aa304241 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 11, 2011 at 04:12, Tobias Oberstein <= tobias.oberstein@tavendo.de<= /a>> wrote:
could s.o. give me a pointer where to find info on x-google-mux?
<= /span>


--000e0cd5f2cc96bcd604aa304241-- From andy@warmcat.com Wed Aug 10 23:16: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 0509711E8078 for ; Wed, 10 Aug 2011 23:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.277 X-Spam-Level: X-Spam-Status: No, score=-2.277 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQNVcP7aep0L for ; Wed, 10 Aug 2011 23:16:23 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7858A11E8073 for ; Wed, 10 Aug 2011 23:16:23 -0700 (PDT) Message-ID: <4E4373D5.3060804@warmcat.com> Date: Thu, 11 Aug 2011 07:16:53 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Ferguson References: <4E3982F2.1080808@caucho.com> <4E3AEC8A.8070403@callenish.com> <4E3AF224.20005@caucho.com> <4E3C08B8.50202@callenish.com> <4E410C41.4090400@isode.com> <4E42DE18.2080802@isode.com> <4E43071F.20101@caucho.com> In-Reply-To: <4E43071F.20101@caucho.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] max frame size. was: consensus call on ability to announce max frame size 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, 11 Aug 2011 06:16:24 -0000 On 08/10/2011 11:33 PM, Somebody in the thread at some point said: > On 08/10/2011 12:38 PM, Alexey Melnikov wrote: >> >> Ok, this might work for the per-frame compression, but there is >> currently no requirement that all extensions must support streaming. >> Greg's example of an extension with digital signature is a good one. >> The data is not even valid until the signature can be verified. If the >> signature fails to verify, what to do with the data which was already >> delivered to the application? > > Those hypothetical extensions need to negotiate their own limits. > Frame-size isn't the only resource limitation an extension might have. Right on dude. That also works for extensions in series with conflicting demands while leaving the base spec layer clean of this specialized detail. -Andy From tobias.oberstein@tavendo.de Thu Aug 11 01:10: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 1FB2F21F8B06 for ; Thu, 11 Aug 2011 01:10:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y87HsSpL1c+B for ; Thu, 11 Aug 2011 01:10:38 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 2492A21F8B03 for ; Thu, 11 Aug 2011 01:10:37 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Thu, 11 Aug 2011 01:11:11 -0700 From: Tobias Oberstein To: Bob Gezelter , "hybi@ietf.org" Date: Thu, 11 Aug 2011 01:11:09 -0700 Thread-Topic: [hybi] WebSocket Frame Size and latency Thread-Index: AcxXQrWajmKl6UiDT2i6Rn4p3uSFBwAu4Qxv Message-ID: In-Reply-To: <20110810024838.ef1fc80126c74c6c202a919c41c7bb0b.8e1b7e484e.wbe@email03.secureserver.net> Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] WebSocket Frame Size and latency 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, 11 Aug 2011 08:10:39 -0000 On 10.08.11 11:48, "Bob Gezelter" wrote: > Andy, >=20 > Indeed. As I noted in my comment yesterday, the only absolute impact of > frame size is on the latency of what can come after a frame. > Realistically speaking, not interfering with PING/PONG and other > administrative traffic requires a latency measured in fractions of a > second. This translates into frame sizes of order 10**4 on present day > LAN interconnects, more like 10**3 on lower speed interconnections. Good that you bring that up, since I think it directs this whole frame size discussion to more fruitful grounds. Here is my cut. Indeed, control messages can be viewed as the messaging on a "control channel". When looked at this in that way, even the base WebSockets protocol has already two channels implicitly built in. When having a data link shared my more than 1 channel (virtual circuit), the question of data link occupation time appears. This again, is in part then related to frame size. But I think choosing an optimal frame size is not so simple as it first appears. There is a tradeoff between the duration a link is occupied on average by channels, and the efficiency of data transfer. I.e. when you allow channels to occupy only for very short periods, a channel can not monopolize bandwidth, latency decreases, but overhead increases, and thus effective bandwidth. Another issue: I.e. ADSL links have vastly different bandwidths in downlink versus uplink direction. More importantly, mobile links have not only also asymmetric bandwidths, but also time varying bandwidths. If you put only those aspects (and there may be more) together, you'll want to have frame size dynamically adjusted based on currently available link bandwidth and acceptable link occupation time (latency). Per direction. The acceptable link occupation time might be application dependent. Announcing a max. frame size in HTTP headers during initial handshake, bein= g fixed for both directions and the whole lifetime of the connection does not fit the bill. >=20 > Multiplexing extensions, which I would prefer not to be extensions, but > part of the base specification, extend this problem in the context of > providing a degree of fairness to the different channels (e.g., an > extremely long frame, >10**8 bytes, does not create an effective, > non-removable blockage in the channel. >=20 > - Bob Gezelter, http://www.rlgsc.com >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi >=20 From andy@warmcat.com Thu Aug 11 02:55: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 A26CB21F8AE6 for ; Thu, 11 Aug 2011 02:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR85cjmHlbT2 for ; Thu, 11 Aug 2011 02:55:07 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1C65721F8AD8 for ; Thu, 11 Aug 2011 02:55:06 -0700 (PDT) Message-ID: <4E43A719.50401@warmcat.com> Date: Thu, 11 Aug 2011 10:55:37 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] WebSocket Frame Size and latency 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, 11 Aug 2011 09:55:07 -0000 On 08/11/2011 09:11 AM, Somebody in the thread at some point said: > Announcing a max. frame size in HTTP headers during initial handshake, being > fixed for both directions and the whole lifetime of the connection does not > fit the bill. The guys who like frame mtu plan to create implementations which break if you send them legal frames bigger than some size they liked when they wrote the code. So they will create an implementation which cannot cope with frames above a certain size. It's that "I'm gonna break" size they want to formally warn peers about so they won't send frames above that size. The standard should not wink at that broken behaviour in the base definition, if some extension wants to be like that then it is up to the peer extension to enforce a fragmentation workaround and that ugliness all belongs to the extension. Optimizing frame size for throughput, overhead and latency is related but different issue, you could still decide to fragment at some more optimal, smaller limit dynamically even with this frame mtu stuff. Really big frames are evil from a latency standpoint and it is legal to block the channel for literally many years as it stands, that can't be right either. -Andy From tobias.oberstein@tavendo.de Thu Aug 11 06:03:11 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 5BF1721F87C9 for ; Thu, 11 Aug 2011 06:03:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nP+K4vQX7vsb for ; Thu, 11 Aug 2011 06:03:10 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 8200821F86F6 for ; Thu, 11 Aug 2011 06:03:10 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Thu, 11 Aug 2011 06:03:44 -0700 From: Tobias Oberstein To: Takeshi Yoshino Date: Thu, 11 Aug 2011 06:03:07 -0700 Thread-Topic: [hybi] mux extension document? Thread-Index: AcxXwXL4sJmmuO3yQXO+aY/Hi+VaIwAYSzfA Message-ID: <634914A010D0B943A035D226786325D422BFBFBF15@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] mux extension document? 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, 11 Aug 2011 13:03:11 -0000 here is some feedback .. 1) The use of opcode 7 is the only use of the WebSocket extension points, n= o reserved bits whatever, right?=20 2) AddChannel 1 is illegal, since logical channel 1 is identical to the dat= a channel on the physical WebSockets connection? 3) Same with DropChannel .. or is that equivalent to Close on physical? 4) "If the extension is successfully negotiated during the handshake, all d= ata frames MUST be sent using the MUX opcode (defined as 0x7) -- except for frames on logical channel 1 before any AddChannel has been se= nt, in which case they may be sent normally on the physical channel." I don't get it: As long as a peer has not yet sent a AddChannel: it MAY send data frames with opcode 1/2 which then are assigned to logical = channel 1 and alternatively it MAY send data frames with opcode 7 and mux_opcode 0, in which case those= are also assigned to channel 1? 5) "If the extension is successfully negotiated during the handshake, all data= frames MUST be sent using the MUX opcode (defined as 0x7)" Does that mean that continuation frames are no longer allowed on the physic= al WS? No fragmented messages? 6) "The payload data of a MUX frame is defined as 1 or more MUX blocks, each d= efined as below (note that MUX frames may be fragmented across mutliple WebSocket frames)." Shouldn't that read "The payload data of a MUX _message_ ... (not that MUX = _messages_ .." Or is "frame" in "MUX frame" something different from "frame" in the WS sen= se? 7) Is the following then a valid example? On physical WS: [opcode =3D 7, fin =3D 0, [++++++++++]][opcode =3D 0, fin =3D 0, [+++++]][ = opcode =3D 0, fin =3D 1, [+++++++++++++]] =3D Fragmented Mux message [++++++++++][+++++][+++++++++++++] =3D frames of Mux message payload on phy= sical WS [******][******][****************] =3D sequence of Mux blocks 8) For MUX Opcode 0 (DATA): "The remainder of this block is a complete WebSocket frame, which may itsel= f be fragmented, multiplexed, masked, etc. The end of this mux block is determined by the length of the frame." By "the length" of which frame? The enclosing physical WS frame or the wrapped WS frame? =3D=3D=3D I'll stop here ... I got lost. From gregw@intalio.com Thu Aug 11 06:32: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 4242621F86AF for ; Thu, 11 Aug 2011 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9mHexULRkisn for ; Thu, 11 Aug 2011 06:32:27 -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 B0F3221F86AD for ; Thu, 11 Aug 2011 06:32:27 -0700 (PDT) Received: by vws12 with SMTP id 12so2085457vws.31 for ; Thu, 11 Aug 2011 06:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.163 with SMTP id dl3mr9321453vdb.229.1313069581794; Thu, 11 Aug 2011 06:33:01 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Thu, 11 Aug 2011 06:33:01 -0700 (PDT) In-Reply-To: <4E43A719.50401@warmcat.com> References: <4E43A719.50401@warmcat.com> Date: Thu, 11 Aug 2011 23:33:01 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] WebSocket Frame Size and latency 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, 11 Aug 2011 13:32:28 -0000 On 11 August 2011 19:55, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" wrote: > The guys who like frame mtu plan to create implementations which break if > you send them legal frames bigger than some size they liked when they wro= te > the code. So they will create an implementation which cannot cope with fr= ames above a certain size. Can you please try to be a little less insulting and dismissive of the views of others that you don't agree with. Your representation of the motivations of "the guys" advocated a declaration of max frame limit are incorrect. You appear to be arguing against the existence of frame size limits, when what is being proposed is simply the declaration a limit IF it exists, which it may do for a number of reasons (including but not limited to simple implementations) and that is allowed to exist by the existence of the frame-too-large close status. I would understand your position better if you were advocating the removal of frame-too-large error, but you've also acknowledged that there are reasons to limit frame size, but that it should be extensions that do it. However I find it a confused situation to advocate that multiple extensions will be required to implement frame size limitation mechanisms that will ultimately be policed by a frame-too-large error mechanism in the base protocol - which does not know what the frame limit is. From tobias.oberstein@tavendo.de Thu Aug 11 07:05: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 72C3E21F8561 for ; Thu, 11 Aug 2011 07:05:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyHTV0SCjr-U for ; Thu, 11 Aug 2011 07:05:00 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id DDDE521F854E for ; Thu, 11 Aug 2011 07:04:59 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Thu, 11 Aug 2011 07:05:33 -0700 From: Tobias Oberstein To: Greg Wilkins , "hybi@ietf.org" Date: Thu, 11 Aug 2011 07:04:58 -0700 Thread-Topic: [hybi] WebSocket Frame Size and latency Thread-Index: AcxYKza7xtRseY5STXSMUh2TpYrqaAAA4Cdw Message-ID: <634914A010D0B943A035D226786325D422BFBFBF77@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [hybi] WebSocket Frame Size and latency 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, 11 Aug 2011 14:05:00 -0000 PiBleHRlbnNpb25zIHRoYXQgZG8gaXQuICAgICBIb3dldmVyIEkgZmluZCBpdCBhIGNvbmZ1c2Vk IHNpdHVhdGlvbiB0bw0KPiBhZHZvY2F0ZSB0aGF0IG11bHRpcGxlIGV4dGVuc2lvbnMgd2lsbCBi ZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgZnJhbWUgc2l6ZQ0KPiBsaW1pdGF0aW9uIG1lY2hhbmlz bXMgdGhhdCB3aWxsIHVsdGltYXRlbHkgYmUgcG9saWNlZCBieSBhIGZyYW1lLXRvby1sYXJnZQ0K DQp0aGVpciBtZWNoYW5pc21zIG1heSBiZSBkaWZmZXJlbnQgLi4gYXMgSSB0cmllZCB0byBzdWdn ZXN0IGluIHRoZSBvdGhlciBwb3N0LA0KYW4gZXh0ZW5zaW9uIG1heSB3YW50IHRvIGR5bmFtaWNh bGx5IGFkanVzdCB0aGUgZnJhbWUgc2l6ZSBhcyBhIGZ1bmN0aW9uIG9mDQpjdXJyZW50IHVwbGlu ay9kb3dubGluayBiYW5kd2lkdGggYW5kIGRlbGF5DQoNCmEgbWVjaGFuaXNtIHdoaWNoIGZpeGVz IGEgbWF4LiBmcmFtZSBzaXplIGR1cmluZyBoYW5kc2hha2UgZm9yIGJvdGgNCnVwbGluayBhbmQg ZG93bmxpbmsgZm9yIHRoZSB3aG9sZSBkdXJhdGlvbiBvZiB0aGUgV1MgY29ubmVjdGlvbiBpcyBq dXN0IF9vbmVfDQpjb25jZWl2YWJsZQ0KDQppZiB0aGF0IG9uZSBtZWNoYW5pc20gd291bGQgYmUg YmFrZWQgaW50byB0aGUgYmFzZSBzcGVjLCBhbiBleHRlbnNpb24NCnRoYXQgd2FudHMgdG8gZHlu YW1pY2FsbHkgYWRqdXN0IGFzIGFib3ZlIHdvdWxkIGJlIGxpbWl0ZWQgaW4gd2hhdCBpdCBjYW4g ZG8sDQpmb3Igbm8gcmVhc29uLCBhbmQgdG8gdGhlIGRpc2FkdmFudGFnZSBvZiB0aGF0IGV4dGVu c2lvbg0KDQo+IGVycm9yIG1lY2hhbmlzbSBpbiB0aGUgYmFzZSBwcm90b2NvbCAtIHdoaWNoIGRv ZXMgbm90IGtub3cgd2hhdCB0aGUgZnJhbWUNCj4gbGltaXQgaXMuDQoNCnRoZSBmcmFtZSB0b28g bGFyZ2UgImVycm9yIiBzaG91bGQgYmUgcmVtb3ZlZCBmcm9tIHRoZSBiYXNlIHNwZWMNCg== From andy@warmcat.com Thu Aug 11 07:10:27 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 51B1D21F8742 for ; Thu, 11 Aug 2011 07:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.282 X-Spam-Level: X-Spam-Status: No, score=-2.282 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfF4jPss561R for ; Thu, 11 Aug 2011 07:10:26 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7E21F86AA for ; Thu, 11 Aug 2011 07:10:26 -0700 (PDT) Message-ID: <4E43E2E3.1050403@warmcat.com> Date: Thu, 11 Aug 2011 15:10:43 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket Frame Size and latency 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, 11 Aug 2011 14:10:27 -0000 On 08/11/2011 02:33 PM, Somebody in the thread at some point said: > On 11 August 2011 19:55, "Andy Green (林安廸)" wrote: >> The guys who like frame mtu plan to create implementations which break if >> you send them legal frames bigger than some size they liked when they wrote >> the code. So they will create an implementation which cannot cope with frames above a certain size. > > Can you please try to be a little less insulting and dismissive of the > views of others that you don't agree with. Your representation of the > motivations of "the guys" advocated a declaration of max frame limit > are incorrect. Not sure why you feel insulted by that observation since ---> > You appear to be arguing against the existence of frame size limits, > when what is being proposed is simply the declaration a limit IF it > exists, which it may do for a number of reasons (including but not > limited to simple implementations) and that is allowed to exist by the > existence of the frame-too-large close status. "... planning to create implementations which break if you send them legal frames bigger than some size they liked when they wrote the code" seems to sum that up fairly. I mean I'm bald Greg, I got over people noticing that a while back it's just a fact. > I would understand your position better if you were advocating the > removal of frame-too-large error, but you've also acknowledged that It's a bit of a 'dark art' of argumentation to try to leverage the existence of an error already into the spec as the basis for this frame mtu stuff ^^ > there are reasons to limit frame size, but that it should be Actually I heard exactly one reason, which is this putative frame signing thing. > extensions that do it. However I find it a confused situation to > advocate that multiple extensions will be required to implement frame > size limitation mechanisms that will ultimately be policed by a > frame-too-large error mechanism in the base protocol - which does not > know what the frame limit is. The base protocol deliberately averts its head from details that go on under the clothes of extensions. Extensions that are constructed with arbitrary frame size limitations fall under that same modesty, it's the business of the extension peers to manage that problem that particular extension decides to introduce. Many times the outcome of discussions here is push it into an extension or let an extension take care of it. Seems this is another one because the only reason found for wanting it involves a characteristic of a particular proposed extension which is able to solve its requirement in the same extension. -Andy From stpeter@stpeter.im Thu Aug 11 09:48: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 2701921F8C83 for ; Thu, 11 Aug 2011 09:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.624 X-Spam-Level: X-Spam-Status: No, score=-102.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTwuF8ybo6d6 for ; Thu, 11 Aug 2011 09:48:39 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 69E8C21F8C73 for ; Thu, 11 Aug 2011 09:48:39 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 664F741477; Thu, 11 Aug 2011 10:50:56 -0600 (MDT) Message-ID: <4E440808.5030907@stpeter.im> Date: Thu, 11 Aug 2011 10:49:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> In-Reply-To: X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 11 Aug 2011 16:48:40 -0000 This is your Area Director speaking. I would very much like to issue an IESG ballot for our base document in the near future. The WG needs to decide this matter in order for us to proceed. See below for details. On 8/11/11 7:33 AM, Greg Wilkins wrote: > On 11 August 2011 19:55, "Andy Green (林安廸)" wrote: >> The guys who like frame mtu plan to create implementations which break if >> you send them legal frames bigger than some size they liked when they wrote >> the code. So they will create an implementation which cannot cope with frames above a certain size. > > Can you please try to be a little less insulting and dismissive of the > views of others that you don't agree with. Your representation of the > motivations of "the guys" advocated a declaration of max frame limit > are incorrect. > > You appear to be arguing against the existence of frame size limits, > when what is being proposed is simply the declaration a limit IF it > exists, which it may do for a number of reasons (including but not > limited to simple implementations) and that is allowed to exist by the > existence of the frame-too-large close status. > > I would understand your position better if you were advocating the > removal of frame-too-large error, but you've also acknowledged that > there are reasons to limit frame size, but that it should be > extensions that do it. However I find it a confused situation to > advocate that multiple extensions will be required to implement frame > size limitation mechanisms that will ultimately be policed by a > frame-too-large error mechanism in the base protocol - which does not > know what the frame limit is. Apparently there is a disconnect in the specification: as currently written, an implementation can reject a frame because it is too big (error code 1004), but it can't signal its maximum frame size. Therefore, as your Area Director, I am requesting a consensus call on the following alternative. 1. Remove error code 1004 "Frame Too Large". or 2. Retain error code 1004, add an OPTIONAL way for an entity to signal its maximum frame size, and specify that an implementation SHOULD NOT send frames larger than the maximum frame size signalled by its peer. Please reply to this consensus call by the close of business next Wednesday, August 17, 2011. When you reply, please indicate your preference ("1" or "2") and provide a brief reason, if appropriate. Thank you. Peter -- Peter Saint-Andre https://stpeter.im/ From bruce@callenish.com Thu Aug 11 10:39: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 840D65E8002 for ; Thu, 11 Aug 2011 10:39:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M25hABgvMsw9 for ; Thu, 11 Aug 2011 10:39:49 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 07FA65E8001 for ; Thu, 11 Aug 2011 10:39:49 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrZF0-0000rX-4u; Thu, 11 Aug 2011 10:40:22 -0700 Message-ID: <4E441405.2020405@callenish.com> Date: Thu, 11 Aug 2011 10:40:21 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: <4E440808.5030907@stpeter.im> Content-Type: text/plain; charset=UTF-8; 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] CONSENSUS CALL 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, 11 Aug 2011 17:39:49 -0000 On 11/08/2011 9:49 AM, Peter Saint-Andre wrote: > This is your Area Director speaking. I would very much like to issue an > IESG ballot for our base document in the near future. The WG needs to > decide this matter in order for us to proceed. See below for details. > > Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size. > > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. > > Please reply to this consensus call by the close of business next > Wednesday, August 17, 2011. When you reply, please indicate your > preference ("1" or "2") and provide a brief reason, if appropriate. > I very strongly prefer 2. No matter what the WG decides, I will be closing connections if a frame is larger than the maximum that I can deal with. My implementation is only intended to be used in situations where the vast majority of messages will be small, and if there is ever a message larger than 64K it will either be a bug or an attack. That means I will never need frames that are bigger than that under any circumstances. Although I could implement in a way to allow very large frames, this would be a violation of YAGNI, overengineering for a case that should never happen. Doing the simplest thing possible that will work requires that I match my maximum frame size with my buffer size. I will deal with any frame I receive no matter what size it is within the range of the payload length, but dealing with it may well mean closing the connection. This is in complete conformance with the spec (whether there is a specific error code for closing the connection or not), so there is no chance that this would be a broken implementation. To me, the question is how other implementations will be interoperable with mine. Option 2 makes it easy. Option 1 makes it difficult. Since option 2 allows all behaviour to be completely optional, I see no reason not to adopt it into the spec. From andy@warmcat.com Thu Aug 11 10:52: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 53BC321F8B71 for ; Thu, 11 Aug 2011 10:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.283 X-Spam-Level: X-Spam-Status: No, score=-2.283 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TV899sWj+vw for ; Thu, 11 Aug 2011 10:52:33 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id C321321F8B5D for ; Thu, 11 Aug 2011 10:52:33 -0700 (PDT) Message-ID: <4E441703.70606@warmcat.com> Date: Thu, 11 Aug 2011 18:53:07 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: <4E440808.5030907@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL 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, 11 Aug 2011 17:52:34 -0000 On 08/11/2011 05:49 PM, Somebody in the thread at some point said: > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. 1) Remove the error code. > Please reply to this consensus call by the close of business next > Wednesday, August 17, 2011. When you reply, please indicate your > preference ("1" or "2") and provide a brief reason, if appropriate. The only valid use that has been given for frame mtu scheme involves one proposed extension, and those extension peers can arrange to meet their restrictions and perform any negotiation at that level without any footprint in the base spec. Introducing it at the base spec instead is inviting people to make fragile implementations by buffering whole frames and adds needless complexity to the protocol and testing. -Andy From tobias.oberstein@tavendo.de Thu Aug 11 11:22: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 97F4D21F8752 for ; Thu, 11 Aug 2011 11:22:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_24=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0NyP1HeL9-t for ; Thu, 11 Aug 2011 11:22:13 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 0FB3C21F86D8 for ; Thu, 11 Aug 2011 11:22:13 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Thu, 11 Aug 2011 11:22:47 -0700 From: Tobias Oberstein To: Peter Saint-Andre , Greg Wilkins Date: Thu, 11 Aug 2011 11:22:12 -0700 Thread-Topic: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) Thread-Index: AcxYRyiNrr9EuoitT9WG2rUU1mOuwAACs6Sg Message-ID: <634914A010D0B943A035D226786325D422BFBFC15C@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: <4E440808.5030907@stpeter.im> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 11 Aug 2011 18:22:13 -0000 PiAxLiBSZW1vdmUgZXJyb3IgY29kZSAxMDA0ICJGcmFtZSBUb28gTGFyZ2UiLg0KDQorMSwgc2lu Y2UgaXQncyBjb25zZXF1ZW50IGFuZCByZW1vdmVzIGEgc291cmNlIG9mIGNvbmZ1c2lvbiBhbmQg bWlzZGlyZWN0aW9uLg0KDQpUaGVyZSBhcmUgY29uY2VpdmFibGUgdXNlIGNhc2VzIGZvciBoYXZp bmcNCg0KLSBubyBmcmFtZSBzaXplIGxpbWl0cyAod2hlcmUgMl42MyBzZXJ2ZXMgcHJhY3RpY2Fs bHkgaW5maW5pdGUpDQotIG1heC4gZnJhbWUgc2l6ZSBuZWdvdGlhdGVkIHBlciBjb25uZWN0aW9u LCB1cCZkb3duLCBmaXhlZCBmb3IgZHVyYXRpb24gb2YgY29ubmVjdGlvbg0KLSBkeW5hbWljL2Fk YXB0aXZlIGZyYW1lIHNpemUsIGRpZmZlcmVudCBmb3IgdXAvZG93bg0KLSBub24tbmVnb3RpYXRl ZCwgZml4ZWQgc2l6ZQ0KDQphbmQgc28gb24gLi4NCg0KVXNlIGNhc2VzIHdpbGwgZGV0ZXJtaW5l IHJlcXVpcmVtZW50cyBhbmQgYnkgdGhhdCBtZWNoYW5pc21zLiBNZWNoYW5pc21zIHdpbGwgZGlm ZmVyDQphbmQgbWF5IGNvbnRyYWRpY3QgZWFjaCBvdGhlci4NCg0KQ29uc3RyYWludHMgb24gZnJh bWUgc2l6ZSBzaG91bGQgYmUgdGhlIGJ1c2luZXNzIG9mIGV4dGVuc2lvbnMuIE5vdCB0aGUgYmFz ZSBzcGVjLg0KDQo= From gregw@intalio.com Thu Aug 11 16:20: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 B023511E8093 for ; Thu, 11 Aug 2011 16:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.912 X-Spam-Level: X-Spam-Status: No, score=-2.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0LEzQCvcKV2 for ; Thu, 11 Aug 2011 16:20:18 -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 C28AC21F8B1E for ; Thu, 11 Aug 2011 16:20:18 -0700 (PDT) Received: by vws12 with SMTP id 12so2572999vws.31 for ; Thu, 11 Aug 2011 16:20:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.163 with SMTP id dl3mr211645vdb.229.1313104853699; Thu, 11 Aug 2011 16:20:53 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Thu, 11 Aug 2011 16:20:53 -0700 (PDT) In-Reply-To: <4E440808.5030907@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Fri, 12 Aug 2011 09:20:53 +1000 Message-ID: From: Greg Wilkins To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 11 Aug 2011 23:20:20 -0000 As it stands, my preference is for #2, as I believe that resource limited implementations like what Bruce Atherton have described are valid and they need a defined error code to indicate the reason of the close. However, if we added a message-too-large error, then I would support option #1 (removal of frame-too-large). The significant difference between frame-too-large and message-too-large is that ws implementations can do something about the frame too large error, which essentially represents a miss negotiation of protocol configuration. The message-too-large error is fatal as far as the protocol is concerned, as there is nothing an implementation can do to reduce the size of the application messages, other than report the reason for the failure. In the absence of extensions, I suspect that implementations like Bruce's are really limited by message size and not frame size. My own implementation support both a max frame size or streaming data to the application layer. If it is accumulating frames into a message, it also supports a maximum message size. Currently if that maximum message size is exceeded it is miss-using the 1004 frame-too-large close code to close the connection, because there is no other reasonable alternative. regards On 12 August 2011 02:49, Peter Saint-Andre wrote: > This is your Area Director speaking. I would very much like to issue an > IESG ballot for our base document in the near future. The WG needs to > decide this matter in order for us to proceed. See below for details. > > On 8/11/11 7:33 AM, Greg Wilkins wrote: >> On 11 August 2011 19:55, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" wrote: >>> The guys who like frame mtu plan to create implementations which break = if >>> you send them legal frames bigger than some size they liked when they w= rote >>> the code. So they will create an implementation which cannot cope with = frames above a certain size. >> >> Can you please try to be a little less insulting and dismissive of the >> views of others that you don't agree with. =C2=A0Your representation of = the >> motivations of "the guys" advocated a declaration of max frame limit >> are incorrect. >> >> You appear to be arguing against the existence of frame size limits, >> when what is being proposed is simply the declaration a limit IF it >> exists, which it may do for a number of reasons (including but not >> limited to simple implementations) and that is allowed to exist by the >> existence of the frame-too-large close status. >> >> I would understand your position better if you were advocating the >> removal of frame-too-large error, but you've also acknowledged that >> there are reasons to limit frame size, but that it should be >> extensions that do it. =C2=A0 =C2=A0 However I find it a confused situat= ion to >> advocate that multiple extensions will be required to implement frame >> size limitation mechanisms that will ultimately be policed by a >> frame-too-large error mechanism in the base protocol - which does not >> know what the frame limit is. > > Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size. > > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. > > Please reply to this consensus call by the close of business next > Wednesday, August 17, 2011. When you reply, please indicate your > preference ("1" or "2") and provide a brief reason, if appropriate. > > Thank you. > > Peter > > -- > Peter Saint-Andre > https://stpeter.im/ > > > From fenix@google.com Thu Aug 11 16:31: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 D92F811E809B for ; Thu, 11 Aug 2011 16:31:46 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pi7IjtEjhayb for ; Thu, 11 Aug 2011 16:31:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id E818511E8099 for ; Thu, 11 Aug 2011 16:31:40 -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 p7BNWA0D010076 for ; Thu, 11 Aug 2011 16:32:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313105531; bh=mMfUHB+ccFLALaCr9c38HV4imns=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=jssXRVhawqg4ZqfL+TXxHmEKJ1cSmG3JxUwYrZl5YCC9P2vlE+0MKtfevXb8u8kVB vkgtRDaL7XOOhY0p7EBCQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=MeYp68Z5cnDwXwDjGkxJgGZqVfamxVWuBhet0YC3ZYpi56ak93y9hopUMcZ4tk6a0 hddEvaLYfG2PDweCeODNA== Received: from gwaa12 (gwaa12.prod.google.com [10.200.27.12]) by wpaz33.hot.corp.google.com with ESMTP id p7BNUvF3009062 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 11 Aug 2011 16:32:09 -0700 Received: by gwaa12 with SMTP id a12so2122351gwa.33 for ; Thu, 11 Aug 2011 16:32:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=F2Xm2qgDyg+qLW/mgGoxIoz68upr7LXGWI9+2PWgF4Y=; b=iBDeksSESKQq3vPlQ0ONcPz2bb/K4/W+gfo4p0lA0q00d9CZZICeo9VhJzVCTEThUR UueYSp/5yhlZbgHYeByw== Received: by 10.150.229.17 with SMTP id b17mr1275486ybh.61.1313105529576; Thu, 11 Aug 2011 16:32:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.229.17 with SMTP id b17mr1275481ybh.61.1313105529433; Thu, 11 Aug 2011 16:32:09 -0700 (PDT) Received: by 10.151.153.7 with HTTP; Thu, 11 Aug 2011 16:32:09 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Thu, 11 Aug 2011 16:32:09 -0700 Message-ID: From: Roberto Peon To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd4d8e0a26f3a04aa4334f1 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 11 Aug 2011 23:31:47 -0000 --000e0cd4d8e0a26f3a04aa4334f1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 message to large -=3DR On Thu, Aug 11, 2011 at 4:20 PM, Greg Wilkins wrote: > As it stands, my preference is for #2, as I believe that resource > limited implementations like what Bruce Atherton have described are > valid and they need a defined error code to indicate the reason of the > close. > > However, if we added a message-too-large error, then I would support > option #1 (removal of frame-too-large). > > The significant difference between frame-too-large and > message-too-large is that ws implementations can do something about > the frame too large error, which essentially represents a miss > negotiation of protocol configuration. The message-too-large error > is fatal as far as the protocol is concerned, as there is nothing an > implementation can do to reduce the size of the application messages, > other than report the reason for the failure. In the absence of > extensions, I suspect that implementations like Bruce's are really > limited by message size and not frame size. > > My own implementation support both a max frame size or streaming data > to the application layer. If it is accumulating frames into a > message, it also supports a maximum message size. Currently if that > maximum message size is exceeded it is miss-using the 1004 > frame-too-large close code to close the connection, because there is > no other reasonable alternative. > > regards > > > On 12 August 2011 02:49, Peter Saint-Andre wrote: > > This is your Area Director speaking. I would very much like to issue an > > IESG ballot for our base document in the near future. The WG needs to > > decide this matter in order for us to proceed. See below for details. > > > > On 8/11/11 7:33 AM, Greg Wilkins wrote: > >> On 11 August 2011 19:55, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" wrote: > >>> The guys who like frame mtu plan to create implementations which brea= k > if > >>> you send them legal frames bigger than some size they liked when they > wrote > >>> the code. So they will create an implementation which cannot cope wit= h > frames above a certain size. > >> > >> Can you please try to be a little less insulting and dismissive of the > >> views of others that you don't agree with. Your representation of the > >> motivations of "the guys" advocated a declaration of max frame limit > >> are incorrect. > >> > >> You appear to be arguing against the existence of frame size limits, > >> when what is being proposed is simply the declaration a limit IF it > >> exists, which it may do for a number of reasons (including but not > >> limited to simple implementations) and that is allowed to exist by the > >> existence of the frame-too-large close status. > >> > >> I would understand your position better if you were advocating the > >> removal of frame-too-large error, but you've also acknowledged that > >> there are reasons to limit frame size, but that it should be > >> extensions that do it. However I find it a confused situation to > >> advocate that multiple extensions will be required to implement frame > >> size limitation mechanisms that will ultimately be policed by a > >> frame-too-large error mechanism in the base protocol - which does not > >> know what the frame limit is. > > > > Apparently there is a disconnect in the specification: as currently > > written, an implementation can reject a frame because it is too big > > (error code 1004), but it can't signal its maximum frame size. > > > > Therefore, as your Area Director, I am requesting a consensus call on > > the following alternative. > > > > 1. Remove error code 1004 "Frame Too Large". > > > > or > > > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > > its maximum frame size, and specify that an implementation SHOULD NOT > > send frames larger than the maximum frame size signalled by its peer. > > > > Please reply to this consensus call by the close of business next > > Wednesday, August 17, 2011. When you reply, please indicate your > > preference ("1" or "2") and provide a brief reason, if appropriate. > > > > Thank you. > > > > Peter > > > > -- > > Peter Saint-Andre > > https://stpeter.im/ > > > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --000e0cd4d8e0a26f3a04aa4334f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 message to large
-=3DR

On Thu, Aug= 11, 2011 at 4:20 PM, Greg Wilkins <gregw@intalio.com> wrote:
As it stands, my preference is for #2, as I believe that resource
limited implementations like what Bruce Atherton have described are
valid and they need a defined error code to indicate the reason of the
close.

However, if we added a message-too-large error, then I would support
option #1 (removal of frame-too-large).

The significant difference between frame-too-large and
message-too-large is that ws implementations can do something about
the frame too large error, which essentially represents a miss
negotiation of protocol configuration. =C2=A0 The message-too-large error is fatal as far as the protocol is concerned, as there is nothing an
implementation can do to reduce the size of the application messages,
other than report the reason for the failure. =C2=A0 In the absence of
extensions, I suspect that implementations like Bruce's are really
limited by message size and not frame size.

My own implementation support both a max frame size or streaming data
to the application layer. =C2=A0 If it is accumulating frames into a
message, it also supports a maximum message size. =C2=A0Currently if that maximum message size is exceeded it is miss-using the 1004
frame-too-large close code to close the connection, because there is
no other reasonable alternative.

regards


On 12 August 2011 02:49, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> This is your Area Director speaking. I would very much like to issue a= n
> IESG ballot for our base document in the near future. The WG needs to<= br> > decide this matter in order for us to proceed. See below for details.<= br> >
> On 8/11/11 7:33 AM, Greg Wilkins wrote:
>> On 11 August 2011 19:55, "Andy Green (=E6=9E=97=E5=AE=89=E5= =BB=B8)" <andy@warmcat.com&= gt; wrote:
>>> The guys who like frame mtu plan to create implementations whi= ch break if
>>> you send them legal frames bigger than some size they liked wh= en they wrote
>>> the code. So they will create an implementation which cannot c= ope with frames above a certain size.
>>
>> Can you please try to be a little less insulting and dismissive of= the
>> views of others that you don't agree with. =C2=A0Your represen= tation of the
>> motivations of "the guys" advocated a declaration of max= frame limit
>> are incorrect.
>>
>> You appear to be arguing against the existence of frame size limit= s,
>> when what is being proposed is simply the declaration a limit IF i= t
>> exists, which it may do for a number of reasons (including but not=
>> limited to simple implementations) and that is allowed to exist by= the
>> existence of the frame-too-large close status.
>>
>> I would understand your position better if you were advocating the=
>> removal of frame-too-large error, but you've also acknowledged= that
>> there are reasons to limit frame size, but that it should be
>> extensions that do it. =C2=A0 =C2=A0 However I find it a confused = situation to
>> advocate that multiple extensions will be required to implement fr= ame
>> size limitation mechanisms that will ultimately be policed by a >> frame-too-large error mechanism in the base protocol - which does = not
>> know what the frame limit is.
>
> Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size.
>
> Therefore, as your Area Director, I am requesting a consensus call on<= br> > the following alternative.
>
> 1. Remove error code 1004 "Frame Too Large".
>
> or
>
> 2. Retain error code 1004, add an OPTIONAL way for an entity to signal=
> its maximum frame size, and specify that an implementation SHOULD NOT<= br> > send frames larger than the maximum frame size signalled by its peer.<= br> >
> Please reply to this consensus call by the close of business next
> Wednesday, August 17, 2011. When you reply, please indicate your
> preference ("1" or "2") and provide a brief reason= , if appropriate.
>
> Thank you.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>
>
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--000e0cd4d8e0a26f3a04aa4334f1-- From fenix@google.com Thu Aug 11 16:32: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 A425821F8B3F for ; Thu, 11 Aug 2011 16:32:03 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVEiUw3SrbKE for ; Thu, 11 Aug 2011 16: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 5EE6C21F8B3C for ; Thu, 11 Aug 2011 16:31:59 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7BNWYpo013263 for ; Thu, 11 Aug 2011 16:32:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313105554; bh=h9i1/4amaN4DC1ENyn8PHoQkZZM=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=Iryxl3Ru1jmrnoZLd1iOir8tT8yjDoX2mx+KPTC36CcSMbxb0V/8m5fkY8kFl1qsD CEbqdbE4qCBPGur+kSWfw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=G48MWkB+PoMeOcDBLE+L+BOZkoWO55NxwoT2UQMa5Eq7x4aJOzCQjRiK5zrQLc3KB tJaAFjOEqf6aeEhP2JC9g== Received: from ywa12 (ywa12.prod.google.com [10.192.1.12]) by hpaq14.eem.corp.google.com with ESMTP id p7BNWVak013311 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 11 Aug 2011 16:32:32 -0700 Received: by ywa12 with SMTP id 12so1613005ywa.9 for ; Thu, 11 Aug 2011 16:32:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5+cA6b2Eel3Oc6wy5qQK6zWlY4brCcUNyNqA0t/tGZ8=; b=tixHpZwgmskXGA9EajWQ0rhHpMytOwX66mwJefhl3QtRS+XcRWSZOIIXHo2j7SD7Nh hn1b+w+65+GhNaQdO5jA== Received: by 10.150.136.5 with SMTP id j5mr1259506ybd.118.1313105551619; Thu, 11 Aug 2011 16:32:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.136.5 with SMTP id j5mr1259488ybd.118.1313105550399; Thu, 11 Aug 2011 16:32:30 -0700 (PDT) Received: by 10.151.153.7 with HTTP; Thu, 11 Aug 2011 16:32:30 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Thu, 11 Aug 2011 16:32:30 -0700 Message-ID: From: Roberto Peon To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd56adae2591404aa433567 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 11 Aug 2011 23:32:03 -0000 --000e0cd56adae2591404aa433567 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable er, message-*too-large. -=3DR On Thu, Aug 11, 2011 at 4:32 PM, Roberto Peon wrote: > +1 message to large > -=3DR > > > On Thu, Aug 11, 2011 at 4:20 PM, Greg Wilkins wrote: > >> As it stands, my preference is for #2, as I believe that resource >> limited implementations like what Bruce Atherton have described are >> valid and they need a defined error code to indicate the reason of the >> close. >> >> However, if we added a message-too-large error, then I would support >> option #1 (removal of frame-too-large). >> >> The significant difference between frame-too-large and >> message-too-large is that ws implementations can do something about >> the frame too large error, which essentially represents a miss >> negotiation of protocol configuration. The message-too-large error >> is fatal as far as the protocol is concerned, as there is nothing an >> implementation can do to reduce the size of the application messages, >> other than report the reason for the failure. In the absence of >> extensions, I suspect that implementations like Bruce's are really >> limited by message size and not frame size. >> >> My own implementation support both a max frame size or streaming data >> to the application layer. If it is accumulating frames into a >> message, it also supports a maximum message size. Currently if that >> maximum message size is exceeded it is miss-using the 1004 >> frame-too-large close code to close the connection, because there is >> no other reasonable alternative. >> >> regards >> >> >> On 12 August 2011 02:49, Peter Saint-Andre wrote: >> > This is your Area Director speaking. I would very much like to issue a= n >> > IESG ballot for our base document in the near future. The WG needs to >> > decide this matter in order for us to proceed. See below for details. >> > >> > On 8/11/11 7:33 AM, Greg Wilkins wrote: >> >> On 11 August 2011 19:55, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" <= andy@warmcat.com> wrote: >> >>> The guys who like frame mtu plan to create implementations which bre= ak >> if >> >>> you send them legal frames bigger than some size they liked when the= y >> wrote >> >>> the code. So they will create an implementation which cannot cope wi= th >> frames above a certain size. >> >> >> >> Can you please try to be a little less insulting and dismissive of th= e >> >> views of others that you don't agree with. Your representation of th= e >> >> motivations of "the guys" advocated a declaration of max frame limit >> >> are incorrect. >> >> >> >> You appear to be arguing against the existence of frame size limits, >> >> when what is being proposed is simply the declaration a limit IF it >> >> exists, which it may do for a number of reasons (including but not >> >> limited to simple implementations) and that is allowed to exist by th= e >> >> existence of the frame-too-large close status. >> >> >> >> I would understand your position better if you were advocating the >> >> removal of frame-too-large error, but you've also acknowledged that >> >> there are reasons to limit frame size, but that it should be >> >> extensions that do it. However I find it a confused situation to >> >> advocate that multiple extensions will be required to implement frame >> >> size limitation mechanisms that will ultimately be policed by a >> >> frame-too-large error mechanism in the base protocol - which does not >> >> know what the frame limit is. >> > >> > Apparently there is a disconnect in the specification: as currently >> > written, an implementation can reject a frame because it is too big >> > (error code 1004), but it can't signal its maximum frame size. >> > >> > Therefore, as your Area Director, I am requesting a consensus call on >> > the following alternative. >> > >> > 1. Remove error code 1004 "Frame Too Large". >> > >> > or >> > >> > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal >> > its maximum frame size, and specify that an implementation SHOULD NOT >> > send frames larger than the maximum frame size signalled by its peer. >> > >> > Please reply to this consensus call by the close of business next >> > Wednesday, August 17, 2011. When you reply, please indicate your >> > preference ("1" or "2") and provide a brief reason, if appropriate. >> > >> > Thank you. >> > >> > Peter >> > >> > -- >> > Peter Saint-Andre >> > https://stpeter.im/ >> > >> > >> > >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >> > > --000e0cd56adae2591404aa433567 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable er, message-*too-large.
-=3DR

On Thu,= Aug 11, 2011 at 4:32 PM, Roberto Peon <fenix@google.com> wrote:
+1 message to large
-=3DR


On Thu, Aug 11, 2011 at 4:20 PM, Greg Wilkins <greg= w@intalio.com> wrote:
As it stands, my preference is for #2, as I believe that resource
limited implementations like what Bruce Atherton have described are
valid and they need a defined error code to indicate the reason of the
close.

However, if we added a message-too-large error, then I would support
option #1 (removal of frame-too-large).

The significant difference between frame-too-large and
message-too-large is that ws implementations can do something about
the frame too large error, which essentially represents a miss
negotiation of protocol configuration. =C2=A0 The message-too-large error is fatal as far as the protocol is concerned, as there is nothing an
implementation can do to reduce the size of the application messages,
other than report the reason for the failure. =C2=A0 In the absence of
extensions, I suspect that implementations like Bruce's are really
limited by message size and not frame size.

My own implementation support both a max frame size or streaming data
to the application layer. =C2=A0 If it is accumulating frames into a
message, it also supports a maximum message size. =C2=A0Currently if that maximum message size is exceeded it is miss-using the 1004
frame-too-large close code to close the connection, because there is
no other reasonable alternative.

regards


On 12 August 2011 02:49, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> This is your Area Director speaking. I would very much like to issue a= n
> IESG ballot for our base document in the near future. The WG needs to<= br> > decide this matter in order for us to proceed. See below for details.<= br> >
> On 8/11/11 7:33 AM, Greg Wilkins wrote:
>> On 11 August 2011 19:55, "Andy Green (=E6=9E=97=E5=AE=89=E5= =BB=B8)" <and= y@warmcat.com> wrote:
>>> The guys who like frame mtu plan to create implementations whi= ch break if
>>> you send them legal frames bigger than some size they liked wh= en they wrote
>>> the code. So they will create an implementation which cannot c= ope with frames above a certain size.
>>
>> Can you please try to be a little less insulting and dismissive of= the
>> views of others that you don't agree with. =C2=A0Your represen= tation of the
>> motivations of "the guys" advocated a declaration of max= frame limit
>> are incorrect.
>>
>> You appear to be arguing against the existence of frame size limit= s,
>> when what is being proposed is simply the declaration a limit IF i= t
>> exists, which it may do for a number of reasons (including but not=
>> limited to simple implementations) and that is allowed to exist by= the
>> existence of the frame-too-large close status.
>>
>> I would understand your position better if you were advocating the=
>> removal of frame-too-large error, but you've also acknowledged= that
>> there are reasons to limit frame size, but that it should be
>> extensions that do it. =C2=A0 =C2=A0 However I find it a confused = situation to
>> advocate that multiple extensions will be required to implement fr= ame
>> size limitation mechanisms that will ultimately be policed by a >> frame-too-large error mechanism in the base protocol - which does = not
>> know what the frame limit is.
>
> Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size.
>
> Therefore, as your Area Director, I am requesting a consensus call on<= br> > the following alternative.
>
> 1. Remove error code 1004 "Frame Too Large".
>
> or
>
> 2. Retain error code 1004, add an OPTIONAL way for an entity to signal=
> its maximum frame size, and specify that an implementation SHOULD NOT<= br> > send frames larger than the maximum frame size signalled by its peer.<= br> >
> Please reply to this consensus call by the close of business next
> Wednesday, August 17, 2011. When you reply, please indicate your
> preference ("1" or "2") and provide a brief reason= , if appropriate.
>
> Thank you.
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/<= /a>
>
>
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi


--000e0cd56adae2591404aa433567-- From howard.wang@huawei.com Thu Aug 11 18:33: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 5B59821F8A56 for ; Thu, 11 Aug 2011 18:33:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0p8uaBQ8-gL for ; Thu, 11 Aug 2011 18:33:00 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 99D1F21F8A4D for ; Thu, 11 Aug 2011 18:33:00 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS001Y4KBWM8@szxga03-in.huawei.com> for hybi@ietf.org; Fri, 12 Aug 2011 09:33:32 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LPS004RTKBU2U@szxga03-in.huawei.com> for hybi@ietf.org; Fri, 12 Aug 2011 09:33:32 +0800 (CST) Received: from 172.24.2.119 (EHLO szxeml202-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ADC83851; Fri, 12 Aug 2011 09:33:30 +0800 (CST) Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 12 Aug 2011 09:33:18 +0800 Received: from SZXEML509-MBS.china.huawei.com ([169.254.2.156]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Fri, 12 Aug 2011 09:33:26 +0800 Date: Fri, 12 Aug 2011 01:33:24 +0000 From: "Howard Wang(Hao)" In-reply-to: <4E440808.5030907@stpeter.im> X-Originating-IP: [10.70.109.128] To: Peter Saint-Andre , Greg Wilkins Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: zh-CN Content-transfer-encoding: 7BIT Accept-Language: zh-CN, en-US Thread-topic: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) Thread-index: AQHMWEafu/QRAUWrcUqNC5a+z/higZUYbcog X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Cc: "hybi@ietf.org" Subject: [hybi] =?utf-8?b?562U5aSNOiAgQ09OU0VOU1VTIENBTEwgKHdhczpSZTogIFdl?= =?utf-8?q?bSocket_Frame_Size_and_latency=29?= X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 01:33:01 -0000 Option 2 Though prefer to include more robust optional approaches to acquire the reason for failure. Therefore, as your Area Director, I am requesting a consensus call on the following alternative. 1. Remove error code 1004 "Frame Too Large". or 2. Retain error code 1004, add an OPTIONAL way for an entity to signal its maximum frame size, and specify that an implementation SHOULD NOT send frames larger than the maximum frame size signalled by its peer. Please reply to this consensus call by the close of business next Wednesday, August 17, 2011. When you reply, please indicate your preference ("1" or "2") and provide a brief reason, if appropriate. Thank you. Peter -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From bruce@callenish.com Thu Aug 11 19:39:27 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 4B21C21F856A for ; Thu, 11 Aug 2011 19:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBzVhm-I8dRS for ; Thu, 11 Aug 2011 19:39:26 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id AECD821F8569 for ; Thu, 11 Aug 2011 19:39:26 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrhfA-0005cp-Pf; Thu, 11 Aug 2011 19:39:56 -0700 Message-ID: <4E44927E.4080807@callenish.com> Date: Thu, 11 Aug 2011 19:39:58 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; 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] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 02:39:27 -0000 On 11/08/2011 4:20 PM, Greg Wilkins wrote: > The significant difference between frame-too-large and > message-too-large is that ws implementations can do something about > the frame too large error, which essentially represents a miss > negotiation of protocol configuration. The message-too-large error > is fatal as far as the protocol is concerned, as there is nothing an > implementation can do to reduce the size of the application messages, > other than report the reason for the failure. In the absence of > extensions, I suspect that implementations like Bruce's are really > limited by message size and not frame size. Not for me, although I can imagine it might be for others. If a message exceeds the maximum size for a particular subprotocol on the sending side it is never sent to the Websockets layer. If it is too large on the receiving side then the application sends a "Message too large" message and all further frames for that message are discarded. I'd be willing to bet that "Message too large" is less of an issue than you think for other implementations, too. Messages are often not all the same size. The applications that will be using my implementation have 80% of messages less than 4K, and 95% are less than 8K. If it were called for I could have the odd outlier message in the multimegabyte range and it wouldn't significantly impact the total memory needed for messages. But make the buffers for frames all multiple megabytes and there are serious scaling issues. So "Message too large" is probably far less of a concern than "Frame too large" in many implementations like mine that buffer frames. As Bob said message size and frame size are orthogonal. Even though 64K is my maximum message size, I do not want to have to create a buffer that size for every incoming frame, it would be terrible for both scaling and latency reasons. That is one of my concerns if max-frame-size does not make it into the spec. I may have to increase my buffer size far beyond what is sensible to the requirements just to deal with implementations that insist on sending every message in its own individual frame, or that happen to choose a size bigger than the one chosen as optimal for my situation. If a major browser chose to allow frame sizes of 64K and I couldn't send a max-frame-size, I'd be forced to adopt the complexity of streaming from connection to message. > My own implementation support both a max frame size or streaming data > to the application layer. If it is accumulating frames into a > message, it also supports a maximum message size. Currently if that > maximum message size is exceeded it is miss-using the 1004 > frame-too-large close code to close the connection, because there is > no other reasonable alternative. > There is no reasonable alternative at the Websockets layer, and I understand why you would want a "message too large" close status. If you can handle it at the application layer instead, though, it is better. If the application wants to close the connection it can and if it wants to say why it is closing the connection it can send a message before it closes it. Or it can arrange for the message to be resent in a smaller form if it has a mechanism for doing so. Or it can ignore dropped messages if that is appropriate. Only the application knows for sure. But I get that for many implementations, maximum message size is a little leaky into the Websockets layer and having the ability to signal it at that layer could be desirable. Please don't drop maximum frame size to get it, though. They serve different needs. From gregw@intalio.com Thu Aug 11 20:43: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 4AE9621F8514 for ; Thu, 11 Aug 2011 20:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yroo4lUo+bwW for ; Thu, 11 Aug 2011 20:43:48 -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 587F521F850B for ; Thu, 11 Aug 2011 20:43:48 -0700 (PDT) Received: by vxi29 with SMTP id 29so2653703vxi.31 for ; Thu, 11 Aug 2011 20:44:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.236 with SMTP id o12mr331011vdg.497.1313120615460; Thu, 11 Aug 2011 20:43:35 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Thu, 11 Aug 2011 20:43:35 -0700 (PDT) In-Reply-To: <4E44927E.4080807@callenish.com> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44927E.4080807@callenish.com> Date: Fri, 12 Aug 2011 13:43:35 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 03:43:49 -0000 Bruce, I agree that frame sizes and message sizes are different things. The reason my implementation has a message size limit is that applications have the option of letting the implementation aggregate byte data arriving into a text message, thus forcing the implementation to buffer the entire message before delivery to the application. Thus I have a max message size (expressed in characters) to be set to control that buffering. If the message is too large, then I cannot defer to the application to send a message-too-large error, because the application never sees the inbound message. I thus am currently sending a 1004 frame-too-large. It would be good to have a proper error code for that - although I guess I could add the option to simply discard the message with a local warning. Note that applications are also free to use an alternate API to consume bytes as they arrive, in which case no limit is needed or applied. Separately to message limits, I have the ability to limit frame sizes to the buffer sizes or let the parser create fake fragments for large frames that are streamed to the aggregation layer. There is no reason in my current implementation to actually limit the frame size, but the capability is there so that future extensions that may need to process entire frames or that have latency concerns can restrict frame size. If we remove the frame-too-large error code, then I will probably remove the option to limit frame sizes to a single buffer and the extensions will have to fend for themselves. So reading about your example, you appear to have the ability to receive large messages in small buffers. You appear to be saying that you want the frame size restriction so that you can keep the small buffers. But I'm not understanding why you need entire frames to fit within those small buffers? Unless you are running extensions that need to process entire frames, you should be able to process large frames in small buffers (in my case if I receive a frame larger than my buffer, I pass it to the frame aggregation/handling layer as a fake smaller frame and when the remaining data is received in the same buffer it is passed on as a fake continuation frame). Can you explain a bit more why you want to process the entire frame at once? cheers On 12 August 2011 12:39, Bruce Atherton wrote: > On 11/08/2011 4:20 PM, Greg Wilkins wrote: >> >> The significant difference between frame-too-large and >> message-too-large is that ws implementations can do something about >> the frame too large error, which essentially represents a miss >> negotiation of protocol configuration. =A0 The message-too-large error >> is fatal as far as the protocol is concerned, as there is nothing an >> implementation can do to reduce the size of the application messages, >> other than report the reason for the failure. =A0 In the absence of >> extensions, I suspect that implementations like Bruce's are really >> limited by message size and not frame size. > > Not for me, although I can imagine it might be for others. If a message > exceeds the maximum size for a particular subprotocol on the sending side= it > is never sent to the Websockets layer. If it is too large on the receivin= g > side then the application sends a "Message too large" message and all > further frames for that message are discarded. > > I'd be willing to bet that "Message too large" is less of an issue than y= ou > think for other implementations, too. Messages are often not all the same > size. The applications that will be using my implementation have 80% of > messages less than 4K, and 95% are less than 8K. If it were called for I > could have the odd outlier message in the multimegabyte range and it > wouldn't significantly impact the total memory needed for messages. But m= ake > the buffers for frames all multiple megabytes and there are serious scali= ng > issues. So "Message too large" is probably far less of a concern than "Fr= ame > too large" in many implementations like mine that buffer frames. > > As Bob said message size and frame size are orthogonal. Even though 64K i= s > my maximum message size, I do not want to have to create a buffer that si= ze > for every incoming frame, it would be terrible for both scaling and laten= cy > reasons. That is one of my concerns if max-frame-size does not make it in= to > the spec. I may have to increase my buffer size far beyond what is sensib= le > to the requirements just to deal with implementations that insist on send= ing > every message in its own individual frame, or that happen to choose a siz= e > bigger than the one chosen as optimal for my situation. If a major browse= r > chose to allow frame sizes of 64K and I couldn't send a max-frame-size, I= 'd > be forced to adopt the complexity of streaming from connection to message= . > >> My own implementation support both a max frame size or streaming data >> to the application layer. =A0 If it is accumulating frames into a >> message, it also supports a maximum message size. =A0Currently if that >> maximum message size is exceeded it is miss-using the 1004 >> frame-too-large close code to close the connection, because there is >> no other reasonable alternative. >> > > There is no reasonable alternative at the Websockets layer, and I underst= and > why you would want a "message too large" close status. If you can handle = it > at the application layer instead, though, it is better. If the applicatio= n > wants to close the connection it can and if it wants to say why it is > closing the connection it can send a message before it closes it. Or it c= an > arrange for the message to be resent in a smaller form if it has a mechan= ism > for doing so. Or it can ignore dropped messages if that is appropriate. O= nly > the application knows for sure. > > But I get that for many implementations, maximum message size is a little > leaky into the Websockets layer and having the ability to signal it at th= at > layer could be desirable. Please don't drop maximum frame size to get it, > though. They serve different needs. > > From tobias.oberstein@tavendo.de Thu Aug 11 22:47: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 5CC8D21F85B9 for ; Thu, 11 Aug 2011 22:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9duvEN7ACZJ for ; Thu, 11 Aug 2011 22:47:18 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 40AFE21F8586 for ; Thu, 11 Aug 2011 22:47:13 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Thu, 11 Aug 2011 22:47:37 -0700 From: Tobias Oberstein To: Bruce Atherton , Greg Wilkins Date: Thu, 11 Aug 2011 22:47:36 -0700 Thread-Topic: [hybi] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) Thread-Index: AcxYmSi5tjHhx3vER5CO/KZ0zOcyqgAGi28/ Message-ID: In-Reply-To: <4E44927E.4080807@callenish.com> Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 05:47:19 -0000 > chosen as optimal for my situation. If a major browser chose to allow > frame sizes of 64K and I couldn't send a max-frame-size, Both Firefox and Chrome currently send a message - independent of size - always _unfragmented_ (that is fragment size =3D message size) I have tested this with messages up to 8MB. Both will receive a 8MB message arbitrarily fragmented (tested with frame sizes from 64 bytes - 8MB) > I'd be forced > to adopt the complexity of streaming from connection to message. There is no complexity in doing streaming. On the contrary: it is easy, good design, and you can layer buffering to any amount/unit on top. Note that you can't layer streaming a implementation which insists on buffering. In any case: having a specific implementation choice be the reason to decide about protocol questions appears weird. From andy@warmcat.com Thu Aug 11 22:57: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 5D5BD21F8568 for ; Thu, 11 Aug 2011 22:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.284 X-Spam-Level: X-Spam-Status: No, score=-2.284 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2UcKSW27BPuW for ; Thu, 11 Aug 2011 22:57:57 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id C976221F84E0 for ; Thu, 11 Aug 2011 22:57:56 -0700 (PDT) Message-ID: <4E44C106.7020505@warmcat.com> Date: Fri, 12 Aug 2011 06:58:30 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 05:57:57 -0000 On 08/12/2011 12:20 AM, Somebody in the thread at some point said: > As it stands, my preference is for #2, as I believe that resource > limited implementations like what Bruce Atherton have described are > valid and they need a defined error code to indicate the reason of the > close. The choice in the consensus call is a false dichotomy... in fact we can keep the error code and not implement the rest of the crap in #2 into the spec if we like, they're not mutually exclusive. This is the "dark art of argumentation" I referred to. Peter, did you come up with that either-or yourself? I wrote libwebsockets targeting weak ARM9 platforms and it was developed both on a PC and a couple of ARMv5-based devices, so I have some experience from the angle of embedded websockets implementation. In fact a websocket peer experiences a websocket frame as a part of, a singular, or a series of TCP/IP packets. The only other footprint of a frame per se is the state of how much is left to come and where it fits inside the message. So, other than what an implementation must be able to do with the message payload, frame processing footprint does not extend beyond max packet size and a few bytes of state. Because frames can legally be a factor of 2^16 and more beyond the resources of any credible peer for the next 10 years, it's a red herring to talk about "resource limited implementatons" and "frames". If you take the wrong approach to processing frames, ALL peers are "resource limited implementations" in the face of 2^63 frames. -Andy From gregw@intalio.com Fri Aug 12 00:44: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 D82F121F8559 for ; Fri, 12 Aug 2011 00:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.765 X-Spam-Level: X-Spam-Status: No, score=-2.765 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnuugWRM1Eug for ; Fri, 12 Aug 2011 00:44:30 -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 49A4E21F8531 for ; Fri, 12 Aug 2011 00:44:29 -0700 (PDT) Received: by vxi29 with SMTP id 29so2769414vxi.31 for ; Fri, 12 Aug 2011 00:43:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr526896vdb.95.1313135026319; Fri, 12 Aug 2011 00:43:46 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Fri, 12 Aug 2011 00:43:46 -0700 (PDT) In-Reply-To: <4E44C106.7020505@warmcat.com> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> Date: Fri, 12 Aug 2011 17:43:46 +1000 Message-ID: From: Greg Wilkins To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 07:44:31 -0000 On 12 August 2011 15:58, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" wrote: > The choice in the consensus call is a false dichotomy... in fact we can k= eep > the error code and not implement the rest of the crap in #2 into the spec= if > we like, they're not mutually exclusive. This is the only option that I'm strongly opposed to. It is ridiculous to allow an implementation to say: "The frame you sent is too large, but I'm not going to tell you what size I will accept". If we are to allow a limit, then we have to provide a way to communicate what that limit is. This can be static via a handshake header or dynamic via some control messages, but it can't be telepathic! From simonp@opera.com Fri Aug 12 01:30: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 A9B0321F86EE for ; Fri, 12 Aug 2011 01:30:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wNzjJW29YWI for ; Fri, 12 Aug 2011 01:30:48 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id BCE0221F86B3 for ; Fri, 12 Aug 2011 01:30:47 -0700 (PDT) Received: from simon-pieterss-macbook.local (c-3f9fe355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.159.63]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7C8TBQE004009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Aug 2011 08:29:12 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Greg Wilkins" , "Peter Saint-Andre" References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Fri, 12 Aug 2011 10:29:40 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: <4E440808.5030907@stpeter.im> User-Agent: Opera Mail/11.50 (MacIntel) Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 08:30:48 -0000 On Thu, 11 Aug 2011 18:49:12 +0200, Peter Saint-Andre wrote: > This is your Area Director speaking. I would very much like to issue an > IESG ballot for our base document in the near future. The WG needs to > decide this matter in order for us to proceed. See below for details. > > On 8/11/11 7:33 AM, Greg Wilkins wrote: >> On 11 August 2011 19:55, "Andy Green (林安廸)" wrote: >>> The guys who like frame mtu plan to create implementations which break >>> if >>> you send them legal frames bigger than some size they liked when they >>> wrote >>> the code. So they will create an implementation which cannot cope with >>> frames above a certain size. >> >> Can you please try to be a little less insulting and dismissive of the >> views of others that you don't agree with. Your representation of the >> motivations of "the guys" advocated a declaration of max frame limit >> are incorrect. >> >> You appear to be arguing against the existence of frame size limits, >> when what is being proposed is simply the declaration a limit IF it >> exists, which it may do for a number of reasons (including but not >> limited to simple implementations) and that is allowed to exist by the >> existence of the frame-too-large close status. >> >> I would understand your position better if you were advocating the >> removal of frame-too-large error, but you've also acknowledged that >> there are reasons to limit frame size, but that it should be >> extensions that do it. However I find it a confused situation to >> advocate that multiple extensions will be required to implement frame >> size limitation mechanisms that will ultimately be policed by a >> frame-too-large error mechanism in the base protocol - which does not >> know what the frame limit is. > > Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size. > > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. > > Please reply to this consensus call by the close of business next > Wednesday, August 17, 2011. When you reply, please indicate your > preference ("1" or "2") and provide a brief reason, if appropriate. I prefer 1. I think 2 is unnecessary complexity. The more overall complexity the protocol has, the less likely it is that it will be implemented interoperably. -- Simon Pieters Opera Software From andy@warmcat.com Fri Aug 12 02:01: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 B091921F85AE for ; Fri, 12 Aug 2011 02:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.286 X-Spam-Level: X-Spam-Status: No, score=-2.286 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsnNuFzzRMRr for ; Fri, 12 Aug 2011 02:01:15 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id E703321F85A1 for ; Fri, 12 Aug 2011 02:01:14 -0700 (PDT) Message-ID: <4E44EBE5.4030000@warmcat.com> Date: Fri, 12 Aug 2011 10:01:25 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:01:15 -0000 On 08/12/2011 08:43 AM, Somebody in the thread at some point said: > On 12 August 2011 15:58, "Andy Green (林安廸)" wrote: >> The choice in the consensus call is a false dichotomy... in fact we can keep >> the error code and not implement the rest of the crap in #2 into the spec if >> we like, they're not mutually exclusive. > > > This is the only option that I'm strongly opposed to. > > It is ridiculous to allow an implementation to say: "The frame you > sent is too large, but I'm not going to tell you what size I will > accept". > > If we are to allow a limit, then we have to provide a way to > communicate what that limit is. This can be static via a handshake > header or dynamic via some control messages, but it can't be > telepathic! The aggregate message can be "too large", but not a frame unless your frame parser is broken (or your signing extension peer ignored the frame size limit agreed / implied). You may say, well, let's say he sends me a message that's too big in one frame, what about then? We could tell him, right? Yeah you could tell him your message limit but he can't react at the frame level, and you're telling him about your message capability not frame. If he sends you the message in multiple smaller frames the message is still too big, if he cuts it into multiple messages it's not one message any more. So frame mtu isn't doing anything useful. -Andy From w@1wt.eu Fri Aug 12 02:09:11 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 957C621F86AF for ; Fri, 12 Aug 2011 02:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.081 X-Spam-Level: X-Spam-Status: No, score=-4.081 tagged_above=-999 required=5 tests=[AWL=-2.038, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zZ2moYwX5ki for ; Fri, 12 Aug 2011 02:09:10 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id E8CE121F86AE for ; Fri, 12 Aug 2011 02:09:08 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p7C99gvJ012505; Fri, 12 Aug 2011 11:09:42 +0200 Date: Fri, 12 Aug 2011 11:09:42 +0200 From: Willy Tarreau To: Peter Saint-Andre Message-ID: <20110812090942.GB12235@1wt.eu> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E440808.5030907@stpeter.im> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:09:11 -0000 On Thu, Aug 11, 2011 at 10:49:12AM -0600, Peter Saint-Andre wrote: > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. > > Please reply to this consensus call by the close of business next > Wednesday, August 17, 2011. When you reply, please indicate your > preference ("1" or "2") and provide a brief reason, if appropriate. I prefer #2, because given all the reluctance that was exposed in this thread, I'm fairly sure than when we later *need* to implement frame size limitation for whatever extension that needs it (eg: compression or digital signature), it will not be possible at all because some lazy implementations will have major design limitations that will make them incompatible with shorter frames. I personally do not see what becomes complex or difficult in deciding that a message that is larger than a *known* frame size limit should be emitted in multiple frames. It's just a matter of repeating a frame header from time to time. I would also add that framing has been there for a very long time now, and I suspect that a number of implementations have silently decided that they did not need it, which would explain why suddenly forcing them to emit frames is annoying. If we're at a point where framing is supposed not to be supported at all by some implementations, we probably have more serious issues to solve than to decide whether or not we should announce a frame size. Regards, Willy From andy@warmcat.com Fri Aug 12 02:32: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 1A76321F855B for ; Fri, 12 Aug 2011 02:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rGwudDWNfHA for ; Fri, 12 Aug 2011 02:32:24 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 64ABA21F8520 for ; Fri, 12 Aug 2011 02:32:24 -0700 (PDT) Message-ID: <4E44F348.80305@warmcat.com> Date: Fri, 12 Aug 2011 10:32:56 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Willy Tarreau References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <20110812090942.GB12235@1wt.eu> In-Reply-To: <20110812090942.GB12235@1wt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Frame signing insecure X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 09:32:25 -0000 On 08/12/2011 10:09 AM, Somebody in the thread at some point said: > I prefer #2, because given all the reluctance that was exposed in this > thread, I'm fairly sure than when we later *need* to implement frame > size limitation for whatever extension that needs it (eg: compression > or digital signature), it will not be possible at all because some Compression won't care, it can pull in or spill a subblock at a time unrelated to actual frame size or like zlib work at bit level. Atomic frame signing is a special hypothetical case but even that's not useful compared to message signing, since it can be attacked by, eg, MITM setting FIN on a signed packet that was not actually the last one, frame header not being signed payload and subject to meddling. > lazy implementations will have major design limitations that will make > them incompatible with shorter frames. > > I personally do not see what becomes complex or difficult in deciding > that a message that is larger than a *known* frame size limit should > be emitted in multiple frames. It's just a matter of repeating a frame > header from time to time. Since only non-base extensions care, let the extension peers be responsible for the chopping-up according to that particular extension's limitations. Bear in mind extension implementations are intimately specific to the framework they're using. If the guy writing the signed frame extension for websocket framework X finds frame handling is broken, he will get it fixed in websocket framework X so his extension can work. > I would also add that framing has been there for a very long time now, > and I suspect that a number of implementations have silently decided > that they did not need it, which would explain why suddenly forcing > them to emit frames is annoying. If we're at a point where framing is Interoperability tests which Greg and I have written (eg, fraggle test in libwebsocket) are the answer to keeping implementations honest or shown to be broken. Adding in bloat to the spec that doesn't actually do anything useful won't do what you're hoping here. -Andy From w@1wt.eu Fri Aug 12 03:15: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 9977C21F8757 for ; Fri, 12 Aug 2011 03:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.061 X-Spam-Level: X-Spam-Status: No, score=-4.061 tagged_above=-999 required=5 tests=[AWL=-2.018, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+vXhp1K529z for ; Fri, 12 Aug 2011 03:15:35 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id A1D9821F871C for ; Fri, 12 Aug 2011 03:15:34 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p7CAG8Ax012664; Fri, 12 Aug 2011 12:16:08 +0200 Date: Fri, 12 Aug 2011 12:16:08 +0200 From: Willy Tarreau To: "Andy Green (?????????)" Message-ID: <20110812101608.GF12235@1wt.eu> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <20110812090942.GB12235@1wt.eu> <4E44F348.80305@warmcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E44F348.80305@warmcat.com> User-Agent: Mutt/1.4.2.3i Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Frame signing insecure X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 10:15:35 -0000 On Fri, Aug 12, 2011 at 10:32:56AM +0100, "Andy Green (?????????)" wrote: > On 08/12/2011 10:09 AM, Somebody in the thread at some point said: > > >I prefer #2, because given all the reluctance that was exposed in this > >thread, I'm fairly sure than when we later *need* to implement frame > >size limitation for whatever extension that needs it (eg: compression > >or digital signature), it will not be possible at all because some > > Compression won't care, it can pull in or spill a subblock at a time > unrelated to actual frame size or like zlib work at bit level. if it's frame-based compression, then yes it will matter. > Atomic frame signing is a special hypothetical case but even that's not > useful compared to message signing, since it can be attacked by, eg, > MITM setting FIN on a signed packet that was not actually the last one, > frame header not being signed payload and subject to meddling. I don't agree. Signing of frames is very useful because it saves intermediaries from buffering the whole *message*. Instead, they can check each frame's signature and forward them as they're checked. It then makes a lot more sense to validate a few kB at a time and let them pass than to store a large block to disk, validate its signature then let it go. Imagine someone who would make use of WS for telephony. It would be a well-suited use of digital signatures and you'd want the frames to be signed, not the message (which is the whole conversation). > >lazy implementations will have major design limitations that will make > >them incompatible with shorter frames. > > > >I personally do not see what becomes complex or difficult in deciding > >that a message that is larger than a *known* frame size limit should > >be emitted in multiple frames. It's just a matter of repeating a frame > >header from time to time. > > Since only non-base extensions care, let the extension peers be > responsible for the chopping-up according to that particular extension's > limitations. I have no issue with that. My concern is that if there is so much reluctance in adopting something as trivial as setting a limit on emitted frames size, surely there is an underlying reason which will surface again when we'll want to design those extensions. My fears now are that 1 frame == 1 message for many years to come and that MUX and other possibly useful extensions will not be possible just because of a few broken implementations which will heavily rely on the assumption above. > Bear in mind extension implementations are intimately specific to the > framework they're using. If the guy writing the signed frame extension > for websocket framework X finds frame handling is broken, he will get it > fixed in websocket framework X so his extension can work. Except that application live for many years and are not changed every few months. > >I would also add that framing has been there for a very long time now, > >and I suspect that a number of implementations have silently decided > >that they did not need it, which would explain why suddenly forcing > >them to emit frames is annoying. If we're at a point where framing is > > Interoperability tests which Greg and I have written (eg, fraggle test > in libwebsocket) are the answer to keeping implementations honest or > shown to be broken. Adding in bloat to the spec that doesn't actually > do anything useful won't do what you're hoping here. But why are you constantly saying that setting a limit is "bloat" Andy ? It's just a matter of storing a value and use it as a check when messages are to be framed. We're not speaking about *forcing* every agent to send that large frames, but the opposite, ask that nobody along the path sends frames larger than what the whole path reliably supports without efforts. The bloat would come from supporting any frame size because some implementations will have to do ugly things for that. Regards, Willy From salvatore.loreto@ericsson.com Fri Aug 12 03:41: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 BF2D321F84CB for ; Fri, 12 Aug 2011 03:41:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.577 X-Spam-Level: X-Spam-Status: No, score=-106.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdZmlryMCBAS for ; Fri, 12 Aug 2011 03:41:57 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 027F921F86FF for ; Fri, 12 Aug 2011 03:41:44 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-b0-4e45038c2e42 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F8.A8.20773.C83054E4; Fri, 12 Aug 2011 12:42:20 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Fri, 12 Aug 2011 12:42:20 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 26C742461 for ; Fri, 12 Aug 2011 13:42:20 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id E1B435127E for ; Fri, 12 Aug 2011 13:42:19 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 3A22D5115B for ; Fri, 12 Aug 2011 13:42:19 +0300 (EEST) Message-ID: <4E450386.6020602@ericsson.com> Date: Fri, 12 Aug 2011 13:42:14 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: hybi@ietf.org References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> In-Reply-To: <4E44C106.7020505@warmcat.com> Content-Type: text/plain; charset="ISO-2022-JP" Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 10:41:57 -0000 On 8/12/11 8:58 AM, "Andy Green ($BNS0BW/(B)" wrote: > On 08/12/2011 12:20 AM, Somebody in the thread at some point said: > >> As it stands, my preference is for #2, as I believe that resource >> limited implementations like what Bruce Atherton have described are >> valid and they need a defined error code to indicate the reason of the >> close. > The choice in the consensus call is a false dichotomy... in fact we can > keep the error code and not implement the rest of the crap in #2 into > the spec if we like, they're not mutually exclusive. This is the "dark > art of argumentation" I referred to. Peter, did you come up with that > either-or yourself? (as individual) if I understood you correctly you state that an implementation should be ready to receive buffer of any size (till 2^63) so I don't see in this case the rational to keep the error code 1004 "Frame too large" in your implementation in which case/scenario do you send this error code, if you do. cheers /Sal -- Salvatore Loreto www.sloreto.com From ibc@aliax.net Fri Aug 12 03:58: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 9869621F8754 for ; Fri, 12 Aug 2011 03:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izgHFV1F5Mj5 for ; Fri, 12 Aug 2011 03:58:10 -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 0F67221F86C0 for ; Fri, 12 Aug 2011 03:58:09 -0700 (PDT) Received: by qyk35 with SMTP id 35so1700623qyk.10 for ; Fri, 12 Aug 2011 03:58:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr479736qcj.216.1313146718036; Fri, 12 Aug 2011 03:58:38 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Fri, 12 Aug 2011 03:58:37 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> Date: Fri, 12 Aug 2011 12:58:37 +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] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 10:58:10 -0000 2011/8/12 Greg Wilkins : > If we are to allow a limit, then we have to provide a way to > communicate what that limit is. =C2=A0 This can be static via a handshake > header or dynamic via some control messages, but it can't be > telepathic! Of course. Which is the problem in indicating maximun frame size during the handshake negotiation?? that's in fact a *negotiation* process! The HTTP request could have a X-WebSocket-Frame-Limit header indicating the maximum frame size the client can receive, and the 101 response could contain same header indicating maximun frame size the server accepts. This is the way rather than ugly reactions after the limit has been reached. --=20 I=C3=B1aki Baz Castillo From len.holgate@gmail.com Fri Aug 12 04:45:11 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 30ACB21F86D0 for ; Fri, 12 Aug 2011 04:45:11 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V03lb8jI7Sa9 for ; Fri, 12 Aug 2011 04:45:10 -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 2EA0821F86C0 for ; Fri, 12 Aug 2011 04:45:10 -0700 (PDT) Received: by wwf5 with SMTP id 5so2083456wwf.13 for ; Fri, 12 Aug 2011 04:45:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=q0nfgzlcvPezUAjmwqE6nTDz+qAg7NwZQRTsUWYVJi0=; b=kSGfFMR5tOGdruZPBKzA1MG30KV4U6pnQDNQhEL83+cF/rGsRyZGsq89sIQQl8TALt SZEugyyXIGsTS/gWb1zPm5YFRlR8EYbCX0XkKoRrIFX7I6q/KUIB836Z1zmUSplbkNfq fs0G3PFrGdvcW2wYHmL+c5NggnNR0I8yBTP6Y= Received: by 10.216.175.4 with SMTP id y4mr2781777wel.91.1313149545633; Fri, 12 Aug 2011 04:45:45 -0700 (PDT) Received: from Venus ([212.39.10.148]) by mx.google.com with ESMTPS id et16sm2269787wbb.36.2011.08.12.04.45.43 (version=SSLv3 cipher=OTHER); Fri, 12 Aug 2011 04:45:44 -0700 (PDT) From: "Len Holgate" To: "'Peter Saint-Andre'" References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Fri, 12 Aug 2011 12:45:29 +0100 Message-ID: <024201cc58e5$574ad9a0$c90aa8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcxYRqGoIFg7J8DHQqehqCjonQao8QAnLoVw In-Reply-To: <4E440808.5030907@stpeter.im> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 11:45:11 -0000 > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. Well, I for one have found the discussion useful and have changed my mind somewhat since the start... My preference is 1. Frame size should not be an issue except for extensions which require complete frames before they can be validated or manipulated; so any frame limit should be part of the extension's specification - though this may result in multiple ways to specify frame limits in different extensions. Message size is more of an issue, but only for APIs that provide a message based interface which can only present complete messages to the user of the API; if such an API allowed the application layer to supply the message buffers then the issue is passed on to the application level code. Furthermore, message size limits are of no interest to APIs that provide a stream based interface. As such, message size limits are an application level concept and should not appear in this protocol spec. Possibly reworking section 1.2 (especially) "A message is a complete unit of data at an application level, with the expectation that many or most applications implementing this protocol (such as web user agents) provide APIs in terms of sending and receiving messages. The WebSocket message does not necessarily correspond to a particular network layer framing, as a fragmented message may be coalesced, or vice versa, e.g. by an intermediary." And "The WebSocket protocol uses this framing so that specifications that use the WebSocket protocol can expose such connections using an event-based mechanism instead of requiring users of those specifications to implement buffering and piecing together of messages manually." To acknowledge that handling of large messages is most likely best done with a streaming interface rather than a message based interface (or removing the suggestion that the websocket protocol handler will provide complete messages) may mean that people wont forever be misunderstanding the design intentions and suggesting message and/or frame limits or implementing the protocol in such a way that they have inherent hidden limits. Len Holgate http://www.lenholgate.com http://www.serverframework.com From andy@warmcat.com Fri Aug 12 04:52: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 02F0621F84DB for ; Fri, 12 Aug 2011 04:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[AWL=-1.438, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HUETgwmdEoHS for ; Fri, 12 Aug 2011 04:52:06 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id E1BEE21F84D4 for ; Fri, 12 Aug 2011 04:52:05 -0700 (PDT) Message-ID: <4E451409.2090901@warmcat.com> Date: Fri, 12 Aug 2011 12:52:41 +0100 From: =?ISO-2022-JP?B?IkFuZHkgR3JlZW4gKBskQk5TMEJXLxsoQiki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Salvatore Loreto References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <4E450386.6020602@ericsson.com> In-Reply-To: <4E450386.6020602@ericsson.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 11:52:07 -0000 On 08/12/2011 11:42 AM, Somebody in the thread at some point said: > On 8/12/11 8:58 AM, "Andy Green ($BNS0BW/(B)" wrote: >> On 08/12/2011 12:20 AM, Somebody in the thread at some point said: >> >>> As it stands, my preference is for #2, as I believe that resource >>> limited implementations like what Bruce Atherton have described are >>> valid and they need a defined error code to indicate the reason of the >>> close. >> The choice in the consensus call is a false dichotomy... in fact we can >> keep the error code and not implement the rest of the crap in #2 into >> the spec if we like, they're not mutually exclusive. This is the "dark >> art of argumentation" I referred to. Peter, did you come up with that >> either-or yourself? > (as individual) > > if I understood you correctly you state that an implementation should be > ready > to receive buffer of any size (till 2^63) so I don't see in this case > the rational to keep the error code 1004 "Frame too large" > > in your implementation in which case/scenario do you send this error code, > if you do. We don't send it. There's no valid use for it IMO. However if the problem is solved just by Greg having it for his extension to use, and without whole frame mtu, an error code reserved for that is so cheap and self-contained, I'm happy to see him have it. The vote though assumes that we have to be against the error code and the frame mtu implementation, or for both; actually I don't care about an error code getting reserved unnecessarily if it makes people happy, and do care about whole frame mtu business being introduced. -Andy From tobias.oberstein@tavendo.de Fri Aug 12 05:12: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 BBEEC21F84EF for ; Fri, 12 Aug 2011 05:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.391 X-Spam-Level: X-Spam-Status: No, score=-2.391 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9RMUt0mG2uIw for ; Fri, 12 Aug 2011 05:12:16 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 3E49521F84EC for ; Fri, 12 Aug 2011 05:12:16 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Fri, 12 Aug 2011 05:12:53 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Greg Wilkins Date: Fri, 12 Aug 2011 05:12:16 -0700 Thread-Topic: [hybi] CONSENSUS CALL / Resource limited implementations Thread-Index: AcxY3tVaAtkIVdnmRP2jxvP9eyYtSwACT2pg Message-ID: <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:12:16 -0000 PiA+IElmIHdlIGFyZSB0byBhbGxvdyBhIGxpbWl0LCB0aGVuIHdlIGhhdmUgdG8gcHJvdmlkZSBh IHdheSB0bw0KPiA+IGNvbW11bmljYXRlIHdoYXQgdGhhdCBsaW1pdCBpcy4gwqAgVGhpcyBjYW4g YmUgc3RhdGljIHZpYSBhIGhhbmRzaGFrZQ0KPiA+IGhlYWRlciBvciBkeW5hbWljIHZpYSBzb21l IGNvbnRyb2wgbWVzc2FnZXMsIGJ1dCBpdCBjYW4ndCBiZQ0KPiA+IHRlbGVwYXRoaWMhDQo+IA0K PiBPZiBjb3Vyc2UuIFdoaWNoIGlzIHRoZSBwcm9ibGVtIGluIGluZGljYXRpbmcgbWF4aW11biBm cmFtZSBzaXplIGR1cmluZyB0aGUNCj4gaGFuZHNoYWtlIG5lZ290aWF0aW9uPz8gdGhhdCdzIGlu IGZhY3QgYSAqbmVnb3RpYXRpb24qIHByb2Nlc3MhDQoNCm9uZSBwcm9ibGVtIGlzOiB2YWx1ZSBp cyBmaXhlZCBmb3IgbGlmZXRpbWUgb2Ygc2Vzc2lvbiAuLiBjYW4ndCBiZSBkeW5hbWljL2FkYXB0 aXZlDQoNCj4gVGhlIEhUVFAgcmVxdWVzdCBjb3VsZCBoYXZlIGEgWC1XZWJTb2NrZXQtRnJhbWUt TGltaXQgaGVhZGVyIGluZGljYXRpbmcNCj4gdGhlIG1heGltdW0gZnJhbWUgc2l6ZSB0aGUgY2xp ZW50IGNhbiByZWNlaXZlLCBhbmQgdGhlIDEwMSByZXNwb25zZSBjb3VsZA0KPiBjb250YWluIHNh bWUgaGVhZGVyIGluZGljYXRpbmcgbWF4aW11biBmcmFtZSBzaXplIHRoZSBzZXJ2ZXIgYWNjZXB0 cy4gVGhpcw0KPiBpcyB0aGUgd2F5IHJhdGhlciB0aGFuIHVnbHkgcmVhY3Rpb25zIGFmdGVyIHRo ZSBsaW1pdCBoYXMgYmVlbiByZWFjaGVkLg0KDQoNCg== From simonp@opera.com Fri Aug 12 05:25: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 3C29421F86BE for ; Fri, 12 Aug 2011 05:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ofWWr72qzD4C for ; Fri, 12 Aug 2011 05:25:38 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 6914E21F85A7 for ; Fri, 12 Aug 2011 05:25:38 -0700 (PDT) Received: from simon-pieterss-macbook.local (c-3f9fe355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.159.63]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7CCQBYg028310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 12 Aug 2011 12:26:12 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Salvatore Loreto" , =?utf-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <4E450386.6020602@ericsson.com> <4E451409.2090901@warmcat.com> Date: Fri, 12 Aug 2011 14:26:41 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: <4E451409.2090901@warmcat.com> User-Agent: Opera Mail/11.50 (MacIntel) Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:25:39 -0000 On Fri, 12 Aug 2011 13:52:41 +0200, Andy Green (林安廸) wrote: > We don't send it. There's no valid use for it IMO. > > However if the problem is solved just by Greg having it for his > extension to use, and without whole frame mtu, an error code reserved > for that is so cheap and self-contained, I'm happy to see him have it. > > The vote though assumes that we have to be against the error code and > the frame mtu implementation, or for both; actually I don't care about > an error code getting reserved unnecessarily if it makes people happy, > and do care about whole frame mtu business being introduced. FWIW I agree with Andy here. I don't mind keeping the error code. -- Simon Pieters Opera Software From ibc@aliax.net Fri Aug 12 05:30: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 14C4721F86BE for ; Fri, 12 Aug 2011 05:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NSTwaQ-4cS+L for ; Fri, 12 Aug 2011 05:30:00 -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 84FD821F86B9 for ; Fri, 12 Aug 2011 05:30:00 -0700 (PDT) Received: by qyk34 with SMTP id 34so303757qyk.10 for ; Fri, 12 Aug 2011 05:30:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.241.205 with SMTP id lf13mr530698qcb.292.1313152237273; Fri, 12 Aug 2011 05:30:37 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Fri, 12 Aug 2011 05:30:37 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 12 Aug 2011 14:30:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:30:01 -0000 2011/8/12 Tobias Oberstein : >> Of course. Which is the problem in indicating maximun frame size during = the >> handshake negotiation?? that's in fact a *negotiation* process! > > one problem is: value is fixed for lifetime of session .. can't be dynami= c/adaptive Why should it be adaptative? During the handshake the client tells its maximum frame size and the server tells the same to the client. After that, they can use whichever frame size (being always lower than the given limits by the remote). If you want such a feature to be re-negotiable after WS has been established, then the design of the protocol is bad as the negotiation takes places during the WS handshake (or should just "some" things be negotiated during handshake and others later but using WS transport protocol?). Giving an example of a *correctly* designed protocol, in SIP a session is established via an INVITE method in which session parameters (audio, video, codecs....) are negotiated (an also in the response to the INVITE). Later during the session (different RTP/MSRP streams) any endpoint can re-nogitiate session parameters by sending a new INVITE (AKA "re-INVITE") with the purpose of adding more streams (i.e. adding video to an audio call), modifying existings streams or whatever. This is robust and well designed. But in WS it seems that any new (or not new) feature requires a hack. --=20 I=C3=B1aki Baz Castillo From andy@warmcat.com Fri Aug 12 05:41: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 8729F21F8784 for ; Fri, 12 Aug 2011 05:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4CQ6FnBLRaf for ; Fri, 12 Aug 2011 05:41:02 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id ACB9021F877F for ; Fri, 12 Aug 2011 05:41:01 -0700 (PDT) Message-ID: <4E451F81.6020604@warmcat.com> Date: Fri, 12 Aug 2011 13:41:37 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Willy Tarreau References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <20110812090942.GB12235@1wt.eu> <4E44F348.80305@warmcat.com> <20110812101608.GF12235@1wt.eu> In-Reply-To: <20110812101608.GF12235@1wt.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Frame signing insecure X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:41:02 -0000 On 08/12/2011 11:16 AM, Somebody in the thread at some point said: > check each frame's signature and forward them as they're checked. It > then makes a lot more sense to validate a few kB at a time and let them > pass than to store a large block to disk, validate its signature then > let it go. Assuring the correctness of all the frames you received is not the same as assuring the correctness of the message, since especially with streamed content like a phone call I can truncate your message as a MITM by messing with the frame's unsigned FIN bit. If the problem is missing frames you can't determine that except from the larger context of what the message ought to have been. > Imagine someone who would make use of WS for telephony. It would be > a well-suited use of digital signatures and you'd want the frames to > be signed, not the message (which is the whole conversation). I agree frame signature extension is pretty interesting. But it has the above vulnerability if there is not also any message digest or signature that makes it alone not usable AFAICT. That's why I say message signature is more useful, although I guess I could put it better. >> Since only non-base extensions care, let the extension peers be >> responsible for the chopping-up according to that particular extension's >> limitations. > > I have no issue with that. My concern is that if there is so much reluctance OK that's good. > in adopting something as trivial as setting a limit on emitted frames size, > surely there is an underlying reason which will surface again when we'll want > to design those extensions. My fears now are that 1 frame == 1 message for > many years to come and that MUX and other possibly useful extensions will > not be possible just because of a few broken implementations which will > heavily rely on the assumption above. Well, I do hear you and was arguing that the 2^63 frame limit on the standard encourages that thinking, whereas a smaller frame limit, still enough to dilute the frame header overhead would enforce people to have to deal with the FIN framing stuff because they're seeing multiframe messages coming in the real world. However trying to 'fix' that approach by defining a frame mtu that otherwise doesn't do anything useful seems to me it'll get worked around by stuff declaring frame limit of 2^63 if they want to take the attitude you're worrying about. So it still doesn't serve any purpose. >> Bear in mind extension implementations are intimately specific to the >> framework they're using. If the guy writing the signed frame extension >> for websocket framework X finds frame handling is broken, he will get it >> fixed in websocket framework X so his extension can work. > > Except that application live for many years and are not changed every > few months. Well, they would be deploying the new extension at that time. Otherwise, they continue to not care it doesn't support what the extension they don't have needs. >>> I would also add that framing has been there for a very long time now, >>> and I suspect that a number of implementations have silently decided >>> that they did not need it, which would explain why suddenly forcing >>> them to emit frames is annoying. If we're at a point where framing is >> >> Interoperability tests which Greg and I have written (eg, fraggle test >> in libwebsocket) are the answer to keeping implementations honest or >> shown to be broken. Adding in bloat to the spec that doesn't actually >> do anything useful won't do what you're hoping here. > > But why are you constantly saying that setting a limit is "bloat" Andy ? I do not hear about it doing anything useful, yet it wants to be added to the spec. In that case, we are adding bloat to the spec. > It's just a matter of storing a value and use it as a check when messages > are to be framed. We're not speaking about *forcing* every agent to send > that large frames, but the opposite, ask that nobody along the path sends > frames larger than what the whole path reliably supports without efforts. > > The bloat would come from supporting any frame size because some > implementations will have to do ugly things for that. We should push that code into extensions that want it, not the base spec that does not need it. Otherwise we can flood the base spec with this and that which one day might be needed by a fantasy extension and there are zero people here who want to start down that road. -Andy From tobias.oberstein@tavendo.de Fri Aug 12 05:51: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 EB9AE21F8802 for ; Fri, 12 Aug 2011 05:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coKnytknjuWv for ; Fri, 12 Aug 2011 05:51:49 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6504F21F87FA for ; Fri, 12 Aug 2011 05:51:49 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Fri, 12 Aug 2011 05:52:26 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Fri, 12 Aug 2011 05:51:50 -0700 Thread-Topic: [hybi] CONSENSUS CALL / Resource limited implementations Thread-Index: AcxY66YfRuoD6nkWSmqo4Pw/B2tsagAACwmg Message-ID: <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 12:51:50 -0000 PiA+IG9uZSBwcm9ibGVtIGlzOiB2YWx1ZSBpcyBmaXhlZCBmb3IgbGlmZXRpbWUgb2Ygc2Vzc2lv biAuLiBjYW4ndCBiZQ0KPiA+IGR5bmFtaWMvYWRhcHRpdmUNCj4gDQo+IFdoeSBzaG91bGQgaXQg YmUgYWRhcHRhdGl2ZT8NCg0KZXhhbXBsZTogYSBtdXhpbmcgZXh0ZW5zaW9uIHdhbnRzIHRvIGR5 bmFtaWNhbGx5IGFkanVzdCBpdCdzIGZyYW1lIHNpemUNCmRlcGVuZGluZyBvbiB1cC9kb3dubGlu ayBiYW5kd2lkdGgvZGVsYXkgdG8gdGFyZ2V0IGEgdHJhZGVvZmYgYmV0d2Vlbg0KbGF0ZW5jeS9l ZmZpY2llbmN5Lg0KDQp3b3VsZCBpdCBiZSBhbm5vdW5jZWQgYSBmaXhlZCwgbWF4LiBmcmFtZSBz aXplIG9mIE4gZHVyaW5nIGhhbmRzaGFrZSwNCnRoZSByYW5nZSB3aXRoaW4gd2hpY2ggZnJhbWUg c2l6ZSBjYW4gYmUgdmFyaWVkIGlzIGxpbWl0ZWQgYnkgTiwgd2hpY2ggbWlnaHQgYmUNCnNtYWxs ZXIgdGhhbiB3aGF0IGl0IHdhbnRzIHRvIGRvIGF0IHNvbWUgcG9pbnQgZHVyaW5nIHNlc3Npb24g bGlmZXRpbWUuDQoNCnRoZSBleHRlbnNpb24gbWlnaHQgc2ltcGx5IHdhbnQgdG8gYWRhcHQgdGhl IGZyYW1lIHNpemUgaXQgZnJhZ21lbnRzIGFueQ0KbWVzc2FnZSBpbnRvIGR1cmluZyBzZW5kaW5n IGJhc2VkIG9uIGl0J3MgZXN0aW1hdGUgb2YgY3VycmVudA0KdXBsaW5rIGJhbmR3aWR0aC9kZWxh eS4NCg0Kd2hlbiB0aGUgZGVjaXNpb24gYWJvdXQgY3VycmVudCBzZW5kIGZyYW1lIHNpemUgaXMg YWx3YXlzIG1hZGUgYnkgdGhlIHNlbmRpbmcNCnBlZXIsIHRoZXJlIGlzIG5vIG5lZWQgdG8gY29t bXVuaWNhdGUgdGhhdCBjdXJyZW50IGZyYW1lIHNpemUgYmV0d2VlbiB0aGUNCnBlZXJzLCBub3Ig aXMgdGhlcmUgYSB1c2Ugb2YgYSAibWF4LiBmcmFtZSBzaXplIi4NCg0KaWYgdGhlIGRlY2lzaW9u IGlzIG1hZGUgYnkgc2VydmVyIGZvciBpdHNlbGYgYW5kIGNsaWVudCwgdGhlIHNlcnZlciB3aWxs IG5lZWQgdG8gDQpjb21tdW5pY2F0ZSB0aGUgY3VycmVudCBmcmFtZSBzaXplIHRoZSBjbGllbnQg aXMgc3VwcG9zZWQgdG8gdXNlIGR1cmluZw0Kc2VuZGluZyB0byB0aGUgY2xpZW50Lg0KDQpub3Rl LCB0aGF0IHRoaXMgImN1cnJlbnQgZnJhbWUgc2l6ZSIgaXMgbm90IGEgbWF4LiBmcmFtZSBzaXpl LCBidXQganVzdCB0aGUgZnJhbWUNCnNpemUgYSBwZWVyIGlzIGZyYWdtZW50aW5nIGFueSBtZXNz YWdlIGludG8NCg0K From ibc@aliax.net Fri Aug 12 06:11: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 D30CE21F8A4D for ; Fri, 12 Aug 2011 06:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qgn20nObd8v1 for ; Fri, 12 Aug 2011 06:11:38 -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 A08F521F8A4B for ; Fri, 12 Aug 2011 06:11:37 -0700 (PDT) Received: by qwc23 with SMTP id 23so2033882qwc.31 for ; Fri, 12 Aug 2011 06:12:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.241.205 with SMTP id lf13mr559436qcb.292.1313154734589; Fri, 12 Aug 2011 06:12:14 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Fri, 12 Aug 2011 06:12:14 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 12 Aug 2011 15:12:14 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:11:40 -0000 2011/8/12 Tobias Oberstein : >> > one problem is: value is fixed for lifetime of session .. can't be >> > dynamic/adaptive >> >> Why should it be adaptative? > > example: a muxing extension wants to dynamically adjust it's frame size > depending on up/downlink bandwidth/delay to target a tradeoff between > latency/efficiency. This stuf should be handled at much more lower layer, within WS protocol as *pure* transport protocol. Letting "extensions" to change such size is, IMHO, a bad design. I don't think that current spec has layers well defined. --=20 I=C3=B1aki Baz Castillo From salvatore.loreto@ericsson.com Fri Aug 12 06:13: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 26F0E21F8A55 for ; Fri, 12 Aug 2011 06:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ev8SYzYg9JOz for ; Fri, 12 Aug 2011 06:13:17 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id 2A50621F8686 for ; Fri, 12 Aug 2011 06:13:16 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-18-4e4527112ed0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F4.8D.09774.117254E4; Fri, 12 Aug 2011 15:13:53 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Fri, 12 Aug 2011 15:13:52 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CB1582461 for ; Fri, 12 Aug 2011 16:13:51 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 943905127E for ; Fri, 12 Aug 2011 16:13:51 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8FC2D5115B for ; Fri, 12 Aug 2011 16:13:50 +0300 (EEST) Message-ID: <4E4526B2.1070401@ericsson.com> Date: Fri, 12 Aug 2011 16:12:18 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 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-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Server-side requirements in draft 10 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:13:18 -0000 On 8/7/11 5:35 PM, Joonas Lehtolahti wrote: > In draft-ietf-hybi-thewebsocketprotocol-10 in Server-side Requirements > (section 5.2.), and more specifically subsection 5.2.1. Reading the > Client's Opening Handshake, I noticed that the requirements do not list > that the client's handshake must contain the upgrade headers (Upgrade: > websocket, Connection: upgrade). > > Based on that, even though it is required for the client to send those > headers, it is not necessary for the server to see those headers to still > consider the connection attempt as a valid WebSocket handshake as long as > it has the other required parts such as Sec-WebSocket-Protocol. This would > allow the server to complete the handshake and ask for protocol upgrade > without the client requesting for upgrade. In other words even if the > client violated the spec for handshake, the server would still accept it. > > Is this an oversight or actually intentional? thanks for the good catch, it is an oversight! > As far as I understood from > RFC2616 (HTTP/1.1) the Upgrade header from server can only be sent in > response to client indicating willingness to upgrade protocols. Therefore > accepting a HTTP request without Upgrade headers as a valid WebSocket > handshake and then responding with server handshake including the Upgrade > headers would be violating the idea behind the headers in my opinion (I > did not see the HTTP spec actually forbidding server from sending Upgrade > headers without client requesting it, but it seems implicit it should not > happen). exactly. cheers /Sal -- Salvatore Loreto www.sloreto.com From andy@warmcat.com Fri Aug 12 06:43:11 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 7942021F86DD for ; Fri, 12 Aug 2011 06:43:11 -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.096, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pu3xrjmLxSVw for ; Fri, 12 Aug 2011 06:43:11 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id C0D4321F86D0 for ; Fri, 12 Aug 2011 06:43:10 -0700 (PDT) Message-ID: <4E452E12.3040103@warmcat.com> Date: Fri, 12 Aug 2011 14:43:46 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:43:11 -0000 On 08/12/2011 02:12 PM, Somebody in the thread at some point said: > 2011/8/12 Tobias Oberstein: >>>> one problem is: value is fixed for lifetime of session .. can't be >>>> dynamic/adaptive >>> >>> Why should it be adaptative? >> >> example: a muxing extension wants to dynamically adjust it's frame size >> depending on up/downlink bandwidth/delay to target a tradeoff between >> latency/efficiency. > > This stuf should be handled at much more lower layer, within WS > protocol as *pure* transport protocol. Letting "extensions" to change > such size is, IMHO, a bad design. I don't think that current spec has > layers well defined. You have to bear in mind the extensions negotiate that they have a peer implementation of the same extension to talk to. So your client "sign-frames-1.0" extension will always have a compliant "sign-frames-1.0" peer on the server side that "speaks its language". In the case that there's a sequence of extensions operating, the ordering of the sequence of extensions can be important that they match. By leaving it to the extension "layer", each extension peer pair which has a fragment size constraint can explicitly or implicitly configure the fragmentation to happen at that layer, also any other constraints or special needs they have can privately occur at that layer. Nobody else needs to know in terms of other extensions or the base protocol. As a side effect, that same-extenion - same-extension constraint stuff can be adaptive, but it's not really the reason to put it there. Since in the case of buffering frames it's only really the signing frame extension that has a legit reason to do it IMO, it's righteous that the code to deal with it should fall inside that extension. -Andy From ibc@aliax.net Fri Aug 12 06:58: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 00AD621F8A30 for ; Fri, 12 Aug 2011 06:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3delzjwMPJ2 for ; Fri, 12 Aug 2011 06:58:17 -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 75B5521F8A23 for ; Fri, 12 Aug 2011 06:58:17 -0700 (PDT) Received: by qyk34 with SMTP id 34so346380qyk.10 for ; Fri, 12 Aug 2011 06:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr598129qcj.216.1313157534498; Fri, 12 Aug 2011 06:58:54 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Fri, 12 Aug 2011 06:58:54 -0700 (PDT) In-Reply-To: <4E452E12.3040103@warmcat.com> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E452E12.3040103@warmcat.com> Date: Fri, 12 Aug 2011 15:58:54 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 13:58:18 -0000 2011/8/12 "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" : > By leaving it to the extension "layer", each extension peer pair which ha= s a > fragment size constraint can explicitly or implicitly configure the > fragmentation to happen at that layer, also any other constraints or spec= ial > needs they have can privately occur at that layer. =C2=A0Nobody else need= s to > know in terms of other extensions or the base protocol. Ok, can my HTTP client (a script in Ruby/Python/whatever) decide the payload size of the Ethernet message sent to my local network? --=20 I=C3=B1aki Baz Castillo From andy@warmcat.com Fri Aug 12 07:15: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 648C021F8A4D for ; Fri, 12 Aug 2011 07:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.209 X-Spam-Level: X-Spam-Status: No, score=-2.209 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6E5eRIfqwtZ for ; Fri, 12 Aug 2011 07:15:20 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 77DEC21F8A4B for ; Fri, 12 Aug 2011 07:15:20 -0700 (PDT) Message-ID: <4E45359A.7030700@warmcat.com> Date: Fri, 12 Aug 2011 15:15:54 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E452E12.3040103@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 14:15:21 -0000 On 08/12/2011 02:58 PM, Somebody in the thread at some point said: > 2011/8/12 "Andy Green (林安廸)": >> By leaving it to the extension "layer", each extension peer pair which has a >> fragment size constraint can explicitly or implicitly configure the >> fragmentation to happen at that layer, also any other constraints or special >> needs they have can privately occur at that layer. Nobody else needs to >> know in terms of other extensions or the base protocol. > > Ok, can my HTTP client (a script in Ruby/Python/whatever) decide the > payload size of the Ethernet message sent to my local network? It can certainly decide in what size packets to issue stuff. What happens after that, before and after your Ethernet adapter in terms of packet coalescing or fragmentation is out of its control. That's the same deal here, except that intermediaries should understand the extensions involved (and follow any private mtu negotiation) if they're going to change fragment sizes. -Andy From tobias.oberstein@tavendo.de Fri Aug 12 07:17: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 80FCB21F8802 for ; Fri, 12 Aug 2011 07:17:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jn8fM--NKTTM for ; Fri, 12 Aug 2011 07:17:55 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id AA25D21F84E1 for ; Fri, 12 Aug 2011 07:17:54 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Fri, 12 Aug 2011 07:18:31 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , =?utf-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Date: Fri, 12 Aug 2011 07:17:55 -0700 Thread-Topic: [hybi] CONSENSUS CALL / Resource limited implementations Thread-Index: AcxY+AIZkLVkdS6mSJWKXEDRmaZyFAAASCvg Message-ID: <634914A010D0B943A035D226786325D422BFBFC394@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E452E12.3040103@warmcat.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 14:17:55 -0000 PiA+IEJ5IGxlYXZpbmcgaXQgdG8gdGhlIGV4dGVuc2lvbiAibGF5ZXIiLCBlYWNoIGV4dGVuc2lv biBwZWVyIHBhaXIgd2hpY2gNCj4gPiBoYXMgYSBmcmFnbWVudCBzaXplIGNvbnN0cmFpbnQgY2Fu IGV4cGxpY2l0bHkgb3IgaW1wbGljaXRseSBjb25maWd1cmUNCj4gPiB0aGUgZnJhZ21lbnRhdGlv biB0byBoYXBwZW4gYXQgdGhhdCBsYXllciwgYWxzbyBhbnkgb3RoZXIgY29uc3RyYWludHMNCj4g PiBvciBzcGVjaWFsIG5lZWRzIHRoZXkgaGF2ZSBjYW4gcHJpdmF0ZWx5IG9jY3VyIGF0IHRoYXQg bGF5ZXIuIMKgTm9ib2R5DQo+ID4gZWxzZSBuZWVkcyB0byBrbm93IGluIHRlcm1zIG9mIG90aGVy IGV4dGVuc2lvbnMgb3IgdGhlIGJhc2UgcHJvdG9jb2wuDQo+IA0KPiBPaywgY2FuIG15IEhUVFAg Y2xpZW50IChhIHNjcmlwdCBpbiBSdWJ5L1B5dGhvbi93aGF0ZXZlcikgZGVjaWRlIHRoZQ0KPiBw YXlsb2FkIHNpemUgb2YgdGhlIEV0aGVybmV0IG1lc3NhZ2Ugc2VudCB0byBteSBsb2NhbCBuZXR3 b3JrPw0KDQpOby4gU28gd2hhdD8NCg0KQ2FuIHRoZSB0b3JyZW50IHByb3RvY29sIHRyYW5zZmVy IGZyYWdtZW50cyBvZiBhIGZpbGU/IFlvdSBiZXQuDQoNCkRvZXMgdGhhdCBtZWFuIHRvcnJlbnQg aXMgImJhZGx5IGRlc2lnbmVkIiBiZWNhdXNlIGl0IHVzZXMgZnJhZ21lbnRzLCB3aGVyZQ0Kd2Ug YWxyZWFkeSBoYXZlIGZyYWdtZW50cyBvbiB0aGUgVENQIGxheWVyLCBwYWNrZXRzIG9uIElQLCBm cmFtZXMgb24gRXRoZXJuZXQsIC4uPw0KDQpUaGUgY29uY2VwdCBvZiAiY2h1bmsiIGV4aXN0cyBv biBtdWx0aXBsZSBsYXllcnMgYW5kIGVhY2ggbGF5ZXIgbWF5IGhhdmUgaXQncw0Kb3duICJjaHVu ayIgY29uY2VwdCwgdXNlIGFuZCBydWxlcyBmb3IgaXQuDQoNCk9uaW9ucyBhcmUgZ29vZDspDQo= From bruce@callenish.com Fri Aug 12 08:44: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 998A221F86B3 for ; Fri, 12 Aug 2011 08:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEECvEwQKGnJ for ; Fri, 12 Aug 2011 08:44:13 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED4A21F86D8 for ; Fri, 12 Aug 2011 08:44:13 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qrtuj-00050S-Mb; Fri, 12 Aug 2011 08:44:49 -0700 Message-ID: <4E454A73.9030100@callenish.com> Date: Fri, 12 Aug 2011 08:44:51 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44927E.4080807@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] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:44:13 -0000 On 11/08/2011 8:43 PM, Greg Wilkins wrote: > Separately to message limits, I have the ability to limit frame sizes > to the buffer sizes or let the parser create fake fragments for large > frames that are streamed to the aggregation layer. There is no reason > in my current implementation to actually limit the frame size, but the > capability is there so that future extensions that may need to process > entire frames or that have latency concerns can restrict frame size. Sounds like you have a good general purpose solution. I started down that road myself, making my solution work both streamily and not in a variety of ways. Then I realized that I was solving a problem that I did not have because my implementation is not intended to be a general one, and ripped much of it out. > Unless you are running extensions > that need to process entire frames, That's part of it. There are three levels of extensions: stream (which will hopefully only have deflate-stream as an example), frame, and message. Frame-based extensions are useful for communicating between the Websocket implementations, and sometimes it can be useful to have them work with the payload. Willy gave one example, I gave another concerning changing the opcode based on the contents of the payload. Yet another would be modifying the payload in some way and thus needing to adjust the payload length. I don't currently have any of these at the moment, but I am thinking about them. The response I have gotten is that such extensions are invalid or that they should set their own length limits. Why they are invalid is beyond me. Since they have no length limits other than what the underlying implementation provides, it makes no sense for them to come up with an arbitrary limit, particularly since the implementation may change the amount it buffers without mentioning it to the extension. > you should be able to process > large frames in small buffers (in my case if I receive a frame larger > than my buffer, I pass it to the frame aggregation/handling layer as a > fake smaller frame and when the remaining data is received in the same > buffer it is passed on as a fake continuation frame). Can you explain > a bit more why you want to process the entire frame at once? > Thanks, but I've been down this road a few times and it doesn't work out, because there is always a workaround for any objection. I start out with a nice clean design that meets my needs but for the lack of being able to declare a maximum frame limit. Someone suggests a different implementation, like "why don't you aggregate the data from smaller buffers into frames?" I come up with reasons I don't like it, for example I don't want to copy data multiple times before reaching the message level. I'll then get responses like, "You don't have to worry, the cost is negligible" and "You don't have to copy, you can maintain the frame as a collection of buffers" and "STREAMIFY". I'll respond to each suggestion. If I maintain the buffers as elements of a frame, I bloat the amount of data needed to store the frame. If I streamify I lose the ability to model the spec. The streaming guys continue to insist that streaming is the one true implementation, completely ignoring anything I've written. Meanwhile, I look back and see my nice simple design disappearing over the horizon, all for a lack of a maximum frame size that would hurt nobody. From ferg@caucho.com Fri Aug 12 08:52: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 0D4ED21F8786 for ; Fri, 12 Aug 2011 08:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.275 X-Spam-Level: X-Spam-Status: No, score=-2.275 tagged_above=-999 required=5 tests=[AWL=0.324, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuvwOU6FakeO for ; Fri, 12 Aug 2011 08:52:54 -0700 (PDT) Received: from nm2.access.bullet.mail.mud.yahoo.com (nm2.access.bullet.mail.mud.yahoo.com [66.94.237.203]) by ietfa.amsl.com (Postfix) with SMTP id 8303521F8764 for ; Fri, 12 Aug 2011 08:52:54 -0700 (PDT) Received: from [66.94.237.197] by nm2.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Aug 2011 15:53:29 -0000 Received: from [98.139.221.60] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 12 Aug 2011 15:53:29 -0000 Received: from [127.0.0.1] by smtp101.biz.mail.bf1.yahoo.com with NNFMP; 12 Aug 2011 15:53:29 -0000 X-Yahoo-Newman-Id: 290564.58128.bm@smtp101.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: e8.HvmUVM1nDxgvCOHJhHNLsecrn8_31_upSNqUynB_ONWH b_IBD8P_OCakDIlfnbJC.ey648SCC7SMr6K4Q3JENhQ17qQeXD1yHsSqnhLi W207awJ3h3ag1ZrjIzN7hg3KWmoqFF77eJv2dft8svvcUevF3xvWKoXWtpUP vPIBnRMpc.JxVnMrSGO71zafaFi1WE9Jgj8cHhx1SW2ZT2xFhYD4y4B54T.M TcpAE_HH6mNMsViyAgcldp.hqJiviDSk91kSjNU.v55Z1IX1NpAitqn_57t4 mNIxt1tN4R_dmPVJa8fd9znFHAmeYwbqCOGKtxpAMHnZYLLCKZC8LgSzL1G9 RKPYsSWHir7qqfu2fjWLy8RRcDhsE8cpFQfAKUd_1uwH4aQ5I77bcB5EUQx6 20XVdjpiPDje9 X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp101.biz.mail.bf1.yahoo.com with SMTP; 12 Aug 2011 08:53:29 -0700 PDT Message-ID: <4E454C73.5060209@caucho.com> Date: Fri, 12 Aug 2011 08:53:23 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: <4E440808.5030907@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 15:52:55 -0000 On 08/11/2011 09:49 AM, Peter Saint-Andre wrote: > > Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size. > > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". 1) remove the error code (more specifically, replace with "Message Too Large") No compelling use-cases have been given for the max-frame-size. The main result would be to allow and encourage limited implementations. Given past headaches in working around broken peers, it's a bad idea for the spec to actively encourage them. Replacing it with a "Message Too Large" would be a good idea, primarily as an application-layer error. Applications need a way of rejecting large messages. (Some WebSocket-layer implementations like the browser API might need to reject large messages.) -- Scott > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. > > Please reply to this consensus call by the close of business next > Wednesday, August 17, 2011. When you reply, please indicate your > preference ("1" or "2") and provide a brief reason, if appropriate. > > Thank you. > > Peter > From ferg@caucho.com Fri Aug 12 09:09: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 24E7821F8736 for ; Fri, 12 Aug 2011 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kNNQobW3jM1 for ; Fri, 12 Aug 2011 09:09:31 -0700 (PDT) Received: from nm13-vm0.bullet.mail.sp2.yahoo.com (nm13-vm0.bullet.mail.sp2.yahoo.com [98.139.91.244]) by ietfa.amsl.com (Postfix) with SMTP id C271521F84EE for ; Fri, 12 Aug 2011 09:09:30 -0700 (PDT) Received: from [98.139.91.66] by nm13.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 16:10:08 -0000 Received: from [98.139.91.3] by tm6.bullet.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 16:10:08 -0000 Received: from [127.0.0.1] by omp1003.mail.sp2.yahoo.com with NNFMP; 12 Aug 2011 16:10:08 -0000 X-Yahoo-Newman-Id: 486169.15208.bm@omp1003.mail.sp2.yahoo.com Received: (qmail 84363 invoked from network); 12 Aug 2011 16:10:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313165408; bh=L1Mqy3shCbxQIhSSRwJKsSspY86Hdzzi/LBZdK7a5BE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=oeuZiq3j/kQkgEa21kic4RLahMEVkgo7lS8awrJidFA76P4miaohSpZdz7krnMpMLFf1bEhIWS1VB0BtjZ3IyQ7OErpR0KPAYo4hp/UXd6rsjG2pcH8DGHwX5+rGlNrzz1a9nSRFuRWJ2lfjQynEWKUIPtYmDSvDSUtszpBdNZs= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qkJ4MY0VM1nYqSN3rTdMoSpj_dLsUIscdRBWqmeB5m_RvvQ id88KtmBvLsB6Gc49o5J3manm4DC6U9jGwPdVXs_FVjZgBQyhNuMd4jcGLon cN.0amHLkDIAcVta4k3cOAcbvF3XzenKl5D0Ed5K.5vOXasWmVIDVCdfWRLY 1GYqI6McinhXnTIUQcn0bfd.HB.GnodhqOxptBHabCKyXY7POkFfoShSglRI 8u9vjkNYezfxdi_BylBjLL7QyIip81MxWrHpGEGkfxg0lUJdL4FglCkYjrde nK.BEclr_aCMFEak8G_LtGWxvAUCf.4L5o0owpzIHBKbWt1XGVmWF7uqUj9Y kvJ2_F0VLBWJARPZRj_G61i1.KZfY9eom4c9yZ5dev4TDImf88_1Lk0K.87M oBGUzNNe8C1_uX7p9lmGdnvlFt8.4O8c- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp111.biz.mail.sp1.yahoo.com with SMTP; 12 Aug 2011 09:10:08 -0700 PDT Message-ID: <4E45505F.2020307@caucho.com> Date: Fri, 12 Aug 2011 09:10:07 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <20110812090942.GB12235@1wt.eu> <4E44F348.80305@warmcat.com> <20110812101608.GF12235@1wt.eu> In-Reply-To: <20110812101608.GF12235@1wt.eu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] CONSENSUS CALL / Frame signing insecure X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 16:09:33 -0000 On 08/12/2011 03:16 AM, Willy Tarreau wrote: > On Fri, Aug 12, 2011 at 10:32:56AM +0100, "Andy Green (?????????)" wrote: >> Since only non-base extensions care, let the extension peers be >> responsible for the chopping-up according to that particular extension's >> limitations. > I have no issue with that. My concern is that if there is so much reluctance > in adopting something as trivial as setting a limit on emitted frames size, > surely there is an underlying reason which will surface again when we'll want > to design those extensions. Well, my opposition is because it's adding complexity primarily to support broken receivers, The brittleness of a broken receiver which relies on a sender to work around its limitations is a bad thing. Given past pain in dealing with broken peers, I don't see the value of encouraging it in the spec. Plus, the max-frame-size makes the whole sendfile() argument for the massive frames pointless, and if we're really limiting frame size, we should have used a fixed 16-bit frame length. :) > My fears now are that 1 frame == 1 message for > many years to come and that MUX and other possibly useful extensions will > not be possible just because of a few broken implementations which will > heavily rely on the assumption above. Huh? Dynamic and stream senders send messages in multiple frames. For example, My Resin implementation uses a fixed 8k sending buffer while accepting any size frame. Any stream-based implementation should have similar behavior. Plus, the complexity of MUX is far beyond just the frame-size. Adding a frame-size doesn't get you anywhere near implementing MUX. -- Scott From bruce@callenish.com Fri Aug 12 09:46: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 97E3811E8082 for ; Fri, 12 Aug 2011 09:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BKlGq1nfZNfX for ; Fri, 12 Aug 2011 09:46:42 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id DF4B511E8081 for ; Fri, 12 Aug 2011 09:46:41 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrutC-0000Pc-LC; Fri, 12 Aug 2011 09:47:18 -0700 Message-ID: <4E455919.3080101@callenish.com> Date: Fri, 12 Aug 2011 09:47:21 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> 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] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 16:46:42 -0000 On 12/08/2011 5:51 AM, Tobias Oberstein wrote: >>> one problem is: value is fixed for lifetime of session .. can't be >>> dynamic/adaptive >> Why should it be adaptative? > example: a muxing extension wants to dynamically adjust it's frame size > depending on up/downlink bandwidth/delay to target a tradeoff between > latency/efficiency. Size limits on extensions have nothing to do with limitations of the underlying implementation. Why do people keep conflating the two issues? Let me try an analogy. A plane has a maximum cargo capacity. A particular airline may have a calculation setting maximum cargo based on calculations to minimize fuel costs. If this is less than the plane's capacity then it acts as the maximum amount of cargo that is carried. But if the calculation comes out to more than the plane's maximum, the plane cannot suddenly carry more cargo. The maximum is set by the lesser of the two values. This analogy can be adaptive as well. Perhaps the calculation changes based on whether there is a headwind. That changes one of the values, but the maximum that the plane can carry stays constant. I know, I know. Streamify and the plane can carry an unlimited cargo. That is a different issue, and one that I am really tired of hearing because I don't want the plane to carry an unlimited cargo. The point is that a maximum frame size does not stop a Mux extension from adjusting its frame size based on circumstances, within the limits of the underlying implementation. From bruce@callenish.com Fri Aug 12 10:01: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 4B19421F85AC for ; Fri, 12 Aug 2011 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.592 X-Spam-Level: X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nU7mAhzRoeSG for ; Fri, 12 Aug 2011 10:01:00 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id DF1B021F85AB for ; Fri, 12 Aug 2011 10:01:00 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qrv73-0002RT-0d; Fri, 12 Aug 2011 10:01:37 -0700 Message-ID: <4E455C73.5070208@callenish.com> Date: Fri, 12 Aug 2011 10:01:39 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein 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 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:01:01 -0000 On 11/08/2011 10:47 PM, Tobias Oberstein wrote: >> chosen as optimal for my situation. If a major browser chose to allow >> frame sizes of 64K and I couldn't send a max-frame-size, > Both Firefox and Chrome currently send a message - independent of size - > always _unfragmented_ (that is fragment size = message size) > > I have tested this with messages up to 8MB. > > Both will receive a 8MB message arbitrarily fragmented (tested with frame > sizes from 64 bytes - 8MB) Ouch. So all that work I went to having separate threads between layers so that control frames could sneak in in the middle of a longer message was totally wasted? How very sad. From tobias.oberstein@tavendo.de Fri Aug 12 10:01: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 EE21511E8083 for ; Fri, 12 Aug 2011 10:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZxYRbmbsDDDa for ; Fri, 12 Aug 2011 10:01:23 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE9F21F85AB for ; Fri, 12 Aug 2011 10:01:21 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Fri, 12 Aug 2011 10:01:57 -0700 From: Tobias Oberstein To: Bruce Atherton Date: Fri, 12 Aug 2011 10:01:21 -0700 Thread-Topic: [hybi] CONSENSUS CALL / Resource limited implementations Thread-Index: AcxZD4MjsKWpeb/TRoePgFmf/WJWFQAAPQlg Message-ID: <634914A010D0B943A035D226786325D422BFBFC46E@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> In-Reply-To: <4E455919.3080101@callenish.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 17:01:24 -0000 > don't want the plane to carry an unlimited cargo. The point is that a max= imum > frame size does not stop a Mux extension from adjusting its frame size ba= sed > on circumstances, within the limits of the underlying implementation. Don't know if it makes sense, but I will try once more, because I think we = should at least listen to each other on this list. Implementation A has a fixed, built-in max. frame size of 64k. It wants to announce that, and make any other implementation obey to that m= ax. Implementation B has no limit on frame size, but wants to scale it dynamica= lly within - lets say 8k - 1M. It wants to do that when it speaks some special = extension. What happens is: B can only use range 8k - 64k, since A imposes the max. of= 64k. What if implementation C has a limit of 125 bytes, because that is the max.= payload of control messages, and C decided for whatever reasons, that it would be s= impler to make that the limit. Now, A, B and C will need to obey 125. How can this be resolved?=20 From bruce@callenish.com Fri Aug 12 11:34: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 9C73821F86B3 for ; Fri, 12 Aug 2011 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8miXsWiBeMUL for ; Fri, 12 Aug 2011 11:34:41 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 2881721F8686 for ; Fri, 12 Aug 2011 11:34:41 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QrwZh-0007oH-Ro; Fri, 12 Aug 2011 11:35:17 -0700 Message-ID: <4E457268.7080509@callenish.com> Date: Fri, 12 Aug 2011 11:35:20 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <634914A010D0B943A035D226786325D422BFBFC46E@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC46E@EXVMBX020-12.exch020.serverdata.net> 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] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:34:41 -0000 On 12/08/2011 10:01 AM, Tobias Oberstein wrote: >> don't want the plane to carry an unlimited cargo. The point is that a maximum >> frame size does not stop a Mux extension from adjusting its frame size based >> on circumstances, within the limits of the underlying implementation. > Don't know if it makes sense, but I will try once more, because I think we should at least > listen to each other on this list. I agree that there is far too little of that going on. > Implementation A has a fixed, built-in max. frame size of 64k. > It wants to announce that, and make any other implementation obey to that max. > > Implementation B has no limit on frame size, but wants to scale it dynamically > within - lets say 8k - 1M. It wants to do that when it speaks some special extension. > > What happens is: B can only use range 8k - 64k, since A imposes the max. of 64k. Almost. Remember that we are talking about maximum frame size, not actual frame size. B can use any frame size 0K to 64K. But let's change the scenario a bit to match what you are saying. Let us say that extension B requires sending a minimum of 8K in each frame. Then you would be right that the range will always be 8K to 64K. > What if implementation C has a limit of 125 bytes, because that is the max. payload > of control messages, and C decided for whatever reasons, that it would be simpler > to make that the limit. > > Now, A, B and C will need to obey 125. > > How can this be resolved? Implementation C is not compatible with extension B because it does not provide the minimum frame size that B requires. So when extensions are negotiated, A would ask to use extension B and C would refuse to use it. Then communication between the two would either continue without it, or the application level in A may shut down the connection if it required the use of B. From pmcmanus@mozilla.com Fri Aug 12 11:39:36 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 6047321F84E2 for ; Fri, 12 Aug 2011 11:39:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KoHapTMcpgg for ; Fri, 12 Aug 2011 11:39:36 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id E388621F84D7 for ; Fri, 12 Aug 2011 11:39:35 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 117BC10193; Fri, 12 Aug 2011 14:40:12 -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 1FA4E10190; Fri, 12 Aug 2011 14:40:08 -0400 (EDT) From: Patrick McManus To: Bruce Atherton In-Reply-To: <4E455C73.5070208@callenish.com> References: <4E455C73.5070208@callenish.com> Content-Type: text/plain; charset="UTF-8" Date: Fri, 12 Aug 2011 14:40:01 -0400 Message-ID: <1313174401.1816.270.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 18:39:36 -0000 On Fri, 2011-08-12 at 10:01 -0700, Bruce Atherton wrote: > On 11/08/2011 10:47 PM, Tobias Oberstein wrote: > >> chosen as optimal for my situation. If a major browser chose to allow > >> frame sizes of 64K and I couldn't send a max-frame-size, > > Both Firefox and Chrome currently send a message - independent of size - > > always _unfragmented_ (that is fragment size = message size) > > > > I have tested this with messages up to 8MB. > > > > Both will receive a 8MB message arbitrarily fragmented (tested with frame > > sizes from 64 bytes - 8MB) > > Ouch. So all that work I went to having separate threads between layers > so that control frames could sneak in in the middle of a longer message > was totally wasted? > > How very sad. > If there was a use case we wanted to support that required fragmenting on transmit, then we would fragment. I expect mux will be that case. It is a mistake to read Tobias's comments as a statement that firefox won't ever send fragments. From tobias.oberstein@tavendo.de Fri Aug 12 12:41: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 196465E800C for ; Fri, 12 Aug 2011 12:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIC2gJzGPciM for ; Fri, 12 Aug 2011 12:41:25 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 75D675E800B for ; Fri, 12 Aug 2011 12:41:25 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Fri, 12 Aug 2011 12:42:02 -0700 From: Tobias Oberstein To: Bruce Atherton Date: Fri, 12 Aug 2011 12:42:01 -0700 Thread-Topic: AW: [hybi] CONSENSUS CALL / Resource limited implementations Thread-Index: AcxZHqGrvxOUsRJTRbq2axAly9US/QACUXfb Message-ID: In-Reply-To: <4E457268.7080509@callenish.com> Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 19:41:26 -0000 >> Implementation A has a fixed, built-in max. frame size of 64k. >> It wants to announce that, and make any other implementation obey to tha= t >> max. >>=20 >> Implementation B has no limit on frame size, but wants to scale it >> dynamically >> within - lets say 8k - 1M. It wants to do that when it speaks some speci= al >> extension. >>=20 >> What happens is: B can only use range 8k - 64k, since A imposes the max.= of >> 64k. >=20 > Almost. Remember that we are talking about maximum frame size, not > actual frame size. B can use any frame size 0K to 64K. >=20 > But let's change the scenario a bit to match what you are saying. Let us > say that extension B requires sending a minimum of 8K in each frame. > Then you would be right that the range will always be 8K to 64K. Ok, I was a bit sloppy with the B example. B is supposed to be able to send and receive frames of any size in the range 0 - 2^63. However, when it sends a _message_ of lets say 1M, it wants to fragment tha= t message into frames of length C, where it wants C depend on network conditions, even varied over time, and varied in a range say R =3D 8k - 1M. In this case, when B talks to A, that range R will clamped to the max. that A has announced, and when that is less than 1M, then B is limited in comparison to what it would do when talking to another peer of type B. =3D=3D In the spirit of listen, two questions rgd. your implementation. a) Suppose you want to send a 1M message. In what frame sizes do you fragment? b) Suppose you talk to another peer that has a very small max. frame size limit (say 125 .. or even 1 byte). What will be the effect on your implementation (i.e. in terms of efficiency)? From theturtle32@gmail.com Fri Aug 12 13:29: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 47B27228309 for ; Fri, 12 Aug 2011 13:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.39 X-Spam-Level: X-Spam-Status: No, score=-3.39 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKNQiUZbcA-o for ; Fri, 12 Aug 2011 13:29:30 -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 D8C38228307 for ; Fri, 12 Aug 2011 13:29:29 -0700 (PDT) Received: by bkar4 with SMTP id r4so2304131bka.31 for ; Fri, 12 Aug 2011 13:30:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G4qRbWY+aIKgSF3FCoWem132kNbh6ucQtwoYnR/RbKM=; b=VnPFhcfpxcPaIUaOMEphv3veJIAgDrEjJueAdUsRzNKyq95Ed2wtLOvD5xx5xg2gtu mcyX/eOCMD539h3iiO18BhNsOPCDYzy/dKfC09h6/yxay3B8kBJxZwKNWn8rTjXc93EY tABCH/B6FjY4KkFEwwYchGqYoul62sJlnwGrE= MIME-Version: 1.0 Received: by 10.204.5.83 with SMTP id 19mr513535bku.361.1313181007001; Fri, 12 Aug 2011 13:30:07 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Fri, 12 Aug 2011 13:30:06 -0700 (PDT) In-Reply-To: References: <4E320640.2080408@gmail.com> Date: Fri, 12 Aug 2011 13:30:06 -0700 Message-ID: From: Brian To: Greg Wilkins Content-Type: multipart/alternative; boundary=00151758b03472b9b604aa54c7e5 Cc: Hybi Subject: Re: [hybi] Supporting OAUTH-like authentication? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 20:29:31 -0000 --00151758b03472b9b604aa54c7e5 Content-Type: text/plain; charset=ISO-8859-1 This seems like a discussion for the JS API to me. The protocol spec already explicitly allows arbitrary HTTP headers to be both sent and received by the WebSocket server and client, if I recall correctly. The only thing preventing usage of this feature is a limitation in the JavaScript API. I don't think there's any reason to disallow arbitrary headers being set on the WS handshake using exactly the same mechanism/restrictions as we do today for XHR. But what does that have to do with HyBi? Brian On Thu, Jul 28, 2011 at 6:34 PM, Greg Wilkins wrote: > Philipp, > > Doing the auth within the connection is certainly possible, maybe even > desirable. However, I think that there could be a concern about not > wanting to accept connections from non-authenticated sources, as to do > so already represents an allocation of resources. There are also > extra RTT's involved in token exchange after the handshake. > > So failing giving access to HTTP headers, doing oauth the "normal" way > in headers in the handshake will not be possible. Those wanting > authentication in the handshake can probably kludge it now using the > protocol string. So do we want to better facilitate auth in the > handshake. > > Note also, that with your counter example, there are probably things > we could do to make it more elegant. For instance, perhaps we want to > allow multiple sub-protocols so we don't have to come up with > "foo+oauth", "bar+oauth" etc and instead just negotiate "oauth,foo" > > Eitherway, I think we need to step through (probably implement), some > common authentication mechanisms to see how they work with the current > protocol and to see how we can improve support for them. > > cheers > > > > > On 29 July 2011 11:00, Philipp Serafin wrote: > > Wouldn't it be better to move the token exchange into the actual WS > > connection where we have efficient two-way communication available? > > > > 1.: Client connects to server using subprotocol "foo", which is known to > > use OAuth as authentication (or e.g. "foo+oauth", if this should be > > decided on per-connection basis) > > 2.: Client and server perform successful WS handshake > > 3.: Server sends token and authority URL in a WS message. > > 4.: Client gets token authorized > > 5.: Client sends authorized token back in a WS message. > > 6.: Server confirms that authorisation was successful. > > 7.: Client and server exchange messages as specified by "foo". > > > > Am 29.07.2011 02:44, schrieb Greg Wilkins: > >> All, > >> > >> Currently the protocol allows arbitrary headers, so in theory an > >> authentication mechanism like OAUTH could be implemented by exchanging > >> tokens in the headers of the handshake. But the js API does not > >> allow an application to set or see HTTP header from the handshake (nor > >> should it), so that is not available as a general mechanism for token > >> passing auth like OAUTH. > >> > >> So what other options do we have to pass tokens in the handshake? > >> > >> Cookies - this is possible, but kind of defeats the purpose of token > >> passing auth if tokens are to be sent/set in a way that facilitates > >> wider access to them. > >> > >> Extensions - we could say that an OAUTH extensions is required to > >> manipulate the headers of the handshake with OAUTH tokens, but I > >> expect that there will be a very high barrier for an extension to be > >> included in browsers, so I think that is probably a non starter (at > >> least until a defacto-standard auth mechanism emerges). > >> > >> Subprotocol/CloseEvents - Subprotocol is a user controlled field sent > >> by the handshake and closeEvents contain a reason string that could > >> originate from the server application/framework. Thus I would not > >> be surprised to see these fields used (misused?) to send challenges > >> and pass tokens eg. > >> > >> 1. Client connects to server with oauth subprotocol. > >> 2. Server accepts connection but immediately closes with a reason > >> string containing a token and/or authority URL. ( might be able to be > >> done with a 403 HTTP response if the HTTP reason string is passed to > >> the onerror call back ?? ] > >> 3. Client gets the token signed by an/the authority > >> 4. Client connections to server with oauth;token=value subprotocol > >> 5. Server validates authorisation of token and accepts connection. > >> > >> [ forgive me if that is not exactly how oauth works or correct > >> terminology ... but it is something like that ] > >> > >> Is this a good usage of the subprotocol field/reason fields? > >> > >> Is there a better way to integrate such authentication into the > handshake? > >> > >> > >> cheers > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --00151758b03472b9b604aa54c7e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This seems like a discussion for the JS API to me. =A0The protocol spec alr= eady explicitly allows arbitrary HTTP headers to be both sent and received = by the WebSocket server and client, if I recall correctly. =A0The only thin= g preventing usage of this feature is a limitation in the JavaScript API. = =A0I don't think there's any reason to disallow arbitrary headers b= eing set on the WS handshake using exactly the same mechanism/restrictions = as we do today for XHR. =A0But what does that have to do with HyBi?

Brian

On Thu, Jul 28, 2011= at 6:34 PM, Greg Wilkins <gregw@intalio.com> wrote:
Philipp,

Doing the auth within the connection is certainly possible, maybe even
desirable. =A0However, I think that there could be a concern about not
wanting to accept connections from non-authenticated sources, as to do
so already represents an allocation of resources. =A0 =A0There are also
extra RTT's involved in token exchange after the handshake.

So failing giving access to HTTP headers, doing oauth the "normal"= ; way
in headers in the handshake will not be possible. =A0 =A0Those wanting
authentication in the handshake can probably kludge it now using the
protocol string. =A0 =A0 =A0So do we want to better facilitate auth in the<= br> handshake.

Note also, that with your counter example, there are probably things
we could do to make it more elegant. =A0For instance, perhaps we want to allow multiple sub-protocols so we don't have to come up with
"foo+oauth", "bar+oauth" etc and instead just negotiate= "oauth,foo"

Eitherway, I think we need to step through (probably implement), some
common authentication mechanisms to see how they work with the current
protocol and to see how we can improve support for them.

cheers




On 29 July 2011 11:00, Philipp Serafin <phil127@gmail.com> wrote:
> Wouldn't it be better to move the token exchange into the actual W= S
> connection where we have efficient two-way communication available? >
> 1.: Client connects to server using subprotocol "foo", which= is known to
> use OAuth as authentication (or e.g. "foo+oauth", if this sh= ould be
> decided on per-connection basis)
> 2.: Client and server perform successful WS handshake
> 3.: Server sends token and authority URL in a WS message.
> 4.: Client gets token authorized
> 5.: Client sends authorized token back in a WS message.
> 6.: Server confirms that authorisation was successful.
> 7.: Client and server exchange messages as specified by "foo"= ;.
>
> Am 29.07.2011 02:44, schrieb Greg Wilkins:
>> All,
>>
>> Currently the protocol allows arbitrary headers, so in theory an >> authentication mechanism like OAUTH could be implemented by exchan= ging
>> tokens in the headers of the handshake. =A0 =A0But the js API does= not
>> allow an application to set or see HTTP header from the handshake = (nor
>> should it), so that is not available as a general mechanism for to= ken
>> passing auth like OAUTH.
>>
>> So what other options do we have to pass tokens in the handshake?<= br> >>
>> Cookies - this is possible, but kind of defeats the purpose of =A0= token
>> passing auth if tokens are to be sent/set in a way that facilitate= s
>> wider access to them.
>>
>> Extensions - we could say that an OAUTH extensions is required to<= br> >> manipulate the headers of the handshake with OAUTH tokens, but I >> expect that there will be a very high barrier for an extension to = be
>> included in browsers, so I think that is probably a non starter (a= t
>> least until a defacto-standard auth mechanism emerges).
>>
>> Subprotocol/CloseEvents - Subprotocol is a user controlled field s= ent
>> by the handshake and closeEvents contain a reason string that coul= d
>> originate from the server application/framework. =A0 =A0 Thus I wo= uld not
>> be surprised to see these fields used (misused?) to send challenge= s
>> and pass tokens eg.
>>
>> =A01. Client connects to server with oauth subprotocol.
>> =A02. Server accepts connection but immediately closes with a reas= on
>> string containing a token and/or authority URL. ( might be able to= be
>> done with a 403 HTTP response if the HTTP reason string is passed = to
>> the onerror call back ?? ]
>> =A03. Client gets the token signed by an/the authority
>> =A04. Client connections to server with oauth;token=3Dvalue subpro= tocol
>> =A05. Server validates authorisation of token and accepts connecti= on.
>>
>> [ forgive me if that is not exactly how oauth works or correct
>> terminology ... but it is something like that ]
>>
>> Is this a good usage of the subprotocol field/reason fields?
>>
>> Is there a better way to integrate such authentication into the ha= ndshake?
>>
>>
>> cheers
>> _______________________________________________
>> hybi mailing list
>> hybi@ietf.org
>> https://www.ietf.org/mailman/listinfo/hybi
>
>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--00151758b03472b9b604aa54c7e5-- From ibc@aliax.net Fri Aug 12 15:27: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 6FDAE21F874A for ; Fri, 12 Aug 2011 15:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sF83u+6uuF-5 for ; Fri, 12 Aug 2011 15:27:40 -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 D626721F86DC for ; Fri, 12 Aug 2011 15:27:39 -0700 (PDT) Received: by qyk35 with SMTP id 35so2005239qyk.10 for ; Fri, 12 Aug 2011 15:28:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr1023511qcb.178.1313188097843; Fri, 12 Aug 2011 15:28:17 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Fri, 12 Aug 2011 15:28:17 -0700 (PDT) In-Reply-To: References: <4E320640.2080408@gmail.com> Date: Sat, 13 Aug 2011 00:28:17 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Brian Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Supporting OAUTH-like authentication? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:27:40 -0000 2011/8/12 Brian : > This seems like a discussion for the JS API to me. =C2=A0The protocol spe= c > already explicitly allows arbitrary HTTP headers to be both sent and > received by the WebSocket server and client, if I recall correctly. =C2= =A0The > only thing preventing usage of this feature is a limitation in the > JavaScript API. =C2=A0I don't think there's any reason to disallow arbitr= ary > headers being set on the WS handshake using exactly the same > mechanism/restrictions as we do today for XHR. > But what does that have to do with HyBi? This is like asking "what does Digest authentication have to do with SIP protocol?", or "what does _XMPP_authentication_mechanism_ have to do with XMPP protocol?". Maybe you prefer to see WebSocket as a "transport" protocol, but it's an application protocol, and it's not crazy *at all* to expect that an application protocol implements an authentication mechanism. But probably, given the ugly HTTP jungle, many people from HTTP world assume that authentication must exist in user layer, based on ugly HTML forms which require rendering a web page in the client. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Aug 12 15:38: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 10BBE21F8639 for ; Fri, 12 Aug 2011 15:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.653 X-Spam-Level: X-Spam-Status: No, score=-2.653 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ4ztVLTDCRP for ; Fri, 12 Aug 2011 15:38:57 -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 3339221F85AC for ; Fri, 12 Aug 2011 15:38:57 -0700 (PDT) Received: by qyk34 with SMTP id 34so29171qyk.10 for ; Fri, 12 Aug 2011 15:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.101.137 with SMTP id c9mr1022345qco.102.1313188773551; Fri, 12 Aug 2011 15:39:33 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Fri, 12 Aug 2011 15:39:33 -0700 (PDT) In-Reply-To: <4E320640.2080408@gmail.com> References: <4E320640.2080408@gmail.com> Date: Sat, 13 Aug 2011 00:39:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Philipp Serafin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi , Greg Wilkins Subject: Re: [hybi] Supporting OAUTH-like authentication? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Aug 2011 22:38:58 -0000 2011/7/29 Philipp Serafin : > Wouldn't it be better to move the token exchange into the actual WS > connection where we have efficient two-way communication available? > > 1.: Client connects to server using subprotocol "foo", which is known to > use OAuth as authentication (or e.g. "foo+oauth", if this should be > decided on per-connection basis) I don't like point 1 (due to same reason given by Greg in next mail). > 2.: Client and server perform successful WS handshake > 3.: Server sends token and authority URL in a WS message. > 4.: Client gets token authorized > 5.: Client sends authorized token back in a WS message. > 6.: Server confirms that authorisation was successful. > 7.: Client and server exchange messages as specified by "foo". Let me propose another approach: 1.: Client connects to server using subprotocol "foo". Client does NOT know which authentication the server requires (neither if the server does require authentication or not). Please don't assume that a specific WS subprotocol always requires the same authentication mechanism. It's the server who must decide it at any time. 2.: Client and server perform successful WS handshake. The server requires (in this case) Digest authentication so the 101 response contains a *standard* header defined in WS core draft: Sec-WebSocket-Authenticate: Digest realm=3D"domain.org", nonce=3D"4e45a9e60000856cac2a6dd2e4edeba1a83e2ceb7137c3d0", qop=3D"auth" 3.: Client supports Digest authentication so it taken the username/passwd from somewhere (WS-API) and starts speaking "auth+digest" WS subprotocol (which should be defined in some RFC). 4.: So client sends a WS message containing the computed Digest credentials= . 5.: Server confirms that authorisation was successful in a WS reply. 6.: Client and server exchange messages as specified by subprotocol "foo". Now replace Digest with OAUTH or whatever. Of course, all those authentication mechanism should be standarized by different RFC's to be used in WS. Each one would involve a defined WS subprotocol ("auth+digest", "auth+oauth"). A WS server could reply more than one Sec-WebSocket-Authenticate header (one with "Digest" and another one with "OAUTH") in case it supports both, so the client could choose which one to use. --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Fri Aug 12 23:20: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 A7CA621F86D6 for ; Fri, 12 Aug 2011 23:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPtX3WdRkJk3 for ; Fri, 12 Aug 2011 23:20:45 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id 6C5E921F86D2 for ; Fri, 12 Aug 2011 23:20:43 -0700 (PDT) Received: (qmail 21003 invoked from network); 13 Aug 2011 06:21:15 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 13 Aug 2011 06:21:15 -0000 Received: (qmail 11376 invoked by uid 99); 13 Aug 2011 06:21:15 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.160.228.119 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110812232114.ef1fc80126c74c6c202a919c41c7bb0b.8906011163.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Fri, 12 Aug 2011 23:21:14 -0700 Mime-Version: 1.0 Subject: [hybi] Consensus Call Response X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 06:20:45 -0000 On the "Consensus Call" relating to frame size declarations:=0A=0AI am in f= avor of Option 2: "retain error code: frame too large", add=0Amechanism to = declare maximum frame size.=0A=0AIn the interest of clarity in vote tabulat= ion, I will post my reasoning=0Aseparately later this weekend.=0A=0A- Bob G= ezelter, http://www.rlgsc.com=0A From andy@warmcat.com Sat Aug 13 01:37: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 0698F21F854D for ; Sat, 13 Aug 2011 01:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.213 X-Spam-Level: X-Spam-Status: No, score=-2.213 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nq9miXYMHrIA for ; Sat, 13 Aug 2011 01:37:01 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 378DE21F8541 for ; Sat, 13 Aug 2011 01:37:01 -0700 (PDT) Message-ID: <4E4637D0.2030500@warmcat.com> Date: Sat, 13 Aug 2011 09:37:36 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> In-Reply-To: <4E455919.3080101@callenish.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Frame too big not possible to occur X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 08:37:02 -0000 On 08/12/2011 05:47 PM, Somebody in the thread at some point said: > On 12/08/2011 5:51 AM, Tobias Oberstein wrote: >>>> one problem is: value is fixed for lifetime of session .. can't be >>>> dynamic/adaptive >>> Why should it be adaptative? >> example: a muxing extension wants to dynamically adjust it's frame size >> depending on up/downlink bandwidth/delay to target a tradeoff between >> latency/efficiency. > > Size limits on extensions have nothing to do with limitations of the > underlying implementation. Why do people keep conflating the two issues? Because emails keep coming which look like they confused the general and common limitation on message length found in every real browser, and frame processing. We are after all talking about an error calling itself *frame* too big, which is not possible --> Because frame processing is performed packet by packet, with the single exception of this proposed frame signing extension, actually the frame layer just deals with a packet at a time. In the case of the exception, since he always has a peer extension of the same type negotiated, that peer extension can fragment frames to satisfy the extension buffering limitation. So, there's *nothing* in the frame layer that can run up against the concept of "frame too big", it just means more packets can be expected to continue the next frame, a packet at a time. And yet, we discuss an error and a whole proposed mtu workaround mechanism for the base spec dealing with the concept of "*frame* too big". "Message too big" is a genuine issue that can only be dealt with by hanging up the connection. Using the controlled close stuff with a reason code sounds like what should happen then. And nothing stops the peer deciding that the message has gotten too big dynamically, eg, on malloc fail for the next chunk or some variable limit without any negotiation action needed. That reflects the reality that the peer may indeed dynamically find itself in an OOM situation and have to close what it otherwise intended to accept randomly. -Andy From ibc@aliax.net Sat Aug 13 05:06: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 4939B21F882E for ; Sat, 13 Aug 2011 05:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=-0.276, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+UiGmjS0Xb1 for ; Sat, 13 Aug 2011 05:06:17 -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 4AEC421F881C for ; Sat, 13 Aug 2011 05:06:17 -0700 (PDT) Received: by qyk34 with SMTP id 34so191835qyk.10 for ; Sat, 13 Aug 2011 05:06:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr1264810qci.254.1313237216691; Sat, 13 Aug 2011 05:06:56 -0700 (PDT) Received: by 10.229.234.65 with HTTP; Sat, 13 Aug 2011 05:06:56 -0700 (PDT) Date: Sat, 13 Aug 2011 14:06:56 +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] Proposal for extensible authentication framework X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 12:06:18 -0000 Hi, I copy&paste this text I've replied in other thread as it could become a different concept (it not just about OAUTH authentication, but about anyone). It is a proposal (for sure it must be improved/corrected) for including a *standard* extensible authentication mechanism in WebSocket protocol. I explain it with an example: 1.: Client connects to server using subprotocol "foo". Client does NOT know which authentication the server requires (neither if the server does require authentication or not). Please don't assume that a specific WS subprotocol always requires the same authentication mechanism. It's the server who must decide it at any time. 2.: Client and server perform successful WS handshake. The server requires (in this case) Digest authentication so the 101 response contains a *standard* header defined in WS core draft (or in other separate draft): Sec-WebSocket-Authenticate: Digest realm=3D"domain.org", nonce=3D"4e45a9e60000856cac2a6dd2e4edeba1a83e2ceb7137c3d0", qop=3D"auth" 3.: Client supports Digest authentication so it takes the username/passwd from somewhere (WS-API stuff), computes the Digest response and starts speaking "auth+digest" WS subprotocol (which should be defined in some RFC). 4.: So client sends a WS message containing the computed Digest credentials= . 5.: Server confirms that authorization was successful in a WS reply. 6.: Client and server exchange messages as specified by subprotocol "foo". Now replace Digest with OAUTH or whatever. Of course, all those authentication mechanism should be standarized by different RFC's to be used in WS. Each one would involve a defined WS subprotocol ("auth+digest", "auth+oauth"). A WS server could reply more than one Sec-WebSocket-Authenticate header (i.e: one with "Digest" and another one with "OAUTH") in case it supports both, so the client could choose which one to use. The point here is that, even if during the WebSocket handshake the WS subprotocol "foo" is negotiated, the presence of a Sec-WebSocket-Authenticate header in the 101 response implies that before speaking "foo", the client must authenticate using the mechanism in such received header (or one of them if there are N headers). This is, before speaking "foo" subprotocol, the client MUST speak "auth+digest" or "auth+oauth" or whatever. A doubt coming to my mind is: if there are two Sec-WebSocket-Authenticate headers (offering Digest and OAUTH) and the client chooses OAUTH (so starts speaking "auth+oauth"), how would the server realize that the first WS message is "auth+digest" or "auth+oauth"? AFAIK such information is not carried within WS messages (but just during handshake). A proposal for this last subject: the "auth" protocol could be standard, and the chosen mechanism would be indicated in a WS message within "auth" protocol (along with the rest of fields required for each authentication mechanism). "auth" WS messages could be, for example, a JSON object like: "auth": { "mechanism": "Digest", "data": { "username": "alice", "nonce": "aksdhakjdshakjs"; "response": "aksdh89akjhsdke", "qop": 1 } } This is, "data" object structure would depend on the chosen "mechanism". Opinions? --=20 I=C3=B1aki Baz Castillo From hannes.tschofenig@gmx.net Sat Aug 13 07:59: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 9408721F8713 for ; Sat, 13 Aug 2011 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.129 X-Spam-Level: X-Spam-Status: No, score=-102.129 tagged_above=-999 required=5 tests=[AWL=-0.430, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G2kuZIQn+NpN for ; Sat, 13 Aug 2011 07:59:44 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 6257621F86F6 for ; Sat, 13 Aug 2011 07:59:44 -0700 (PDT) Received: (qmail invoked by alias); 13 Aug 2011 15:00:22 -0000 Received: from letku214.adsl.netsonic.fi (EHLO [10.0.0.6]) [194.29.195.214] by mail.gmx.net (mp027) with SMTP; 13 Aug 2011 17:00:22 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX181kGQAnXM14LKdLIb8IuT8tB8zhYb41ibV7ncuQp VFMPNO1WdnpF1w Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Hannes Tschofenig In-Reply-To: Date: Sat, 13 Aug 2011 18:00:20 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] Proposal for extensible authentication framework X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Aug 2011 14:59:45 -0000 Take a look at=20 http://tools.ietf.org/html/draft-williams-rest-gss-00 and see whether this fits your needs of an extensible authentication = framework. Ciao Hannes PS: OAuth is btw not protocol that authenticates the end user. Instead = the handshake allows the end user to authorize the subsequent exchange = of data.=20 On Aug 13, 2011, at 3:06 PM, I=F1aki Baz Castillo wrote: > Hi, I copy&paste this text I've replied in other thread as it could > become a different concept (it not just about OAUTH authentication, > but about anyone). >=20 > It is a proposal (for sure it must be improved/corrected) for > including a *standard* extensible authentication mechanism in > WebSocket protocol. I explain it with an example: >=20 >=20 > 1.: Client connects to server using subprotocol "foo". Client does NOT > know which authentication the server requires (neither if the server > does require authentication or not). Please don't assume that a > specific WS subprotocol always requires the same authentication > mechanism. It's the server who must decide it at any time. >=20 > 2.: Client and server perform successful WS handshake. The server > requires (in this case) Digest authentication so the 101 response > contains a *standard* header defined in WS core draft (or in other > separate draft): >=20 > Sec-WebSocket-Authenticate: Digest realm=3D"domain.org", > nonce=3D"4e45a9e60000856cac2a6dd2e4edeba1a83e2ceb7137c3d0", > qop=3D"auth" >=20 > 3.: Client supports Digest authentication so it takes the > username/passwd from somewhere (WS-API stuff), computes the Digest > response and starts speaking > "auth+digest" WS subprotocol (which should be defined in some RFC). >=20 > 4.: So client sends a WS message containing the computed Digest = credentials. >=20 > 5.: Server confirms that authorization was successful in a WS reply. >=20 > 6.: Client and server exchange messages as specified by subprotocol = "foo". >=20 >=20 >=20 > Now replace Digest with OAUTH or whatever. Of course, all those > authentication mechanism should be standarized by different RFC's to > be used in WS. Each one would involve a defined WS subprotocol > ("auth+digest", "auth+oauth"). >=20 > A WS server could reply more than one Sec-WebSocket-Authenticate > header (i.e: one with "Digest" and another one with "OAUTH") in case = it > supports both, so the client could choose which one to use. >=20 > The point here is that, even if during the WebSocket handshake the WS > subprotocol "foo" is negotiated, the presence of a > Sec-WebSocket-Authenticate header in the 101 response > implies that before speaking "foo", the client must authenticate using > the mechanism in such received header (or one of them if there are N > headers). This is, before speaking "foo" subprotocol, the client MUST > speak "auth+digest" or "auth+oauth" or whatever. >=20 > A doubt coming to my mind is: if there are two > Sec-WebSocket-Authenticate headers (offering Digest and OAUTH) and the > client chooses OAUTH (so starts speaking "auth+oauth"), how would the > server realize that the first WS message is "auth+digest" or > "auth+oauth"? AFAIK such information is not carried within WS messages > (but just during handshake). >=20 > A proposal for this last subject: the "auth" protocol could be > standard, and the chosen mechanism would be indicated in a WS message > within "auth" protocol (along with the rest of fields required for > each authentication mechanism). "auth" WS messages could be, for > example, a JSON object like: >=20 > "auth": { > "mechanism": "Digest", > "data": { > "username": "alice", > "nonce": "aksdhakjdshakjs"; > "response": "aksdh89akjhsdke", > "qop": 1 > } > } >=20 > This is, "data" object structure would depend on the chosen = "mechanism". >=20 > Opinions? >=20 >=20 > --=20 > I=F1aki Baz Castillo > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From alexey.melnikov@isode.com Sun Aug 14 11:53:36 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 9E45921F86EE for ; Sun, 14 Aug 2011 11:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.509 X-Spam-Level: X-Spam-Status: No, score=-102.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bzj1cW2+9vyN for ; Sun, 14 Aug 2011 11:53:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 0045A21F86DD for ; Sun, 14 Aug 2011 11:53:35 -0700 (PDT) Received: from [188.28.0.188] (188.28.0.188.threembb.co.uk [188.28.0.188]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Sun, 14 Aug 2011 19:54:18 +0100 Message-ID: <4E47FDB5.6070207@isode.com> Date: Sun, 14 Aug 2011 17:54:13 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.21) Gecko/20090303 SeaMonkey/1.1.15 To: Server-Initiated HTTP MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Removing Sec-WebSocket-Origin header field from the WebSocket document 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, 14 Aug 2011 18:53:36 -0000 Hi, Richard Barnes who did Gen-Art team review of the protocol document asked the following question: Why is this document creating a separate Sec-WebSocket-Origin header, rather than using the Origin header from draft-ietf-websec-origin? I've asked several people and nobody could tell me why the document is defining a new header field. So unless I hear some objection/explanation of why an additional header field is useful, it will be removed in -11. Thank you, Alexey, on behalf of editors of the document. From jat@google.com Sun Aug 14 12:15: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 7666921F85C6 for ; Sun, 14 Aug 2011 12:15:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.943 X-Spam-Level: X-Spam-Status: No, score=-105.943 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY4KQC7Oc4rR for ; Sun, 14 Aug 2011 12:15: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 B55BC21F853E for ; Sun, 14 Aug 2011 12:15:25 -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 p7EJG6Ut022072 for ; Sun, 14 Aug 2011 12:16:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313349366; bh=pZEONARqNSbaJ0B4VGP/xTAAtZM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VdCD1EVB0e680Eo9XyMqxY3MsYRUEL7k1demzAUTFbdhgHHUh7bavGLQgMALabhDi xsAQlzOJjlF7qehCksYZQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=p4bUqxZYIuYxaNldNrJ8EIJeXSp6Q2GHcCnnFdM8ALOnvtUth3XhjG8sWVo2O0Tbt gW8HPSbC3iM8/I5Ilxs/A== Received: from ywp17 (ywp17.prod.google.com [10.192.16.17]) by wpaz29.hot.corp.google.com with ESMTP id p7EJG5lF032655 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 14 Aug 2011 12:16:05 -0700 Received: by ywp17 with SMTP id 17so2967960ywp.8 for ; Sun, 14 Aug 2011 12:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=0q32AreaBIfc4cjf1bwiRBGPbGjJOPrE3d4xd9ILRhY=; b=lhyEZcNlAkaYDp9GEEK9SL2EZCre0nY4KnD5CmgSqvyD64TDv/nTc+/CXmhDL/bFsv rfBubmqC7vO8gHC9HGVQ== Received: by 10.151.118.20 with SMTP id v20mr4352158ybm.401.1313349365387; Sun, 14 Aug 2011 12:16:05 -0700 (PDT) Received: by 10.151.118.20 with SMTP id v20mr4352151ybm.401.1313349365171; Sun, 14 Aug 2011 12:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Sun, 14 Aug 2011 12:15:45 -0700 (PDT) In-Reply-To: <4E47FDB5.6070207@isode.com> References: <4E47FDB5.6070207@isode.com> From: John Tamplin Date: Sun, 14 Aug 2011 15:15:45 -0400 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001e680f09fc60871804aa7bfadb X-System-Of-Record: true Cc: Server-Initiated HTTP Subject: Re: [hybi] Removing Sec-WebSocket-Origin header field from the WebSocket document 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, 14 Aug 2011 19:15:30 -0000 --001e680f09fc60871804aa7bfadb Content-Type: text/plain; charset=UTF-8 On Sun, Aug 14, 2011 at 12:54 PM, Alexey Melnikov wrote: > Richard Barnes who did Gen-Art team review of the protocol document asked > the following question: > > Why is this document creating a separate Sec-WebSocket-Origin header, > rather than using the Origin header from draft-ietf-websec-origin? > > I've asked several people and nobody could tell me why the document is > defining a new header field. So unless I hear some objection/explanation of > why an additional header field is useful, it will be removed in -11. > My understanding is that the Sec-* headers were used because they cannot be set on arbitrary XHR requests by hostile Javascript, thus helping prevent spoofing of WS connections. -- John A. Tamplin Software Engineer (GWT), Google --001e680f09fc60871804aa7bfadb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 14, 2011 at 12:54 PM, Alexey Melniko= v <alexey= .melnikov@isode.com> wrote:
Subject: Re: [hybi] Removing Sec-WebSocket-Origin header field from the WebSocket document 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, 14 Aug 2011 19:26:52 -0000 This is a multi-part message in MIME format. --------------000403080302050008020705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 14.08.2011 21:15, schrieb John Tamplin: > On Sun, Aug 14, 2011 at 12:54 PM, Alexey Melnikov > > wrote: > > Richard Barnes who did Gen-Art team review of the protocol > document asked the following question: > > Why is this document creating a separate Sec-WebSocket-Origin > header, rather than using the Origin header from > draft-ietf-websec-origin? > > I've asked several people and nobody could tell me why the > document is defining a new header field. So unless I hear some > objection/explanation of why an additional header field is useful, > it will be removed in -11. > > > My understanding is that the Sec-* headers were used because they > cannot be set on arbitrary XHR requests by hostile Javascript, thus > helping prevent spoofing of WS connections. > Would that really be a security issue? On XHR implementations that support CORS, neither can the Origin header be spoofed. Old implementations without CORS support only permit same-origin requests. I'd think if an attacker can inject JS code into pages of the victim's origin, spoofed WS connections are probably the least concern. > -- > John A. Tamplin > Software Engineer (GWT), Google > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------000403080302050008020705 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 14.08.2011 21:15, schrieb John Tamplin:
On Sun, Aug 14, 2011 at 12:54 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
Richard Barnes who did Gen-Art team review of the protocol document asked the following question:

 Why is this document creating a separate Sec-WebSocket-Origin header, rather than using the Origin header from draft-ietf-websec-origin?

I've asked several people and nobody could tell me why the document is defining a new header field. So unless I hear some objection/explanation of why an additional header field is useful, it will be removed in -11.

My understanding is that the Sec-* headers were used because they cannot be set on arbitrary XHR requests by hostile Javascript, thus helping prevent spoofing of WS connections. 

Would that really be a security issue?

On XHR implementations that support CORS, neither can the Origin header be spoofed.
Old implementations without CORS support only permit same-origin requests. I'd think if an attacker can inject JS code into pages of the victim's origin, spoofed WS connections are probably the least concern.

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


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

--------------000403080302050008020705-- From gregw@intalio.com Sun Aug 14 17:08: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 E735A21F85FE for ; Sun, 14 Aug 2011 17:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.913 X-Spam-Level: X-Spam-Status: No, score=-2.913 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qiah0Y-o1WrL for ; Sun, 14 Aug 2011 17:08:53 -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 D7DC521F85F7 for ; Sun, 14 Aug 2011 17:08:52 -0700 (PDT) Received: by vxi29 with SMTP id 29so4443720vxi.31 for ; Sun, 14 Aug 2011 17:09:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.52 with SMTP id dh20mr1567333vdb.296.1313366976523; Sun, 14 Aug 2011 17:09:36 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Sun, 14 Aug 2011 17:09:36 -0700 (PDT) In-Reply-To: <4E482192.7050507@gmail.com> References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> Date: Mon, 15 Aug 2011 10:09:36 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Removing Sec-WebSocket-Origin header field from the WebSocket document 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, 15 Aug 2011 00:08:54 -0000 On 15 August 2011 05:27, Philipp Serafin wrote: > My understanding is that the Sec-* headers were used because they cannot be > set on arbitrary XHR requests by hostile Javascript, thus helping prevent > spoofing of WS connections. > > Would that really be a security issue? Also note that we don't need Sec-* on all headers in the handshake request. We only need to require Sec- on 1 mandatory header and that should be sufficient to prevent spoofing. The key exchange header fits that bill, so I don't see why we need it on Origin. After all we are not sending a Sec-Upgrade header! cheers From gregw@intalio.com Sun Aug 14 17:44:05 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 9871021F8785 for ; Sun, 14 Aug 2011 17:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnmhBegxW0aq for ; Sun, 14 Aug 2011 17:44:05 -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 57BA721F8782 for ; Sun, 14 Aug 2011 17:44:00 -0700 (PDT) Received: by vws12 with SMTP id 12so4499855vws.31 for ; Sun, 14 Aug 2011 17:44:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.21.201 with SMTP id x9mr3155957vde.363.1313369084175; Sun, 14 Aug 2011 17:44:44 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Sun, 14 Aug 2011 17:44:44 -0700 (PDT) Date: Mon, 15 Aug 2011 10:44:44 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [hybi] Interleaved frames and x-google-mux 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, 15 Aug 2011 00:44:05 -0000 Moving this discuss here from google doc comments on https://docs.google.com/document/d/14DYRxmRTPVhV1GbVXlxg8KVrS1SEq4UhCNq6q8i= NOws/edit?hl=3Den&ndplr=3D1&pli=3D1 The comments said: > Now that the websocket spec allows fragments of one message to be > interleaved with fragments of another, are MUX blocks required? > Can=92t each ws frame be a mux block? We already have the restriction t= hat > fragmentation can only be done if the extensions are known and understood= . > =97gregory.j.wilkins > Where does the WS spec allow this? How do you distinguish which > message a fragment is for if you allowed interleaving fragments from > different messages? > --jat The specification now allows extensions to interleave messages - in section 4.4 it says: o The fragments of one message MUST NOT be interleaved between the fragments of another message unless an extension has been negotiated that can interpret the interleaving. Thus I think it would be a significant simplification of the mux proposal to remove the MUX block layer and directly use websocket frames. The current x-google-mux proposal has websocket frames (opcode 0x7) wrapping MUX block frames which then wrap more websocket frames (which may themselves contain more MUX blocks wrapping more websocket frames). With frame interleaving, we can avoid this nested/recursive framing and instead just use extension data in the normal framing to add a mux opcode and mux channel id. I think the rest of the semantics can then follow more or less as outlined in the proposal. Are there any other reasons to maintain MUX blocks? regards From jat@google.com Sun Aug 14 18:01: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 D256A11E80A6 for ; Sun, 14 Aug 2011 18:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.935 X-Spam-Level: X-Spam-Status: No, score=-105.935 tagged_above=-999 required=5 tests=[AWL=0.041, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+8Cfn5rj-P3 for ; Sun, 14 Aug 2011 18:01:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id E676E11E80A0 for ; Sun, 14 Aug 2011 18:01:14 -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 p7F11vam018950 for ; Sun, 14 Aug 2011 18:01:57 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313370118; bh=KaqgSldxP5CnJkCA3cTjGJzlWhA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Ki3MGAUHBUuOUseRcbnCgppuFkIi3Tc3Q0mj9LBdpxTozJDLFAJnJXecaMsITTJI9 XxaP+y8H1kfdpil0Xxkkg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=P3CqsJRbH+nZkfsz75sd1B/32U8q3KITeh8YFgOxZTNAIZB42VCDuTongjT5A4JEf QKTMSikBozNU9QBlEjlPg== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by wpaz13.hot.corp.google.com with ESMTP id p7F11uQX008940 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 14 Aug 2011 18:01:56 -0700 Received: by gxk2 with SMTP id 2so3146808gxk.36 for ; Sun, 14 Aug 2011 18:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bRD+6cIiBlemscch6lN2X5S/axOXlLsrr4VgN23BnSs=; b=OHvkY4oP1pIvcQSM+Hk+22TzzFfoUdf500k7Ukc+n3l6ZWBLxbfa6Vq/wywJ2j6/9A 9k3gIKRxL+U32vrK+uKQ== Received: by 10.151.114.20 with SMTP id r20mr4254214ybm.2.1313370116328; Sun, 14 Aug 2011 18:01:56 -0700 (PDT) Received: by 10.151.114.20 with SMTP id r20mr4254210ybm.2.1313370116197; Sun, 14 Aug 2011 18:01:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Sun, 14 Aug 2011 18:01:36 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Sun, 14 Aug 2011 21:01:36 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=00151750e5543c0c7804aa80cf24 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Interleaved frames and x-google-mux 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, 15 Aug 2011 01:01:15 -0000 --00151750e5543c0c7804aa80cf24 Content-Type: text/plain; charset=UTF-8 On Sun, Aug 14, 2011 at 8:44 PM, Greg Wilkins wrote: > The specification now allows extensions to interleave messages - in > section 4.4 it says: > o The fragments of one message MUST NOT be interleaved between the > fragments of another message unless an extension has been negotiated that can interpret the interleaving. Hmm, I didn't notice that going into the spec, and I am not sure that is a good idea. Now, an intermediary that doesn't understand all the negotiated extensions can't even identify message boundaries. I thought this was one of the reasons you were so unhappy with deflate-stream, that it obscured message boundaries to those who didn't understand the extension. > Thus I think it would be a significant simplification of the mux > proposal to remove the MUX block layer and directly use websocket > frames. > > The current x-google-mux proposal has websocket frames (opcode 0x7) > wrapping MUX block frames which then wrap more websocket frames (which > may themselves contain more MUX blocks wrapping more websocket > frames). > > With frame interleaving, we can avoid this nested/recursive framing > and instead just use extension data in the normal framing to add a mux > opcode and mux channel id. I think the rest of the semantics can then > follow more or less as outlined in the proposal. > > Are there any other reasons to maintain MUX blocks? > You would have to do more than that, as there are other things being sent, for example flow control information and add/drop channel messages. Using a separate frame to transfer that information makes it significantly more expensive, since you are paying the header (including mask) cost for those. You would still need a sub-opcode, since we didn't put that into the base spec we can't afford to use multiple opcodes for MUX. So, I am not sure the value of simplifying the structure justifies the cost. Other than that, I agree that it could be changed as you suggest. -- John A. Tamplin Software Engineer (GWT), Google --00151750e5543c0c7804aa80cf24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Aug 14, 2011 at 8:44 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:=C2=A0=C2=A0
The specification n= ow allows extensions to interleave messages - in
section 4.4 it says:
=C2=A0 o =C2= =A0The fragments of one message MUST NOT be interleaved between the
=C2=A0 =C2=A0 = =C2=A0fragments of another message unless an extension has been=C2= =A0
=C2=A0 =C2=A0 =C2= =A0negotiated that can interpret the interleaving.
=
Hmm, I didn't notice that going into the spec, and I am = not sure that is a good idea. =C2=A0Now, an intermediary that doesn't u= nderstand all the negotiated extensions can't even identify message bou= ndaries.

I thought this was one of the reasons you were so unhap= py with deflate-stream, that it obscured message boundaries to those who di= dn't understand the extension.
=C2=A0
Thus I think it would be a significant simplification of the mux
proposal to remove the MUX block layer and directly use websocket
frames.

The current x-google-mux proposal has websocket frames (opcode 0x7)
wrapping MUX block frames which then wrap more websocket frames (which
may themselves contain more MUX blocks wrapping more websocket
frames).

With frame interleaving, we can avoid this nested/recursive framing
and instead just use extension data in the normal framing to add a mux
opcode and mux channel id. =C2=A0I think the rest of the semantics can then=
follow more or less as outlined in the proposal.

Are there any other reasons to maintain MUX blocks?
You would have to do more than that, as there are other things= being sent, for example flow control information and add/drop channel mess= ages. =C2=A0Using a separate frame to transfer that information makes it si= gnificantly more expensive, since you are paying the header (including mask= ) cost for those. =C2=A0You would still need a sub-opcode, since we didn= 9;t put that into the base spec we can't afford to use multiple opcodes= for MUX. =C2=A0So, I am not sure the value of simplifying the structure ju= stifies the cost.


--
John A. Tamplin
Software Engineer (GWT)= , Google
--00151750e5543c0c7804aa80cf24-- From gregw@intalio.com Sun Aug 14 19:47: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 724FB21F862F for ; Sun, 14 Aug 2011 19:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LohQyj9TNJS for ; Sun, 14 Aug 2011 19:47:22 -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 B59CA21F8515 for ; Sun, 14 Aug 2011 19:47:22 -0700 (PDT) Received: by vxi29 with SMTP id 29so4505348vxi.31 for ; Sun, 14 Aug 2011 19:48:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.201 with SMTP id dm9mr2987829vdb.95.1313376486799; Sun, 14 Aug 2011 19:48:06 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Sun, 14 Aug 2011 19:48:06 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 12:48:06 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Interleaved frames and x-google-mux 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, 15 Aug 2011 02:47:23 -0000 On 15 August 2011 11:01, John Tamplin wrote: > On Sun, Aug 14, 2011 at 8:44 PM, Greg Wilkins wrote: >> >> The specification now allows extensions to interleave messages - in >> section 4.4 it says: >> =A0 o =A0The fragments of one message MUST NOT be interleaved between th= e >> =A0 =A0 =A0fragments of another message unless an extension has been >> >> =A0 =A0 =A0negotiated that can interpret the interleaving. > > Hmm, I didn't notice that going into the spec, and I am not sure that is = a > good idea. =A0Now, an intermediary that doesn't understand all the negoti= ated > extensions can't even identify message boundaries. > I thought this was one of the reasons you were so unhappy with > deflate-stream, that it obscured message boundaries to those who didn't > understand the extension. An intermediary that does not understand the extensions negotiated is unlikely to be able to do anything meaningful with messages or messages boundaries. It certainly is not able to aggregate frames or fragment, as this is explicitly prohibited by the spec. It will still be able to identify frame boundaries and control frames, which would be useful for buffering/flushing purposes. > You would have to do more than that, as there are other things being sent= , > for example flow control information and add/drop channel messages. > Using a separate frame to transfer that information makes it significantl= y > more expensive, since you are paying the header (including mask) cost > for those. You would still need a sub-opcode, since we didn't put that i= nto > the base spec we can't afford to use multiple opcodes for MUX. I'm not sure I'd describe a 2 or 6 bytes frame overhead as a significant cost. The most frequent control messages will be the flow control ones. If traffic is mostly 1 way then the back channel is mostly idle and sending any data < the networks MTU is approximately equal cost. If the traffic is two way, then there is lots of data in the back channel and 2/6 bytes extra will represent a very small fraction of that. OK this is a simplistic analysis, but is there really concern about 2/6 byte frame overhead on control frames? > So, I am not sure the value of simplifying the structure justifies the c= ost. For my implementations, the cost is definitely justified. The WS frame inside a MUX block inside a WS frame is a significant complication in the infrastructure. It would not be so bad if it was just framing, as I could simply reuse WS parsers/generators. For me the issue is that the nested WS framing is a full WS infrastructure that can negotiate its own extensions, including another layer of MUX. Because MUX is achieved by wrapping frames rather than augmenting them, I would think that MUX inside MUX is highly likely to occur if there are multiple layers of aggregating devices (eg MUX in browser then MUX in proxy). So implementations and all the state associated with them would have to be fully recursive, which can be needlessly complicated, have lots of data copies and buffering and will make resource allocation/management very difficult. Consider the question - how many open channels are there in a server? To answer this is difficult because there would not be a single channel map of ID to channel. Instead there is a map of maps (of maps ...) with the leaves being channel IDs. Without the frame wrapping, MUX would have to augment existing frames. This would put a bit more responsibility onto MUXing intermediaries, as they would need to resolve streams that were already MUXed (eg in browser) and map incoming channel IDs to outgoing channel IDs. A server implementation would have a single map of channelID to channel, making resource accounting much simpler. I'd pay 2/6 bytes extra on a few control messages for this simplicity any d= ay! cheers From andy@warmcat.com Mon Aug 15 02:45: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 9882721F8B30 for ; Mon, 15 Aug 2011 02:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiCairKq41dJ for ; Mon, 15 Aug 2011 02:45:14 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 69C7A21F8B2E for ; Mon, 15 Aug 2011 02:45:14 -0700 (PDT) Message-ID: <4E48EAD3.3080904@warmcat.com> Date: Mon, 15 Aug 2011 10:45:55 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] Interleaved frames and x-google-mux 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, 15 Aug 2011 09:45:15 -0000 On 08/15/2011 03:48 AM, Somebody in the thread at some point said: > On 15 August 2011 11:01, John Tamplin wrote: >> On Sun, Aug 14, 2011 at 8:44 PM, Greg Wilkins wrote: >>> >>> The specification now allows extensions to interleave messages - in >>> section 4.4 it says: >>> o The fragments of one message MUST NOT be interleaved between the >>> fragments of another message unless an extension has been >>> >>> negotiated that can interpret the interleaving. >> >> Hmm, I didn't notice that going into the spec, and I am not sure that is a >> good idea. Now, an intermediary that doesn't understand all the negotiated >> extensions can't even identify message boundaries. >> I thought this was one of the reasons you were so unhappy with >> deflate-stream, that it obscured message boundaries to those who didn't >> understand the extension. To be fair that is effectively what x-google-mux is doing anyway, it's an extension which allows bits of different messages to be interleaved with each other. > An intermediary that does not understand the extensions negotiated is > unlikely to be able to do anything meaningful with messages or > messages boundaries. It certainly is not able to aggregate frames or > fragment, as this is explicitly prohibited by the spec. > > It will still be able to identify frame boundaries and control frames, > which would be useful for buffering/flushing purposes. I can't really imagine what an intermediary faced with a "roughly chopped message pate" it was unable to follow could really usefully do. If the control frames are in a subframe context, actually it can't follow those either since in the case it doesn't know the extension it doesn't know the subframe coding scheme of the extension either. Either it keeps seeing subframe close control frames coming and interprets them as main channel close or they're coded with a different control opcode or are not control opcodes then it doesn't even know any closing was happening. So it could only really pass stuff through AFAICS without even understanding subchannel lifecycle; the best you can say is it would be able to be transparent same as current scheme. >> You would have to do more than that, as there are other things being sent, >> for example flow control information and add/drop channel messages. >> Using a separate frame to transfer that information makes it significantly >> more expensive, since you are paying the header (including mask) cost >> for those. You would still need a sub-opcode, since we didn't put that into >> the base spec we can't afford to use multiple opcodes for MUX. > > I'm not sure I'd describe a 2 or 6 bytes frame overhead as a > significant cost. The most frequent control messages will be the > flow control ones. If traffic is mostly 1 way then the back channel > is mostly idle and sending any data< the networks MTU is > approximately equal cost. If the traffic is two way, then there is > lots of data in the back channel and 2/6 bytes extra will represent a > very small fraction of that. OK this is a simplistic analysis, but > is there really concern about 2/6 byte frame overhead on control > frames? > >> So, I am not sure the value of simplifying the structure justifies the cost. > > For my implementations, the cost is definitely justified. The WS I have to agree with Greg (and I believe Bob Gezelter was suggesting a similar simplified single header scheme months ago), as it is defined mux is a very complex to implement. This would simplify it a bit. However there are two separate issues suggested here: 1) Migrate mux block info inside a standard frame 2) 'Flatten' the mux so we just have frames in one dimension, not frames inside frames as currently > frame inside a MUX block inside a WS frame is a significant > complication in the infrastructure. It would not be so bad if it was > just framing, as I could simply reuse WS parsers/generators. For me You can reuse parsers and generators with John's existing scheme; I did it, they're just wrapped in another layer. You will lose the ability to mux mux parents aka "turtles all the way down". > the issue is that the nested WS framing is a full WS infrastructure > that can negotiate its own extensions, including another layer of MUX. > Because MUX is achieved by wrapping frames rather than augmenting > them, I would think that MUX inside MUX is highly likely to occur if > there are multiple layers of aggregating devices (eg MUX in browser > then MUX in proxy). So implementations and all the state associated > with them would have to be fully recursive, which can be needlessly > complicated, have lots of data copies and buffering and will make > resource allocation/management very difficult. That's not the problem I found implementing this. The problem was it became so intricately nested it was very hard to debug and quickly packet dumps became effectively white noise. When it doesn't "just work", you are quickly lost in a vast spew of logging. Removing the nesting concept (I recall an argument about if it is nested or not, so read it as "prepending with mux headers" if you like) and just using one dimension of framing should simplify that. Whether it's done with subopcode and subchannel tacked on to existing framing, or done with a "mux opcode" that has that is less critical. > Consider the question - how many open channels are there in a server? > To answer this is difficult because there would not be a single > channel map of ID to channel. Instead there is a map of maps (of maps > ...) with the leaves being channel IDs. Yeah ie, flatten the mux structure and disallow nesting. > Without the frame wrapping, MUX would have to augment existing frames. > This would put a bit more responsibility onto MUXing > intermediaries, as they would need to resolve streams that were > already MUXed (eg in browser) and map incoming channel IDs to outgoing > channel IDs. A server implementation would have a single map of > channelID to channel, making resource accounting much simpler. > > I'd pay 2/6 bytes extra on a few control messages for this simplicity any day! As I say I think you find where to put the subchannel and subopcode info is providing less simplification than flattening out the mux into a single flat stream of frames belonging to one subchannel or another. If getting rid of "the mux opcode" is worthwhile should be something we can figure out based on "bang for the byte". -Andy From tobias.oberstein@tavendo.de Mon Aug 15 03:52:47 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 218C621F8B16 for ; Mon, 15 Aug 2011 03:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.536 X-Spam-Level: X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I+lihDvepsq for ; Mon, 15 Aug 2011 03:52:46 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 5DA7A21F8B10 for ; Mon, 15 Aug 2011 03:52:46 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Mon, 15 Aug 2011 03:53:29 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Mon, 15 Aug 2011 03:52:52 -0700 Thread-Topic: Flat MUX Thread-Index: AcxbOFzbs0vQBC5sTBKveXfA+t8OBA== Message-ID: <634914A010D0B943A035D226786325D422BFBFC64E@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] Flat MUX 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, 15 Aug 2011 10:52:47 -0000 Here is a variant of muxing that=20 - does not wrap/nest complete WS connections (recursively) inside WS or reframe the payload of MUXed messages - does not require intermediaries to understand message interleaving or adjust it's fragmentation/coalescing logic - uses 1 reserved Opcode and 2 reserved bits The approach is to pack a MUXed message specific FIN bit into reserved bit = 2: RSV2 =3D MUX FIN 0 =3D non-final MUX message frame 1 =3D final MUX message frame On the base WS layer, all data is sent (by endpoints) using a new Opcode 0x= 8 and FIN =3D 1. The extension data of a Opcode 0x8 frame has the channel ID, which is an integer encoded the same as the payload length in base WS. The payload type of a muxed message (text or binary) is signaled in the first frame of the MUXed message RSV3 =3D MUX Payload Type (0 =3D binary, 1 =3D text) For a MUX continuation frame (MUX FIN =3D 0 after first frame) the RSV3 bit= is 0. An example of 2 MUXed messages interleaved (a text message on chn 23 and a binary message on chn 70): chn23, text: "data23_a-data23_b-data23_c-data23_d" chn70, binary: "data70_a-data70_b-data70_c" WS base layer frames: FIN, Opcode, RSV2 (MUX FIN), RSV3 (MUX Payload Type), Channel ID, Payload 1, 0x8, 0, 1, 23, "data23_a-" 1, 0x8, 0, 0, 70, "data70_a-" 1, 0x8, 0, 0, 70, "data70_b-" 1, 0x8, 0, 0, 23, "data23_b-" 1, 0x8, 1, 0, 70, "data70_c" 1, 0x8, 0, 0, 23, "data23_c-" 1, 0x8, 1, 0, 23, "data23_d" The reason to choose RSV 2 and 3 is to allow compatibility with the per-fra= me compression extension proposed by Takeshi which uses RSV 1 to signal whethe= r a frame is compressed or not. Since there is no interleaving on the base WS layer to understand, intermed= iaries don't get confused. Moreoever, since endpoints are required to send Mux messages unfragmented, intermediaries can fragment those (and subsequent intermediaries could coal= esce again). The receiving endpoint can just reassemble the fragments that make up a MUX= frame. Mux message frame sent by endpoint: 1, 0x8, 0, 0, 23, "data23_b-" Fragmented frames received by endpoint: 0, 0x8, 0, 0, 23, "dat" 0, 0x8, ?, ?, "a2" 1, 0x8, ?, ?, "3_b-" The intermediary can set the RSV bits of the fragments following the first = arbitrary. The receiver only cares about RSV for the first base WS frame of a Mux fram= e. The question of channel setup/teardown and channel credit replenishment signaling is somewhat orthogonal .. tbd. Is there a catch I missed? From ibc@aliax.net Mon Aug 15 05:30: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 02D6921F8B64 for ; Mon, 15 Aug 2011 05:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HfySaZCcfIS0 for ; Mon, 15 Aug 2011 05:30:03 -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 48FC321F8B61 for ; Mon, 15 Aug 2011 05:30:03 -0700 (PDT) Received: by qwc23 with SMTP id 23so3191827qwc.31 for ; Mon, 15 Aug 2011 05:30:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr1159283qcc.292.1313411446665; Mon, 15 Aug 2011 05:30:46 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 05:30:46 -0700 (PDT) Date: Mon, 15 Aug 2011 14:30:46 +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] Comments about draft 10 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, 15 Aug 2011 12:30:04 -0000 * Page 6: The "Request-URI" of the GET method [RFC2616] is used to identify the endpoint of the WebSocket connection, both to allow multiple domains to be served from one IP address and to allow multiple WebSocket endpoints to be served by a single server. 1) "The "Request-URI" of the GET method" is wrong. The RURI does not belong to the method but to the request itself so better: The "Request-URI" of the GET request 2) What does "both to allow multiple domains" mean there? It's just speaking about "Request-URI". I propose to re-phrase it as follows: The "Request-URI" and Host header of the GET request [RFC2616] are used to identify the endpoint of the WebSocket connection, both to allow mult= iple domains to be served from one IP address and to allow multiple WebSocket endpoints to be served by a single server. and remove the next paragraph (which says nothing new): The client includes the hostname in the Host header of its handshake as per [RFC2616], so that both the client and the server can verify that they agree on which host is in use. * Page 8: These fields are checked by the Web browser when it is acting as a |WebSocket| client for scripted pages. 1) AFAIK this is not just about Web browsers, but about any WebSocket client, right? Please, replace "Web browser" with "WebSocket client". 2) The notation of |WebSocket| (using "|" between the world) looks ugly (at least for me). I've not seen it in other drafts/RFC's. I would remove all those "|". * Page 8: Still is not clear at all how a client should react in case the 101 response has no Sec-WebSocket-Protocol header or it contains a protocol not present in the request. Example: - WS client sends GET request with "Sec-WebSocket-Protocol: chat" - Server replies 101 with: 1) Sec-WebSocket-Protocol: foo 2) Sec-WebSocket-Protocol: foo, chat 3) Sec-WebSocket-Protocol: (empty header value) 4) No header How should *exactly* react the WS client in all these cases? The draft says nothing (AFAIK). * Page 10: Conceptually, WebSocket is really just a layer on top of TCP that does the following: o adds a Web "origin"-based security model for browsers o adds an addressing and protocol naming mechanism to support multiple services on one port and multiple host names on one IP address; This is not true. Such feature is provided by HTTP protocol (Request-URI means the server resource to contact and Host header allows identifying the domain being contacted). I suggest refactoring this point as (also remove the last ";"): ------------------- o adds a protocol naming mechanism to support multiple services to be provided by the same WebSocket server ------------------ o layers a framing mechanism on top of TCP to get back to the IP packet mechanism that TCP is built on, but without length limits This is ugly. WebSocket is a layer 5 protocol (application). Could you please forget layers 3 and 4 for a while please? o includes an additional closing handshake in-band that is designed to work in the presence of proxies and other intermediaries Any application layer protocol should include a "closing" mechanism, totally independant of TCP connection termination. Protocols, anyway, can *react* when the TCP connection is closed prematurely, and decide (or NOT) to terminate the application session. But this is NOT true for any protocol working on top of TCP (for example in SIP over TCP, a dialog/call could use different TCP connections for each request, like the initial INVITE or the BYE after 5 minutes). Again, don't assume paralelism between layer 4 (TCP) and layer 5. If WebSocket protocol requires that the TCP connection to be open (which is legitimate) then mandate that a WS session must be terminated using WS control messages, and explain that in case of TCP premature termination, both endpoints should inmediately terminate the WS session internally. More later. Regards. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 05:47: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 1DCA921F886A for ; Mon, 15 Aug 2011 05:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnG1mI-k90Sn for ; Mon, 15 Aug 2011 05:47:18 -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 890AA21F8686 for ; Mon, 15 Aug 2011 05:47:18 -0700 (PDT) Received: by qwc23 with SMTP id 23so3200006qwc.31 for ; Mon, 15 Aug 2011 05:48:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.173.207 with SMTP id q15mr2144155qaz.278.1313412483673; Mon, 15 Aug 2011 05:48:03 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 05:48:03 -0700 (PDT) Date: Mon, 15 Aug 2011 14:48:03 +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] Question about payload length 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, 15 Aug 2011 12:47:19 -0000 Page 17 (draft 10): Payload length: 7 bits, 7+16 bits, or 7+64 bits The length of the payload data, in bytes: if 0-125, that is the payload length. If 126, the following 2 bytes interpreted as a 16 bit unsigned integer are the payload length. If 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. What does it mean "the most significant bit MUST be 0"? why? Thanks. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 15 05:56: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 3ED7821F86F6 for ; Mon, 15 Aug 2011 05:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.388 X-Spam-Level: X-Spam-Status: No, score=-2.388 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deDK0zYLr6uV for ; Mon, 15 Aug 2011 05:56:14 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id C10A221F86AF for ; Mon, 15 Aug 2011 05:56:14 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 15 Aug 2011 05:57:00 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "hybi@ietf.org" Date: Mon, 15 Aug 2011 05:56:23 -0700 Thread-Topic: [hybi] Question about payload length Thread-Index: AcxbSZeAHyz5rl0tQKCYlw9ymxRviwAANJIg Message-ID: <634914A010D0B943A035D226786325D422BFBFC68C@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [hybi] Question about payload length 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, 15 Aug 2011 12:56:15 -0000 PiAgICBQYXlsb2FkIGxlbmd0aDogIDcgYml0cywgNysxNiBiaXRzLCBvciA3KzY0IGJpdHMNCj4g DQo+ICAgICAgIFRoZSBsZW5ndGggb2YgdGhlIHBheWxvYWQgZGF0YSwgaW4gYnl0ZXM6IGlmIDAt MTI1LCB0aGF0IGlzIHRoZQ0KPiAgICAgICBwYXlsb2FkIGxlbmd0aC4gIElmIDEyNiwgdGhlIGZv bGxvd2luZyAyIGJ5dGVzIGludGVycHJldGVkIGFzIGEgMTYNCj4gICAgICAgYml0IHVuc2lnbmVk IGludGVnZXIgYXJlIHRoZSBwYXlsb2FkIGxlbmd0aC4gIElmIDEyNywgdGhlDQo+ICAgICAgIGZv bGxvd2luZyA4IGJ5dGVzIGludGVycHJldGVkIGFzIGEgNjQtYml0IHVuc2lnbmVkIGludGVnZXIg KHRoZQ0KPiAgICAgICBtb3N0IHNpZ25pZmljYW50IGJpdCBNVVNUIGJlIDApIGFyZSB0aGUgcGF5 bG9hZCBsZW5ndGguDQo+IA0KPiANCj4gV2hhdCBkb2VzIGl0IG1lYW4gInRoZSBtb3N0IHNpZ25p ZmljYW50IGJpdCBNVVNUIGJlIDAiPyB3aHk/DQoNCkl0IG1lYW5zIHRoYXQgTVNCID0gMSBpcyBh IHByb3RvY29sIHZpb2xhdGlvbi4NCg0KSSBkb24ndCBrbm93IHdoeSwgYnV0IG15IGd1ZXNzIHdv dWxkIGJlOiB0aGVyZSBpcyBubyAidW5zaWduZWQgbG9uZyIgaW4gSmF2YS4NCg0K From ibc@aliax.net Mon Aug 15 05:58: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 1229321F8B8D for ; Mon, 15 Aug 2011 05:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.65 X-Spam-Level: X-Spam-Status: No, score=-2.65 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5afwsFRZx5fp for ; Mon, 15 Aug 2011 05:58:51 -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 8614B21F8B8C for ; Mon, 15 Aug 2011 05:58:51 -0700 (PDT) Received: by qwc23 with SMTP id 23so3205197qwc.31 for ; Mon, 15 Aug 2011 05:59:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.208 with SMTP id u16mr2454825qaz.328.1313413176832; Mon, 15 Aug 2011 05:59:36 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 05:59:36 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 14:59:36 +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: Re: [hybi] Question about payload length 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, 15 Aug 2011 12:58:52 -0000 2011/8/15 I=C3=B1aki Baz Castillo : > What does it mean "the most significant bit MUST be 0"? why? Ok, it basically limites the payload size to 2^63 bytes. Hummmm, 2^63 bytes =3D 8,5899347e9 Giga Bytes =3D 8192 Peta Bytes... And this is the frame size (not the WS message size)... mmm Why so MUCH??? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 05:59: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 789FA21F8B8E for ; Mon, 15 Aug 2011 05:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.651 X-Spam-Level: X-Spam-Status: No, score=-2.651 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FxCVBGt-wyss for ; Mon, 15 Aug 2011 05:59:45 -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 EAEDF21F8B8D for ; Mon, 15 Aug 2011 05:59:44 -0700 (PDT) Received: by qyk34 with SMTP id 34so796874qyk.10 for ; Mon, 15 Aug 2011 06:00:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr2395072qci.254.1313413230208; Mon, 15 Aug 2011 06:00:30 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 06:00:30 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC68C@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFBFC68C@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 15 Aug 2011 15:00:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Question about payload length 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, 15 Aug 2011 12:59:45 -0000 2011/8/15 Tobias Oberstein : > I don't know why, but my guess would be: there is no "unsigned long" in J= ava. A protocol design based on currently programming languages. Upsss. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 15 06:06: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 BD20F21F8BA7 for ; Mon, 15 Aug 2011 06:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.385 X-Spam-Level: X-Spam-Status: No, score=-2.385 tagged_above=-999 required=5 tests=[AWL=-0.086, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyem32P26POk for ; Mon, 15 Aug 2011 06:06:29 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5F121F8BA0 for ; Mon, 15 Aug 2011 06:06:29 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 15 Aug 2011 06:07:14 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "hybi@ietf.org" Date: Mon, 15 Aug 2011 06:06:36 -0700 Thread-Topic: [hybi] Question about payload length Thread-Index: AcxbSznccr6KXOiST+aOY8GJyfUtVQAACwUA Message-ID: <634914A010D0B943A035D226786325D422BFBFC6A7@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [hybi] Question about payload length 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, 15 Aug 2011 13:06:29 -0000 PiAyMDExLzgvMTUgScOxYWtpIEJheiBDYXN0aWxsbyA8aWJjQGFsaWF4Lm5ldD46DQo+ID4gV2hh dCBkb2VzIGl0IG1lYW4gInRoZSBtb3N0IHNpZ25pZmljYW50IGJpdCBNVVNUIGJlIDAiPyB3aHk/ DQo+IA0KPiBPaywgaXQgYmFzaWNhbGx5IGxpbWl0ZXMgdGhlIHBheWxvYWQgc2l6ZSB0byAyXjYz IGJ5dGVzLg0KPiANCj4gSHVtbW1tLCAyXjYzIGJ5dGVzID0gOCw1ODk5MzQ3ZTkgR2lnYSBCeXRl cyA9IDgxOTIgUGV0YSBCeXRlcy4uLg0KPiBBbmQgdGhpcyBpcyB0aGUgZnJhbWUgc2l6ZSAobm90 IHRoZSBXUyBtZXNzYWdlIHNpemUpLi4uIG1tbQ0KPiANCj4gV2h5IHNvIE1VQ0g/Pz8NCg0KV2h5 IG5vdD8NCg0KV2VsY29tZSBiYWNrIHRvIHRoZSBtYXguIGZyYW1lIHNpemUgZGlzY3Vzc2lvbjsp DQoNCkhvdyBtdWNoIGlzIGNvbWZvcnRhYmxlIHRvIHlvdT8gMWs/IDY0az8NCg0KSXMgdGhpbmsg R3JlZyBtYWRlIHRoYXQgYXJndW1lbnQ6IGZyYW1lIHNpemUgaXNuJ3QgaW5maW5pdGUgcmVhbGx5 LCBpdCdzIGxpbWl0ZWQgLi4geWVzLCB0byAyXjYzLg0KDQpPbiBhbnkgYWNjb3VudCwgMl42MyBp cyBwcmFjdGljYWxseSBpbmZpbml0ZS4NCg0KT24gdGhlIG90aGVyIGhhbmQ6IGl0IHdvdWxkIGJl IHRyaXZpYWwgdG8gaGF2ZSBhICJpbmZpbml0ZS1mcmFtZSIgZXh0ZW5zaW9uIHRoYXQgd2hlbg0K YWN0aXZlIGFsbG93cyBNU0IgPSAxLCB3aGljaCB3b3VsZCBtZWFuOiBmcmFtZSBsZW5ndGggaW5m aW5pdGUuDQoNClRoYXQgd2F5LCB5b3UgZXNzZW50aWFsbHkgc3dpdGNoIGJhY2sgdG8gYSBub24t ZnJhbWVkIHJhdyBUQ1AgKG1vZHVsbyB0aGUgcmVxdWlyZWQNCm1hc2tpbmcgZnJvbSBjbGllbnQg dG8gc2VydmVyKS4NCg0KV2ViU29ja2V0cyB0aGVuIGlzIGp1c3QgYSBmYW5jeSBwcmVsdWRlIHRv IGEgcmF3IFRDUCBhZnRlcndhcmRzIC4uDQo= From ibc@aliax.net Mon Aug 15 06:25: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 C78AE21F8BA7 for ; Mon, 15 Aug 2011 06:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UjBCPZp5xZrD for ; Mon, 15 Aug 2011 06:25:46 -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 4F58821F8620 for ; Mon, 15 Aug 2011 06:25:46 -0700 (PDT) Received: by qwc23 with SMTP id 23so3218619qwc.31 for ; Mon, 15 Aug 2011 06:26:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr2411793qci.254.1313414791376; Mon, 15 Aug 2011 06:26:31 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 06:26:31 -0700 (PDT) Date: Mon, 15 Aug 2011 15:26:31 +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] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 13:25:46 -0000 Hi, I don't like the mechanism to tell whether a fragment is a single message or a continuation. Basically it works as follows (a combination of two bits): - frame 1: FIN=3D0, opcode=3D1 (text message) - frame 2: FIN=3D0, opcode=3D0 (continuation) - frame 3: FIN=3D1, opcode=3D0 (continuation) This is a message spitted in 3 frames. Unfortunatelly having to set opcode=3D0 is useless (if I'm not wrong) and leaves the door open to ugly cases, for example, how should the server react on the following cases?: case 1) - frame 1: FIN=3D0, opcode=3D1 (text message) - frame 2: FIN=3D0, opcode=3D1 (text message) case 2) - frame 1: FIN=3D0, opcode=3D1 (text message) - frame 2: FIN=3D1, opcode=3D1 (text message) case 3) - frame 1: FIN=3D0, opcode=3D0 (continuation) case 4) - frame 1: FIN=3D1, opcode=3D0 (continuation) Frames belonging to the same message must be sequential so, wouldn't be much easier to drop "opcode=3D0" (continuation) and just use the FIN bit? Then the opcode is just inspected by the server in the first frame. If such frame has FIN=3D0 then opcode is not inspected in next frames of the same message. So: - frame 1: FIN=3D0, opcode=3D1 (text message) - frame 2: FIN=3D0, opcode=3DX (it does not matter) - frame 3: FIN=3D1, opcode=3DX (it does not matter) This would make much more easy ugly cases described below. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 07:05: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 2A4D921F8B6F for ; Mon, 15 Aug 2011 07:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLF3J701SjYh for ; Mon, 15 Aug 2011 07:05:47 -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 9DDB821F8B6D for ; Mon, 15 Aug 2011 07:05:47 -0700 (PDT) Received: by qwc23 with SMTP id 23so3239009qwc.31 for ; Mon, 15 Aug 2011 07:06:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr2556190qcb.178.1313417190529; Mon, 15 Aug 2011 07:06:30 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:06:30 -0700 (PDT) Date: Mon, 15 Aug 2011 16:06:30 +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] Multiplexing (suggesting sequence number in each frame) 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, 15 Aug 2011 14:05:48 -0000 Hi, I recognize that I don't know what the purpose of the MUX extension is (a Google extension?). But I suppose it intends to allow sending frames (fragments) of different WS messages at the same time. It could be easily achieved if each frame contains message sequence number or just a message identificator (a random integer). So a client could send frames belonging to different messages in parallel: - frame 1: message_id =3D 123, FIN=3D0, opcode=3D1 - frame 2: message_id =3D 961, FIN=3D0, opcode=3D1 - frame 3: message_id =3D 123, FIN=3D0, opcode=3D0 - frame 4: message_id =3D 123, FIN=3D0, opcode=3D0 - frame 5: message_id =3D 961, FIN=3D0, opcode=3D0 - frame 6: message_id =3D 123, FIN=3D1, opcode=3D0 - frame 7: message_id =3D 961, FIN=3D1, opcode=3D0 Doesn't it seem easy? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 07:09: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 02BA421F8B84 for ; Mon, 15 Aug 2011 07:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id of9ot8vASBfG for ; Mon, 15 Aug 2011 07:09:08 -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 E246921F8B80 for ; Mon, 15 Aug 2011 07:09:02 -0700 (PDT) Received: by qyk34 with SMTP id 34so829068qyk.10 for ; Mon, 15 Aug 2011 07:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr1224899qcc.292.1313417388322; Mon, 15 Aug 2011 07:09:48 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:09:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 16:09:48 +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: Re: [hybi] Multiplexing (suggesting sequence number in each frame) 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, 15 Aug 2011 14:09:09 -0000 2011/8/15 I=C3=B1aki Baz Castillo : > Hi, I recognize that I don't know what the purpose of the MUX > extension is (a Google extension?). But I suppose it intends to allow > sending frames (fragments) of different WS messages at the same time. > > It could be easily achieved if each frame contains message sequence > number or just a message identificator (a random integer). So a client > could send frames belonging to different messages in parallel: > > > - frame 1: =C2=A0 =C2=A0 message_id =3D 123, =C2=A0FIN=3D0, =C2=A0opcode= =3D1 > - frame 2: =C2=A0 =C2=A0 message_id =3D 961, =C2=A0FIN=3D0, =C2=A0opcode= =3D1 > - frame 3: =C2=A0 =C2=A0 message_id =3D 123, =C2=A0FIN=3D0, =C2=A0opcode= =3D0 > - frame 4: =C2=A0 =C2=A0 message_id =3D 123, =C2=A0FIN=3D0, =C2=A0opcode= =3D0 > - frame 5: =C2=A0 =C2=A0 message_id =3D 961, =C2=A0FIN=3D0, =C2=A0opcode= =3D0 > - frame 6: =C2=A0 =C2=A0 message_id =3D 123, =C2=A0FIN=3D1, =C2=A0opcode= =3D0 > - frame 7: =C2=A0 =C2=A0 message_id =3D 961, =C2=A0FIN=3D1, =C2=A0opcode= =3D0 > > > Doesn't it seem easy? By adding such simple "msg_id" to each frame, the following point in the draft-10 could be removed: o The fragments of one message MUST NOT be interleaved between the fragments of another message unless an extension has been negotiated that can interpret the interleaving. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 07:10:27 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 0C4C421F8B85 for ; Mon, 15 Aug 2011 07:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gb1gV2avemqx for ; Mon, 15 Aug 2011 07:10:26 -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 7834A21F8B80 for ; Mon, 15 Aug 2011 07:10:26 -0700 (PDT) Received: by qyk35 with SMTP id 35so2806963qyk.10 for ; Mon, 15 Aug 2011 07:11:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr2458454qcj.216.1313417471706; Mon, 15 Aug 2011 07:11:11 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:11:11 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 16:11:11 +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: Re: [hybi] Multiplexing (suggesting sequence number in each frame) 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, 15 Aug 2011 14:10:27 -0000 2011/8/15 I=C3=B1aki Baz Castillo : > By adding such simple "msg_id" to each frame, the following point in > the draft-10 could be removed: > > > =C2=A0 o =C2=A0The fragments of one message MUST NOT be interleaved betwe= en the > =C2=A0 =C2=A0 =C2=A0fragments of another message unless an extension has = been > =C2=A0 =C2=A0 =C2=A0negotiated that can interpret the interleaving. And next one (as it would be implicit): o An endpoint MUST be capable of handling control frames in the middle of a fragmented message. --=20 I=C3=B1aki Baz Castillo From dendicott@gmail.com Mon Aug 15 07:18: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 6285021F8B29 for ; Mon, 15 Aug 2011 07:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P17YSGpLaeJe for ; Mon, 15 Aug 2011 07:18:09 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8B321F8AAA for ; Mon, 15 Aug 2011 07:18:09 -0700 (PDT) Received: by wyg8 with SMTP id 8so4051020wyg.31 for ; Mon, 15 Aug 2011 07:18:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XHYnBHt92g7DIQhgP7IS/sHJXPhn3+KrMgIZDRQXu8g=; b=ft26Kdr2j3ZzU/fgRu30lw+tse+ZlOHbgT/UIKG0DnywuFIgnj9MOIyH+MeZDWKE5t 9noQoDlS6BN6OB+j05ybVg8Wy1sJun6CDaNPH2YtzpLD5eZncKwQ9LCVDCsq46xxB5AO HKxFz45pRKhQLE9adjQQcW9i/wQodhOVFUcOw= MIME-Version: 1.0 Received: by 10.216.186.66 with SMTP id v44mr2209639wem.0.1313417931010; Mon, 15 Aug 2011 07:18:51 -0700 (PDT) Received: by 10.217.3.203 with HTTP; Mon, 15 Aug 2011 07:18:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 10:18:50 -0400 Message-ID: From: David Endicott To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001485f1dd0238346304aa8bf14f Cc: hybi@ietf.org Subject: Re: [hybi] Comments about draft 10 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, 15 Aug 2011 14:18:10 -0000 --001485f1dd0238346304aa8bf14f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 15, 2011 at 8:30 AM, I=F1aki Baz Castillo wrote= : > 1) "The "Request-URI" of the GET method" is wrong. The RURI does not > belong to the method but to the request itself so better: > The "Request-URI" of the GET request > Some consider the HTTP verbs to represent a "method" on a resource. "Method" is also in common usage. > * Page 10: > ------------------ > o layers a framing mechanism on top of TCP to get back to the IP > packet mechanism that TCP is built on, but without length limits > > This is ugly. WebSocket is a layer 5 protocol (application). Could you > please forget layers 3 and 4 for a while please? > I always (had hoped) that Websocket would be considered a Transport protoco= l (ie. the same conceptual layer as TCP) not an application protocol. Sinc= e Websocket does not define contents (ie. it's content agnostic), it is a transport protocol. HTTP is an application protocol because it defines th= e type and structure of content and methods of interaction (GET, PUT, etc.) Again, don't assume paralelism between layer 4 (TCP) and layer 5. If WebSocket protocol requires that the TCP connection to be open (which > is legitimate) then mandate that a WS session must be terminated using > WS control messages, and explain that in case of TCP premature > termination, both endpoints should inmediately terminate the WS > session internally. > I continue to push to consider WS to be a Transport protocol. Like how TC= P and IP are both transports, but TCP is "value-add" and supports streaming and reliability, WS is a transport that adds functionality to TCP. If you're going to insist on calling WS an application layer protocol, I will then insist we define content-type mechanisms. (But let's not - that's a bad idea) --001485f1dd0238346304aa8bf14f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2011 at 8:30 AM, I=F1aki= Baz Castillo <ibc@al= iax.net> wrote:
=A0
1) "The "Request-= URI" of the GET method" is wrong. The RURI does not
belong to the method but to the request itself so better:
=A0The "Request-URI" of the GET request
Some consider the HTTP verbs to represent a "method" = on a resource. =A0 "Method" is also in common usage.


* Page 10:
------------------
Again, don't assume paralelism between layer 4 (TCP) and layer 5. If
WebSocket protocol requires that the TCP connection to be open (which
is legitimate) then mandate that a WS session must be terminated using
WS control messages, and explain that in case of TCP premature
termination, both endpoints should inmediately terminate the WS
session internally.

I continue to push = to consider WS to be a Transport protocol. =A0 Like how TCP and IP are both= transports, but TCP is "value-add" and supports streaming and re= liability, WS is a transport that adds functionality to TCP.

If you're going to insist on calling WS an applicat= ion layer protocol, I will then insist we define content-type mechanisms. = =A0 (But let's not - that's a bad idea)



--001485f1dd0238346304aa8bf14f-- From ibc@aliax.net Mon Aug 15 07:19: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 B303421F8B29 for ; Mon, 15 Aug 2011 07:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zndx4VYSrlZp for ; Mon, 15 Aug 2011 07:19:25 -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 2572921F8AAA for ; Mon, 15 Aug 2011 07:19:25 -0700 (PDT) Received: by qyk34 with SMTP id 34so834053qyk.10 for ; Mon, 15 Aug 2011 07:20:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr2449861qci.254.1313418010596; Mon, 15 Aug 2011 07:20:10 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:20:10 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 16:20:10 +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: Re: [hybi] Multiplexing (suggesting sequence number in each frame) 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, 15 Aug 2011 14:19:25 -0000 2011/8/15 I=C3=B1aki Baz Castillo : > 2011/8/15 I=C3=B1aki Baz Castillo : >> By adding such simple "msg_id" to each frame, the following point in >> the draft-10 could be removed: >> >> >> =C2=A0 o =C2=A0The fragments of one message MUST NOT be interleaved betw= een the >> =C2=A0 =C2=A0 =C2=A0fragments of another message unless an extension has= been >> =C2=A0 =C2=A0 =C2=A0negotiated that can interpret the interleaving. > > And next one (as it would be implicit): > > =C2=A0 o =C2=A0An endpoint MUST be capable of handling control frames in = the > =C2=A0 =C2=A0 =C2=A0middle of a fragmented message. The current spec is a hack: _Note: if control frames could not be interjected, the latency of a ping, for example, would be very long if behind a large message. Hence, the requirement of handling control frames in the middle of a fragmented message._ And the very same could occur in the following example: XMPP over WebSocket.: - A contact sends me a very big file (various MBs) which becomes a MS message splitted in N frames. - It takes 3 minutes to arrive the full file. - During those 3 minutes I cannot receive presence/status updates for other contacts in my buddylist. Ugly design, period. Add a msg_id to frame binary format and problem solved, without extensions, just as easy as a single identificator field (like in many other protocols). In HTTP there is no such "id" field to correlate responses and requests, so parallesims/pipeline is a ugly hack (just valid for some specific cases and with heavy constrains). Don't learn just from HTTP please. Check SIP protocol in which the same TCP connection can hold different transactions (request+responses) by using a "branch" field for mathing responses and the requests they belong to. Regards. --=20 I=C3=B1aki Baz Castillo From jat@google.com Mon Aug 15 07:20: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 16A9F21F8B29 for ; Mon, 15 Aug 2011 07:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.494 X-Spam-Level: X-Spam-Status: No, score=-105.494 tagged_above=-999 required=5 tests=[AWL=-0.418, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UCvNF8ZPyHB for ; Mon, 15 Aug 2011 07:20: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 656DE21F8AAA for ; Mon, 15 Aug 2011 07:20:29 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p7FELCVe027649 for ; Mon, 15 Aug 2011 07:21:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313418072; bh=E4vRYSIGhmlN+p4sIfkVanGvfl8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=x2bOZuSITo2+bVpKkpoTXLVPPRDbKTyyMvF7ceUNFeqtNtaE0JVIVHM8Sk85V5ATe ossY3xkBhKxIRD6Ptejkg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=X+WoJsRBxbMBYBZcCKtstdf5OM0SBiJD3+j6SFi2xUj/9qZC3ioInzhcRwsokIBOv kCwJceIPO7TSmz4VBY3wQ== Received: from yxp4 (yxp4.prod.google.com [10.190.4.196]) by wpaz21.hot.corp.google.com with ESMTP id p7FEKq0H014335 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 15 Aug 2011 07:21:11 -0700 Received: by yxp4 with SMTP id 4so2950631yxp.3 for ; Mon, 15 Aug 2011 07:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=tzQeAcV7en8lZbpTVz7n8Bi4QRyuVm/l/2vbjiVPaW4=; b=NHb2hN+Gw5TP6oh5MPS9XaGY790Df9Jx7LfDBLHN2iRzRmijbaAEO6cZEBSUB8rjBj QVJDy/UqYEbW8gg2Wb2A== Received: by 10.151.114.20 with SMTP id r20mr4828234ybm.2.1313418071421; Mon, 15 Aug 2011 07:21:11 -0700 (PDT) Received: by 10.151.114.20 with SMTP id r20mr4828225ybm.2.1313418071168; Mon, 15 Aug 2011 07:21:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 15 Aug 2011 07:20:51 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Mon, 15 Aug 2011 10:20:51 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00151750e55492d98904aa8bf91c X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 14:20:30 -0000 --00151750e55492d98904aa8bf91c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 15, 2011 at 9:26 AM, I=C3=B1aki Baz Castillo wr= ote: > - frame 1: FIN=3D0, opcode=3D1 (text message) > - frame 2: FIN=3D0, opcode=3DX (it does not matter) > - frame 3: FIN=3D1, opcode=3DX (it does not matter) > > This would make much more easy ugly cases described below. The value must be set to something, so allowing it to be set arbitrarily seems ripe for errors -- for example, one implementation always uses the opcode of the last frame when delivering the message, and another using the first. Attackers use similar problems in how browsers interpret things today, and it seems prudent to avoid it by defining the continuation opcode= . --=20 John A. Tamplin Software Engineer (GWT), Google --00151750e55492d98904aa8bf91c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 15, 2011 at 9:26 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
- frame 1: =C2=A0 FIN=3D0, opcode=3D1 =C2=A0(text message)
- frame 2: =C2=A0 FIN=3D0, opcode=3DX =C2=A0(it does not matter)
- frame 3: =C2=A0 FIN=3D1, opcode=3DX =C2=A0(it does not matter)

This would make much more easy ugly cases described below.

The value must be set to something, so allowing it to be se= t arbitrarily seems ripe for errors -- for example, one implementation alwa= ys uses the opcode of the last frame when delivering the message, and anoth= er using the first. =C2=A0Attackers use similar problems in how browsers in= terpret things today, and it seems prudent to avoid it by defining the cont= inuation opcode.

--
John A. Tamplin
Software Engineer (GWT), Google
--00151750e55492d98904aa8bf91c-- From ibc@aliax.net Mon Aug 15 07:23:05 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 6005021F8B84 for ; Mon, 15 Aug 2011 07:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.272, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYoJBMGgrgyZ for ; Mon, 15 Aug 2011 07:23:05 -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 C805121F8B74 for ; Mon, 15 Aug 2011 07:23:04 -0700 (PDT) Received: by qwc23 with SMTP id 23so3248293qwc.31 for ; Mon, 15 Aug 2011 07:23:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr2571026qcb.178.1313418223978; Mon, 15 Aug 2011 07:23:43 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:23:43 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 16:23:43 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 14:23:05 -0000 2011/8/15 John Tamplin : > On Mon, Aug 15, 2011 at 9:26 AM, I=C3=B1aki Baz Castillo = wrote: >> >> - frame 1: =C2=A0 FIN=3D0, opcode=3D1 =C2=A0(text message) >> - frame 2: =C2=A0 FIN=3D0, opcode=3DX =C2=A0(it does not matter) >> - frame 3: =C2=A0 FIN=3D1, opcode=3DX =C2=A0(it does not matter) >> >> This would make much more easy ugly cases described below. > > The value must be set to something, so allowing it to be set arbitrarily > seems ripe for errors -- for example, one implementation always uses the > opcode of the last frame when delivering the message, and another using t= he > first. =C2=A0Attackers use similar problems in how browsers interpret thi= ngs > today, and it seems prudent to avoid it by defining the continuation opco= de. Ok, so just make opcode to be constant within frames of the same message: - frame 1: FIN=3D0, opcode=3D1 (text message) - frame 2: FIN=3D0, opcode=3D1 - frame 3: FIN=3D1, opcode=3D1 But the point here is that the server does NOT need to inspect opcode for frames after the first one. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 15 07:29: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 9B14321F8BBC for ; Mon, 15 Aug 2011 07:29:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.083 X-Spam-Level: X-Spam-Status: No, score=-2.083 tagged_above=-999 required=5 tests=[AWL=-0.384, BAYES_00=-2.599, J_CHICKENPOX_61=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNjIM6UpL+GC for ; Mon, 15 Aug 2011 07:29:55 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id BC37621F8B8C for ; Mon, 15 Aug 2011 07:29:54 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 15 Aug 2011 07:30:40 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "hybi@ietf.org" Date: Mon, 15 Aug 2011 07:30:03 -0700 Thread-Topic: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) Thread-Index: AcxbTveU+Ny0W0HSQD6TEl7XvcsJwwABFJ3w Message-ID: <634914A010D0B943A035D226786325D422BFBFC73B@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 14:29:55 -0000 PiBVbmZvcnR1bmF0ZWxseSBoYXZpbmcgdG8gc2V0IG9wY29kZT0wIGlzIHVzZWxlc3MgKGlmIEkn bSBub3Qgd3JvbmcpIGFuZA0KPiBsZWF2ZXMgdGhlIGRvb3Igb3BlbiB0byB1Z2x5IGNhc2VzLCBm b3IgZXhhbXBsZSwgaG93IHNob3VsZCB0aGUgc2VydmVyIHJlYWN0DQo+IG9uIHRoZSBmb2xsb3dp bmcgY2FzZXM/Og0KDQpUaGUgY29ubmVjdGlvbiBzaG91bGQgYmUgaW1tZWRpYXRlbHkgZmFpbGVk LiBUaGlzIGlzIG5vdCByZXF1aXJlZCBieSB0aGUgc3BlYywNCndoaWxlIElNSE8gdGhlIHNwZWMg c2hvdWxkIHJlcXVpcmUgdGhhdCBhIE1VU1QuDQoNCj4gY2FzZSAxKQ0KPiANCj4gLSBmcmFtZSAx OiAgIEZJTj0wLCBvcGNvZGU9MSAgKHRleHQgbWVzc2FnZSkNCj4gLSBmcmFtZSAyOiAgIEZJTj0w LCBvcGNvZGU9MSAgKHRleHQgbWVzc2FnZSkNCj4gDQo+IA0KPiBjYXNlIDIpDQo+IA0KPiAtIGZy YW1lIDE6ICAgRklOPTAsIG9wY29kZT0xICAodGV4dCBtZXNzYWdlKQ0KPiAtIGZyYW1lIDI6ICAg RklOPTEsIG9wY29kZT0xICAodGV4dCBtZXNzYWdlKQ0KPiANCj4gDQo+IGNhc2UgMykNCj4gDQo+ IC0gZnJhbWUgMTogICBGSU49MCwgb3Bjb2RlPTAgIChjb250aW51YXRpb24pDQo+IA0KPiANCj4g Y2FzZSA0KQ0KPiANCj4gLSBmcmFtZSAxOiAgIEZJTj0xLCBvcGNvZGU9MCAgKGNvbnRpbnVhdGlv bikNCg0KQWxsIGNhc2VzIGFyZSB0ZXN0ZWQgaW4gYSBsaXR0bGUgdGVzdCBzdWl0ZSBJIHdyb3Rl IC4uIHNlZSBjYXNlcyA1LngNCg0KaHR0cDovL3d3dy50YXZlbmRvLmRlL2F1dG9iYWhuL3Rlc3Rz dWl0ZS9yZXBvcnQvDQoNCkZpcmVmb3ggTmlnaHRseSBoYXMgYWxsIGNhc2VzIGNvcnJlY3QgYW5k IGZhaWxzIHRoZSBjb25uZWN0aW9uIGltbWVkaWF0ZWx5Lg0KDQpNeSBpbXBsZW1lbnRhdGlvbiBm YWlscyB0aGUgY29ubmVjdGlvbiB3aXRoIDIgZXJyb3JzIGZvciB0aGUgY2FzZXMgYWJvdmUNCg0K InJlY2VpdmVkIGNvbnRpbnVhdGlvbiBkYXRhIGZyYW1lIG91dHNpZGUgZnJhZ21lbnRlZCBtZXNz YWdlIg0KInJlY2VpdmVkIG5vbi1jb250aW51YXRpb24gZGF0YSBmcmFtZSB3aGlsZSBpbnNpZGUg ZnJhZ21lbnRlZCBtZXNzYWdlIg0KDQo+IEZyYW1lcyBiZWxvbmdpbmcgdG8gdGhlIHNhbWUgbWVz c2FnZSBtdXN0IGJlIHNlcXVlbnRpYWwgc28sIHdvdWxkbid0IGJlDQo+IG11Y2ggZWFzaWVyIHRv IGRyb3AgIm9wY29kZT0wIiAoY29udGludWF0aW9uKSBhbmQganVzdCB1c2UgdGhlIEZJTiBiaXQ/ DQo+IFRoZW4gdGhlIG9wY29kZSBpcyBqdXN0IGluc3BlY3RlZCBieSB0aGUgc2VydmVyIGluIHRo ZSBmaXJzdCBmcmFtZS4gSWYgc3VjaA0KPiBmcmFtZSBoYXMgRklOPTAgdGhlbiBvcGNvZGUgaXMg bm90IGluc3BlY3RlZCBpbiBuZXh0IGZyYW1lcyBvZiB0aGUgc2FtZQ0KPiBtZXNzYWdlLg0KPiAN Cj4gU286DQo+IA0KPiAtIGZyYW1lIDE6ICAgRklOPTAsIG9wY29kZT0xICAodGV4dCBtZXNzYWdl KQ0KPiAtIGZyYW1lIDI6ICAgRklOPTAsIG9wY29kZT1YICAoaXQgZG9lcyBub3QgbWF0dGVyKQ0K PiAtIGZyYW1lIDM6ICAgRklOPTEsIG9wY29kZT1YICAoaXQgZG9lcyBub3QgbWF0dGVyKQ0KPiAN Cj4gVGhpcyB3b3VsZCBtYWtlIG11Y2ggbW9yZSBlYXN5IHVnbHkgY2FzZXMgZGVzY3JpYmVkIGJl bG93Lg0KDQpZb3UgY2FuJ3QgaGF2ZSBYIGFyYml0cmFyeSwgc2luY2UgdGhlcmUgY2FuIGJlIGlu dGVybGVhdmVkICh1bmZyYWdtZW50ZWQpIGNvbnRyb2wgbWVzc2FnZXMuDQoNClNvIFggY291bGQg b25seSBiZSBhIGRhdGEgZnJhbWUgb3Bjb2RlLg0KIA0KQnV0IHRoZW4sIHNheWluZyBYIGNvdWxk IGJlIGFueXRoaW5nIChiZWNhdXNlIHlvdSBkb24ndCBpbnRlcnByZXQgaXQpIGRvZXNuJ3QgbWFr ZSB0aGluZ3MNCmVhc2llci4gWW91IHJlbW92ZSBwcm90b2NvbCB2aW9sYXRpb25zIGZvciBpbnRy b2R1Y2luZyBwcm90b2NvbCB2YXJpYW5jZS4gSW1wbGVtZW50YXRpb25zDQp3aWxsIGNob3NlIGRp ZmZlcmVudCBYLiBPbmUgbWF5IGNob29zZSB0aGUgWCA9IE9wY29kZSBvZiBmaXJzdC4gT25lIG1h eSBjaG9vc2UgWCA9IHNvbWUNCmZpeGVkIGRhdGEgb3Bjb2RlLg0KDQpNb3Jlb2V2ZXIsIHdoYXQg YWJvdXQgaW50ZXJtZWRpYXJpZXM/DQoNCkluc3RlYWQsIElNSE8gdGhlcmUgYXJlIDMgdGhpbmdz IG1peGVkIHVwOg0KDQpGSU4NCmFuIE9wY29kZSBmb3IgY29udGludWF0aW9uDQpPcGNvZGVzIGZv ciBwYXlsb2FkIF90eXBlc18NCg0KVGhlcmUgc2hvdWxkIGhhdmUgYmVlbiBubyBkaXN0aW5jdGlv biBpbnRvIHRleHQvYmluYXJ5IHBheWxvYWRzLCBhbmQgdGhlbg0KdGhlcmUgd291bGQgYmUgbm8g bmVlZCBmb3IgY29udGludWF0aW9uIG9wY29kZSwgYnV0IG9ubHkgRklOIGFuZCAxIG9wY29kZSBm b3INCmRhdGEgKHRvIGRpc3Rpbmd1aXNoIGZyb20gY29udHJvbCkuDQoNCg== From ibc@aliax.net Mon Aug 15 07:32: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 2753921F8ABC for ; Mon, 15 Aug 2011 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrfiRSKB8NR1 for ; Mon, 15 Aug 2011 07:32:18 -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 9A8FE21F8862 for ; Mon, 15 Aug 2011 07:32:18 -0700 (PDT) Received: by qyk35 with SMTP id 35so2817436qyk.10 for ; Mon, 15 Aug 2011 07:33:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.200.197 with SMTP id ex5mr2736729qab.228.1313418783710; Mon, 15 Aug 2011 07:33:03 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:33:03 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC73B@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFBFC73B@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 15 Aug 2011 16:33:03 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 14:32:19 -0000 2011/8/15 Tobias Oberstein : > You can't have X arbitrary, since there can be interleaved (unfragmented)= control messages. > > So X could only be a data frame opcode. > > But then, saying X could be anything (because you don't interpret it) doe= sn't make things > easier. You remove protocol violations for introducing protocol variance.= Implementations > will chose different X. One may choose the X =3D Opcode of first. One may= choose X =3D some > fixed data opcode. Ok, I've already replied in other mail that instead of "any opcode", mandate that all the frames have the same opcode as the first one. But there is no need at all for the opcode=3D0 (continuation) value, as its meaning is already given by the FIN bit. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 07:37: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 201F721F8AF7 for ; Mon, 15 Aug 2011 07:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygnfptADvpGy for ; Mon, 15 Aug 2011 07:37:19 -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 8AEFA21F8A4F for ; Mon, 15 Aug 2011 07:37:14 -0700 (PDT) Received: by qwc23 with SMTP id 23so3256048qwc.31 for ; Mon, 15 Aug 2011 07:37:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr2582663qcb.178.1313419079132; Mon, 15 Aug 2011 07:37:59 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:37:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 16:37:59 +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: Re: [hybi] Multiplexing (suggesting sequence number in each frame) 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, 15 Aug 2011 14:37:20 -0000 2011/8/15 I=C3=B1aki Baz Castillo : > The current spec is a hack: > > =C2=A0 _Note: if control frames could not be interjected, the latency of = a > =C2=A0 ping, for example, would be very long if behind a large message. > =C2=A0 Hence, the requirement of handling control frames in the middle of= a > =C2=A0 fragmented message._ Another hack in the spec: If an endpoint receives a Ping frame and has not yet sent Pong frame(s) in response to previous Ping frame(s), the endpoint MAY elect to send a Pong frame for only the most recently processed Ping frame. It does not make sense. The endpoint cannot decide "which Ping to reply" as the Pong frame has no way to identify which Ping belongs to. So basically the endpoint can just decide whether sending two Pong or just one. In the last case, the remote endpoint will never know which Ping the received Pong belongs to. NOTE: *Again* using a msg_id in the frame would solve this issue by mandating that a Pong frame MUST mirror the same msg_id than the Ping it's replying to. Easy. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 15 07:40: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 C6AF121F8B94 for ; Mon, 15 Aug 2011 07:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MC+sZimickVM for ; Mon, 15 Aug 2011 07:40:14 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 527D821F8B85 for ; Mon, 15 Aug 2011 07:40:14 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Mon, 15 Aug 2011 07:40:59 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 15 Aug 2011 07:40:22 -0700 Thread-Topic: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) Thread-Index: AcxbWEAesguRKyhhSuakWq3quyafCgAAB+bg Message-ID: <634914A010D0B943A035D226786325D422BFBFC754@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFBFC73B@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 14:40:14 -0000 PiA+IFlvdSBjYW4ndCBoYXZlIFggYXJiaXRyYXJ5LCBzaW5jZSB0aGVyZSBjYW4gYmUgaW50ZXJs ZWF2ZWQgKHVuZnJhZ21lbnRlZCkNCj4gY29udHJvbCBtZXNzYWdlcy4NCj4gPg0KPiA+IFNvIFgg Y291bGQgb25seSBiZSBhIGRhdGEgZnJhbWUgb3Bjb2RlLg0KPiA+DQo+ID4gQnV0IHRoZW4sIHNh eWluZyBYIGNvdWxkIGJlIGFueXRoaW5nIChiZWNhdXNlIHlvdSBkb24ndCBpbnRlcnByZXQgaXQp DQo+ID4gZG9lc24ndCBtYWtlIHRoaW5ncyBlYXNpZXIuIFlvdSByZW1vdmUgcHJvdG9jb2wgdmlv bGF0aW9ucyBmb3INCj4gPiBpbnRyb2R1Y2luZyBwcm90b2NvbCB2YXJpYW5jZS4gSW1wbGVtZW50 YXRpb25zIHdpbGwgY2hvc2UgZGlmZmVyZW50IFguDQo+ID4gT25lIG1heSBjaG9vc2UgdGhlIFgg PSBPcGNvZGUgb2YgZmlyc3QuIE9uZSBtYXkgY2hvb3NlIFggPSBzb21lIGZpeGVkDQo+IGRhdGEg b3Bjb2RlLg0KPiANCj4gT2ssIEkndmUgYWxyZWFkeSByZXBsaWVkIGluIG90aGVyIG1haWwgdGhh dCBpbnN0ZWFkIG9mICJhbnkgb3Bjb2RlIiwgbWFuZGF0ZQ0KPiB0aGF0IGFsbCB0aGUgZnJhbWVz IGhhdmUgdGhlIHNhbWUgb3Bjb2RlIGFzIHRoZSBmaXJzdCBvbmUuIEJ1dCB0aGVyZSBpcyBubw0K PiBuZWVkIGF0IGFsbCBmb3IgdGhlIG9wY29kZT0wIChjb250aW51YXRpb24pIHZhbHVlLCBhcyBp dHMgbWVhbmluZyBpcyBhbHJlYWR5DQo+IGdpdmVuIGJ5IHRoZSBGSU4gYml0Lg0KDQpZZXMsIGJ1 dCAibWFuZGF0ZSIgbWVhbnMgaXQgY291bGQgYmUgdmlvbGF0ZWQsIHRoZXJlZm9yIHlvdSBuZWVk IHRvIGNoZWNrDQppbiBpbXBsZW1lbnRhdGlvbnMgYW55d2F5Lg0KDQpGb3IgZXhhbXBsZSwgd2hl dGhlciB0aGUgY2hlY2sgaXMNCg0KIm9wY29kZSA9PSAwIiBvciAib3Bjb2RlID09IG9wY29kZSBv ZiAxc3QgZnJhZ21lbnQiDQoNCndoZW4gaW5zaWRlIGZyYWdtZW50ZWQgbWVzc2FnZSBzZWVtcyB0 byBtYWtlIG5vIGRpZmZlcmVuY2UuDQo= From ibc@aliax.net Mon Aug 15 07:47: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 C8F4621F8A4E for ; Mon, 15 Aug 2011 07:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uja67tgsYZjP for ; Mon, 15 Aug 2011 07:47:19 -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 45C0921F8B3E for ; Mon, 15 Aug 2011 07:47:19 -0700 (PDT) Received: by qwc23 with SMTP id 23so3261535qwc.31 for ; Mon, 15 Aug 2011 07:48:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr2592341qcb.178.1313419683380; Mon, 15 Aug 2011 07:48:03 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 07:48:03 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 16:48:03 +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: Re: [hybi] Comments about draft 10 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, 15 Aug 2011 14:47:19 -0000 More comments: * Page 29: 2. The Method of the request MUST be GET and the HTTP version MUST be at least 1.1. For example, if the WebSocket URI is "ws://example.com/chat", The first line sent should be "GET /chat HTTP/1.1" No, it could also be an absolute URI: "GET ws://example.com/chat HTTP/1.1" In fact next point 3 says that: 3. The request MUST contain a "Request-URI" as part of the GET method. This MUST match the /resource name/ Section 3 (a relative URI), or be an absolute URI that, when parsed, has a matching /resource name/ as well as matching /host/, /port/, and appropriate scheme (ws or wss). 4. The request MUST contain a "Host" header whose value is equal to /host/. AFAIK "Host" header is not mandatory at all: a) The server could handle a single domain so ignores the "Host" value. b) The Request-URI could be an absolute URI so the domain is already present there. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 08:06:36 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 8EDF221F8C3C for ; Mon, 15 Aug 2011 08:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQuXekBSVXwh for ; Mon, 15 Aug 2011 08:06:36 -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 0885A21F8C35 for ; Mon, 15 Aug 2011 08:06:35 -0700 (PDT) Received: by qyk35 with SMTP id 35so2835060qyk.10 for ; Mon, 15 Aug 2011 08:07:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr2491384qci.254.1313420841526; Mon, 15 Aug 2011 08:07:21 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 08:07:21 -0700 (PDT) Date: Mon, 15 Aug 2011 17:07:21 +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] About 9.2.1. Compression 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, 15 Aug 2011 15:06:36 -0000 9.2.1. Compression Senders using this extension MUST apply [RFC1951] encodings to all bytes of the data stream following the opening handshake including both data and control frames. What does "all bytes of the data stream" mean? all the frames? If frames are compressed, how can know the receiver how much to read in order to get the payload size? so does the compression extension transform WS protocol in a streamed protocol rather than frames oriented protocol?? Anyhow I remember long discussions about "compression of frames VS compression of frames payload". Is there final decision for that? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From jat@google.com Mon Aug 15 08:24: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 A8C3821F8BEF for ; Mon, 15 Aug 2011 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.789 X-Spam-Level: X-Spam-Status: No, score=-105.789 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCPX4dmbOOdH for ; Mon, 15 Aug 2011 08:24:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DBE5621F8BE5 for ; Mon, 15 Aug 2011 08:24:44 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p7FFPKQh000759 for ; Mon, 15 Aug 2011 08:25:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313421921; bh=rxmADTEcBtDEhv4FKrrnVDXH5F4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fALd9vRu6ADH4sndgodTsLm1gGL18pyNQxP+wz83fJtdBrkLJVx0ECEnL63YQJJcM cM63IUy9uKhy1Su+z3oQA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=HQRoaGhZnNhxcSNC3eM2nO02nKvMGCvuEXLrdDghtfhffmwhHgSwiNABMkoYXYknP opn8B2ppReKNSr21BEbXg== Received: from gyg10 (gyg10.prod.google.com [10.243.50.138]) by wpaz9.hot.corp.google.com with ESMTP id p7FFP283030798 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 15 Aug 2011 08:25:19 -0700 Received: by gyg10 with SMTP id 10so3479427gyg.0 for ; Mon, 15 Aug 2011 08:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1z/7a0ouRuA/NEVHX4C4VqF0W0OonaJdrVClTplovH4=; b=veL0xEDuGlsMg81uMhL0b0Xy/WwaF0vwSquwNBJIdSIydsI3jmFOW8Y7wwqScd2lKz Si/IQZQv6uXYXo8vLOyw== Received: by 10.151.118.20 with SMTP id v20mr5189404ybm.401.1313421919377; Mon, 15 Aug 2011 08:25:19 -0700 (PDT) Received: by 10.151.118.20 with SMTP id v20mr5189395ybm.401.1313421919155; Mon, 15 Aug 2011 08:25:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 15 Aug 2011 08:24:59 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422BFBFC68C@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Mon, 15 Aug 2011 11:24:59 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001e680f09fcee782704aa8cdeec X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Question about payload length 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, 15 Aug 2011 15:24:45 -0000 --001e680f09fcee782704aa8cdeec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 15, 2011 at 9:00 AM, I=C3=B1aki Baz Castillo wr= ote: > 2011/8/15 Tobias Oberstein : > > I don't know why, but my guess would be: there is no "unsigned long" in > Java. > > A protocol design based on currently programming languages. Upsss. The point is what is the value over allowing 2^64 frames rather than 2^63? If there is no value, then why do something which is known to complicate some implementations? You are likely to wind up with implementations that use Java long anyway rather than sacrifice performance for the frames that will actually be sent, which leaves open an attack where some implementations interpret the frame length differently than other implementations. Such cases where different implementations implement slightly different things have been the cause of many security holes, and are to be avoided. --=20 John A. Tamplin Software Engineer (GWT), Google --001e680f09fcee782704aa8cdeec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 15, 2011 at 9:00 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
2011/8/15 Tobias Oberstein <tobias.oberstein@tavendo.de>:
> I don't know why, but my guess would be: there i= s no "unsigned long" in Java.

A protocol design based on currently programming languages. Upsss.

The point is what is the value over allowing = 2^64 frames rather than 2^63? =C2=A0If there is no value, then why do somet= hing which is known to complicate some implementations? =C2=A0You are likel= y to wind up with implementations that use Java long anyway rather than sac= rifice performance for the frames that will actually be sent, which leaves = open an attack where some implementations interpret the frame length differ= ently than other implementations.

Such cases where different implementations implement sl= ightly different things have been the cause of many security holes, and are= to be avoided.

--
John A. Tamplin
Software Engineer = (GWT), Google
--001e680f09fcee782704aa8cdeec-- From jmason@rim.com Mon Aug 15 10:24: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 DE9B821F8C9D for ; Mon, 15 Aug 2011 10:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qfz1Bn5vc8UU for ; Mon, 15 Aug 2011 10:24:59 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE6E21F8C9B for ; Mon, 15 Aug 2011 10:24:58 -0700 (PDT) X-AuditID: 0a41282f-b7b1cae0000013b1-a1-4e4956873ac3 Received: from XHT109CNC.rim.net (xht109cnc.rim.net [10.65.12.218]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 59.A4.05041.786594E4; Mon, 15 Aug 2011 17:25:28 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT109CNC.rim.net ([fe80::8412:4d9e:eb55:2c7b%11]) with mapi; Mon, 15 Aug 2011 13:25:44 -0400 From: Joe Mason To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , John Tamplin Date: Mon, 15 Aug 2011 13:25:46 -0400 Thread-Topic: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) Thread-Index: AcxbVva22448KlAKTYme4uZObrMhewAGO/Og Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPKsWRmVeSWpSXmKPExsXC5chzS7cjzNPP4OY5Jov3L7cxWUzfZ2Px dNIBdgdmj3MN79k9Fmwq9Viy5CdTAHNUA6NNYl5efkliSapCSmpxsq2ST2p6Yo5CQFFmWWJy pYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jNS85P ycxLt1XyDPbXtbAwtdQ1VLLTRQIJ/7gzFt1fylTwjqPi8ZVPzA2MFzi6GDk5JARMJC6vfMMK YYtJXLi3nq2LkYtDSKCXSWLe06msEM5iRolbfz8xg1SxCShIfD78gKmLkYNDRCBW4sASIZAw s4CyxNVjK1hAbBYBVYk/S1vBbGEBJ4kZu9eDtYoIOEvs77vODmEbSbSevgJWwyvgIXHz+GFG EFtI4B6jRMfEcBCbUyBQ4s3pCWC9jEDHfT+1hglil7jErSfzmSCOFpBYsuc8M4QtKvHy8T9W iHpRiTvt6xlBzmQW0JRYv0sfolVRYkr3Q3aItYISJ2c+YZnAKDYLydRZCB2zkHTMQtKxgJFl FaNgbkaxgZlBcl6yXlFmrl5easkmRnDK0NDfwdi3V+sQowAHoxIP78zXHn5CrIllxZW5hxgl OJiVRHhnGnn6CfGmJFZWpRblxxeV5qQWH2K0AIbbRGYp7uR8YDrLK4k3NjBA4SiJ8wZLG/gJ CaQDk1F2ampBahFMKxMHp1QDo9oZxq2aF8uOfOMtVEvIsPua4vPx2GWDHvOkyk8qYZV5cTKc kZe4G56GJE7pjzjXMPGzgNj8V/tZXoo9enbrE8vlgImeFZuy908zEj3eM49XqDRqW/KnyJqD 3K++n+AqOpccsrPbVThES2eeysxdPNa8oSECuw882JuRk1Kn7MUgbW7gd6laiaU4I9FQi7mo OBEAGBPylzIDAAA= Cc: "hybi@ietf.org" Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 17:25:00 -0000 PiBPaywgc28ganVzdCBtYWtlIG9wY29kZSB0byBiZSBjb25zdGFudCB3aXRoaW4gZnJhbWVz IG9mIHRoZSBzYW1lDQo+IG1lc3NhZ2U6DQo+IA0KPiAtIGZyYW1lIDE6ICAgRklOPTAsIG9w Y29kZT0xICAodGV4dCBtZXNzYWdlKQ0KPiAtIGZyYW1lIDI6ICAgRklOPTAsIG9wY29kZT0x DQo+IC0gZnJhbWUgMzogICBGSU49MSwgb3Bjb2RlPTENCj4gDQo+IEJ1dCB0aGUgcG9pbnQg aGVyZSBpcyB0aGF0IHRoZSBzZXJ2ZXIgZG9lcyBOT1QgbmVlZCB0byBpbnNwZWN0IG9wY29k ZQ0KPiBmb3IgZnJhbWVzIGFmdGVyIHRoZSBmaXJzdCBvbmUuDQoNClRoZSBzZXJ2ZXIgYWx3 YXlzIG5lZWRzIHRvIGNoZWNrIHRoZSBvcGNvZGUgdG8gbG9vayBmb3IgY29udHJvbCBtZXNz YWdlcyBlbWJlZGRlZCBpbiBhIGZyYWdtZW50ZWQgbWVzc2FnZS4NCg0KUmVxdWlyaW5nIHRo ZSBvcGNvZGUgdG8gYmUgMCBsZXRzIHVzIGRldGVjdCB0aGUgY2FzZSB3aGVyZSBhIGNsaWVu dCB0cmllcyB0byBpbnRlcmxlYXZlIGZyYWdtZW50ZWQgZGF0YSBtZXNzYWdlcyAod2hpY2gg aXMgZGlzYWxsb3dlZCksIG9yIGZhaWxzIHRvIHNlbmQgYSBGSU4gZm9yIG9uZSBtZXNzYWdl LCBhbmQgZmFpbCB0aGUgY29ubmVjdGlvbiBpbW1lZGlhdGVseS4gIElmIHdlIHJldXNlIHRo ZSBzYW1lIG9wY29kZSB0aGVyZSdzIG5vIHdheSB0byBkaXN0aW5ndWlzaCBmcmFtZSAxIG9m IGEgbmV3IG1lc3NhZ2UgZnJvbSBmcmFtZSAyIG9mIHRoZSBjdXJyZW50IG1lc3NhZ2UsIHNv IHdlIG11c3QgYXNzdW1lIHRoYXQgdGhlIGNsaWVudCBpcyBkb2luZyBldmVyeXRoaW5nIHBl cmZlY3RseS4NCg0KSm9lDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24g KGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHBy b3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHBy aXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1 c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4g VXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhv cml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== From ibc@aliax.net Mon Aug 15 10:29: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 C4E8921F8CBD for ; Mon, 15 Aug 2011 10:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VO65ObwT7vzH for ; Mon, 15 Aug 2011 10:29:33 -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 B0B7821F8CA0 for ; Mon, 15 Aug 2011 10:29:33 -0700 (PDT) Received: by qyk34 with SMTP id 34so927626qyk.10 for ; Mon, 15 Aug 2011 10:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr2619663qcj.216.1313429419509; Mon, 15 Aug 2011 10:30:19 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 10:30:19 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 19:30:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Joe Mason Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 17:29:34 -0000 2011/8/15 Joe Mason : > The server always needs to check the opcode to look for control messages = embedded in a fragmented message. Do I miss something? that is forbidden. Control frames must have FIN=3D1 and opcode !=3D 0. --=20 I=C3=B1aki Baz Castillo From jmason@rim.com Mon Aug 15 10:32: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 2931621F8C70 for ; Mon, 15 Aug 2011 10:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RNKOMxBBZ+LG for ; Mon, 15 Aug 2011 10:32:37 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9222121F8C63 for ; Mon, 15 Aug 2011 10:32:37 -0700 (PDT) X-AuditID: 0a41282f-b7b1cae0000013b1-5a-4e4958531313 Received: from XHT105CNC.rim.net (xht105cnc.rim.net [10.65.12.216]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 45.45.05041.358594E4; Mon, 15 Aug 2011 17:33:07 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT105CNC.rim.net ([fe80::24dd:699b:a19e:2bcc%11]) with mapi; Mon, 15 Aug 2011 13:33:23 -0400 From: Joe Mason To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 15 Aug 2011 13:33:26 -0400 Thread-Topic: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) Thread-Index: AcxbcQGF5WQ498QLSCebTa7TppyAdAAAEd5A Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRmVeSWpSXmKPExsXC5chzQzc4wtPP4MVfEYv3L7cxWUzfZ2Px dNIBdgdmj3MN79k9Fmwq9Viy5CdTAHNUA6NNYl5efkliSapCSmpxsq2ST2p6Yo5CQFFmWWJy pYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jNS85P ycxLt1XyDPbXtbAwtdQ1VLLTRQIJ/7gzzv2eylpwjr3i67OrbA2MW9i7GDk5JARMJKbPvcwG YYtJXLi3Hsjm4hAS6GWSmLvzCQuEs5hRYvbX22BVbAIKEp8PP2ACsUUEbCT+XbgANolZwEni 1+ZeMJtFQFWit3U/WI0wUHzG7vXMEPXOEvv7rrND2EYSy9evBopzcPAKeEi87MgHCQsJPGGS WPHLBiTMKRAo0TkzDiTMCHTb91NrmCA2iUvcejKfCeJmAYkle84zQ9iiEi8f/2OFqBeVuNO+ nhFkDLOApsT6XfoQrYoSU7ofgh3AKyAocXLmE5YJjGKzkEydhdAxC0nHLCQdCxhZVjEK5mYU G5gZJOcl6xVl5urlpZZsYgQnDA39HYx9e7UOMQpwMCrx8M587eEnxJpYVlyZe4hRgoNZSYR3 ppGnnxBvSmJlVWpRfnxRaU5q8SFGC2CoTWSW4k7OByazvJJ4YwMDFI6SOG+wtIGfkEA6MBVl p6YWpBbBtDJxcEo1MLo0Wv3/4/Pio9TNB60LLSTK3X1NVJI9o5VztDpnTDTb9+X1/+TE+J0p jFvFTvwWnh8m8DPk6vquJ3OCjmtqfjn2ePoS5fmTe79eEw1bs2F2pbRO6CkT3+ybfwP+96xb NPuzZFFPmkSy465Qf54tU7aukWcSzbDY/PfBCfs3HzLmTWq1//l3d68SS3FGoqEWc1FxIgCc LsPZMQMAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] FIN bit and opcode=0 (why rely on opcode=0 ??) 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, 15 Aug 2011 17:32:38 -0000 WWVzLCBpZiBhIGNsaWVudCBzZW5kcyBhIGNvbnRyb2wgb3Bjb2RlIHdpdGggRklOPTAsIHRo aXMgaXMgYWxzbyBhbiBlcnJvci4gIFNvIGlmIHRoZSBzZXJ2ZXIgZGlkIG5vdCByZWFkIHRo ZSBvcGNvZGUsIGl0IHdvdWxkIG5ldmVyIGRldGVjdCB0aGlzIGVycm9yLg0KDQo+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEnDsWFraSBCYXogQ2FzdGlsbG8gW21h aWx0bzppYmNAYWxpYXgubmV0XQ0KPiBTZW50OiBNb25kYXksIEF1Z3VzdCAxNSwgMjAxMSAx OjMwIFBNDQo+IFRvOiBKb2UgTWFzb24NCj4gQ2M6IEpvaG4gVGFtcGxpbjsgaHliaUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW2h5YmldIEZJTiBiaXQgYW5kIG9wY29kZT0wICh3aHkg cmVseSBvbiBvcGNvZGU9MCA/PykNCj4gDQo+IDIwMTEvOC8xNSBKb2UgTWFzb24gPGptYXNv bkByaW0uY29tPjoNCj4gPiBUaGUgc2VydmVyIGFsd2F5cyBuZWVkcyB0byBjaGVjayB0aGUg b3Bjb2RlIHRvIGxvb2sgZm9yIGNvbnRyb2wNCj4gbWVzc2FnZXMgZW1iZWRkZWQgaW4gYSBm cmFnbWVudGVkIG1lc3NhZ2UuDQo+IA0KPiBEbyBJIG1pc3Mgc29tZXRoaW5nPyB0aGF0IGlz IGZvcmJpZGRlbi4gQ29udHJvbCBmcmFtZXMgbXVzdCBoYXZlIEZJTj0xDQo+IGFuZCBvcGNv ZGUgIT0gMC4NCj4gDQo+IC0tDQo+IEnDsWFraSBCYXogQ2FzdGlsbG8NCj4gPGliY0BhbGlh eC5uZXQ+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGlu ZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlv biwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBi eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMp LCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhp cyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5k IG1heSBiZSB1bmxhd2Z1bC4NCg== From gezelter@rlgsc.com Mon Aug 15 11:18: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 1204F228307 for ; Mon, 15 Aug 2011 11:18:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5uziD7TjbyUy for ; Mon, 15 Aug 2011 11:17:59 -0700 (PDT) Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by ietfa.amsl.com (Postfix) with SMTP id 0B060228309 for ; Mon, 15 Aug 2011 11:17:55 -0700 (PDT) Received: (qmail 31824 invoked from network); 15 Aug 2011 18:18:41 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 15 Aug 2011 18:18:41 -0000 Received: (qmail 20891 invoked by uid 99); 15 Aug 2011 18:18:41 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.149.49.233 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@IETF.ORG Date: Mon, 15 Aug 2011 11:18:40 -0700 Mime-Version: 1.0 Subject: [hybi] Binary/Text Distinction 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, 15 Aug 2011 18:18:00 -0000 I agree with I?aki that the distinction between text/binary data is=0Aunnec= essary. Similarly, I agree with Dave Endicott's and I?aki's=0Acomments abou= t the mixing of different classes of functionality in the=0AWebSocket proto= col.=0A=0AAs has been observed, the WebSocket protocol is payload-agnostic.= =0ARegardless of the politics, it is thus emphatically NOT an applications= =0Aprotocol. It is a protocol that provides a foundational service layered= =0Aon top of another transport protocol (e.g. TCP).=0A=0AThe protocol defin= ition and usage would be far clearer if the areas=0Awhere mixing is occurri= ng are edited. Examples include:=0A=0A- The text/binary dichotomy in the op= codes and payloads=0A- The dependency on TCP (which is actually a dependenc= y on a "serial,=0Aguaranteed delivery transport"=0A- The interrelationship = with HTTP (which is limited to session=0Aestablishment, and the specificati= on of=0A the WS and WSS schema=0A=0AAdditionally, as I have observed in th= e past, IMHO multiplexing is=0Anecessary for effective use of the WebSocket= protocol in the wild, it=0Ashould be part of the base specification, not a= n add on. However, I=0Afreely admit that I do not see a compelling use case= for a multiplexing=0Aprotocol with nesting, the aforementioned removal of = the text/binary=0Adistinction (to a separate document), and the non-exclude= d potential for=0Arunning a VPN-like tunnel within a WebSocket protocol sub= -channel seems=0Amore than sufficient to allow nesting without specifically= including it.=0A=0ASimilarly, intermediate proxies could split a multiplex= ed stream into=0Aseparate streams as needed. IMHO, nesting makes that task = more complex.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A=0A From jat@google.com Mon Aug 15 11:23: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 8F5F521F8CCA for ; Mon, 15 Aug 2011 11:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.624 X-Spam-Level: X-Spam-Status: No, score=-105.624 tagged_above=-999 required=5 tests=[AWL=-0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2kASOy9KIjGH for ; Mon, 15 Aug 2011 11:23:59 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id EFFFC21F8CD1 for ; Mon, 15 Aug 2011 11:23:58 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7FIOiGg023469 for ; Mon, 15 Aug 2011 11:24:44 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313432684; bh=qlJjrkx7wSgTuvjHQab+G95E6A0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EHcIYdr3bn226X9nVQ8Lu02Lp26UGkVcaGQWx2qkCTUdZTCv6SSYk5LiFiT+Bi25g UCD9PEvJ1OqOiW1HGilnQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=R7TwVPb3yGS+0+CppOsyTq9sovufc+CMhCqd2vkrqnx15v++6t9vBhfjxnUIqvKoV 6Umcf8NZ70PvCx+vQuo9A== Received: from yie19 (yie19.prod.google.com [10.243.66.19]) by wpaz1.hot.corp.google.com with ESMTP id p7FIOhkR028425 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 15 Aug 2011 11:24:43 -0700 Received: by yie19 with SMTP id 19so3719312yie.29 for ; Mon, 15 Aug 2011 11:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RuPyqB/uWNaTv83NRjsWcbaY3mcRvg+THSVp3p/xyeQ=; b=ywXcbhBuwqGl6nm0apGrHkiTEKB0TU43LA7RDx9gG2j5aeSwqXgcmdEjPyQQqPSm+H HcQG3QYLpu9r/xA3s9Jg== Received: by 10.150.114.12 with SMTP id m12mr5369347ybc.287.1313432683487; Mon, 15 Aug 2011 11:24:43 -0700 (PDT) Received: by 10.150.114.12 with SMTP id m12mr5369340ybc.287.1313432683257; Mon, 15 Aug 2011 11:24:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 15 Aug 2011 11:24:23 -0700 (PDT) In-Reply-To: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> From: John Tamplin Date: Mon, 15 Aug 2011 14:24:23 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=000e0cdf13ca85a05204aa8f603b X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction 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, 15 Aug 2011 18:23:59 -0000 --000e0cdf13ca85a05204aa8f603b Content-Type: text/plain; charset=UTF-8 On Mon, Aug 15, 2011 at 2:18 PM, Bob Gezelter wrote: > I agree with I?aki that the distinction between text/binary data is > unnecessary. > There were months of discussions about this point during the framing discussion. Revisiting them at this point seems suboptimal. Basically, the browsers need to be able to call JS code delivering the message, and they want a simple API for JS code to access the message. If you left it up to the JS code to interpret it, then you would have to have a much more complicated API and you would also leave open accessing binary data as if it were text. -- John A. Tamplin Software Engineer (GWT), Google --000e0cdf13ca85a05204aa8f603b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 15, 2011 at 2:18 PM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
I agree with I?aki that the distinction between text/binary data is
unnecessary.

There were months of discu= ssions about this point during the framing discussion. =C2=A0Revisiting the= m at this point seems suboptimal.
=C2=A0
Basically, the= browsers need to be able to call JS code delivering the message, and they = want a simple API for JS code to access the message. =C2=A0If you left it u= p to the JS code to interpret it, then you would have to have a much more c= omplicated API and you would also leave open accessing binary data as if it= were text.

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cdf13ca85a05204aa8f603b-- From sdw@lig.net Mon Aug 15 11:26: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 D7D3C21F8CDD for ; Mon, 15 Aug 2011 11:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05ruyiFxrB1j for ; Mon, 15 Aug 2011 11:26:14 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id A67E521F8CCA for ; Mon, 15 Aug 2011 11:26:14 -0700 (PDT) Received: from mq.lig.net (ligemail.lig.net [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 0FEDEAB5DB0 for ; Mon, 15 Aug 2011 11:37:49 -0700 (PDT) Message-ID: <4E4964F4.90904@lig.net> Date: Mon, 15 Aug 2011 11:27:00 -0700 From: Stephen Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> In-Reply-To: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] Binary/Text Distinction 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, 15 Aug 2011 18:26:16 -0000 I strongly agree that the protocol should be binary payload based. Nesting will be needed, and tunneling should be an examined case for that. However, there should be a lighter weight way to do something similar. Channel naming might be an easy way to accomplish that: A subchannel could just be a normal peer channel "named" in a way that all of the peer channels are clearly together, for anything that needs to know that. Then the protocol only need to work with a flat set of peer channels in most or all respects. On Mon Aug 15 11:18:40 2011, Bob Gezelter wrote: > I agree with I?aki that the distinction between text/binary data is > unnecessary. Similarly, I agree with Dave Endicott's and I?aki's > comments about the mixing of different classes of functionality in the > WebSocket protocol. > > As has been observed, the WebSocket protocol is payload-agnostic. > Regardless of the politics, it is thus emphatically NOT an applications > protocol. It is a protocol that provides a foundational service layered > on top of another transport protocol (e.g. TCP). > > The protocol definition and usage would be far clearer if the areas > where mixing is occurring are edited. Examples include: > > - The text/binary dichotomy in the opcodes and payloads > - The dependency on TCP (which is actually a dependency on a "serial, > guaranteed delivery transport" > - The interrelationship with HTTP (which is limited to session > establishment, and the specification of > the WS and WSS schema > > Additionally, as I have observed in the past, IMHO multiplexing is > necessary for effective use of the WebSocket protocol in the wild, it > should be part of the base specification, not an add on. However, I > freely admit that I do not see a compelling use case for a multiplexing > protocol with nesting, the aforementioned removal of the text/binary > distinction (to a separate document), and the non-excluded potential for > running a VPN-like tunnel within a WebSocket protocol sub-channel seems > more than sufficient to allow nesting without specifically including it. > > Similarly, intermediate proxies could split a multiplexed stream into > separate streams as needed. IMHO, nesting makes that task more complex. > > - Bob Gezelter, http://www.rlgsc.com > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer From gezelter@rlgsc.com Mon Aug 15 11:27: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 1E66B11E809E for ; Mon, 15 Aug 2011 11:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.092 X-Spam-Level: X-Spam-Status: No, score=-1.092 tagged_above=-999 required=5 tests=[AWL=-0.907, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z60qv0sOVmCa for ; Mon, 15 Aug 2011 11:27:00 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id 1C85011E809B for ; Mon, 15 Aug 2011 11:27:00 -0700 (PDT) Received: (qmail 12133 invoked from network); 15 Aug 2011 18:27:45 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 15 Aug 2011 18:27:45 -0000 Received: (qmail 25884 invoked by uid 99); 15 Aug 2011 18:27:44 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.149.49.233 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110815112743.ef1fc80126c74c6c202a919c41c7bb0b.97ee9b7227.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Mon, 15 Aug 2011 11:27:43 -0700 Mime-Version: 1.0 Cc: gregw@intalio.com Subject: [hybi] Multiplexing/Frames 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, 15 Aug 2011 18:27:01 -0000 Andy,=0A=0AThank you for remembering. =0A=0AYes, I did suggest a while back= that a simple multiplexing scheme within=0Aframes would IMHO provide the b= est tradeoff between performance,=0Afunctionality, and efficiency. I am in = the middle of several things, so=0AI have not had a chance to sit with your= latest comments and the current=0Aspec, but your description sounds consis= tent with what I recall, to wit:=0A=0A - multiplex frame-by-frame=0A - ne= sting is not defined (one is free, as I mentioned a few minutes=0Aago in an= other post to the list, to implement nesting, but I see no=0Areason for the= specification to be nesting-cognizant)=0A=0AI still hold that opinion.=0A= =0A- Bob Gezelter, http://www.rlgsc.com=0A From gezelter@rlgsc.com Mon Aug 15 11:33: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 DF30621F8C82 for ; Mon, 15 Aug 2011 11:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FHUSOrG-liV for ; Mon, 15 Aug 2011 11:33:19 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id 491EB21F8C37 for ; Mon, 15 Aug 2011 11:33:19 -0700 (PDT) Received: (qmail 15026 invoked from network); 15 Aug 2011 18:34:05 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 15 Aug 2011 18:34:05 -0000 Received: (qmail 31549 invoked by uid 99); 15 Aug 2011 18:34:05 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.149.49.233 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110815113403.ef1fc80126c74c6c202a919c41c7bb0b.42fc91233e.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "John Tamplin" Date: Mon, 15 Aug 2011 11:34:03 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction 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, 15 Aug 2011 18:33:20 -0000 John,=0A=0AI do not see the need for separate opcodes for text/binary messa= ges.=0A=0AWhether a connection is binary/text is an applications protocol i= ssue,=0Aand should be at the level of the connection setup. At that point, = the=0AJS API is free to enforce the restriction.=0A=0AIn fact, if the text/= binary attribute is part of the connection's=0Aconfiguration, there is zero= chance of the API delivering bad data (as=0Aopposed to relying on its coun= ter-party to be well-behaved). I have=0Aimplemented many many interfaces ov= er the years with similar=0Arestrictions, without any problems. Relying on = the other side of the=0Aconnection is simply less reliable.=0A=0A- Bob Geze= lter, http://www.rlgsc.com=0A=0A=0A> -------- Original Message --------=0A>= Subject: Re: [hybi] Binary/Text Distinction=0A> From: John Tamplin =0A> Date: Mon, August 15, 2011 11:24 am=0A> To: Bob Gezelter =0A> Cc: hybi@ietf.org=0A> =0A> =0A> On Mon, Aug 15, 2011 a= t 2:18 PM, Bob Gezelter wrote:=0A> =0A> > I agree with= I?aki that the distinction between text/binary data is=0A> > unnecessary.= =0A> >=0A> =0A> There were months of discussions about this point during th= e framing=0A> discussion. Revisiting them at this point seems suboptimal.= =0A> =0A> Basically, the browsers need to be able to call JS code deliverin= g the=0A> message, and they want a simple API for JS code to access the mes= sage. If=0A> you left it up to the JS code to interpret it, then you would= have to have a=0A> much more complicated API and you would also leave open= accessing binary=0A> data as if it were text.=0A> =0A> -- =0A> John A. Tam= plin=0A> Software Engineer (GWT), Google=0A From ibc@aliax.net Mon Aug 15 11:48: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 8A48D21F8CB3 for ; Mon, 15 Aug 2011 11:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.363, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mFaGbHUhXgI for ; Mon, 15 Aug 2011 11:48:10 -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 5495121F8CB0 for ; Mon, 15 Aug 2011 11:48:08 -0700 (PDT) Received: by qyk34 with SMTP id 34so962725qyk.10 for ; Mon, 15 Aug 2011 11:48:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr2681516qcj.216.1313434134291; Mon, 15 Aug 2011 11:48:54 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 11:48:54 -0700 (PDT) Date: Mon, 15 Aug 2011 20:48:54 +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] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 18:48:10 -0000 Hi, probably is TOO late for this comment: WebSocket protocol is not based on request-response, but just on "message". This makes things difficult as we've observed in some recent threads: - How to reject a message because frame size is too big? - A Pong requires same body as the Ping (is it really the most efficient way to match a "response" with a previous request??). Now imagine that WS is frame-request/frame-response based and each frame contains a "msg_id" or just "id" field (as I've suggested in other mail), so: 1) - Endpoint A sends a frame request (FIN=3D1, opcode=3D1, id=3Daiusdy87). - Endpoint B replies a 200 code in a frame response (a simple frame with id=3Daiusdy87 and code=3D200, no more). Endpoint A knows that the remote has received the frame. 2) - Endpoint A sends a frame request (FIN=3D1, opcode=3D1, id=3Dqweqwe) *very= * big. - Endpoint B does not accept so long frame so replies a 485 (or whatever) code in a frame response (a simple frame with id=3Daiusdy87 and status=3D485, and optionally a "reason" text field). 3) - Endpoint A sends a Ping (FIN=3D1, opcode=3D8, id=3Dasdasd) with *any* pay= load data. - Endpoing B replies 200 (id=3Dasdasd, code=3D200) and that's all. Advantages: - Implicit multiplexation (thanks to "id" field) which allows varios frames (fragments of different messages) being sent in parallel. - The client can know the rejection reason of a specific request (instead of receiving a close connection control frame). - Extensible: extensions can use request-response control frames to re-negotiate during an established WS session. Too late for this? Sure, I know XD --=20 I=C3=B1aki Baz Castillo From dendicott@gmail.com Mon Aug 15 12: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 DA9CA11E80E2 for ; Mon, 15 Aug 2011 12:14:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3un1JrNJV3W for ; Mon, 15 Aug 2011 12:14:37 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF99711E80D7 for ; Mon, 15 Aug 2011 12:14:36 -0700 (PDT) Received: by wyg8 with SMTP id 8so4251031wyg.31 for ; Mon, 15 Aug 2011 12:15:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RXTETqftsGy4qi31cmy5WPXJWxXMWeb19PuNtcBpJV0=; b=ChyFNbGJiUpqOuZ8NEcraoWwBzEQqUqPpPeXI4HacQ9Z8sdy/jNqeYsopa5wCAC7hj hdIrMR3xpshJC+5tTRvUwNA1yuZqHVwtOSh1UAT42j+aHaee5ffjc1MOHOI2IbBrjXuk noasEB4QH97y0uY/NTSxJnCTZmwGqw4s8/Lb8= MIME-Version: 1.0 Received: by 10.216.8.85 with SMTP id 63mr3804454weq.29.1313435722269; Mon, 15 Aug 2011 12:15:22 -0700 (PDT) Received: by 10.217.3.203 with HTTP; Mon, 15 Aug 2011 12:15:22 -0700 (PDT) In-Reply-To: References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> Date: Mon, 15 Aug 2011 15:15:22 -0400 Message-ID: From: David Endicott To: John Tamplin Content-Type: multipart/alternative; boundary=0016364d1c1fa943f904aa901522 Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 15 Aug 2011 19:14:38 -0000 --0016364d1c1fa943f904aa901522 Content-Type: text/plain; charset=ISO-8859-1 If consensus has not been reached then further discussion is the optimal choice. To recap my understanding of why we ended up with binary and text frame types: since JS (currently) has limited ability to support binary content (byte sequences) a concession to the de-facto reality is what the text type was designed to support. It would allow a "just-work" arrangement for JS clients. For those non JS client-agents that can support "pure" binary, we have the binary frame type. My choice, if it had been solely up to me, would have only an opaque frame and let the application layer decide what the content-type was. I can envision several JS client implementations that would handle this without much upset. (ie. you could include an .as_text() method on the MessageEvent or even .as_content(content-type) for a more general solution. The existing Blob/arraybuffer interface would remain as the default.) I continue to fail to see the true advantage of a text frame type - it brings content-type awareness into the WS protocol, but in a limited, kludgy manner. If a WS agent specifies a text frame, but then includes data that isn't UTF-8 ... what are the failure modes? Is it kept, but mangled? Is it discarded? Is the connection dropped? Error response? If there was only an untyped binary frame, the decision would then be left (properly) to the application layer. My opinion is that this was a bad design choice. My position is that I don't really care as it's not a big headache to work with or around. On Mon, Aug 15, 2011 at 2:24 PM, John Tamplin wrote: > On Mon, Aug 15, 2011 at 2:18 PM, Bob Gezelter wrote: > >> I agree with I?aki that the distinction between text/binary data is >> unnecessary. >> > > There were months of discussions about this point during the framing > discussion. Revisiting them at this point seems suboptimal. > > Basically, the browsers need to be able to call JS code delivering the > message, and they want a simple API for JS code to access the message. If > you left it up to the JS code to interpret it, then you would have to have a > much more complicated API and you would also leave open accessing binary > data as if it were text. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --0016364d1c1fa943f904aa901522 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If consensus has not been reached then further discussion is the optimal ch= oice.

To recap my understanding of why we ended up with = binary and text frame types: =A0since JS (currently) has limited ability to= support binary content (byte sequences) a concession to the de-facto reali= ty is what the text type was designed to support. =A0 It would allow a &quo= t;just-work" arrangement for JS clients. =A0 =A0 =A0For those non JS c= lient-agents that can support "pure" binary, we have the binary f= rame type.

My choice, if it had been=A0solely=A0up to me, would ha= ve only an opaque frame and let the application layer decide what the conte= nt-type was. =A0 I can envision several JS client implementations that woul= d handle this without much upset. =A0 (ie. you could include an .as_text() = method on the MessageEvent or even .as_content(content-type) for a more gen= eral solution. =A0 The existing Blob/arraybuffer interface would remain as = the default.)

I continue to fail to see the true advantage of a text = frame type - it brings content-type awareness into the WS protocol, but in = a limited, kludgy manner. =A0 =A0If a WS agent specifies a text frame, but = then includes data that isn't UTF-8 ... what are the failure modes? =A0= Is it kept, but mangled? =A0Is it discarded? =A0Is the connection dropped? = =A0 Error response? =A0=A0

If there was only an untyped binary frame, the decision= would then be left (properly) to the application layer. =A0 =A0
=
My opinion is that this was a bad design choice. =A0=A0

My position is that I don't really care as it's not = a big headache to work with or around.



On Mon, Aug 15, 2011 at 2:24 PM, John Tamplin <jat@google.com> wrote:
On Mon, Aug 15, 2011 at 2:18 PM, Bob Gezelter <gezelter@rlgsc.com&g= t; wrote:
I agree with I?aki that the distinction between text/binary data is
unnecessary.

There were months of= discussions about this point during the framing discussion. =A0Revisiting = them at this point seems suboptimal.
=A0
Basically, the= browsers need to be able to call JS code delivering the message, and they = want a simple API for JS code to access the message. =A0If you left it up t= o the JS code to interpret it, then you would have to have a much more comp= licated API and you would also leave open accessing binary data as if it we= re text.

--
John A. Tamplin
Software Engine= er (GWT), Google

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


--0016364d1c1fa943f904aa901522-- From dendicott@gmail.com Mon Aug 15 12:25:32 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 7810811E80EB for ; Mon, 15 Aug 2011 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.013 X-Spam-Level: X-Spam-Status: No, score=-3.013 tagged_above=-999 required=5 tests=[AWL=-0.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tvetn+uQTKjw for ; Mon, 15 Aug 2011 12:25:31 -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 4A67111E80D7 for ; Mon, 15 Aug 2011 12:25:31 -0700 (PDT) Received: by wwf5 with SMTP id 5so3481023wwf.13 for ; Mon, 15 Aug 2011 12:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=77Rz35699fKcToLHg+jN/3JV1Dt0ps1v2Ykfg6O7W30=; b=I1MyrNzaPU8H0UXNlxf/4q4uuXZg3ffbwV2QkQR452zeH2J2/vNg6jSa/Nsfo2Qeso NlFsHneUfGrOOkbObsWuNI3DPRqoLneI83deqkrUV4nCBdmGESDI0XkW+zLHTmjwfjiu y5Rog16VAgGHLsi/UZ0x4vHBvTIxloFdg+4iU= MIME-Version: 1.0 Received: by 10.216.8.85 with SMTP id 63mr3812049weq.29.1313436373535; Mon, 15 Aug 2011 12:26:13 -0700 (PDT) Received: by 10.217.3.203 with HTTP; Mon, 15 Aug 2011 12:26:13 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 15:26:13 -0400 Message-ID: From: David Endicott To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0016364d1c1f7acc8704aa903c8b Cc: hybi@ietf.org Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 19:25:32 -0000 --0016364d1c1f7acc8704aa903c8b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is a well thought-out and comprehensive analysis. However, I am against this in the strongest possible terms. Websockets is an asynchronous protocol. Introducing any request/response mechanisms introduces synchronicity and defeats one of the fundamental design goals of WS. Reliable delivery is provided by TCP. WS has no need to confirm delivery= . Message processing failure and any requirements by the application layer to synchronize or verify handling by the counter-party are the responsibility of the application(s), not of WS. On Mon, Aug 15, 2011 at 2:48 PM, I=F1aki Baz Castillo wrote= : > Hi, probably is TOO late for this comment: > > WebSocket protocol is not based on request-response, but just on > "message". This makes things difficult as we've observed in some > recent threads: > > - How to reject a message because frame size is too big? > > - A Pong requires same body as the Ping (is it really the most > efficient way to match a "response" with a previous request??). > > > Now imagine that WS is frame-request/frame-response based and each > frame contains a "msg_id" or just "id" field (as I've suggested in > other mail), so: > > > 1) > - Endpoint A sends a frame request (FIN=3D1, opcode=3D1, id=3Daiusdy87). > - Endpoint B replies a 200 code in a frame response (a simple frame > with id=3Daiusdy87 and code=3D200, no more). > > Endpoint A knows that the remote has received the frame. > > > 2) > - Endpoint A sends a frame request (FIN=3D1, opcode=3D1, id=3Dqweqwe) *ve= ry* big. > - Endpoint B does not accept so long frame so replies a 485 (or > whatever) code in a frame response (a simple frame with id=3Daiusdy87 > and status=3D485, and optionally a "reason" text field). > > > 3) > - Endpoint A sends a Ping (FIN=3D1, opcode=3D8, id=3Dasdasd) with *any* p= ayload > data. > - Endpoing B replies 200 (id=3Dasdasd, code=3D200) and that's all. > > > Advantages: > > - Implicit multiplexation (thanks to "id" field) which allows varios > frames (fragments of different messages) being sent in parallel. > - The client can know the rejection reason of a specific request > (instead of receiving a close connection control frame). > - Extensible: extensions can use request-response control frames to > re-negotiate during an established WS session. > > > Too late for this? Sure, I know XD > > > -- > I=F1aki Baz Castillo > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016364d1c1f7acc8704aa903c8b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable That is a well thought-out and comprehensive analysis. =A0 =A0However, I am= against this in the strongest possible terms. =A0=A0

We= bsockets is an asynchronous protocol. =A0 Introducing any request/response= =A0mechanisms=A0introduces=A0synchronicity=A0and defeats one of the fundame= ntal design goals of WS.

Reliable delivery is provided by TCP. =A0 =A0WS has no need = to confirm delivery.

Message processing failure an= d any requirements by the application layer to synchronize or =A0verify han= dling by the counter-party are the responsibility of the application(s), no= t of WS.




On Mon, Aug 15, 2011 at 2:48 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
Hi, probably is TOO late for this comment:<= br>
WebSocket protocol is not based on request-response, but just on
"message". This makes things difficult as we've observed in s= ome
recent threads:

- How to reject a message because frame size is too big?

- A Pong requires same body as the Ping (is it really the most
efficient way to match a "response" with a previous request??).

Now imagine that WS is frame-request/frame-response based and each
frame contains a "msg_id" or just "id" field (as I'= ve suggested in
other mail), so:


1)
- Endpoint A sends a frame request (FIN=3D1, opcode=3D1, id=3Daiusdy87). - Endpoint B replies a 200 code in a frame response (a simple frame
with id=3Daiusdy87 and code=3D200, no more).

Endpoint A knows that the remote has received the frame.


2)
- Endpoint A sends a frame request (FIN=3D1, opcode=3D1, id=3Dqweqwe) *very= * big.
- Endpoint B does not accept so long frame so replies a 485 (or
whatever) code in a frame response (a simple frame with id=3Daiusdy87
and status=3D485, and optionally a "reason" text field).


3)
- Endpoint A sends a Ping (FIN=3D1, opcode=3D8, id=3Dasdasd) with *any* pay= load data.
- Endpoing B replies 200 (id=3Dasdasd, code=3D200) and that's all.


Advantages:

- Implicit multiplexation (thanks to "id" field) which allows var= ios
frames (fragments of different messages) being sent in parallel.
- The client can know the rejection reason of a specific request
(instead of receiving a close connection control frame).
- Extensible: extensions can use request-response control frames to
re-negotiate during an established WS session.


Too late for this? Sure, I know XD


--
I=F1aki Baz Castillo
<ibc@aliax.net>
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016364d1c1f7acc8704aa903c8b-- From ibc@aliax.net Mon Aug 15 12:41: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 DBC8721F8CD0 for ; Mon, 15 Aug 2011 12:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.252 X-Spam-Level: X-Spam-Status: No, score=-2.252 tagged_above=-999 required=5 tests=[AWL=-0.359, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nskjYYRrZhtK for ; Mon, 15 Aug 2011 12:41:39 -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 6551F21F8CCE for ; Mon, 15 Aug 2011 12:41:39 -0700 (PDT) Received: by qwc23 with SMTP id 23so3413222qwc.31 for ; Mon, 15 Aug 2011 12:42:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr2831689qcb.178.1313437345158; Mon, 15 Aug 2011 12:42:25 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 12:42:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 21:42:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: David Endicott Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 19:41:40 -0000 2011/8/15 David Endicott : > Websockets is an asynchronous protocol. =C2=A0 Introducing any > request/response=C2=A0mechanisms=C2=A0introduces=C2=A0synchronicity=C2=A0= and defeats one of the > fundamental design goals of WS. I don't think it breaks so much, or at least it's not so bad. Why? most of the protocols work in such a way. > Reliable delivery is provided by TCP. Not true in presence of intermediary proxies, right? >=C2=A0WS has no need to confirm delivery. Why not? what about my examples? > Message processing failure and any requirements by the application layer = to > synchronize or =C2=A0verify handling by the counter-party are the respons= ibility > of the application(s), not of WS. I just don't agree. Confirming the receipt of a response at transport level is fully legitimate. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 12:44: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 B88AE21F8C76 for ; Mon, 15 Aug 2011 12:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=-0.356, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJfCvFV9gVTV for ; Mon, 15 Aug 2011 12:44:52 -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 332A121F8C75 for ; Mon, 15 Aug 2011 12:44:51 -0700 (PDT) Received: by qyk35 with SMTP id 35so2963129qyk.10 for ; Mon, 15 Aug 2011 12:45:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr1497538qcc.292.1313437538072; Mon, 15 Aug 2011 12:45:38 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 12:45:38 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 21:45:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: David Endicott Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 19:44:52 -0000 2011/8/15 I=C3=B1aki Baz Castillo : >> Message processing failure and any requirements by the application layer= to >> synchronize or =C2=A0verify handling by the counter-party are the respon= sibility >> of the application(s), not of WS. > > I just don't agree. Confirming the receipt of a response at transport > level is fully legitimate. Sorry, I mean "Confirming the receipt of a request at transport level is fully legitimate" --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Mon Aug 15 12:58: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 CA39611E8080 for ; Mon, 15 Aug 2011 12:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.815 X-Spam-Level: X-Spam-Status: No, score=-1.815 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Woh5YaqYcd0o for ; Mon, 15 Aug 2011 12:58:01 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id 27E9711E8073 for ; Mon, 15 Aug 2011 12:58:01 -0700 (PDT) Received: (qmail 9898 invoked from network); 15 Aug 2011 19:58:39 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 15 Aug 2011 19:58:38 -0000 Received: (qmail 14337 invoked by uid 99); 15 Aug 2011 19:58:38 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 173.52.161.53 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110815125836.ef1fc80126c74c6c202a919c41c7bb0b.8ab62b3eac.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Mon, 15 Aug 2011 12:58:36 -0700 Mime-Version: 1.0 Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 19:58:01 -0000 I?aki,=0A=0AWith all due respect, I must disagree. IMHO, "request-response"= is not=0Aan appropriate design choice for the WebSocket protocol.=0A=0AReq= uest-response would effectively make the WebSocket protocol=0Ahalf-duplex, = with the attendant resource utilization and inherent=0Alatency problems, pa= rticularly on non-local connections. Additionally,=0Asince the WebSocket pr= otocol is defined to be layered above an=0A(essentially) error-free, sequen= ce assured transport, the normal reasons=0Afor request-response are not pre= sent.=0A=0AWhat is likely needed, particularly in a multiplexed context, is= a flow=0Acontrol scheme to avoid clogging the underlying channel. However,= that=0Amechanism, which is generally described as "credit/debit" is far mo= re=0Aamenable to full-duplex, non-blocked operation than "request-response"= .=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From dendicott@gmail.com Mon Aug 15 12:58: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 02C5311E80B4 for ; Mon, 15 Aug 2011 12:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.99 X-Spam-Level: X-Spam-Status: No, score=-2.99 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ObKYbxgk0J5E for ; Mon, 15 Aug 2011 12:58:14 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E494A11E8073 for ; Mon, 15 Aug 2011 12:58:13 -0700 (PDT) Received: by wyg8 with SMTP id 8so4277676wyg.31 for ; Mon, 15 Aug 2011 12:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=H5lzEd+e9O28shhF5WzT0YfcfMnuuVMuGTcMW+2EZBQ=; b=Gbop7HIHHiqiAhX8qGRqc1DxuUNq4fW6hV8hredqSFwDGDf8ulCb/3UL/NhlY4/TUW JYTfY6VU4sLxWEp1Dko01492PLr8UnlFa17rDknVe5MXyslGZ8Oa1udd+hF6+WIe8gZA h/P6AJeWWTvDSZJzb1D8bomf2FdkBZiE6l8aY= MIME-Version: 1.0 Received: by 10.216.72.132 with SMTP id t4mr2482229wed.29.1313438339396; Mon, 15 Aug 2011 12:58:59 -0700 (PDT) Received: by 10.217.3.203 with HTTP; Mon, 15 Aug 2011 12:58:59 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 15:58:59 -0400 Message-ID: From: David Endicott To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00504502c5eba7743e04aa90b109 Cc: hybi@ietf.org Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 19:58:15 -0000 --00504502c5eba7743e04aa90b109 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 15, 2011 at 3:42 PM, I=F1aki Baz Castillo wrote= : > 2011/8/15 David Endicott : > > Websockets is an asynchronous protocol. Introducing any > > request/response mechanisms introduces synchronicity and defeats one of > the > > fundamental design goals of WS. > > I don't think it breaks so much, or at least it's not so bad. Why? > most of the protocols work in such a way. > Most protocols in widespread use are synchronous. Notable exceptions are those based on UDP. It breaks everything because it's a different paradigm. > Reliable delivery is provided by TCP. > > Not true in presence of intermediary proxies, right? > Wrong. TCP is a reliable transport protocol. Intermediary proxies messing things up is not a problem with TCP, it's a problem with the infrastructure and is comparable to router failure, cable breaks, alien intervention, etc. > WS has no need to confirm delivery. > > Why not? what about my examples? > Because TCP is a reliable transport and we know that frames will arrive or our connection is lost. > Message processing failure and any requirements by the application layer > to > > synchronize or verify handling by the counter-party are the > responsibility > > of the application(s), not of WS. > > I just don't agree. Confirming the receipt of a response at transport > level is fully legitimate. > TCP "confirms receipt" (actually adjusts transport window, but same idea) o= f the IP frames. And that is how TCP implements "reliable delivery" over "unreliable" IP. Since WS builds on TCP, we do not need to reinvent the wheel and provide reliable transport. Defining a request/response mechanism and confirming receipt of response is the responsibility of an application protocol. And you just re-invented HTTP. WS is asynchronous. If the application using WS wants to implement a request/response model, they are free to do so, but that should not be part of the base WS protocol. Asynchrony is a fundamental design goal of WebSockets. This is also reflected by the event-driven nature of the Javascript client implementation. --00504502c5eba7743e04aa90b109 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 15, 2011 at 3:42 PM, I=F1aki Baz= Castillo <ibc@aliax.= net> wrote:
2011/8/15 David Endicott <dendico= tt@gmail.com>:
> Websockets is an asynchronous protocol. =A0 Introduc= ing any
> request/response=A0mechanisms=A0introduces=A0synchronicity=A0and defea= ts one of the
> fundamental design goals of WS.

I don't think it breaks so much, or at least it's not so bad.= Why?
most of the protocols work in such a way.

Most protocols in widespread use are=A0synchronous. =A0 =A0Notable excep= tions are those based on UDP. =A0 =A0 =A0It breaks everything because it= 9;s a different paradigm. =A0


> Reliable delivery is provided by TCP.

Not true in presence of intermediary proxies, right?
=

Wrong. =A0 TCP is a reliable transport protocol. =A0 = =A0Intermediary proxies messing things up is not a problem with TCP, it'= ;s a problem with the infrastructure and is comparable to router failure, c= able breaks, alien intervention, etc.
=A0

>=A0WS has no need to confirm delivery.

Why not? what about my examples?

= Because TCP is a reliable transport and we know that frames will arrive or = our connection is lost. =A0 =A0


> Message processing failure and any requirements by t= he application layer to
> synchronize or =A0verify handling by the counter-party are the respons= ibility
> of the application(s), not of WS.

I just don't agree. Confirming the receipt of a response at trans= port
level is fully legitimate.

TCP "co= nfirms receipt" (actually adjusts transport window, but same idea) of = the IP frames. And that is how TCP implements "reliable delivery"= over "unreliable" IP. =A0 =A0 Since WS builds on TCP, we do not = need to reinvent the wheel and provide reliable transport.

Defining a request/response mechanism and confirming re= ceipt of response is the=A0responsibility=A0of an application protocol. =A0= And you just re-invented HTTP.

WS is asynchronous= . =A0 =A0If the application using WS wants to implement a request/response = model, they are free to do so, but that should not be part of the base WS p= rotocol. =A0

Asynchrony=A0is a fundamental design goal of WebSockets= . =A0 This is also reflected by the event-driven nature of the Javascript c= lient implementation.


--00504502c5eba7743e04aa90b109-- From ibc@aliax.net Mon Aug 15 13:08: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 68C1321F8D19 for ; Mon, 15 Aug 2011 13:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.246 X-Spam-Level: X-Spam-Status: No, score=-2.246 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 082od3aBnYgO for ; Mon, 15 Aug 2011 13:08:30 -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 E44CC21F8D18 for ; Mon, 15 Aug 2011 13:08:29 -0700 (PDT) Received: by qyk35 with SMTP id 35so2973837qyk.10 for ; Mon, 15 Aug 2011 13:09:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr1513814qcc.292.1313438955952; Mon, 15 Aug 2011 13:09:15 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 13:09:15 -0700 (PDT) In-Reply-To: <20110815125836.ef1fc80126c74c6c202a919c41c7bb0b.8ab62b3eac.wbe@email03.secureserver.net> References: <20110815125836.ef1fc80126c74c6c202a919c41c7bb0b.8ab62b3eac.wbe@email03.secureserver.net> Date: Mon, 15 Aug 2011 22:09:15 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 20:08:30 -0000 2011/8/15 Bob Gezelter : > Request-response would effectively make the WebSocket protocol > half-duplex, with the attendant resource utilization and inherent > latency problems, particularly on non-local connections. Hi, why latency? I=C2=A1m speaking about very small response (just an id and status field). Also, I'm not mandating that a second request requires confirmation (response) of a previous request. Varios requests can be sent in parallel without waiting for each request's reponse. > What is likely needed, particularly in a multiplexed context, is a flow > control scheme to avoid clogging the underlying channel. However, that > mechanism, which is generally described as "credit/debit" is far more > amenable to full-duplex, non-blocked operation than "request-response". What about the "id" field I suggest for achieving it? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 15 13:11: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 AD63821F8D32 for ; Mon, 15 Aug 2011 13:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.242 X-Spam-Level: X-Spam-Status: No, score=-2.242 tagged_above=-999 required=5 tests=[AWL=-0.349, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veqfOW8qTatE for ; Mon, 15 Aug 2011 13:11:16 -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 2C33A21F8D23 for ; Mon, 15 Aug 2011 13:11:16 -0700 (PDT) Received: by qwc23 with SMTP id 23so3426590qwc.31 for ; Mon, 15 Aug 2011 13:12:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr1515594qcc.292.1313439122238; Mon, 15 Aug 2011 13:12:02 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 13:12:02 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Aug 2011 22:12:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: David Endicott Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 20:11:16 -0000 2011/8/15 David Endicott : >> > Reliable delivery is provided by TCP. >> >> Not true in presence of intermediary proxies, right? > > Wrong. =C2=A0 TCP is a reliable transport protocol. =C2=A0 =C2=A0Intermed= iary proxies > messing things up is not a problem with TCP, it's a problem with the > infrastructure and is comparable to router failure, cable breaks, alien > intervention, etc. I don't agree at all. TCP is a end-to-end protocol just in case intermediaries are IP routers. But when the intermediary is an HTTP proxy then there are two TCP connections (from client to HTTP proxy, and from HTTP proxy to the server). >> >=C2=A0WS has no need to confirm delivery. >> >> Why not? what about my examples? > > Because TCP is a reliable transport and we know that frames will arrive o= r > our connection is lost. Same argument as above. > Asynchrony=C2=A0is a fundamental design goal of WebSockets. =C2=A0 This i= s also > reflected by the event-driven nature of the Javascript client > implementation. Again, I don't see how a request-response protocol cannot be event-driven. Of course it can be. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 15 13:38: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 0755621F8C89 for ; Mon, 15 Aug 2011 13:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=-0.313, BAYES_00=-2.599, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YP3i7F7BhOLy for ; Mon, 15 Aug 2011 13:38:52 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 4405421F8C59 for ; Mon, 15 Aug 2011 13:38:52 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.115]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Mon, 15 Aug 2011 13:39:38 -0700 From: Tobias Oberstein To: Bob Gezelter , "hybi@ietf.org" Date: Mon, 15 Aug 2011 13:39:37 -0700 Thread-Topic: [hybi] WS is not a request-response protocol (which would make things easier) Thread-Index: AcxbhcRBcQaCLqsNRmuZofqzv3NhdQABa518 Message-ID: In-Reply-To: <20110815125836.ef1fc80126c74c6c202a919c41c7bb0b.8ab62b3eac.wbe@email03.secureserver.net> Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 20:38:53 -0000 > With all due respect, I must disagree. IMHO, "request-response" is not > an appropriate design choice for the WebSocket protocol. couldn't agree more. > What is likely needed, particularly in a multiplexed context, is a flow > control scheme to avoid clogging the underlying channel. However, that > mechanism, which is generally described as "credit/debit" is far more > amenable to full-duplex, non-blocked operation than "request-response". aren't there 2 things involved? 1. access to link (underlying channel) must be fair .. the clogging issue .= . frames must be small enough to do that 2. there should be flow-control between both ends of a logical channel .. the credit stuff if you agree, what is appropriate terms to distinguish those 2? i.e. congestion control vs flow control? From bruce@callenish.com Mon Aug 15 15:57: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 C536E21F8CDB for ; Mon, 15 Aug 2011 15:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.663 X-Spam-Level: X-Spam-Status: No, score=-1.663 tagged_above=-999 required=5 tests=[AWL=-0.923, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8KIQr5XDtXD for ; Mon, 15 Aug 2011 15:57:37 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 6711A21F8C9C for ; Mon, 15 Aug 2011 15:57:37 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qt66w-00089W-Dv; Mon, 15 Aug 2011 15:58:22 -0700 Message-ID: <4E49A492.2090208@callenish.com> Date: Mon, 15 Aug 2011 15:58:26 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Patrick McManus References: <4E455C73.5070208@callenish.com> <1313174401.1816.270.camel@ds9> In-Reply-To: <1313174401.1816.270.camel@ds9> Content-Type: text/plain; charset=UTF-8; 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] Message too large does not eliminate need for frame too large (was CONSENSUS CALL) 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, 15 Aug 2011 22:57:37 -0000 On 12/08/2011 11:40 AM, Patrick McManus wrote: > If there was a use case we wanted to support that required fragmenting > on transmit, then we would fragment. I expect mux will be that case. It > is a mistake to read Tobias's comments as a statement that firefox won't > ever send fragments. > Thanks for the clarification. Can I ask for a bit more info, though? 1) If you received a close message with a "Frame Too Large" status, would the Firefox implementation ever retry the connection with a smaller frame size? 2) If the spec included the language about maximum frame size that is proposed (the "MAY" and "SHOULD NOT"), would Firefox honour a request for a particular maximum frame size? From bruce@callenish.com Mon Aug 15 16:14: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 E4CCC21F8CE0 for ; Mon, 15 Aug 2011 16:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x9Tq9UaZbOR for ; Mon, 15 Aug 2011 16:14:43 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE921F8CDF for ; Mon, 15 Aug 2011 16:14:43 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qt6NU-0001zB-Ky; Mon, 15 Aug 2011 16:15:28 -0700 Message-ID: <4E49A895.6000509@callenish.com> Date: Mon, 15 Aug 2011 16:15:33 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> In-Reply-To: <4E4637D0.2030500@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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] CONSENSUS CALL / Frame too big not possible to occur 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, 15 Aug 2011 23:14:44 -0000 On 13/08/2011 1:37 AM, "Andy Green (林安廸)" wrote: > On 08/12/2011 05:47 PM, Somebody in the thread at some point said: >> On 12/08/2011 5:51 AM, Tobias Oberstein wrote: >>>>> one problem is: value is fixed for lifetime of session .. can't be >>>>> dynamic/adaptive >>>> Why should it be adaptative? >>> example: a muxing extension wants to dynamically adjust it's frame size >>> depending on up/downlink bandwidth/delay to target a tradeoff between >>> latency/efficiency. >> >> Size limits on extensions have nothing to do with limitations of the >> underlying implementation. Why do people keep conflating the two issues? > > Because emails keep coming which look like they confused the general > and common limitation on message length found in every real browser, > and frame processing. We are after all talking about an error calling > itself *frame* too big, which is not possible --> You keep saying this, but that doesn't make it any less incorrect. A frame can be too large for any number of reasons: latency, denial of service limitations, etc. Requirements for a particular situation trump the theoretical limits of a standard every time. So long as the standard does not require that all frame sizes be handled in the same way, it is a legitimate implementation decision to choose to handle a particular frame size by closing the connection. That behaviour is not broken nor bogus, it is completely conforming to the specification. Point me to ANY portion of the specification that prohibits it. And if it is conforming, there are going to be more people than me choosing to implement that way. And their implementations will be just as correct as yours is. > > Because frame processing is performed packet by packet, with the > single exception of this proposed frame signing extension, actually > the frame layer just deals with a packet at a time. It can do. It doesn't have to. There is nothing in the specification that requires that behaviour. As I have said many times before, and say here for the last time. From sdw@lig.net Mon Aug 15 16:17: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 C11DB21F8C7D for ; Mon, 15 Aug 2011 16:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nxX0FRzP-ipQ for ; Mon, 15 Aug 2011 16:17:22 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id B57BA21F8C7A for ; Mon, 15 Aug 2011 16:17:22 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id C47CBAB5DB0 for ; Mon, 15 Aug 2011 16:28:52 -0700 (PDT) Message-ID: <4E49A930.8090002@lig.net> Date: Mon, 15 Aug 2011 16:18:08 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040707010203010808090702" Subject: Re: [hybi] Binary/Text Distinction 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, 15 Aug 2011 23:17:23 -0000 This is a multi-part message in MIME format. --------------040707010203010808090702 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I have a lot of experience with implementing and designing text, structured data, media, binary XML (i.e. W3C EXI), and otherwise binary protocols in C++, Java, and some other environments. Based on that experience, I strongly suggest to make any text-only mode a subset of the default binary case, or ideally just a convention. I would vote for UTF-8, no BOM as the de facto "binary" text representation. I'm not very well versed on traditional limitations and headaches of Javascript in browsers (although I'm doing js development now and getting there), however I tend to think that the following demonstrates that binary can't really be much of a problem for modern Javascript in a modern browser: http://jslinux.org/ I would suggest that minor issues with ease of programming today for text vs. binary protocol / application payloads can likely be solved by small libraries and/or language improvements. The reality is that this protocol, if done right, will be used for all kinds of things in all types of languages. It should be designed properly for that endpoint. Stephen On 8/15/11 12:15 PM, David Endicott wrote: > If consensus has not been reached then further discussion is the optimal choice. > > To recap my understanding of why we ended up with binary and text frame types: since JS (currently) has limited ability to > support binary content (byte sequences) a concession to the de-facto reality is what the text type was designed to support. It > would allow a "just-work" arrangement for JS clients. For those non JS client-agents that can support "pure" binary, we have > the binary frame type. > > My choice, if it had been solely up to me, would have only an opaque frame and let the application layer decide what the > content-type was. I can envision several JS client implementations that would handle this without much upset. (ie. you could > include an .as_text() method on the MessageEvent or even .as_content(content-type) for a more general solution. The existing > Blob/arraybuffer interface would remain as the default.) > > I continue to fail to see the true advantage of a text frame type - it brings content-type awareness into the WS protocol, but in > a limited, kludgy manner. If a WS agent specifies a text frame, but then includes data that isn't UTF-8 ... what are the > failure modes? Is it kept, but mangled? Is it discarded? Is the connection dropped? Error response? > > If there was only an untyped binary frame, the decision would then be left (properly) to the application layer. > > My opinion is that this was a bad design choice. > > My position is that I don't really care as it's not a big headache to work with or around. > > > > On Mon, Aug 15, 2011 at 2:24 PM, John Tamplin > wrote: > > On Mon, Aug 15, 2011 at 2:18 PM, Bob Gezelter > wrote: > > I agree with I?aki that the distinction between text/binary data is > unnecessary. > > > There were months of discussions about this point during the framing discussion. Revisiting them at this point seems suboptimal. > Basically, the browsers need to be able to call JS code delivering the message, and they want a simple API for JS code to > access the message. If you left it up to the JS code to interpret it, then you would have to have a much more complicated API > and you would also leave open accessing binary data as if it were text. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer --------------040707010203010808090702 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I have a lot of experience with implementing and designing text, structured data, media, binary XML (i.e. W3C EXI), and otherwise binary protocols in C++, Java, and some other environments.  Based on that experience, I strongly suggest to make any text-only mode a subset of the default binary case, or ideally just a convention.  I would vote for UTF-8, no BOM as the de facto "binary" text representation.

I'm not very well versed on traditional limitations and headaches of Javascript in browsers (although I'm doing js development now and getting there), however I tend to think that the following demonstrates that binary can't really be much of a problem for modern Javascript in a modern browser:

http://jslinux.org/

I would suggest that minor issues with ease of programming today for text vs. binary protocol / application payloads can likely be solved by small libraries and/or language improvements.

The reality is that this protocol, if done right, will be used for all kinds of things in all types of languages.  It should be designed properly for that endpoint.

Stephen

On 8/15/11 12:15 PM, David Endicott wrote:
If consensus has not been reached then further discussion is the optimal choice.

To recap my understanding of why we ended up with binary and text frame types:  since JS (currently) has limited ability to support binary content (byte sequences) a concession to the de-facto reality is what the text type was designed to support.   It would allow a "just-work" arrangement for JS clients.      For those non JS client-agents that can support "pure" binary, we have the binary frame type.

My choice, if it had been solely up to me, would have only an opaque frame and let the application layer decide what the content-type was.   I can envision several JS client implementations that would handle this without much upset.   (ie. you could include an .as_text() method on the MessageEvent or even .as_content(content-type) for a more general solution.   The existing Blob/arraybuffer interface would remain as the default.)

I continue to fail to see the true advantage of a text frame type - it brings content-type awareness into the WS protocol, but in a limited, kludgy manner.    If a WS agent specifies a text frame, but then includes data that isn't UTF-8 ... what are the failure modes?  Is it kept, but mangled?  Is it discarded?  Is the connection dropped?   Error response?   

If there was only an untyped binary frame, the decision would then be left (properly) to the application layer.    

My opinion is that this was a bad design choice.   

My position is that I don't really care as it's not a big headache to work with or around.



On Mon, Aug 15, 2011 at 2:24 PM, John Tamplin <jat@google.com> wrote:
On Mon, Aug 15, 2011 at 2:18 PM, Bob Gezelter <gezelter@rlgsc.com> wrote:
I agree with I?aki that the distinction between text/binary data is
unnecessary.

There were months of discussions about this point during the framing discussion.  Revisiting them at this point seems suboptimal.
 
Basically, the browsers need to be able to call JS code delivering the message, and they want a simple API for JS code to access the message.  If you left it up to the JS code to interpret it, then you would have to have a much more complicated API and you would also leave open accessing binary data as if it were text.

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

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




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


--
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
--------------040707010203010808090702-- From sdw@lig.net Mon Aug 15 16:37: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 32D7521F8C64 for ; Mon, 15 Aug 2011 16:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.006 X-Spam-Level: X-Spam-Status: No, score=-1.006 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, J_CHICKENPOX_33=0.6, SARE_SUB_NEED_REPLY=0.784] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jciyV2kSJRiI for ; Mon, 15 Aug 2011 16:37:28 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8A521F8C5A for ; Mon, 15 Aug 2011 16:37:28 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 62975AB5DB0 for ; Mon, 15 Aug 2011 16:49:01 -0700 (PDT) Message-ID: <4E49ADEA.1060404@lig.net> Date: Mon, 15 Aug 2011 16:38:18 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110815125836.ef1fc80126c74c6c202a919c41c7bb0b.8ab62b3eac.wbe@email03.secureserver.net> In-Reply-To: <20110815125836.ef1fc80126c74c6c202a919c41c7bb0b.8ab62b3eac.wbe@email03.secureserver.net> Content-Type: multipart/alternative; boundary="------------000206060605050500090203" Subject: Re: [hybi] WS is not a request-response protocol (which would make things easier) 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, 15 Aug 2011 23:37:29 -0000 This is a multi-part message in MIME format. --------------000206060605050500090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/15/11 12:58 PM, Bob Gezelter wrote: > I?aki, > > With all due respect, I must disagree. IMHO, "request-response" is not > an appropriate design choice for the WebSocket protocol. > > Request-response would effectively make the WebSocket protocol > half-duplex, with the attendant resource utilization and inherent I don't believe that anyone intended "request-response" here to mean half-duplex RPC-style communication. We've had far too much of that for too long and hopefully everyone sees the errors there. You can still track messages sent in an async, pipelined, message oriented fashion to know how much is in the pipeline and when something gets processed. > latency problems, particularly on non-local connections. Additionally, > since the WebSocket protocol is defined to be layered above an > (essentially) error-free, sequence assured transport, the normal reasons > for request-response are not present. That is only true for a 1 tier, client-server application use. As soon as you have N-tier, you have the case where a message may be received by an intermediary but lost before reaching the endpoint. There are two real solutions: enforce true fire and forget semantics which require strong transactional persistence in the face of restarts, etc., and end to end notification of some kind. The former generally is expensive in various ways and often results in synchronous or semi-synchronous operation. The latter supports lightweight, message oriented operation and allows the endpoints to understand and manage what's going on. Any bulk transport of data through an N-tier message oriented system requires end to end flow control and success signalling. Anything else will have chronic problems with performance and/or resource overrun (out of memory, etc.). Something RabbitMQ for Wall Street messaging is fine when all of the messages are tiny and the bandwidth is huge. It's normal modes of usage are completely wrong for bulk transfer over congested pipes. > > What is likely needed, particularly in a multiplexed context, is a flow > control scheme to avoid clogging the underlying channel. However, that > mechanism, which is generally described as "credit/debit" is far more > amenable to full-duplex, non-blocked operation than "request-response". There are various names for credit/debit, rate-based protocols, end-to-end flow control, etc. They, in effect, result in some type of response to the sender similar to, but sometimes better than, TCP success feedback. Note that you don't need anything synchronous (up to the point where you have exhausted your credit / maximum data in flight), or an ack for each message, or anything expensive. You can piggyback, combine, etc. in a tunable way. My favorite method is to have each sender explicitly request an ack when desired as part of the protocol stream. This gives maximum flexibility and allows changing parameters and overhead on the fly. Note that while it may be advantageous to build this capability into the protocol, given certain constraints it is also possible to layer it by convention. For instance, if message order is guaranteed, then you can send small "ack request" messages periodically between other messages. The semantics could be to send back nack on any error or just simply to ack, perhaps with message count or serial #s. This could be one way to handle detection of "message too big to be processed": If an ack of a sentinal before a big message is received, and one after that indicates that the big message was skipped or reports actual intervening error codes, then you could deduce that the message was too big. Unless messages are very small already, I think that a per-message ID is not a bad idea, perhaps differentially encoded (my.app.stream1.45, .46, .47). Having a unique ID in email messages is extremely useful. Here, perhaps a unique connection / stream ID, channel, message ID would be useful, at least in debug mode. Data bloat is the biggest argument against this, but it would be noise in a typical web app protocol these days. > > - Bob Gezelter, http://www.rlgsc.com > > sdw -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer --------------000206060605050500090203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/15/11 12:58 PM, Bob Gezelter wrote: 
I?aki,

With all due respect, I must disagree. IMHO, "request-response" is not
an appropriate design choice for the WebSocket protocol.

Request-response would effectively make the WebSocket protocol
half-duplex, with the attendant resource utilization and inherent

I don't believe that anyone intended "request-response" here to mean half-duplex RPC-style communication.  We've had far too much of that for too long and hopefully everyone sees the errors there.  You can still track messages sent in an async, pipelined, message oriented fashion to know how much is in the pipeline and when something gets processed.

latency problems, particularly on non-local connections. Additionally,
since the WebSocket protocol is defined to be layered above an
(essentially) error-free, sequence assured transport, the normal reasons
for request-response are not present.

That is only true for a 1 tier, client-server application use.  As soon as you have N-tier, you have the case where a message may be received by an intermediary but lost before reaching the endpoint.  There are two real solutions: enforce true fire and forget semantics which require strong transactional persistence in the face of restarts, etc., and end to end notification of some kind.  The former generally is expensive in various ways and often results in synchronous or semi-synchronous operation.  The latter supports lightweight, message oriented operation and allows the endpoints to understand and manage what's going on.

Any bulk transport of data through an N-tier message oriented system requires end to end flow control and success signalling.  Anything else will have chronic problems with performance and/or resource overrun (out of memory, etc.).  Something RabbitMQ for Wall Street messaging is fine when all of the messages are tiny and the bandwidth is huge.  It's normal modes of usage are completely wrong for bulk transfer over congested pipes.


What is likely needed, particularly in a multiplexed context, is a flow
control scheme to avoid clogging the underlying channel. However, that
mechanism, which is generally described as "credit/debit" is far more
amenable to full-duplex, non-blocked operation than "request-response".

There are various names for credit/debit, rate-based protocols, end-to-end flow control, etc.  They, in effect, result in some type of response to the sender similar to, but sometimes better than, TCP success feedback.  Note that you don't need anything synchronous (up to the point where you have exhausted your credit / maximum data in flight), or an ack for each message, or anything expensive.  You can piggyback, combine, etc. in a tunable way.  My favorite method is to have each sender explicitly request an ack when desired as part of the protocol stream.  This gives maximum flexibility and allows changing parameters and overhead on the fly.

Note that while it may be advantageous to build this capability into the protocol, given certain constraints it is also possible to layer it by convention.  For instance, if message order is guaranteed, then you can send small "ack request" messages periodically between other messages.  The semantics could be to send back nack on any error or just simply to ack, perhaps with message count or serial #s.  This could be one way to handle detection of "message too big to be processed": If an ack of a sentinal before a big message is received, and one after that indicates that the big message was skipped or reports actual intervening error codes, then you could deduce that the message was too big.

Unless messages are very small already, I think that a per-message ID is not a bad idea, perhaps differentially encoded (my.app.stream1.45, .46, .47).
Having a unique ID in email messages is extremely useful.  Here, perhaps a unique connection / stream ID, channel, message ID would be useful, at least in debug mode.  Data bloat is the biggest argument against this, but it would be noise in a typical web app protocol these days.


- Bob Gezelter, http://www.rlgsc.com

sdw
--
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer

--------------000206060605050500090203-- From gregw@intalio.com Mon Aug 15 16:50: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 93C4121F8CA6 for ; Mon, 15 Aug 2011 16:50:56 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7oqMhnVggKZ for ; Mon, 15 Aug 2011 16:50:55 -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 7DE5321F8CA9 for ; Mon, 15 Aug 2011 16:50:55 -0700 (PDT) Received: by vws12 with SMTP id 12so5376670vws.31 for ; Mon, 15 Aug 2011 16:51:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.21.201 with SMTP id x9mr4262751vde.363.1313452301878; Mon, 15 Aug 2011 16:51:41 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Mon, 15 Aug 2011 16:51:41 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422BFBFC64E@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFBFC64E@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 16 Aug 2011 09:51:41 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Flat MUX 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, 15 Aug 2011 23:50:56 -0000 Tobias, This appears workable. However, I would prefer a MUX system that actually uses websocket frames as designed rather than inventing new framing that is based on a layer above WS messages. We sweated virtual blood to agree on the framing mechanism that would be flexible enough for all/most concerns - and it would be a shame that if on the first hurdle we decided that intermediaries could not respect the requirements for the spec and discarded the flexibility of the framing system we have. WS framing allows extension data per frame. This is sufficient to tag each frame with a channel. WS framing allows interleaving if there is an extension to sort out the interleaving. WS framing does not allow intermediaries that do not understand the extensions to fragment or aggregate frames. Now, there may be real technical reasons to go for MUX as a layer on top of ws messages - but allowing poor intermediary implementations should not be one of them. cheers On 15 August 2011 20:52, Tobias Oberstein wrote: > Here is a variant of muxing that > > - does not wrap/nest complete WS connections (recursively) inside WS or > reframe the payload of MUXed messages > > - does not require intermediaries to understand message interleaving or > adjust it's fragmentation/coalescing logic > > - uses 1 reserved Opcode and 2 reserved bits > > > The approach is to pack a MUXed message specific FIN bit into reserved bit 2: > > RSV2 = MUX FIN > > 0 = non-final MUX message frame > 1 = final MUX message frame > > On the base WS layer, all data is sent (by endpoints) using a new Opcode 0x8 and FIN = 1. > > The extension data of a Opcode 0x8 frame has the channel ID, which > is an integer encoded the same as the payload length in base WS. > > The payload type of a muxed message (text or binary) is signaled in > the first frame of the MUXed message > > RSV3 = MUX Payload Type (0 = binary, 1 = text) > > For a MUX continuation frame (MUX FIN = 0 after first frame) the RSV3 bit is 0. > > An example of 2 MUXed messages interleaved (a text message on chn 23 > and a binary message on chn 70): > > chn23, text: "data23_a-data23_b-data23_c-data23_d" > chn70, binary: "data70_a-data70_b-data70_c" > > WS base layer frames: > > FIN, Opcode, RSV2 (MUX FIN), RSV3 (MUX Payload Type), Channel ID, Payload > > 1, 0x8, 0, 1, 23, "data23_a-" > 1, 0x8, 0, 0, 70, "data70_a-" > 1, 0x8, 0, 0, 70, "data70_b-" > 1, 0x8, 0, 0, 23, "data23_b-" > 1, 0x8, 1, 0, 70, "data70_c" > 1, 0x8, 0, 0, 23, "data23_c-" > 1, 0x8, 1, 0, 23, "data23_d" > > The reason to choose RSV 2 and 3 is to allow compatibility with the per-frame > compression extension proposed by Takeshi which uses RSV 1 to signal whether a frame > is compressed or not. > > Since there is no interleaving on the base WS layer to understand, intermediaries > don't get confused. > > Moreoever, since endpoints are required to send Mux messages unfragmented, > intermediaries can fragment those (and subsequent intermediaries could coalesce again). > > The receiving endpoint can just reassemble the fragments that make up a MUX frame. > > Mux message frame sent by endpoint: > > 1, 0x8, 0, 0, 23, "data23_b-" > > Fragmented frames received by endpoint: > > 0, 0x8, 0, 0, 23, "dat" > 0, 0x8, ?, ?, "a2" > 1, 0x8, ?, ?, "3_b-" > > The intermediary can set the RSV bits of the fragments following the first arbitrary. > The receiver only cares about RSV for the first base WS frame of a Mux frame. > > The question of channel setup/teardown and channel credit replenishment > signaling is somewhat orthogonal .. tbd. > > Is there a catch I missed? > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From gregw@intalio.com Mon Aug 15 17:10: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 AFE4021F8C29 for ; Mon, 15 Aug 2011 17:10:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aoK-54yzI9cj for ; Mon, 15 Aug 2011 17:10:16 -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 1BE4021F8C1E for ; Mon, 15 Aug 2011 17:10:16 -0700 (PDT) Received: by vxi29 with SMTP id 29so5347735vxi.31 for ; Mon, 15 Aug 2011 17:10:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.95.163 with SMTP id dl3mr4315542vdb.229.1313453439317; Mon, 15 Aug 2011 17:10:39 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Mon, 15 Aug 2011 17:10:39 -0700 (PDT) In-Reply-To: References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> Date: Tue, 16 Aug 2011 10:10:39 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 00:10:16 -0000 On 16 August 2011 05:15, David Endicott wrote: > My opinion is that this was a bad design choice. > My position is that I don't really care as it's not a big headache to work > with or around. +1 It is a poor design, but it was a necessary compromise to lose the two different framings we had for text and binary messages (YES, for those new to the WG, we really did have totally different message framing depending on the content type of the message!!!!). The cost now is just the allocation of an opcode and a bit of split personality in the APIs - which is a price that I'm prepared to pay to avoid another round of design by war of attrition. I can say the same for the 2^64 max frame size. I can't justify it - I expect few implementations will handle it - I expect even fewer will ever send frames larger that 2^16, but I'm prepared to accept it in the spec just so we can make progress. cheers From gregw@intalio.com Mon Aug 15 17:20: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 D872F11E8096 for ; Mon, 15 Aug 2011 17:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.769 X-Spam-Level: X-Spam-Status: No, score=-2.769 tagged_above=-999 required=5 tests=[AWL=-0.092, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj14ppe5FfDT for ; Mon, 15 Aug 2011 17:20:05 -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 473CD11E808B for ; Mon, 15 Aug 2011 17:20:05 -0700 (PDT) Received: by vws12 with SMTP id 12so5392464vws.31 for ; Mon, 15 Aug 2011 17:20:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.88.2 with SMTP id bc2mr4252378vdb.162.1313454051663; Mon, 15 Aug 2011 17:20:51 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Mon, 15 Aug 2011 17:20:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 10:20:51 +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] Multiplexing (suggesting sequence number in each frame) 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, 16 Aug 2011 00:20:06 -0000 Inaki, a message ID would certainly allow message fragments to be interleaved and then disentangled. However, it would not support another important aspect of MUX, namely routing the different messages to different endpoints. regards On 16 August 2011 00:06, I=F1aki Baz Castillo wrote: > Hi, I recognize that I don't know what the purpose of the MUX > extension is (a Google extension?). But I suppose it intends to allow > sending frames (fragments) of different WS messages at the same time. > > It could be easily achieved if each frame contains message sequence > number or just a message identificator (a random integer). So a client > could send frames belonging to different messages in parallel: > > > - frame 1: =A0 =A0 message_id =3D 123, =A0FIN=3D0, =A0opcode=3D1 > - frame 2: =A0 =A0 message_id =3D 961, =A0FIN=3D0, =A0opcode=3D1 > - frame 3: =A0 =A0 message_id =3D 123, =A0FIN=3D0, =A0opcode=3D0 > - frame 4: =A0 =A0 message_id =3D 123, =A0FIN=3D0, =A0opcode=3D0 > - frame 5: =A0 =A0 message_id =3D 961, =A0FIN=3D0, =A0opcode=3D0 > - frame 6: =A0 =A0 message_id =3D 123, =A0FIN=3D1, =A0opcode=3D0 > - frame 7: =A0 =A0 message_id =3D 961, =A0FIN=3D1, =A0opcode=3D0 > > > Doesn't it seem easy? From ibc@aliax.net Mon Aug 15 17:22: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 98D1F21F8BF8 for ; Mon, 15 Aug 2011 17:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8IICykrzAN0 for ; Mon, 15 Aug 2011 17:22:25 -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 1803021F8BE5 for ; Mon, 15 Aug 2011 17:22:25 -0700 (PDT) Received: by qyk34 with SMTP id 34so1085068qyk.10 for ; Mon, 15 Aug 2011 17:23:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.12 with SMTP id t12mr2845784qci.254.1313454191676; Mon, 15 Aug 2011 17:23:11 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Mon, 15 Aug 2011 17:23:11 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 02:23:11 +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] Multiplexing (suggesting sequence number in each frame) 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, 16 Aug 2011 00:22:25 -0000 2011/8/16 Greg Wilkins : > a message ID would certainly allow message fragments to be interleaved > and then disentangled. > However, it would not support another important aspect of MUX, namely > routing the different messages to different endpoints. Ok, but which of those features should be part of the core protocol and which want an extension? --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Mon Aug 15 17:26: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 B313821F8D12 for ; Mon, 15 Aug 2011 17:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.768 X-Spam-Level: X-Spam-Status: No, score=-2.768 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 84vhanmfzqGh for ; Mon, 15 Aug 2011 17:26:08 -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 3131E21F8D11 for ; Mon, 15 Aug 2011 17:26:08 -0700 (PDT) Received: by vxi29 with SMTP id 29so5356051vxi.31 for ; Mon, 15 Aug 2011 17:26:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.139 with SMTP id dc11mr3960636vdb.28.1313454414804; Mon, 15 Aug 2011 17:26:54 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Mon, 15 Aug 2011 17:26:54 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 10:26:54 +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] Multiplexing (suggesting sequence number in each frame) 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, 16 Aug 2011 00:26:08 -0000 On 16 August 2011 10:23, I=F1aki Baz Castillo wrote: > 2011/8/16 Greg Wilkins : >> a message ID would certainly allow message fragments to be interleaved >> and then disentangled. >> However, it would not support another important aspect of MUX, namely >> routing the different messages to different endpoints. > > Ok, but which of those features should be part of the core protocol > and which want an extension? Currently it is proposed that both message interleaving and virtual channels will be supported in an extension. While there is significant support for MUX to be in the base protocol, I think it is more productive to get on with a design (in an extension) and wide spread implementations. cheers From derhoermi@gmx.net Mon Aug 15 17:51:05 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 3A2C121F8C87 for ; Mon, 15 Aug 2011 17:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.127 X-Spam-Level: X-Spam-Status: No, score=-3.127 tagged_above=-999 required=5 tests=[AWL=-1.128, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gfR5uJ9B1Td for ; Mon, 15 Aug 2011 17:51:04 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 09B2A21F8C85 for ; Mon, 15 Aug 2011 17:51:03 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2011 00:51:49 -0000 Received: from dslb-094-223-181-191.pools.arcor-ip.net (EHLO HIVE) [94.223.181.191] by mail.gmx.net (mp011) with SMTP; 16 Aug 2011 02:51:49 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1+YBhIUCHmY/hhtr5f/UF3Fss1zPwZfx7cTUagXQB ZCfyDMlWm88l0V From: Bjoern Hoehrmann To: "Bob Gezelter" Date: Tue, 16 Aug 2011 02:51:48 +0200 Message-ID: <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> In-Reply-To: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: hybi@IETF.ORG Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 00:51:05 -0000 * Bob Gezelter wrote: >I agree with I?aki that the distinction between text/binary data is >unnecessary. Similarly, I agree with Dave Endicott's and I?aki's >comments about the mixing of different classes of functionality in the >WebSocket protocol. Not having this distinction in the protocol would mean the information is lost in transit and has to be coordinated out of protocol. I know of no notable system where this has not caused problems. On the contrary, it is common practise now to design systems to maintain the distinction, new programming languages for instance typically have dedicated types for binary data and separate types for text data. If you want this to be reconsidered, show us systems where the need to convey this meta data out of band has not lead to problems and has not lead to complaints about how unwiedly use of the system is; or systems where rates of both are very low, or systems where this distinction is maintained where that has lead to something worse. Note that the general expectation is that WebSocket-based protocols do not enjoy the level of coordination, documentation, standardization, we would expect of TCP-based protocols. With TCP you might say "Oh, HTTP will handle that" (and HTTP might say media types handle that) but the asumptions are do not involve standardized lower levels in the same way. JavaScript applications are a primary target for the protocol. In JS, the distinction between text and binary data is maintained through its data types. Your argument is that instead of letting computers maintain the distinction, humans should expend extra effort to re-establish it. I understand not liking the distinction, but that doesn't make it wrong. -- 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 derhoermi@gmx.net Mon Aug 15 17:57: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 692AA21F8C4E for ; Mon, 15 Aug 2011 17:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.393 X-Spam-Level: X-Spam-Status: No, score=-3.393 tagged_above=-999 required=5 tests=[AWL=-0.794, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wud-9mJG3HB7 for ; Mon, 15 Aug 2011 17:57:57 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 4EA8021F8B28 for ; Mon, 15 Aug 2011 17:57:57 -0700 (PDT) Received: (qmail invoked by alias); 16 Aug 2011 00:58:42 -0000 Received: from dslb-094-223-181-191.pools.arcor-ip.net (EHLO HIVE) [94.223.181.191] by mail.gmx.net (mp058) with SMTP; 16 Aug 2011 02:58:42 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX19xUeNiCelxSb4g3/Sbsmsjb0UDWEFTR//JmwzoFW RREdku/fv7SyyW From: Bjoern Hoehrmann To: John Tamplin Date: Tue, 16 Aug 2011 02:58:42 +0200 Message-ID: References: <634914A010D0B943A035D226786325D422BFBFC68C@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Question about payload length 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, 16 Aug 2011 00:57:58 -0000 * John Tamplin wrote: >The point is what is the value over allowing 2^64 frames rather than 2^63? > If there is no value, then why do something which is known to complicate >some implementations? You are likely to wind up with implementations that >use Java long anyway rather than sacrifice performance for the frames that >will actually be sent, which leaves open an attack where some >implementations interpret the frame length differently than other >implementations. Implementations that would have no trouble supporting frames larger than 2^63 byte would have to add a check for this error or code to ignore the most significant bit, which is more complicated than allowing this. And implementations that have trouble supporting this would have to have the check (or workarounds) either way (in code it may be for free, but you'd get more or more complicated instructions either way). I could not immediately find what implementations are supposed to do if they encounter frames where the bit in question is set. It's not clear to me that disallowing such frames is the best way to communicate what implementations are expected to do with them, even if this is defined in the specification (some would think, since it's not allowed, they do not have to worry about the case, for instance). (I note that more than 2^63 bytes in a frame would amount to something like downloading all data stored on hard drives in the Netherlands and would take a year to move through the world's largest exchange point at peak throughput levels at the moment; it's not reasonable to send this amount of data, so disallowing sending it would not guide implementers in what they should put in their code; it's "yeah, whatever".) -- 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 Martin.Thomson@commscope.com Mon Aug 15 18:01: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 19F3521F8C72 for ; Mon, 15 Aug 2011 18:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDUceHdNByiY for ; Mon, 15 Aug 2011 18:01:45 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3FF21F873A for ; Mon, 15 Aug 2011 18:01:45 -0700 (PDT) X-AuditID: 0a0404e9-b7b99ae000002f72-64-4e49c1b12741 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 75.02.12146.1B1C94E4; Mon, 15 Aug 2011 20:02:41 -0500 (CDT) Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 15 Aug 2011 20:02:32 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 16 Aug 2011 09:00:52 +0800 From: "Thomson, Martin" To: Bjoern Hoehrmann , Bob Gezelter Date: Tue, 16 Aug 2011 09:00:50 +0800 Thread-Topic: [hybi] Binary/Text Distinction Thread-Index: Acxbrr0v/7chPQEEREmTz7QN+vcDXwAAC0jQ Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45C350@SISPE7MB1.commscope.com> References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> In-Reply-To: <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "hybi@IETF.ORG" Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 01:01:46 -0000 On 2011-08-16 at 10:51:48, Bjoern Hoehrmann wrote: > Not having this distinction in the protocol would mean the information=20 > is lost in transit and has to be coordinated out of protocol.=20 The defining characteristic of thewebsocketprotocol is it's deployment mode= l, which provides a perfect channel for this sort of coordination. The ser= ver is effectively talking to itself. Thus, no need for any form of negoti= ation...the server is no longer interacting with the browser, it's interact= ing with itself. If you deploy a page with some JS that talks back to your server using XmlH= TTPRequest, do you demand standardization or negotiation of the JSON encodi= ng [1]? I'll bet that most JS doesn't even check Content-Type headers befo= re calling JSON.parse. This is no different. Negotiating text and binary is an artefact of the process that got us to th= is point, nothing more. It provides no significant utility. --Martin From tyoshino@google.com Mon Aug 15 19:31: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 46F0C21F8CC6 for ; Mon, 15 Aug 2011 19:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.826 X-Spam-Level: X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZaAwkUyvmAbV for ; Mon, 15 Aug 2011 19:31:50 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 73F4A21F8CC5 for ; Mon, 15 Aug 2011 19:31:50 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7G2WaNF008231 for ; Mon, 15 Aug 2011 19:32:36 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313461956; bh=ZeFHd9tXHP4gr7MH1h2Dam4c6sM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jbETrRanuniSver5ejhKa3r4gnBaczLyBshG0inSJi9G4vNM6fx+cU9Je8yTZKG0d zde/DyvEoY5B9aQzoHelQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=oqfeT1siaPSN0Wrao6SHNVEaOVlCiWxy261H9I9eiJgZulN5XlCyrHLPtrLcBJPdh 60sM+IpJ31BNGu+AB08nQ== Received: from ywo32 (ywo32.prod.google.com [10.192.15.32]) by hpaq3.eem.corp.google.com with ESMTP id p7G2WJhL008755 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 15 Aug 2011 19:32:35 -0700 Received: by ywo32 with SMTP id 32so2873232ywo.13 for ; Mon, 15 Aug 2011 19:32:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=BtoPYCiuOqlwtSWbcHOeGN8mEPfkWHCVOn8TTa7j218=; b=stW6p81Pl+diPd4pmFR5AXE1IY8Oi9aF8ODlYiwFotv+wtuLiRuQxm/2XLn+mSsn4z 6u9y0hyGwQe03kBoMYKQ== Received: by 10.151.61.17 with SMTP id o17mr5500218ybk.399.1313461955277; Mon, 15 Aug 2011 19:32:35 -0700 (PDT) Received: by 10.151.61.17 with SMTP id o17mr5500213ybk.399.1313461955117; Mon, 15 Aug 2011 19:32:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Mon, 15 Aug 2011 19:32:15 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 16 Aug 2011 11:32:15 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000325552b4a42c1c904aa9631ad X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About 9.2.1. Compression 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, 16 Aug 2011 02:31:51 -0000 --000325552b4a42c1c904aa9631ad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2011 at 00:07, I=F1aki Baz Castillo wrote: > 9.2.1. Compression > > Senders using this extension MUST apply [RFC1951] encodings to all > bytes of the data stream following the opening handshake including > both data and control frames. > > > What does "all bytes of the data stream" mean? all the frames? > Yes. Including header octets. > If frames are compressed, how can know the receiver how much to read > in order to get the payload size? so does the compression extension > There's no way to know the exact number of bytes needed to be read for a certain frame. A receiver has to attempt to read octets available in the socket and pour them into inflater until it gets all the octets for the frame decompressed. > transform WS protocol in a streamed protocol rather than frames > oriented protocol?? > > Anyhow I remember long discussions about "compression of frames VS > compression of frames payload". Is there final decision for that? > > This is the thread for consensus call on removing deflate-stream made last month, http://www.ietf.org/mail-archive/web/hybi/current/msg07982.html and this is consensus confirmation in that thread. http://www.ietf.org/mail-archive/web/hybi/current/msg08073.html Thanks, Takeshi --000325552b4a42c1c904aa9631ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 00:07, I=F1aki Baz Castillo = <ibc@aliax.net> wrote:
9.2.1. =A0Compression

=A0 Senders using this extension MUST apply [RFC1951] encodings to all
=A0 bytes of the data stream following the opening handshake including
=A0 both data and control frames.


What does "all bytes of the data stream" mean? all the frames?

Yes. Including header octets.
= =A0
If frames are compressed, how can know the receiver how much to read
in order to get the payload size? so does the compression extension

There's no way to know the exact number of= bytes needed to be read for a certain frame. A receiver has to attempt to = read octets available in the socket and pour them into inflater until it ge= ts all the octets for the frame decompressed.
=A0
transform WS protocol in a streamed protocol rather than frames
oriented protocol??

Anyhow I remember long discussions about "compression of frames VS
compression of frames payload". Is there final decision for that?


This is the thread for consensus call = on removing deflate-stream made last month,
and this is consensus confirmation in that thread.
Thanks,
Takeshi

--000325552b4a42c1c904aa9631ad-- From dendicott@gmail.com Mon Aug 15 20:02: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 AD4A621F81D7 for ; Mon, 15 Aug 2011 20:02:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.212 X-Spam-Level: X-Spam-Status: No, score=-3.212 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmFm0v5BeLoT for ; Mon, 15 Aug 2011 20:02:28 -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 91BE821F8888 for ; Mon, 15 Aug 2011 20:02:27 -0700 (PDT) Received: by wwf5 with SMTP id 5so3652706wwf.13 for ; Mon, 15 Aug 2011 20:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RNfuaaGUWpSLYzVlawkGAdzj94SkCaCRvnBCpW8y2nA=; b=ibgxJT5kRO2lNm3dTNz7wizLGX+pof0uv4+fv5u+8FsPkm1HkF+2kt3ROyfuPF/+qz 6NmnzkjQf+5F06BAZc3wiuUFhGtIPxmdCtGtO+XBsy7F7KzuYzwwsFJ6tr8kjk1uMbTU dn66OeBDQ7S4ridVC7Os0w0D5MjDEMLblJEAA= MIME-Version: 1.0 Received: by 10.216.8.85 with SMTP id 63mr4084783weq.29.1313463794066; Mon, 15 Aug 2011 20:03:14 -0700 (PDT) Received: by 10.217.3.203 with HTTP; Mon, 15 Aug 2011 20:03:14 -0700 (PDT) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040D45C350@SISPE7MB1.commscope.com> References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> <8B0A9FCBB9832F43971E38010638454F040D45C350@SISPE7MB1.commscope.com> Date: Mon, 15 Aug 2011 23:03:14 -0400 Message-ID: From: David Endicott To: "Thomson, Martin" Content-Type: multipart/alternative; boundary=0016364d1c1fdee77b04aa969ed6 Cc: "hybi@IETF.ORG" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 03:02:28 -0000 --0016364d1c1fdee77b04aa969ed6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 15, 2011 at 9:00 PM, Thomson, Martin < Martin.Thomson@commscope.com> wrote: > On 2011-08-16 at 10:51:48, Bjoern Hoehrmann wrote: > > Not having this distinction in the protocol would mean the information > > is lost in transit and has to be coordinated out of protocol. > > The defining characteristic of thewebsocketprotocol is it's deployment > model, which provides a perfect channel for this sort of coordination. The > server is effectively talking to itself. Thus, no need for any form of > negotiation...the server is no longer interacting with the browser, it's > interacting with itself. > Please clarify. If you're saying what I think you're saying, I'm must disagree. I would say the defining characteristics (there are several) of WS is that it is an asynchronous framing transport protocol intended to be used primarily by browser client-agents. I don't understand what you mean by "server is effectively talking to itself" - that seems nonsensical. Further to Bjoern's comments about, what I believe he's saying about including content-type information in the protocol: I would point out that WS is content agnostic - the payload of the frame is not examined or considered by WS. This is because WS is a transport protocol. TCP does not care what goes thru it, be it HTTP, SMTP, SSH or whatever, it's job is only to transport the bytes to the endpoint. Similarly, WS does not care what is in it's frames. It is the application using WS that imposes the concept of content-type on the data communicated. The text frame hack is simply a nod to common use convenience. (And an unnecessary one at that, IMHO) > If you deploy a page with some JS that talks back to your server using > XmlHTTPRequest, do you demand standardization or negotiation of the JSON > encoding [1]? I'll bet that most JS doesn't even check Content-Type headers > before calling JSON.parse. This is no different. > > Negotiating text and binary is an artefact of the process that got us to > this point, nothing more. It provides no significant utility. > > --Martin > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0016364d1c1fdee77b04aa969ed6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 15, 2011 at 9:00 PM, Thomson= , Martin <Martin.Thomson@commscope.com> wrote:
On 2011-08-16 at 10:51:48, Bjoern Hoehrmann wrote:
> Not having this distinction in the protocol would mean the information=
> is lost in transit and has to be coordinated out of protocol.

The defining characteristic of thewebsocketprotocol is it's deplo= yment model, which provides a perfect channel for this sort of coordination= . =A0The server is effectively talking to itself. =A0Thus, no need for any = form of negotiation...the server is no longer interacting with the browser,= it's interacting with itself.

Please clarify. =A0 If you're saying w= hat I think you're saying, I'm must disagree.

<= div>I would say the defining=A0characteristics=A0(there are several) of WS = is that it is an=A0asynchronous=A0framing transport protocol intended to be= used primarily by browser client-agents.

I don't understand what you mean by "server is= effectively talking to itself" - that seems nonsensical.
Further to Bjoern's comments about, what I believe he'= s saying about including content-type information in the protocol: I would = point out that WS is content agnostic - the payload of the frame is not exa= mined or considered by WS. =A0 This is because WS is a transport protocol. = =A0=A0

TCP does not care what goes thru it, be it HTTP, SMTP, = SSH or whatever, it's job is only to transport the bytes to the endpoin= t. =A0Similarly, WS does not care what is in it's frames. =A0 =A0It is = the application using WS that imposes the concept of content-type on the da= ta communicated. =A0=A0

The text frame hack is simply a nod to common use=A0con= venience. =A0 (And an unnecessary one at that, IMHO)




If you deploy a page with some JS that talks back to your server using XmlH= TTPRequest, do you demand standardization or negotiation of the JSON encodi= ng [1]? =A0I'll bet that most JS doesn't even check Content-Type he= aders before calling JSON.parse. =A0This is no different.

Negotiating text and binary is an artefact of the process that got us to th= is point, nothing more. =A0It provides no significant utility.

--Martin
__________________________________= _____________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--0016364d1c1fdee77b04aa969ed6-- From sdw@lig.net Mon Aug 15 20:11: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 BAE6A21F8C58 for ; Mon, 15 Aug 2011 20:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDJPvWTKFOQ9 for ; Mon, 15 Aug 2011 20:11:24 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id B9E5021F8C09 for ; Mon, 15 Aug 2011 20:11:24 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 410EFAB5DB0 for ; Mon, 15 Aug 2011 20:22:58 -0700 (PDT) Message-ID: <4E49E016.6060306@lig.net> Date: Mon, 15 Aug 2011 20:12:22 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> <8B0A9FCBB9832F43971E38010638454F040D45C350@SISPE7MB1.commscope.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090704050000060900080101" Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 03:11:25 -0000 This is a multi-part message in MIME format. --------------090704050000060900080101 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/15/11 8:03 PM, David Endicott wrote: > > > On Mon, Aug 15, 2011 at 9:00 PM, Thomson, Martin > wrote: > > On 2011-08-16 at 10:51:48, Bjoern Hoehrmann wrote: > > Not having this distinction in the protocol would mean the information > > is lost in transit and has to be coordinated out of protocol. > > The defining characteristic of thewebsocketprotocol is it's deployment model, which provides a perfect channel for this sort > of coordination. The server is effectively talking to itself. Thus, no need for any form of negotiation...the server is no > longer interacting with the browser, it's interacting with itself. > > > Please clarify. If you're saying what I think you're saying, I'm must disagree. > > I would say the defining characteristics (there are several) of WS is that it is an asynchronous framing transport protocol > intended to be used primarily by browser client-agents. > > I don't understand what you mean by "server is effectively talking to itself" - that seems nonsensical. I took that to mean: The typical use case for WS will be for a web server app that serves a Javascript-enabled web page to a browser. Since the Javascript code is coming from the server it will be talking to, it shouldn't typically be very hard to keep them in sync. This is opposed to use as a Web API for general applications that might involve code from multiple unrelated parties. Because this may be the first widely available web (server/protocol/security model) protocol for applications, it would be good to be friendly to the JS page and general cases. > > Further to Bjoern's comments about, what I believe he's saying about including content-type information in the protocol: I would > point out that WS is content agnostic - the payload of the frame is not examined or considered by WS. This is because WS is a > transport protocol. > > TCP does not care what goes thru it, be it HTTP, SMTP, SSH or whatever, it's job is only to transport the bytes to the endpoint. > Similarly, WS does not care what is in it's frames. It is the application using WS that imposes the concept of content-type on > the data communicated. > > The text frame hack is simply a nod to common use convenience. (And an unnecessary one at that, IMHO) A flag to indicate something like "Content-Type: application/UTF-8" is OK. But it shouldn't be necessary. > > > > > If you deploy a page with some JS that talks back to your server using XmlHTTPRequest, do you demand standardization or > negotiation of the JSON encoding [1]? I'll bet that most JS doesn't even check Content-Type headers before calling > JSON.parse. This is no different. > > Negotiating text and binary is an artefact of the process that got us to this point, nothing more. It provides no significant > utility. > > --Martin > sdw --------------090704050000060900080101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/15/11 8:03 PM, David Endicott wrote:


On Mon, Aug 15, 2011 at 9:00 PM, Thomson, Martin <Martin.Thomson@commscope.com> wrote:
On 2011-08-16 at 10:51:48, Bjoern Hoehrmann wrote:
> Not having this distinction in the protocol would mean the information
> is lost in transit and has to be coordinated out of protocol.

The defining characteristic of thewebsocketprotocol is it's deployment model, which provides a perfect channel for this sort of coordination.  The server is effectively talking to itself.  Thus, no need for any form of negotiation...the server is no longer interacting with the browser, it's interacting with itself.

Please clarify.   If you're saying what I think you're saying, I'm must disagree.

I would say the defining characteristics (there are several) of WS is that it is an asynchronous framing transport protocol intended to be used primarily by browser client-agents.

I don't understand what you mean by "server is effectively talking to itself" - that seems nonsensical.

I took that to mean: The typical use case for WS will be for a web server app that serves a Javascript-enabled web page to a browser.  Since the Javascript code is coming from the server it will be talking to, it shouldn't typically be very hard to keep them in sync.  This is opposed to use as a Web API for general applications that might involve code from multiple unrelated parties.  Because this may be the first widely available web (server/protocol/security model) protocol for applications, it would be good to be friendly to the JS page and general cases.


Further to Bjoern's comments about, what I believe he's saying about including content-type information in the protocol: I would point out that WS is content agnostic - the payload of the frame is not examined or considered by WS.   This is because WS is a transport protocol.   

TCP does not care what goes thru it, be it HTTP, SMTP, SSH or whatever, it's job is only to transport the bytes to the endpoint.  Similarly, WS does not care what is in it's frames.    It is the application using WS that imposes the concept of content-type on the data communicated.   

The text frame hack is simply a nod to common use convenience.   (And an unnecessary one at that, IMHO)

A flag to indicate something like "Content-Type: application/UTF-8" is OK.  But it shouldn't be necessary.





If you deploy a page with some JS that talks back to your server using XmlHTTPRequest, do you demand standardization or negotiation of the JSON encoding [1]?  I'll bet that most JS doesn't even check Content-Type headers before calling JSON.parse.  This is no different.

Negotiating text and binary is an artefact of the process that got us to this point, nothing more.  It provides no significant utility.

--Martin

sdw

--------------090704050000060900080101-- From Martin.Thomson@commscope.com Mon Aug 15 20:34:32 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 746AB11E8087 for ; Mon, 15 Aug 2011 20:34:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.593 X-Spam-Level: X-Spam-Status: No, score=-2.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICCVz2pfK8lp for ; Mon, 15 Aug 2011 20:34:31 -0700 (PDT) Received: from cdcsmgw01.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id C9F0D11E8086 for ; Mon, 15 Aug 2011 20:34:31 -0700 (PDT) X-AuditID: 0a0404e8-b7cb4ae000004e51-3c-4e49e582ead8 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw01.commscope.com (Symantec Brightmail Gateway) with SMTP id FE.89.20049.285E94E4; Mon, 15 Aug 2011 22:35:31 -0500 (CDT) Received: from CDCE10HC1.commscope.com (10.86.28.21) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Mon, 15 Aug 2011 22:35:17 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by CDCE10HC1.commscope.com (10.86.28.21) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 15 Aug 2011 22:35:17 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 16 Aug 2011 11:35:08 +0800 From: "Thomson, Martin" To: David Endicott Date: Tue, 16 Aug 2011 11:35:07 +0800 Thread-Topic: [hybi] Binary/Text Distinction Thread-Index: AcxbwRY/GbohnsQ7RyScRugBbL9GIQAA6uyA Message-ID: <8B0A9FCBB9832F43971E38010638454F040D45C3A1@SISPE7MB1.commscope.com> References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> <8B0A9FCBB9832F43971E38010638454F040D45C350@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "hybi@IETF.ORG" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 03:34:32 -0000 On 2011-08-16 at 13:03:14, David Endicott wrote: > I don't understand what you mean by "server is effectively talking to=20 > itself" - that seems nonsensical. It's how thewebsocketprotocol works. In the most hand-wavey fashion: the s= erver deploys some of its code. The server exchanges messages with that co= de over thewebsocketprotocol. =20 > The text frame hack is simply a nod to common use convenience. (And > an unnecessary one at that, IMHO) I agree. --Martin From andy@warmcat.com Mon Aug 15 22:43: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 A8ED221F8B3C for ; Mon, 15 Aug 2011 22:43:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.222 X-Spam-Level: X-Spam-Status: No, score=-2.222 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbsNx2jTikM5 for ; Mon, 15 Aug 2011 22:43:10 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id C7B1721F8B3A for ; Mon, 15 Aug 2011 22:43:09 -0700 (PDT) Message-ID: <4E4A0396.6060303@warmcat.com> Date: Tue, 16 Aug 2011 06:43:50 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> In-Reply-To: <4E49A895.6000509@callenish.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 05:43:10 -0000 On 08/16/2011 12:15 AM, Somebody in the thread at some point said: >> Because emails keep coming which look like they confused the general >> and common limitation on message length found in every real browser, >> and frame processing. We are after all talking about an error calling >> itself *frame* too big, which is not possible --> > > You keep saying this, but that doesn't make it any less incorrect. A > frame can be too large for any number of reasons: latency, denial of Evidently the "any number of reasons" you could come up with is two. However if we think about what they mean to a receiver on a duplex transport, they are not convincing as reasons for the receiving peer to object to with "frame too big" concept. The problems with latency if the transmitting peer sends a big frame are all at the sender. The receiver can asynchronously send frames any time; the error you like to send relies on that. So the only latency that gets stretched is that of the sender being able to send a new frame while he's still going on with the old one. Likewise the service being denied is the ability of the sender to send other frames, the receiver can still send frames, accept new connections etc. If that's what you want to call a DoS then you can do the same with telling a 2-byte frame is coming and then send one byte of payload and go silent. "DoS" has nothing to do with "frame too long". Actually, you need to manage all three of these cases ("latency", "long frame DoS", "never complete DoS") with timeouts for the things that care, if anything cares. Making an arbitrary frame length limit (which requires you to assess connection bandwidth to come up with a reasonable estimate) and killing the connection does not actually address latency that can be caused other ways too. Whereas timeouts do solve all kinds of latency and do not require guessing a frame limit and having a "frame too long" error. Further, the timeouts only operate if something actually cares, and let the sender babble on optimally if that's OK for that protocol / situation and the data is wanted. > service limitations, etc. Requirements for a particular situation trump > the theoretical limits of a standard every time. So long as the standard > does not require that all frame sizes be handled in the same way, it is > a legitimate implementation decision to choose to handle a particular > frame size by closing the connection. That behaviour is not broken nor > bogus, it is completely conforming to the specification. Point me to ANY > portion of the specification that prohibits it. These arguments are about what should appear in and should be removed from the specification itself. Many times on the list we detected the spec is broken or not self-consistent at the moment. So it's better if we use logic, clear descriptions, honest argumentation without handwaving to figure out what's good and bad as well as what the spec seems to be intending. > And if it is conforming, there are going to be more people than me > choosing to implement that way. And their implementations will be just > as correct as yours is. > >> >> Because frame processing is performed packet by packet, with the >> single exception of this proposed frame signing extension, actually >> the frame layer just deals with a packet at a time. > > It can do. It doesn't have to. There is nothing in the specification > that requires that behaviour. As I have said many times before, and say > here for the last time. That's right but it brings us full circle, you are standing up for the right to make a crappy and fragile implementation when the good one is simple and there's no reason not to use it. If that was my argument, I wouldn't wanna repeat it either ^^ -Andy From gregw@intalio.com Mon Aug 15 23:09: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 6758921F8BEF for ; Mon, 15 Aug 2011 23:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.916 X-Spam-Level: X-Spam-Status: No, score=-2.916 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TNznTBWct68 for ; Mon, 15 Aug 2011 23:09:12 -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 C962C21F8BDE for ; Mon, 15 Aug 2011 23:09:11 -0700 (PDT) Received: by vxi29 with SMTP id 29so5528548vxi.31 for ; Mon, 15 Aug 2011 23:09:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.230 with SMTP id o6mr4026453vdg.430.1313474998962; Mon, 15 Aug 2011 23:09:58 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Mon, 15 Aug 2011 23:09:58 -0700 (PDT) In-Reply-To: <4E4A0396.6060303@warmcat.com> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> Date: Tue, 16 Aug 2011 16:09:58 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 06:09:12 -0000 On 16 August 2011 15:43, "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" wrote: > That's right but it brings us full circle, you are standing up for the ri= ght > to make a crappy and fragile implementation when the good one is simple a= nd > there's no reason not to use it. > > If that was my argument, I wouldn't wanna repeat it either ^^ C'mon Andy - keep the scorn out of the group. It's not helpful. I'm mostly convinced that we don't need frame-too-long, but I have to say your attitude is not helping me to that conclusion. From andy@warmcat.com Mon Aug 15 23:52: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 0BE6611E8098 for ; Mon, 15 Aug 2011 23:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3Uf2uQoCe-g for ; Mon, 15 Aug 2011 23:52:17 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 89E2811E8085 for ; Mon, 15 Aug 2011 23:52:17 -0700 (PDT) Message-ID: <4E4A13CD.3040102@warmcat.com> Date: Tue, 16 Aug 2011 07:53:01 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 06:52:18 -0000 On 08/16/2011 07:09 AM, Somebody in the thread at some point said: > On 16 August 2011 15:43, "Andy Green (林安廸)" wrote: >>>> Because frame processing is performed packet by packet, with the >>>> single exception of this proposed frame signing extension, actually >>>> the frame layer just deals with a packet at a time. >>> It can do. It doesn't have to. There is nothing in the specification >>> that requires that behaviour. As I have said many times before, and say >>> here for the last time. >> That's right but it brings us full circle, you are standing up for the right >> to make a crappy and fragile implementation when the good one is simple and >> there's no reason not to use it. >> >> If that was my argument, I wouldn't wanna repeat it either ^^ > > C'mon Andy - keep the scorn out of the group. It's not helpful. > I'm mostly convinced that we don't need frame-too-long, but I have to > say your attitude is not helping me to that conclusion. What you take as 'scorn' is actually a fair summary of the argument given (replaced from your snipping above); and I think you're misinformed if you believe I'm posting on this list to keep you happy. -Andy From tobias.oberstein@tavendo.de Tue Aug 16 01:17: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 D0C1A21F8B31 for ; Tue, 16 Aug 2011 01:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJ6wPe0eHuoR for ; Tue, 16 Aug 2011 01:17:57 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id D2B8E21F8B2C for ; Tue, 16 Aug 2011 01:17:56 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Tue, 16 Aug 2011 01:18:44 -0700 From: Tobias Oberstein To: Greg Wilkins Date: Tue, 16 Aug 2011 01:18:04 -0700 Thread-Topic: [hybi] Flat MUX Thread-Index: AcxbpkpvdGaShQLGTDezCLEhWJgAPAARXWYg Message-ID: <634914A010D0B943A035D226786325D422C0B9A05B@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFBFC64E@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Flat MUX 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, 16 Aug 2011 08:17:57 -0000 > This appears workable. However, I would prefer a MUX system that actuall= y > uses websocket frames as designed rather than inventing new framing that > is based on a layer above WS messages. I agree, it would prefer that also, but the price is that intermediaries ne= eded to understand (or at least don't touch) the interleaving. This is required = by the spec, but will intermediaries obey? Maximum compatibility with intermediaries for me is an even bigger concern than design cleanness .. >=20 > We sweated virtual blood to agree on the framing mechanism that would be > flexible enough for all/most concerns - and it would be a shame that if o= n the > first hurdle we decided that intermediaries could not respect the > requirements for the spec and discarded the flexibility of the framing sy= stem > we have. >=20 > WS framing allows extension data per frame. This is sufficient to tag ea= ch > frame with a channel. > WS framing allows interleaving if there is an extension to sort out the > interleaving. > WS framing does not allow intermediaries that do not understand the > extensions to fragment or aggregate frames. Yes, formally, this is sufficient. However I fear that intermediaries that do not understand an extension that modifies the rules for interleaving message fragments could then choose to either block the extension or don't play to the rules and get confused by the interleaving. >=20 > Now, there may be real technical reasons to go for MUX as a layer on top = of Layer on top (with some flat muxed interleaving .. be it baked into standar= d framing or with a new MUX FIN bit) is something I prefer in any case to wrapping/tunneling whole WS connection within WS like x-google-mux, which introduces a lot complexity. > ws messages - but allowing poor intermediary implementations should not > be one of them. Ideally, yes. But practically? >=20 > cheers >=20 >=20 >=20 >=20 > On 15 August 2011 20:52, Tobias Oberstein > wrote: > > Here is a variant of muxing that > > > > - does not wrap/nest complete WS connections (recursively) inside WS > > or reframe the payload of MUXed messages > > > > - does not require intermediaries to understand message interleaving > > or adjust it's fragmentation/coalescing logic > > > > - uses 1 reserved Opcode and 2 reserved bits > > > > > > The approach is to pack a MUXed message specific FIN bit into reserved = bit > 2: > > > > RSV2 =3D MUX FIN > > > > 0 =3D non-final MUX message frame > > 1 =3D final MUX message frame > > > > On the base WS layer, all data is sent (by endpoints) using a new Opcod= e > 0x8 and FIN =3D 1. > > > > The extension data of a Opcode 0x8 frame has the channel ID, which is > > an integer encoded the same as the payload length in base WS. > > > > The payload type of a muxed message (text or binary) is signaled in > > the first frame of the MUXed message > > > > RSV3 =3D MUX Payload Type (0 =3D binary, 1 =3D text) > > > > For a MUX continuation frame (MUX FIN =3D 0 after first frame) the RSV3= bit > is 0. > > > > An example of 2 MUXed messages interleaved (a text message on chn 23 > > and a binary message on chn 70): > > > > chn23, text: "data23_a-data23_b-data23_c-data23_d" > > chn70, binary: "data70_a-data70_b-data70_c" > > > > WS base layer frames: > > > > FIN, Opcode, RSV2 (MUX FIN), RSV3 (MUX Payload Type), Channel ID, > > Payload > > > > 1, 0x8, 0, 1, 23, "data23_a-" > > 1, 0x8, 0, 0, 70, "data70_a-" > > 1, 0x8, 0, 0, 70, "data70_b-" > > 1, 0x8, 0, 0, 23, "data23_b-" > > 1, 0x8, 1, 0, 70, "data70_c" > > 1, 0x8, 0, 0, 23, "data23_c-" > > 1, 0x8, 1, 0, 23, "data23_d" > > > > The reason to choose RSV 2 and 3 is to allow compatibility with the > > per-frame compression extension proposed by Takeshi which uses RSV 1 > > to signal whether a frame is compressed or not. > > > > Since there is no interleaving on the base WS layer to understand, > > intermediaries don't get confused. > > > > Moreoever, since endpoints are required to send Mux messages > > unfragmented, intermediaries can fragment those (and subsequent > intermediaries could coalesce again). > > > > The receiving endpoint can just reassemble the fragments that make up a > MUX frame. > > > > Mux message frame sent by endpoint: > > > > 1, 0x8, 0, 0, 23, "data23_b-" > > > > Fragmented frames received by endpoint: > > > > 0, 0x8, 0, 0, 23, "dat" > > 0, 0x8, ?, ?, "a2" > > 1, 0x8, ?, ?, "3_b-" > > > > The intermediary can set the RSV bits of the fragments following the fi= rst > arbitrary. > > The receiver only cares about RSV for the first base WS frame of a Mux > frame. > > > > The question of channel setup/teardown and channel credit > > replenishment signaling is somewhat orthogonal .. tbd. > > > > Is there a catch I missed? > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > > From tobias.oberstein@tavendo.de Tue Aug 16 01:34: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 0DF6D21F8B38 for ; Tue, 16 Aug 2011 01:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.514 X-Spam-Level: X-Spam-Status: No, score=-2.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Lk15YGISvr for ; Tue, 16 Aug 2011 01:34:18 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0C121F8B31 for ; Tue, 16 Aug 2011 01:34:18 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Tue, 16 Aug 2011 01:35:05 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Tue, 16 Aug 2011 01:34:28 -0700 Thread-Topic: Intermedaries: coalescing with interleaved control messages Thread-Index: Acxb7wdS+SuLSh3rSquKK03vAZKLSA== Message-ID: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 08:34:19 -0000 In the absence of a negotiated extension / use of any reserved bits, an int= ermediary MAY modify the fragmentation a of data message: coalesce fragments or fragment further= . How does that play with interleaved control messages? Do control messages act as "barries" across which intermedaries must not co= alesce? For example, when an intermediary receives: [MSG1-fragment1] [MSG1-fragment2] [CONTROL-message] [MSG1-fragment3] Which of the following is allowed to the intermediary? Coalescing C1. [MSG1-fragment12] [CONTROL-message] [MSG1-fragment3] C2. [MSG1-fragment123] [CONTROL-message] =20 C3. [CONTROL-message] [MSG1-fragment123] C4. [MSG1-fragment1] [CONTROL-message] [MSG1-fragment23] Fragmenting F1. [MSG1-fragment1] [MSG1-fragment2a] [MSG1-fragment2b] [CONTROL-message] [MS= G1-fragment3] F2. [MSG1-fragment1] [MSG1-fragment2a] [CONTROL-message] [MSG1-fragment2b] [MS= G1-fragment3] From gregw@intalio.com Tue Aug 16 01:55: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 116BF21F8B66 for ; Tue, 16 Aug 2011 01:55:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zn+vgFAw9YBq for ; Tue, 16 Aug 2011 01:55:52 -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 5E5BA21F8B1B for ; Tue, 16 Aug 2011 01:55:51 -0700 (PDT) Received: by vws12 with SMTP id 12so5665828vws.31 for ; Tue, 16 Aug 2011 01:56:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.230 with SMTP id o6mr4136297vdg.430.1313484999348; Tue, 16 Aug 2011 01:56:39 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Tue, 16 Aug 2011 01:56:39 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 16 Aug 2011 18:56:39 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 08:55:53 -0000 On 16 August 2011 18:34, Tobias Oberstein wrote: > In the absence of a negotiated extension / use of any reserved bits, an intermediary MAY modify > the fragmentation a of data message: coalesce fragments or fragment further. > > How does that play with interleaved control messages? > > Do control messages act as "barries" across which intermedaries must not coalesce? It would be nice if this was the case, as that would allow a ping/pong to act as a kind of acknowledgement. ie when you receive the pong you will know that all frames sent prior to the ping have been delivered (at least to the destination host, but not the application). Measuring latency between the pong and an application response to a message prior to the ping would be a good way to remotely measure application latency vs network latency. cheers From andy@warmcat.com Tue Aug 16 02:00: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 E732C21F8BBE for ; Tue, 16 Aug 2011 02:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.228 X-Spam-Level: X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-WHuQXXKyQd for ; Tue, 16 Aug 2011 02:00:16 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 40B4721F8BC5 for ; Tue, 16 Aug 2011 02:00:16 -0700 (PDT) Message-ID: <4E4A31CE.1060007@warmcat.com> Date: Tue, 16 Aug 2011 10:01:02 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein References: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 09:00:17 -0000 On 08/16/2011 09:34 AM, Somebody in the thread at some point said: Hi - > In the absence of a negotiated extension / use of any reserved bits, I think this is "a negotiated extension that the intermediary does not understand". > an intermediary MAY modify the fragmentation a of data message: > coalesce fragments or fragment further. > > How does that play with interleaved control messages? You mean control *frames*. > Do control messages act as "barries" across which intermedaries must > not coalesce? > > > For example, when an intermediary receives: > > [MSG1-fragment1] [MSG1-fragment2] [CONTROL-message] [MSG1-fragment3] > > > Which of the following is allowed to the intermediary? > > Coalescing > > C1. [MSG1-fragment12] [CONTROL-message] [MSG1-fragment3] > > C2. [MSG1-fragment123] [CONTROL-message] > > C3. [CONTROL-message] [MSG1-fragment123] > > C4. [MSG1-fragment1] [CONTROL-message] [MSG1-fragment23] > > Fragmenting > > F1. [MSG1-fragment1] [MSG1-fragment2a] [MSG1-fragment2b] > [CONTROL-message] [MSG1-fragment3] > > F2. [MSG1-fragment1] [MSG1-fragment2a] [CONTROL-message] > [MSG1-fragment2b] [MSG1-fragment3] I think it should not bind together frames either side of the non-payload frame, but send the control frame out and do what it likes with contiguous frames of the same message. But... what's the advantage to binding the frame content together in fact? It implies it is willing to buffer multiple frame payloads (in order to find out the aggregate lengths). That sounds kind of prone to not scaling. Unless there's something the intermediary was planning to do that likes getting a lot of payload, eg compression, it sounds like a better plan the intermediary would just spill what was coming in as it came in packet by packet and not bind frames together at all. -Andy From tobias.oberstein@tavendo.de Tue Aug 16 02:20: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 7282621F8B5E for ; Tue, 16 Aug 2011 02:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOr8oshJPgc3 for ; Tue, 16 Aug 2011 02:20:29 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id D8F0421F8B5B for ; Tue, 16 Aug 2011 02:20:28 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Tue, 16 Aug 2011 02:21:16 -0700 From: Tobias Oberstein To: Greg Wilkins Date: Tue, 16 Aug 2011 02:19:29 -0700 Thread-Topic: [hybi] Intermedaries: coalescing with interleaved control messages Thread-Index: Acxb8mvVKo9+xkySROSH/nTgbSKCcAAAX9NA Message-ID: <634914A010D0B943A035D226786325D422C0B9A05D@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 09:20:29 -0000 > > In the absence of a negotiated extension / use of any reserved bits, > > an intermediary MAY modify the fragmentation a of data message: > coalesce fragments or fragment further. > > > > How does that play with interleaved control messages? > > > > Do control messages act as "barries" across which intermedaries must no= t > coalesce? >=20 > It would be nice if this was the case, as that would allow a ping/pong to= act as > a kind of acknowledgement. ie when you receive the pong you will know > that all frames sent prior to the ping have been delivered (at least to t= he > destination host, but not the application). > Measuring latency between the pong and an application response to a > message prior to the ping would be a good way to remotely measure > application latency vs network latency. Interesting usage .. didn't thought about that kind. Can this be generalized? I mean: With base WS we have 1 ordered channel for data messages. Intermediaries mu= st obviously not change ordering. But we also have a 2nd channel: control. Within that channel, ordering must= also be preserved. Are there rules which introduce ordering constraints between the 2? Having a message on the control channel act as a barrier for the data chann= el is one conceivable constraint. Or is it even already implied (or meant) by the spec? In the presence of some MUX with more channels: what about ordering constra= ints? When channels had priorities, a message on channel A could act as reorderin= g barrier for messages on channels with lower prio. The control channel is then a highest prio channel .. it introduces barrier= s for all data channels .. From tobias.oberstein@tavendo.de Tue Aug 16 02:32: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 B433E21F8ACC for ; Tue, 16 Aug 2011 02:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.368 X-Spam-Level: X-Spam-Status: No, score=-2.368 tagged_above=-999 required=5 tests=[AWL=-0.069, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Izvc9-+UBjdP for ; Tue, 16 Aug 2011 02:32:57 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id C8DF021F8AF2 for ; Tue, 16 Aug 2011 02:32:56 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Tue, 16 Aug 2011 02:33:44 -0700 From: Tobias Oberstein To: =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= Date: Tue, 16 Aug 2011 02:33:01 -0700 Thread-Topic: [hybi] Intermedaries: coalescing with interleaved control messages Thread-Index: Acxb8wy+LpadbJPKQxWgyxiaSok6CQAANMBQ Message-ID: <634914A010D0B943A035D226786325D422C0B9A05E@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> <4E4A31CE.1060007@warmcat.com> In-Reply-To: <4E4A31CE.1060007@warmcat.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 09:32:57 -0000 PiA+IEluIHRoZSBhYnNlbmNlIG9mIGEgbmVnb3RpYXRlZCBleHRlbnNpb24gLyB1c2Ugb2YgYW55 IHJlc2VydmVkIGJpdHMsDQo+IA0KPiBJIHRoaW5rIHRoaXMgaXMgImEgbmVnb3RpYXRlZCBleHRl bnNpb24gdGhhdCB0aGUgaW50ZXJtZWRpYXJ5IGRvZXMgbm90DQo+IHVuZGVyc3RhbmQiLg0KDQpJ IG1lYW50IG5vIGV4dGVuc2lvbiBoYXMgYmVlbiBuZWdvdGlhdGVkIC4uIHRoYXQgaXMgYm90aCBw ZWVycyBhZ3JlZWQNCnRvIHNwZWFrIHRoZSBiYXNlIFdTIHByb3RvY29sIHdpdGhvdXQgYW55IGV4 dGVuc2lvbi4NCg0KPiANCj4gPiBhbiBpbnRlcm1lZGlhcnkgTUFZIG1vZGlmeSB0aGUgZnJhZ21l bnRhdGlvbiBhIG9mIGRhdGEgbWVzc2FnZToNCj4gPiBjb2FsZXNjZSBmcmFnbWVudHMgb3IgZnJh Z21lbnQgZnVydGhlci4NCj4gPg0KPiA+IEhvdyBkb2VzIHRoYXQgcGxheSB3aXRoIGludGVybGVh dmVkIGNvbnRyb2wgbWVzc2FnZXM/DQo+IA0KPiBZb3UgbWVhbiBjb250cm9sICpmcmFtZXMqLg0K DQpZZXAuICBJIHVzZSB0aGF0IHN5bm9ueW1vdXNseSBmb3IgY29udHJvbCwgc2luY2UgY29udHJv bCAibWVzc2FnZXMiIGNhbid0DQpiZSBmcmFnbWVudGVkLiBTaG91bGRuJ3QgZG8gdGhhdCBwcm9i YWJseTspDQoNCj4gDQo+ID4gRG8gY29udHJvbCBtZXNzYWdlcyBhY3QgYXMgImJhcnJpZXMiIGFj cm9zcyB3aGljaCBpbnRlcm1lZGFyaWVzIG11c3QNCj4gPiBub3QgY29hbGVzY2U/DQo+ID4NCj4g Pg0KPiA+IEZvciBleGFtcGxlLCB3aGVuIGFuIGludGVybWVkaWFyeSByZWNlaXZlczoNCj4gPg0K PiA+IFtNU0cxLWZyYWdtZW50MV0gW01TRzEtZnJhZ21lbnQyXSBbQ09OVFJPTC1tZXNzYWdlXSBb TVNHMS0NCj4gZnJhZ21lbnQzXQ0KPiA+DQo+ID4NCj4gPiBXaGljaCBvZiB0aGUgZm9sbG93aW5n IGlzIGFsbG93ZWQgdG8gdGhlIGludGVybWVkaWFyeT8NCj4gPg0KPiA+IENvYWxlc2NpbmcNCj4g Pg0KPiA+IEMxLiBbTVNHMS1mcmFnbWVudDEyXSBbQ09OVFJPTC1tZXNzYWdlXSBbTVNHMS1mcmFn bWVudDNdDQo+ID4NCj4gPiBDMi4gW01TRzEtZnJhZ21lbnQxMjNdIFtDT05UUk9MLW1lc3NhZ2Vd DQo+ID4NCj4gPiBDMy4gW0NPTlRST0wtbWVzc2FnZV0gW01TRzEtZnJhZ21lbnQxMjNdDQo+ID4N Cj4gPiBDNC4gW01TRzEtZnJhZ21lbnQxXSBbQ09OVFJPTC1tZXNzYWdlXSBbTVNHMS1mcmFnbWVu dDIzXQ0KPiA+DQo+ID4gRnJhZ21lbnRpbmcNCj4gPg0KPiA+IEYxLiBbTVNHMS1mcmFnbWVudDFd IFtNU0cxLWZyYWdtZW50MmFdIFtNU0cxLWZyYWdtZW50MmJdDQo+ID4gW0NPTlRST0wtbWVzc2Fn ZV0gW01TRzEtZnJhZ21lbnQzXQ0KPiA+DQo+ID4gRjIuIFtNU0cxLWZyYWdtZW50MV0gW01TRzEt ZnJhZ21lbnQyYV0gW0NPTlRST0wtbWVzc2FnZV0NCj4gPiBbTVNHMS1mcmFnbWVudDJiXSAgW01T RzEtZnJhZ21lbnQzXQ0KPiANCj4gSSB0aGluayBpdCBzaG91bGQgbm90IGJpbmQgdG9nZXRoZXIg ZnJhbWVzIGVpdGhlciBzaWRlIG9mIHRoZSBub24tcGF5bG9hZA0KPiBmcmFtZSwgYnV0IHNlbmQg dGhlIGNvbnRyb2wgZnJhbWUgb3V0IGFuZCBkbyB3aGF0IGl0IGxpa2VzIHdpdGggY29udGlndW91 cw0KPiBmcmFtZXMgb2YgdGhlIHNhbWUgbWVzc2FnZS4NCj4gDQo+IEJ1dC4uLiB3aGF0J3MgdGhl IGFkdmFudGFnZSB0byBiaW5kaW5nIHRoZSBmcmFtZSBjb250ZW50IHRvZ2V0aGVyIGluIGZhY3Q/ ICBJdA0KPiBpbXBsaWVzIGl0IGlzIHdpbGxpbmcgdG8gYnVmZmVyIG11bHRpcGxlIGZyYW1lIHBh eWxvYWRzIChpbiBvcmRlciB0byBmaW5kIG91dCB0aGUNCj4gYWdncmVnYXRlIGxlbmd0aHMpLiAg VGhhdCBzb3VuZHMga2luZCBvZiBwcm9uZSB0byBub3Qgc2NhbGluZy4NCj4gDQo+IFVubGVzcyB0 aGVyZSdzIHNvbWV0aGluZyB0aGUgaW50ZXJtZWRpYXJ5IHdhcyBwbGFubmluZyB0byBkbyB0aGF0 IGxpa2VzDQo+IGdldHRpbmcgYSBsb3Qgb2YgcGF5bG9hZCwgZWcgY29tcHJlc3Npb24sIGl0IHNv dW5kcyBsaWtlIGEgYmV0dGVyIHBsYW4gdGhlDQo+IGludGVybWVkaWFyeSB3b3VsZCBqdXN0IHNw aWxsIHdoYXQgd2FzIGNvbWluZyBpbiBhcyBpdCBjYW1lIGluIHBhY2tldCBieQ0KPiBwYWNrZXQg YW5kIG5vdCBiaW5kIGZyYW1lcyB0b2dldGhlciBhdCBhbGwuDQoNCkkgaGF2ZSBubyBjbHVlIHdo YXQgaW50ZXJtZWRpYXJpZXMgd2FudCB0byBkbyBhbmQgZm9yIHdoYXQgcmVhc29ucy4gV2hhdCBJ DQp3YXMgdHJ5aW5nIHRvIGZpbmQgb3V0IGlzIHdoYXQgdGhleSBhcmUgX2FsbG93ZWRfIHRvIGRv IGJ5IHRoZSBzcGVjLg0KDQpNeSBiaWdnZXN0IHdvcnJ5IGlzOiBzb21lIGluc2FuY2UgY29udGVu dCBpbnNwZWN0aW9uIHN5c3RlbXMgd2FudHMgdG8NCmluc3BlY3Qgb24gYSBwZXItbWVzc2FnZSBi YXNpcy4gVG8gZG8gdGhhdCwgaXQgYnVmZmVycyBhbGwgZnJhbWVzIG9mIGEgbWVzc2FnZSwNCmRv ZXMgaXQncyBpbnNwZWN0aW9uIHRoaW5neSwgYW5kIG9ubHkgdGhlbiBmb3J3YXJkIHRoZSBtZXNz YWdlIGluIG9uZSBmcmFtZQ0KKHRodXMsIGNvYWxlc2NpbmcgYWxsIGZyYW1lcyBvZiB0aGUgZnJh Z21lbnRlZCBtZXNzYWdlIGludG8gb25lKS4NCg0KDQoNCg0KDQoNCg== From andy@warmcat.com Tue Aug 16 02:51: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 6B45E21F8B04 for ; Tue, 16 Aug 2011 02:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pFdf8rkomRYS for ; Tue, 16 Aug 2011 02:51:23 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 96BC821F8AF9 for ; Tue, 16 Aug 2011 02:51:22 -0700 (PDT) Message-ID: <4E4A3DC8.8020001@warmcat.com> Date: Tue, 16 Aug 2011 10:52:08 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein References: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> <4E4A31CE.1060007@warmcat.com> <634914A010D0B943A035D226786325D422C0B9A05E@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A05E@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 09:51:23 -0000 On 08/16/2011 10:33 AM, Somebody in the thread at some point said: >>> In the absence of a negotiated extension / use of any reserved bits, >> >> I think this is "a negotiated extension that the intermediary does not >> understand". > > I meant no extension has been negotiated .. that is both peers agreed > to speak the base WS protocol without any extension. Right.. but actually AIUI you are additionally allowed to mess with framing in the case extensions are negotiated, and the intermediary understands the extensions. >> But... what's the advantage to binding the frame content together in fact? It >> implies it is willing to buffer multiple frame payloads (in order to find out the >> aggregate lengths). That sounds kind of prone to not scaling. >> >> Unless there's something the intermediary was planning to do that likes >> getting a lot of payload, eg compression, it sounds like a better plan the >> intermediary would just spill what was coming in as it came in packet by >> packet and not bind frames together at all. > > I have no clue what intermediaries want to do and for what reasons. What I > was trying to find out is what they are _allowed_ to do by the spec. > > My biggest worry is: some insance content inspection systems wants to > inspect on a per-message basis. To do that, it buffers all frames of a message, > does it's inspection thingy, and only then forward the message in one frame > (thus, coalescing all frames of the fragmented message into one). Hm well messages can be of infinite length in fact so it's on a bit of a loser with that approach. I know what you mean though with the case of buffer boundaries making the inspection parsers blind. However it'll have to find a smarter (eg, bytewise state machine) scheme if it isn't going to be prone to simple attacks prepended with enough whitespace it has to give up on scanning the message at all. There's something else about aggregating frames that's not good, if the thing is going to buffer n frames then it cannot begin to issue until it has the header of the nth frame, since it must first emit the aggregated length. If the traffic is realtime latency sensitive like voice and issued from the endpoint at a fixed rate again like many audio implementations, that introduces really disproportionate latency. For example, if you have 8kHz uLaw coming (1 byte per sample) originally is 1kByte packets every 125ms, if the intermediary decides to buffer and aggregate at 4kByte buffer size, you introduced half a second latency in the audio connection for no gain other than a few bytes less from not having to give the three frame headers that got merged. -Andy From simonp@opera.com Tue Aug 16 03:16: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 CC9C921F8ABD for ; Tue, 16 Aug 2011 03:16:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.074 X-Spam-Level: X-Spam-Status: No, score=-5.074 tagged_above=-999 required=5 tests=[AWL=-1.375, BAYES_00=-2.599, J_CHICKENPOX_14=0.6, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T1BW3J9PV0dE for ; Tue, 16 Aug 2011 03:16:15 -0700 (PDT) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 9085021F8A7B for ; Tue, 16 Aug 2011 03:16:14 -0700 (PDT) Received: from simon-pieterss-macbook.local (c-479de355.410-6-64736c14.cust.bredbandsbolaget.se [85.227.157.71]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id p7GAGv4e022169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Aug 2011 10:17:00 GMT Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Server-Initiated HTTP" , "Alexey Melnikov" References: <4E47FDB5.6070207@isode.com> Date: Tue, 16 Aug 2011 12:17:35 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Simon Pieters" Message-ID: In-Reply-To: <4E47FDB5.6070207@isode.com> User-Agent: Opera Mail/11.50 (MacIntel) Subject: Re: [hybi] Removing Sec-WebSocket-Origin header field from the WebSocket document 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, 16 Aug 2011 10:16:15 -0000 On Sun, 14 Aug 2011 18:54:13 +0200, Alexey Melnikov wrote: > Hi, > > Richard Barnes who did Gen-Art team review of the protocol document > asked the following question: > > Why is this document creating a separate Sec-WebSocket-Origin header, > rather than using the Origin header from draft-ietf-websec-origin? > > I've asked several people and nobody could tell me why the document is > defining a new header field. So unless I hear some objection/explanation > of why an additional header field is useful, it will be removed in -11. > > Thank you, > Alexey, on behalf of editors of the document. zcorpan: back when i was editing the spec, it had Origin: client-to-server, and Sec-WebSocket-Origin server-to-client zcorpan: because Origin: is only defined for client-to-server, and because it was another way to prevent echo servers getting p0wned http://krijnhoetmer.nl/irc-logs/whatwg/20110815#l-802 I note that indeed http://tools.ietf.org/html/draft-hixie-thewebsocketprotocol-76 has Origin as a request header and Sec-WebSocket-Origin as a response header, while http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10 has only Sec-WebSocket-Origin as a request header, and no such response header (I guess the server needs to reject the connection if it doesn't want to accept the origin). I have no idea why the request header was renamed between -76/-00 and -10. I'm fine with renaming it back to Origin. -- Simon Pieters Opera Software From tobias.oberstein@tavendo.de Tue Aug 16 03:30: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 9B50A21F8AF3 for ; Tue, 16 Aug 2011 03:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqKjKyrpLqBS for ; Tue, 16 Aug 2011 03:30:41 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3B521F8AEE for ; Tue, 16 Aug 2011 03:30:40 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Tue, 16 Aug 2011 03:31:28 -0700 From: Tobias Oberstein To: =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= Date: Tue, 16 Aug 2011 03:30:45 -0700 Thread-Topic: AW: [hybi] Intermedaries: coalescing with interleaved control messages Thread-Index: Acxb+i75KE7Jf1HwSJur4djxn7tZCwABVY+g Message-ID: <634914A010D0B943A035D226786325D422C0B9A05F@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A05C@EXVMBX020-12.exch020.serverdata.net> <4E4A31CE.1060007@warmcat.com> <634914A010D0B943A035D226786325D422C0B9A05E@EXVMBX020-12.exch020.serverdata.net> <4E4A3DC8.8020001@warmcat.com> In-Reply-To: <4E4A3DC8.8020001@warmcat.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 10:30:41 -0000 PiA+Pj4gSW4gdGhlIGFic2VuY2Ugb2YgYSBuZWdvdGlhdGVkIGV4dGVuc2lvbiAvIHVzZSBvZiBh bnkgcmVzZXJ2ZWQgYml0cywNCj4gPj4NCj4gPj4gSSB0aGluayB0aGlzIGlzICJhIG5lZ290aWF0 ZWQgZXh0ZW5zaW9uIHRoYXQgdGhlIGludGVybWVkaWFyeSBkb2VzDQo+ID4+IG5vdCB1bmRlcnN0 YW5kIi4NCj4gPg0KPiA+IEkgbWVhbnQgbm8gZXh0ZW5zaW9uIGhhcyBiZWVuIG5lZ290aWF0ZWQg Li4gdGhhdCBpcyBib3RoIHBlZXJzIGFncmVlZA0KPiA+IHRvIHNwZWFrIHRoZSBiYXNlIFdTIHBy b3RvY29sIHdpdGhvdXQgYW55IGV4dGVuc2lvbi4NCj4gDQo+IFJpZ2h0Li4gYnV0IGFjdHVhbGx5 IEFJVUkgeW91IGFyZSBhZGRpdGlvbmFsbHkgYWxsb3dlZCB0byBtZXNzIHdpdGggZnJhbWluZyBp bg0KPiB0aGUgY2FzZSBleHRlbnNpb25zIGFyZSBuZWdvdGlhdGVkLCBhbmQgdGhlIGludGVybWVk aWFyeSB1bmRlcnN0YW5kcyB0aGUNCj4gZXh0ZW5zaW9ucy4NCg0KWWVzLCBteSBxdWVzdGlvbiAN Cg0KIldoYXQgZXhhY3RseSBhcmUgdGhlIHJ1bGVzIGluIHRoZSBiYXNlIFdTIHNwZWMgdGhhdCBy ZXN0cmljdCBob3cgaW50ZXJtZWRpYXJpZXMgbWF5DQpjaGFuZ2UgZnJhZ21lbnRhdGlvbj8gLSBJ biBwYXJ0aWN1bGFyIGluIHRoZSBwcmVzZW5jZSBvZiBpbnRlcmxlYXZlZCBjb250cm9sIGZyYW1l cy4iDQoNCmFwcGxpZXMgdG8gYSkgYW5kIGMpOg0KDQphKQ0KLSBubyBleHRlbnNpb24gYWN0aXZl DQo9PiBpbnRlcm1lZGlhcnkgTUFZIGNoYW5nZSBmcmFnbWVudGF0aW9uIGFjY29yZGluZyB0byBy dWxlcyBvZiB0aGUgYmFzZSBXUyBzcGVjDQoNCmIpDQotIGV4dGVuc2lvbiBhY3RpdmUNCi0gaW50 ZXJtZWRpYXJ5IGRvZXMgbm90IHVuZGVyc3RhbmQgZXh0ZW5zaW9uDQo9PiBpbnRlcm1lZGlhcnkg TVVTVCBOT1QgY2hhbmdlIGZyYWdtZW50YXRpb24gaW4gYW55IHdheQ0KDQpjKQ0KLSBleHRlbnNp b24gYWN0aXZlDQotIGV4dGVuc2lvbiBpbnRyb2R1Y2VzIG5vIG93biBmcmFnbWVudGF0aW9uIHJ1 bGVzDQotIGludGVybWVkaWFyeSBkb2VzIHVuZGVyc3RhbmQgZXh0ZW5zaW9uDQo9PiBpbnRlcm1l ZGlhcnkgTUFZIGNoYW5nZSBmcmFnbWVudGF0aW9uIGFjY29yZGluZyB0byBydWxlcyBvZiB0aGUg YmFzZSBXUyBzcGVjDQoNCmQpDQotIGV4dGVuc2lvbiBhY3RpdmUNCi0gZXh0ZW5zaW9uIGludHJv ZHVjZXMgb3duIGZyYWdtZW50YXRpb24gcnVsZXMNCi0gaW50ZXJtZWRpYXJ5IGRvZXMgdW5kZXJz dGFuZCBleHRlbnNpb24NCj0+IGludGVybWVkaWFyeSBNQVkgY2hhbmdlIGZyYWdtZW50YXRpb24g T05MWSBhY2NvcmRpbmcgdG8gcnVsZXMgb2YgdGhlIGV4dGVuc2lvbg0KDQphbmQgdGhlIGV4dGVu c2lvbiBpbiBkKSBjYW4gb2YgY291cnNlIGp1c3QgcmVxdWlyZTogZG9uJ3QgdG91Y2ggZnJhZ21l bnRhdGlvbiBpbiBhbnkgd2F5Lg0KIA0KPiBUaGVyZSdzIHNvbWV0aGluZyBlbHNlIGFib3V0IGFn Z3JlZ2F0aW5nIGZyYW1lcyB0aGF0J3Mgbm90IGdvb2QsIGlmIHRoZSB0aGluZw0KPiBpcyBnb2lu ZyB0byBidWZmZXIgbiBmcmFtZXMgdGhlbiBpdCBjYW5ub3QgYmVnaW4gdG8gaXNzdWUgdW50aWwg aXQgaGFzIHRoZQ0KPiBoZWFkZXIgb2YgdGhlIG50aCBmcmFtZSwgc2luY2UgaXQgbXVzdCBmaXJz dCBlbWl0IHRoZSBhZ2dyZWdhdGVkIGxlbmd0aC4gIElmIHRoZQ0KPiB0cmFmZmljIGlzIHJlYWx0 aW1lIGxhdGVuY3kgc2Vuc2l0aXZlIGxpa2Ugdm9pY2UgYW5kIGlzc3VlZCBmcm9tIHRoZSBlbmRw b2ludCBhdA0KPiBhIGZpeGVkIHJhdGUgYWdhaW4gbGlrZSBtYW55IGF1ZGlvIGltcGxlbWVudGF0 aW9ucywgdGhhdCBpbnRyb2R1Y2VzIHJlYWxseQ0KPiBkaXNwcm9wb3J0aW9uYXRlIGxhdGVuY3ku DQoNClllcywgYmFkLiBJbnRlcm1lZGFyaWVzIHNob3VsZCBub3QgZ2V0IGludG8gdGhlIHdheS4N Cg0KSSB3b25kZXIgd2h5IHRoZSBiYXNlIFdTIHNwZWMgYWxsb3dzIGNvYWxlc2NpbmcgYnkgaW50 ZXJtZWRpYXJpZXMgYXQgYWxsLg0KDQo= From ibc@aliax.net Tue Aug 16 03:53: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 5AAC621F8AA8 for ; Tue, 16 Aug 2011 03:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.631 X-Spam-Level: X-Spam-Status: No, score=-2.631 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdyXtaoQhzoY for ; Tue, 16 Aug 2011 03:52: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 74A6421F8A56 for ; Tue, 16 Aug 2011 03:52:50 -0700 (PDT) Received: by qyk35 with SMTP id 35so3258525qyk.10 for ; Tue, 16 Aug 2011 03:53:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr3141818qcj.216.1313492017322; Tue, 16 Aug 2011 03:53:37 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 03:53:37 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 12:53:37 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] About 9.2.1. Compression 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, 16 Aug 2011 10:53:06 -0000 2011/8/16 Takeshi Yoshino : >> What does "all bytes of the data stream" mean? all the frames? > > Yes. Including header octets. > >> >> If frames are compressed, how can know the receiver how much to read >> in order to get the payload size? so does the compression extension > > There's no way to know the exact number of bytes needed to be read for a > certain frame. A receiver has to attempt to read octets available in the > socket and pour them into inflater until it gets all the octets for the > frame decompressed. > >> >> transform WS protocol in a streamed protocol rather than frames >> oriented protocol?? >> >> Anyhow I remember long discussions about "compression of frames VS >> compression of frames payload". Is there final decision for that? >> > > This is the thread for consensus call on removing deflate-stream made las= t > month, > http://www.ietf.org/mail-archive/web/hybi/current/msg07982.html > and this is consensus confirmation in that thread. > http://www.ietf.org/mail-archive/web/hybi/current/msg08073.html Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Aug 16 04:50: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 3C8FC21F889A for ; Tue, 16 Aug 2011 04:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cx3T9QqRAKby for ; Tue, 16 Aug 2011 04:50:45 -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 B58C121F886D for ; Tue, 16 Aug 2011 04:50:45 -0700 (PDT) Received: by qwc23 with SMTP id 23so3774154qwc.31 for ; Tue, 16 Aug 2011 04:51:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr1966100qcc.292.1313495493696; Tue, 16 Aug 2011 04:51:33 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 04:51:33 -0700 (PDT) Date: Tue, 16 Aug 2011 13:51:33 +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] Connection header allows multi value separated by COMMA 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, 16 Aug 2011 11:50:46 -0000 Hi, according to RFC 2616 (HTTP 1.1) Connection header allows multivalue: Connection =3D "Connection" ":" 1#(connection-token) connection-token =3D token Could a HTTP WS handshake contain a Connection header with more than "Upgrade" value? for example: Connection: upgrade, close or: Connection: close, upgrade --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Aug 16 05:30:32 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 EBAD921F8A66 for ; Tue, 16 Aug 2011 05:30:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63mA2e4n-Dgt for ; Tue, 16 Aug 2011 05:30:32 -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 69A3D21F8A1A for ; Tue, 16 Aug 2011 05:30:32 -0700 (PDT) Received: by qwc23 with SMTP id 23so3794880qwc.31 for ; Tue, 16 Aug 2011 05:31:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.155 with SMTP id 27mr3202195qcj.216.1313497880177; Tue, 16 Aug 2011 05:31:20 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 05:31:20 -0700 (PDT) Date: Tue, 16 Aug 2011 14:31:20 +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] draft-10: ABNF error in section 9.1 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, 16 Aug 2011 12:30:33 -0000 ------------------------------------------------------------ 9.1. Negotiating Extensions extension-list =3D 1#extension extension =3D extension-token *( ";" extension-param ) extension-token =3D registered-token / private-use-token registered-token =3D token private-use-token =3D "x-" token extension-param =3D token [ "=3D" token ] Note that like other HTTP headers, this header MAY be split or combined across multiple lines. Ergo, the following are equivalent: Sec-WebSocket-Extensions: foo Sec-WebSocket-Extensions: bar; baz=3D2 is exactly equivalent to Sec-WebSocket-Extensions: foo, bar; baz=3D2 ---------------------------------------------------------------------------= -- The examples are wrong since the defined ABNF grammar does NOT allow a space before the ";" (for the extension-param). Correct syntax: Sec-WebSocket-Extensions: bar;baz=3D2 Sec-WebSocket-Extensions: foo, bar;baz=3D2 --=20 I=C3=B1aki Baz Castillo From tyoshino@google.com Tue Aug 16 06:04: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 8302321F8A4E for ; Tue, 16 Aug 2011 06:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.788 X-Spam-Level: X-Spam-Status: No, score=-105.788 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zFYRrNLgMUC for ; Tue, 16 Aug 2011 06:04: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 E00E421F89BE for ; Tue, 16 Aug 2011 06:04:06 -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 p7GD4mAk019393 for ; Tue, 16 Aug 2011 06:04:49 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313499889; bh=2CHDAadNSA6BGIXHR7mjna4pQn0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=wPfjp2KiKyWrh8lPaeLfF0tOIlCh+sO2KjkqSWISGmF/IgfpbpVB3AAL9N1r4MqIL zfoiAulx0t2Bg8IGefshA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=RDXJwzGUsQS/TdbWWoUwd5hFWOZeDE1+JAKD/PX0LJgffvrqxM+6tGuLJ5o8gpUXP DnuVW2gl5+h/sEPv4kuZw== Received: from ywo32 (ywo32.prod.google.com [10.192.15.32]) by wpaz5.hot.corp.google.com with ESMTP id p7GD4PAN012956 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 06:04:47 -0700 Received: by ywo32 with SMTP id 32so3105294ywo.41 for ; Tue, 16 Aug 2011 06:04:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NjZrKwdNiEPaGCRXw8btWMvo4Q1NIooBviodduNC0EU=; b=O5tlx5iWgziQh4IgpaCh1g5xtRCguE6JtF4ZmhLuj3IiSrlk0bi/GNDKWh6qkODkIQ caP98WIhG5ATtXZZkt/w== Received: by 10.151.9.21 with SMTP id m21mr2985575ybi.342.1313499885710; Tue, 16 Aug 2011 06:04:45 -0700 (PDT) Received: by 10.151.9.21 with SMTP id m21mr2985564ybi.342.1313499885487; Tue, 16 Aug 2011 06:04:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Tue, 16 Aug 2011 06:04:23 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 16 Aug 2011 22:04:23 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd4047016453b04aa9f068c X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 16 Aug 2011 13:04:10 -0000 --000e0cd4047016453b04aa9f068c Content-Type: text/plain; charset=ISO-8859-1 My understanding is that they are "implied *LWS" of RFC2616 ABNF. --000e0cd4047016453b04aa9f068c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My understanding is that they are "implied *LWS" of=A0RFC2616=A0A= BNF.

--000e0cd4047016453b04aa9f068c-- From ibc@aliax.net Tue Aug 16 06:13: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 89A3921F8906 for ; Tue, 16 Aug 2011 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wY3reNznXKRq for ; Tue, 16 Aug 2011 06:13:10 -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 F2BAA21F86E0 for ; Tue, 16 Aug 2011 06:13:09 -0700 (PDT) Received: by qyk35 with SMTP id 35so3321563qyk.10 for ; Tue, 16 Aug 2011 06:13:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.173.207 with SMTP id q15mr2905333qaz.278.1313500437646; Tue, 16 Aug 2011 06:13:57 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 06:13:57 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 15:13:57 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 16 Aug 2011 13:13:10 -0000 2011/8/16 Takeshi Yoshino : > My understanding is that they are "implied *LWS" of=C2=A0RFC2616=C2=A0ABN= F. Not al all. The full grammar is described in the WS draft: extension-list =3D 1#extension extension =3D extension-token *( ";" extension-param ) extension-token =3D registered-token / private-use-token registered-token =3D token private-use-token =3D "x-" token extension-param =3D token [ "=3D" token ] And there is no LWS at all. If LWS is allowed then the following line: extension =3D extension-token *( ";" extension-param ) should become: extension =3D extension-token *( SEMI" extension-param ) taking into account that: SEMI =3D SWS ";" SWS; SWS =3D LWS?; The ABNF grammar in section 9.1 is just wrong, sure. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Aug 16 06:14: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 8E79421F888A for ; Tue, 16 Aug 2011 06:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9dndtL+Jkhnp for ; Tue, 16 Aug 2011 06:14:38 -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 0725F21F86E0 for ; Tue, 16 Aug 2011 06:14:37 -0700 (PDT) Received: by qyk35 with SMTP id 35so3322266qyk.10 for ; Tue, 16 Aug 2011 06:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.20 with SMTP id g20mr3381646qac.178.1313500526131; Tue, 16 Aug 2011 06:15:26 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 06:15:26 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 15:15:26 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 16 Aug 2011 13:14:38 -0000 2011/8/16 I=C3=B1aki Baz Castillo : > should become: > > =C2=A0extension =3D extension-token *( SEMI" extension-param ) Sorry: extension =3D extension-token *( SEMI extension-param ) --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Tue Aug 16 06:24: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 5195621F8ABD for ; Tue, 16 Aug 2011 06:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.478 X-Spam-Level: X-Spam-Status: No, score=-1.478 tagged_above=-999 required=5 tests=[AWL=-1.122, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DOaWh+CMMvBW for ; Tue, 16 Aug 2011 06:24:00 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 7D6ED21F8ABB for ; Tue, 16 Aug 2011 06:24:00 -0700 (PDT) Received: (qmail 24241 invoked from network); 16 Aug 2011 13:24:47 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 13:24:46 -0000 Received: (qmail 3900 invoked by uid 99); 16 Aug 2011 13:24:46 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816062444.ef1fc80126c74c6c202a919c41c7bb0b.ed14630c86.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Bjoern Hoehrmann" Date: Tue, 16 Aug 2011 06:24:44 -0700 Mime-Version: 1.0 Cc: hybi@IETF.ORG Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 13:24:01 -0000 > =0A> * Bob Gezelter wrote:=0A> >I agree with I?aki that the distinction b= etween text/binary data is=0A> >unnecessary. Similarly, I agree with Dave E= ndicott's and I?aki's=0A> >comments about the mixing of different classes o= f functionality in the=0A> >WebSocket protocol.=0A> =0A> Not having this di= stinction in the protocol would mean the information=0A> is lost in transit= and has to be coordinated out of protocol. I know of=0A> no notable system= where this has not caused problems. On the contrary,=0A> it is common prac= tise now to design systems to maintain the distinction,=0A> new programming= languages for instance typically have dedicated types=0A> for binary data = and separate types for text data.=0A> =0A> If you want this to be reconside= red, show us systems where the need to=0A> convey this meta data out of ban= d has not lead to problems and has not=0A> lead to complaints about how unw= iedly use of the system is; or systems=0A> where rates of both are very low= , or systems where this distinction is=0A> maintained where that has lead t= o something worse.=0A> =0A> Note that the general expectation is that WebSo= cket-based protocols do=0A> not enjoy the level of coordination, documentat= ion, standardization, we=0A> would expect of TCP-based protocols. With TCP = you might say "Oh, HTTP=0A> will handle that" (and HTTP might say media typ= es handle that) but the=0A> asumptions are do not involve standardized lowe= r levels in the same way.=0A> =0A> JavaScript applications are a primary ta= rget for the protocol. In JS,=0A> the distinction between text and binary d= ata is maintained through its=0A> data types. Your argument is that instead= of letting computers maintain=0A> the distinction, humans should expend ex= tra effort to re-establish it.=0A> I understand not liking the distinction,= but that doesn't make it wrong.=0A> -- =0A> Bj=C3=B6rn H=C3=B6hrmann =C2= =B7 mailto:bjoern@hoehrmann.de =C2=B7 http://bjoern.hoehrmann.de=0A> Am Bad= edeich 7 =C2=B7 Telefon: +49(0)160/4415681 =C2=B7 http://www.bjoernsworld.d= e=0A> 25899 Dageb=C3=BCll =C2=B7 PGP Pub. KeyID: 0xA4357E78 =C2=B7 http://w= ww.websitedev.de/=0A=0ABjoern,=0A=0AOn the contrary, I am not suggesting th= at the information be=0Aout-of-band. It is properly the responsibility of t= he applications layer=0Athat is the client of the WebSocket protocol transp= ort layer. It is true=0Athat in many small applications, the "applications = layer" protocol is=0Anothing more than an informal agreement between develo= pers, but it is=0Aquite real. =0A=0AIn the context of the base, often refer= enced, WHATWG WebSockets API, the=0Amode question can be addressed by API t= o API communications at session=0Aestablishment. While I recall many commen= ts about the UTF-8 mode being=0A"necessary" to accommodate the Websockets A= PI JavaScript-based=0Alimitations, I do not recall any arguments that it wo= uld be appropriate=0Ato switch modes between text/binary on a record-to-rec= ord (or=0Aframe-to-frame) basis. Thus, the inclusion of that information in= every=0Aquantum of information is both redundant and potentially dangerous= , in=0Athat it clearly cannot be relied upon.=0A=0ALooking at the rest of t= he Internet protocol stack, one only see=0Adeclarations of binary/text cont= ent in contexts such as FTP, where the=0Adeclaration is needed to permit (o= r suppress, depending upon your=0Aperspective) formatting conversions at ei= ther end of the connection. As=0Aone who was around early in the Internet, = when character codes and file=0Aformats were far more diverse, it was regre= ttably eminently necessary. A=0Asimilar set of declarations exists for TELN= ET, for similar reasons. =0A=0AA transport or network level protocol withou= t need for code conversions,=0Ahas no need to make any statements about the= contents of the bit stream=0Athat it is carrying as payload. Control frame= s and channel (subchannel=0Ain the mux case) initiation dialogues are a dif= ferent matter, and in=0Athat respect I do not disagree with the IETF standa= rd of using UTF-8 for=0Athat administrative traffic.=0A=0AIf the WebSockets= API (managed by WHATWG, if I recall) wishes to=0Arestrict the use of the W= ebSocket protocol to UTF-8, based upon=0Alimitations of JavaScript, it is a= question for the API. (IMHO, that=0Adecision would be a serious misjudgeme= nt; JavaScript support for binary=0Adata is in the ascendant, as shown by t= he Files API use of BLOB objects,=0Aand the XHR2 revisions.)=0A=0A- Bob Gez= elter, http://www.rlgsc.com=0A From tyoshino@google.com Tue Aug 16 07:00: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 C05DB21F8B07 for ; Tue, 16 Aug 2011 07:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.77 X-Spam-Level: X-Spam-Status: No, score=-105.77 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlfLmOarpbSy for ; Tue, 16 Aug 2011 07:00:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id BBB8C21F8AD3 for ; Tue, 16 Aug 2011 07:00:40 -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 p7GE1Ott024837 for ; Tue, 16 Aug 2011 07:01:26 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313503286; bh=YVx8fzehOE0mO48WaXIpNzB69WU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tf4vWkImGnvAq2rJsvEhp+P3wBazc+Xg34gSO7B/zHLYX9bGBz9KpIgja/iZJXUOe A9VDILtAj0fD+rDEmsOMg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=HrRIJ4OjEjKn6fE88XgNQcbL2QVW3yLnbbZTEvHcnAwEA6E91+LCWBsG9FAgw7BjG HxGkuRk5TSAe0IzkYVEfg== Received: from gyf3 (gyf3.prod.google.com [10.243.50.67]) by hpaq1.eem.corp.google.com with ESMTP id p7GE156i012891 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 07:01:22 -0700 Received: by gyf3 with SMTP id 3so5310040gyf.17 for ; Tue, 16 Aug 2011 07:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Sb0HtJ13d2oXJnXl10Rs4X7/mH2k9X6R2xKEvy8L7J4=; b=An2Y6NpRl4lpt83wWjeI5KumWQYPQ8nsCYwQkcQm5J2xub7rMZAPGUoDBEbK3pbotU P0sIIufN8s/4CSf4F8ng== Received: by 10.150.40.15 with SMTP id n15mr6075316ybn.0.1313503282308; Tue, 16 Aug 2011 07:01:22 -0700 (PDT) Received: by 10.150.40.15 with SMTP id n15mr6075310ybn.0.1313503282151; Tue, 16 Aug 2011 07:01:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Tue, 16 Aug 2011 07:01:01 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 16 Aug 2011 23:01:01 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd5f2cc8b41d604aa9fd0f6 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Connection header allows multi value separated by COMMA 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, 16 Aug 2011 14:00:42 -0000 --000e0cd5f2cc8b41d604aa9fd0f6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2011 at 20:51, I=F1aki Baz Castillo wrote: > Hi, according to RFC 2616 (HTTP 1.1) Connection header allows multivalue: > > Connection =3D "Connection" ":" 1#(connection-token) > connection-token =3D token > > Could a HTTP WS handshake contain a Connection header with more than > "Upgrade" value? for example: > > Connection: upgrade, close > > or: > > Connection: close, upgrade It's allowed. Section 5.1 also implies that by saying ""Connection" header whose value MUST include the "Upgrade" token" (not "is" like "Upgrade" header but "include"). E.g. if we allow reuse of the TCP connection for new HTTP request or even more WebSocket handshake attempt after unsuccessful handshaking, having keep-alive token together (as Firefox Aurora does) might make sense. A few of possible combinations may make sense, but maybe most doesn't since after handshaking it's no longer HTTP. I think we don't have to prohibit multiple values in it, but rather should have some text to explain how to handle such multi-value Connection header for interoperability if we decide to use it. Thanks, Takeshi --000e0cd5f2cc8b41d604aa9fd0f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 20:51, I=F1aki Baz Castillo = <ibc@aliax.net>= ; wrote:
Hi, according to RFC 2616 (HTTP 1.1) Connect= ion header allows multivalue:

=A0 =A0 =A0 Connection =3D "Connection" ":" 1#(connect= ion-token)
=A0 =A0 =A0 connection-token =A0=3D token

Could a HTTP WS handshake contain a Connection header with more than
"Upgrade" value? for example:

=A0Connection: upgrade, close

or:

=A0Connection: close, upgrade

It's all= owed.=A0Section 5.1 also implies that by saying ""Connection"= ; header whose value MUST=A0include the "Upgrade" token" (no= t "is" like "Upgrade" header but "include").<= /div>

E.g. if=A0we allow reuse of the TCP connection for new = HTTP request or even more WebSocket handshake attempt=A0after unsuccessful = handshaking, having keep-alive token together (as=A0Firefox Aurora does) mi= ght make sense.

A few of possible combinations may make sense, but= maybe most doesn't since after handshaking it's no longer HTTP. I = think we don't have to prohibit multiple values in it, but rather shoul= d have some text to explain how to handle such multi-value Connection heade= r for interoperability if we decide to use it.

Thanks,
Takeshi
<= /div>
--000e0cd5f2cc8b41d604aa9fd0f6-- From gezelter@rlgsc.com Tue Aug 16 07:14: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 B907A21F8B3B for ; Tue, 16 Aug 2011 07:14:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.217 X-Spam-Level: X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZMgnQ0batj0 for ; Tue, 16 Aug 2011 07:14:28 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id 1F09521F8B26 for ; Tue, 16 Aug 2011 07:14:28 -0700 (PDT) Received: (qmail 29799 invoked from network); 16 Aug 2011 14:15:16 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 14:15:16 -0000 Received: (qmail 15880 invoked by uid 99); 16 Aug 2011 14:15:16 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816071515.ef1fc80126c74c6c202a919c41c7bb0b.e103bd8485.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Tue, 16 Aug 2011 07:15:15 -0700 Mime-Version: 1.0 Cc: gregw@intalio.com Subject: [hybi] Sender-Receiver Latency 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, 16 Aug 2011 14:14:28 -0000 Concerning a message from Andy Green to Bruce=0AAtherton= on Tue, 16 Aug 2011 06:43:50 +0100=0Aentitled "Re: [= hybi] CONSENSUS CALL / Frame too big not possible to=0Aoccur"=0A=0ABreaking= the latency discussion into sender vs. receiver latency is not,=0AIMHO, pa= rticularly constructive. There are multiple sets of queued=0Ainterfaces bet= ween when a sender application hands a message to the API=0Aand when the re= sponse is received by the sender. =0A=0AIt is this round-trip delay that is= measured by the applicable timeout.=0AA huge frame (e.g., many seconds of = channel time) causes a timeout,=0Aregardless of whether it interferes with = the transmission of the=0Aoriginal request, or whether it delays the revers= e direction response.=0AThe next effect is the same: a failed request. This= is the phenomenon=0Areferred to in military communications circles as "a m= essage not=0Areceived is was as if never sent" (For the literary minded, th= e quote is=0Afrom Edward Beach's "Dust on the Sea" (1972); similar referenc= es occur=0Ain other places, both fiction and non-fiction).=0A=0AThis is one= of the reasons for keeping frames relatively small relative=0Ato transmiss= ion bandwidth. In the case of multiplexing, it is also the=0Areason for doi= ng frame-based multiplexing as opposed to message-based=0Amultiplexing.=0A= =0A- Bob Gezelter, http://www.rlgsc.com=0A=0A From jat@google.com Tue Aug 16 07:16: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 7283621F8B5E for ; Tue, 16 Aug 2011 07:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=0.064, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou-OQLSak+f5 for ; Tue, 16 Aug 2011 07:16:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4B97621F8B5B for ; Tue, 16 Aug 2011 07:16:23 -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 p7GEHB1h012850 for ; Tue, 16 Aug 2011 07:17:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313504231; bh=r5HijXn5qZSuARaJFEdUr6RjJfs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IAK2mrrZm9jR1y2Kcy7jaeItQD+IzYhOAWUZ6n6M/P82SLl52adh91Su7Q3oEOA/p audh2adgocloJdh3Zbf9g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=GYcJTHIQIKQ4DNSo7h70jKMXHv4nEwfES6nSTghWccfmSIOrVBLVxFn6oBtiZO/RQ nhByf8orXRNjfXDcrkVgg== Received: from gwj22 (gwj22.prod.google.com [10.200.10.22]) by hpaq11.eem.corp.google.com with ESMTP id p7GEH8os002124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 07:17:09 -0700 Received: by gwj22 with SMTP id 22so5147523gwj.7 for ; Tue, 16 Aug 2011 07:17:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ImgmqBwg7WNYEB9kfNMx5q7OFzb9Xje8Vvj19E1tIeY=; b=cS3mi4St9tcFqadWeKd1svRjyQOcQsttwd6w6Y41UpSpxQUFbOvIeZqLzDrNmwu2M3 lvD59tv/Bjz/DzOLjD0Q== Received: by 10.151.25.12 with SMTP id c12mr284185ybj.116.1313504228243; Tue, 16 Aug 2011 07:17:08 -0700 (PDT) Received: by 10.151.25.12 with SMTP id c12mr284179ybj.116.1313504228105; Tue, 16 Aug 2011 07:17:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 16 Aug 2011 07:16:48 -0700 (PDT) In-Reply-To: <20110816062444.ef1fc80126c74c6c202a919c41c7bb0b.ed14630c86.wbe@email03.secureserver.net> References: <20110816062444.ef1fc80126c74c6c202a919c41c7bb0b.ed14630c86.wbe@email03.secureserver.net> From: John Tamplin Date: Tue, 16 Aug 2011 10:16:48 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=000e0cd293c2ed5e9b04aaa00827 X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 14:16:24 -0000 --000e0cd293c2ed5e9b04aaa00827 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2011 at 9:24 AM, Bob Gezelter wrote: > In the context of the base, often referenced, WHATWG WebSockets API, the > mode question can be addressed by API to API communications at session > establishment. While I recall many comments about the UTF-8 mode being > "necessary" to accommodate the Websockets API JavaScript-based > limitations, I do not recall any arguments that it would be appropriate > to switch modes between text/binary on a record-to-record (or > frame-to-frame) basis. Thus, the inclusion of that information in every > quantum of information is both redundant and potentially dangerous, in > that it clearly cannot be relied upon. > Actually, it seems quite likely that both text and binary data will be transferred on one connection. For example, a chat program will frequently exchange text messages (perhaps JSON) and yet also needs to be able to transfer images and user files. If the WebSockets API (managed by WHATWG, if I recall) wishes to > restrict the use of the WebSocket protocol to UTF-8, based upon > limitations of JavaScript, it is a question for the API. (IMHO, that > decision would be a serious misjudgement; JavaScript support for binary > data is in the ascendant, as shown by the Files API use of BLOB objects, > and the XHR2 revisions.) Which is exactly why binary frames are supported. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd293c2ed5e9b04aaa00827 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 9:24 AM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
In the context of the base, often referenced, WHATWG WebS= ockets API, the
mode question can be addressed by API to API communications at session
establishment. While I recall many comments about the UTF-8 mode being
"necessary" to accommodate the Websockets API JavaScript-based limitations, I do not recall any arguments that it would be appropriate
to switch modes between text/binary on a record-to-record (or
frame-to-frame) basis. Thus, the inclusion of that information in every
quantum of information is both redundant and potentially dangerous, in
that it clearly cannot be relied upon.

=
Actually, it seems quite likely that both text and binary da= ta will be transferred on one connection. =C2=A0For example, a chat program= will frequently exchange text messages (perhaps JSON) and yet also needs t= o be able to transfer images and user files.
=C2=A0

If the WebS= ockets API (managed by WHATWG, if I recall) wishes to
restrict the use of the WebSocket protocol to UTF-8, based upon
limitations of JavaScript, it is a question for the API. (IMHO, that
decision would be a serious misjudgement; JavaScript support for binary
data is in the ascendant, as shown by the Files API use of BLOB objects, and the XHR2 revisions.)


Whi= ch is exactly why binary frames are supported.

--=
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd293c2ed5e9b04aaa00827-- From gezelter@rlgsc.com Tue Aug 16 07:20: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 8279721F8B7F for ; Tue, 16 Aug 2011 07:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-0.174, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSzE4AemW29e for ; Tue, 16 Aug 2011 07:20:43 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id 0556A21F8B33 for ; Tue, 16 Aug 2011 07:20:41 -0700 (PDT) Received: (qmail 9153 invoked from network); 16 Aug 2011 14:21:30 -0000 Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 14:21:30 -0000 Received: (qmail 5743 invoked by uid 99); 16 Aug 2011 14:21:30 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816072129.ef1fc80126c74c6c202a919c41c7bb0b.df19a7b74a.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "John Tamplin" Date: Tue, 16 Aug 2011 07:21:29 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 14:20:44 -0000 =0A=0A> -------- Original Message --------=0A> Subject: Re: [hybi] Binary/T= ext Distinction=0A> From: John Tamplin =0A> Date: Tue, Augu= st 16, 2011 7:16 am=0A> To: Bob Gezelter =0A> Cc: Bjoer= n Hoehrmann , hybi@ietf.org=0A> =0A...... [repeat of ear= lier exchanged suppressed for brevity]=0A> =0A> Which is exactly why binary= frames are supported.=0A> =0A> -- =0A> John A. Tamplin=0A> Software Engine= er (GWT), Google=0A=0AJohn,=0A=0AMy objection to the distinction is that it= does not, IMHO, belong in the=0AWebSocket protocol, it belongs in the next= layer above the basic=0AWebSocket protocol transport layer.=0A=0A- Bob Gez= elter, http://www.rlgsc.com=0A From jat@google.com Tue Aug 16 07:24: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 1CA9F21F8B1E for ; Tue, 16 Aug 2011 07:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.93 X-Spam-Level: X-Spam-Status: No, score=-105.93 tagged_above=-999 required=5 tests=[AWL=0.046, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVeZF2OL64Ol for ; Tue, 16 Aug 2011 07:24:00 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 524E121F8772 for ; Tue, 16 Aug 2011 07:24:00 -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 p7GEOlSM016703 for ; Tue, 16 Aug 2011 07:24:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313504688; bh=tSlDGVXlJyPGDEWAfwf5NS6qln8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EBP+qyB8Z9ppvtmJapJf7pcs334firxn01fgmtkwVJT/heFXYGhgwxPv2aQsB3gwQ uGxTYhYIxvNvCLXixCBxQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=oBzhAS6wQRQxB0ras9MlZJH0Zu9KKBLtqJW2becOzVJVMUKRJmiV1Gh6Ykln62dPW Lnjh6ZH9a0c3hZTDiXM1w== Received: from gxk8 (gxk8.prod.google.com [10.202.11.8]) by wpaz29.hot.corp.google.com with ESMTP id p7GEOehN028089 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 07:24:46 -0700 Received: by gxk8 with SMTP id 8so3621426gxk.9 for ; Tue, 16 Aug 2011 07:24:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=JP6IJ1uRrof6OXnJi1jtO89k2/Txc24kezA67oJBZ3g=; b=xI/uDX/tbQfcfQ/wUtNyGteHsAZV0o+TEgCuSaJY0gA8pCNCcQlpD5vom4pLOS1c97 KUz8YrOJAwK1mVmbyrZQ== Received: by 10.151.13.11 with SMTP id q11mr6116228ybi.173.1313504686466; Tue, 16 Aug 2011 07:24:46 -0700 (PDT) Received: by 10.151.13.11 with SMTP id q11mr6116218ybi.173.1313504686135; Tue, 16 Aug 2011 07:24:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 16 Aug 2011 07:24:26 -0700 (PDT) In-Reply-To: <20110816072129.ef1fc80126c74c6c202a919c41c7bb0b.df19a7b74a.wbe@email03.secureserver.net> References: <20110816072129.ef1fc80126c74c6c202a919c41c7bb0b.df19a7b74a.wbe@email03.secureserver.net> From: John Tamplin Date: Tue, 16 Aug 2011 10:24:26 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=000e0cd6a93e3a5ae404aaa024b6 X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 14:24:01 -0000 --000e0cd6a93e3a5ae404aaa024b6 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2011 at 10:21 AM, Bob Gezelter wrote: > My objection to the distinction is that it does not, IMHO, belong in the > WebSocket protocol, it belongs in the next layer above the basic > WebSocket protocol transport layer. Then you have to provide some way for JS apps to serialize/deserialize arbitrary mixes of text and binary data to a binary frame to send in WS. It might be possible to standardize on such a thing and make sure it is robust against hostile JS, but given how long WS has been in development it seems prudent to avoid making such a mechanism a blocker for deploying WS. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6a93e3a5ae404aaa024b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 10:21 AM, Bob Gezelter <= span dir=3D"ltr"><gezelter@rlgsc.c= om> wrote:
My objection to the distinction is that it does not, IMHO= , belong in the
WebSocket protocol, it belongs in the next layer above the basic
WebSocket protocol transport layer.

Then y= ou have to provide some way for JS apps to serialize/deserialize arbitrary = mixes of text and binary data to a binary frame to send in WS. =C2=A0It mig= ht be possible to standardize on such a thing and make sure it is robust ag= ainst hostile JS, but given how long WS has been in development it seems pr= udent to avoid making such a mechanism a blocker for deploying WS.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd6a93e3a5ae404aaa024b6-- From gezelter@rlgsc.com Tue Aug 16 07:25: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 7B9C321F8BAC for ; Tue, 16 Aug 2011 07:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.086 X-Spam-Level: X-Spam-Status: No, score=-1.086 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZU5g-bIJRVM for ; Tue, 16 Aug 2011 07:25:43 -0700 (PDT) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by ietfa.amsl.com (Postfix) with SMTP id 43DBA21F8BAA for ; Tue, 16 Aug 2011 07:25:38 -0700 (PDT) Received: (qmail 8443 invoked from network); 16 Aug 2011 14:26:26 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 14:26:26 -0000 Received: (qmail 6532 invoked by uid 99); 16 Aug 2011 14:26:26 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816072625.ef1fc80126c74c6c202a919c41c7bb0b.55b7e6e34f.wbe@email03.secureserver.net> From: "Bob Gezelter" To: tobias.oberstein@tavendo.de Date: Tue, 16 Aug 2011 07:26:25 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org Subject: [hybi] Ping/Pong, Intermediaries, Multiplexing 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, 16 Aug 2011 14:25:44 -0000 Tobias,=0A=0AI cannot give you a precise citation at this instant, but it h= as always=0Abeen my assumption that Control frames were not of the sizes th= at would=0Abe subject to further fragmentation.=0A=0AIf this is not specifi= cally prohibited, IMHO it should be.=0A=0AThat would admittedly somewhat tr= ansform the discussion from "Maximum=0Aframe size" to "Minimum/Maximum fram= e size".=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From gezelter@rlgsc.com Tue Aug 16 07:33: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 59BB021F8B34 for ; Tue, 16 Aug 2011 07:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.06 X-Spam-Level: X-Spam-Status: No, score=-1.06 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bY9isLXOnQYI for ; Tue, 16 Aug 2011 07:33:13 -0700 (PDT) Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by ietfa.amsl.com (Postfix) with SMTP id BAD7221F8B2F for ; Tue, 16 Aug 2011 07:33:13 -0700 (PDT) Received: (qmail 16613 invoked from network); 16 Aug 2011 14:34:02 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 14:34:02 -0000 Received: (qmail 22297 invoked by uid 99); 16 Aug 2011 14:34:02 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816073401.ef1fc80126c74c6c202a919c41c7bb0b.f02db904ba.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Tue, 16 Aug 2011 07:34:01 -0700 Mime-Version: 1.0 Subject: [hybi] "Intermediaries" 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, 16 Aug 2011 14:33:14 -0000 I would like to suggest that as a group, we be far more precise about=0Aour= usage of the term "intermediaries".=0A=0AA device that terminates a WebSoc= ket protocol connection underlying=0Atransport connection (e.g., TCP link) = is most properly referred to as a=0A"gateway". In a multiplexed context, su= ch a device might also forward=0Athe contained sub-channels to different ph= ysical endpoints, functioning=0Aas a traffic director or proxy.=0A=0AA devi= ce that seemingly transparently inspects (and possibly interferes=0Awith) t= he transport stream WITHOUT being the endpoint of the transport=0Aconnectio= n is a very different beast. It is hardly a proxy.=0A=0AThese two devices (= and I DO NOT claim that the above is an exhaustive=0Ataxonomy) are far diff= erent in their issues and implications.=0A=0AFor example, consider the mean= ing of PING/PONG in the above cases. For=0Aone thing, it is clear that a mu= ltiplexed implementation requires a=0Asub-channel PING/PONG, or an explicit= note that an application using a=0Achannel is responsible for ascertaining= the state of its correspondent=0Athrough a similar, applications level con= struct (preferably the latter,=0Athe only assurance that an application end= point is actually functioning=0Ais a response from the application itself, = not a response from the=0Aremote API).=0A=0A- Bob Gezelter, http://www.rlgs= c.com=0A From dendicott@gmail.com Tue Aug 16 07:34: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 96B1E21F8B34 for ; Tue, 16 Aug 2011 07:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.503 X-Spam-Level: X-Spam-Status: No, score=-3.503 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a6Y4oQAdoWoD for ; Tue, 16 Aug 2011 07:34:51 -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 A6AD721F8B2F for ; Tue, 16 Aug 2011 07:34:50 -0700 (PDT) Received: by wwf5 with SMTP id 5so3989150wwf.13 for ; Tue, 16 Aug 2011 07:35:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1xcq575Z0C+pg2vhxwW19qILqBp0XnLtiEAyd1Bg2ns=; b=gIpB91g2eLaKRScB3MedWaBIF2uwN46it6QN1TQU7+631w2Qsy6Vr3cBJGZV5rfm2Z 5l5Ir3liCa8sgFAiKXHveI1T0SZwnRYMSrvjNl7J+qSVvCifoL3hU7U4vjirG95GzGSh +Sfr5LyLKltevkutYq7PqFNqrKUZ6oY7K/Zrk= MIME-Version: 1.0 Received: by 10.216.8.85 with SMTP id 63mr4683400weq.29.1313505334938; Tue, 16 Aug 2011 07:35:34 -0700 (PDT) Received: by 10.217.3.203 with HTTP; Tue, 16 Aug 2011 07:35:34 -0700 (PDT) In-Reply-To: <4E49E016.6060306@lig.net> References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> <5qdj47lrjf60rugujbc8jt8qkulegg3knu@hive.bjoern.hoehrmann.de> <8B0A9FCBB9832F43971E38010638454F040D45C350@SISPE7MB1.commscope.com> <4E49E016.6060306@lig.net> Date: Tue, 16 Aug 2011 10:35:34 -0400 Message-ID: From: David Endicott To: Stephen Williams Content-Type: multipart/alternative; boundary=0016364d1c1fe64d2004aaa04a35 Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction 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, 16 Aug 2011 14:34:52 -0000 --0016364d1c1fe64d2004aaa04a35 Content-Type: text/plain; charset=ISO-8859-1 > > model, which provides a perfect channel for this sort of coordination. The >> server is effectively talking to itself. Thus, no need for any form of >> negotiation...the server is no longer interacting with the browser, it's >> interacting with itself. >> > > Please clarify. If you're saying what I think you're saying, I'm must > disagree. > > > I took that to mean: The typical use case for WS will be for a web server > app that serves a Javascript-enabled web page to a browser. Since the > Javascript code is coming from the server it will be talking to, it > shouldn't typically be very hard to keep them in sync. This is opposed to > use as a Web API for general applications that might involve code from > multiple unrelated parties. Because this may be the first widely available > web (server/protocol/security model) protocol for applications, it would be > good to be friendly to the JS page and general cases. > Yep, I completely missed the point. I agree with your explanation. The server extrudes part of the code onto the browser. A rendering front-end. This will be a common use case. Another use case I suspect will be equally common is where Websockets becomes a conduit for messages. The client-agents will process these messages in their own fashion. The server then becomes a resource api (ie. service). > The text frame hack is simply a nod to common use convenience. (And an > unnecessary one at that, IMHO) > > > A flag to indicate something like "Content-Type: application/UTF-8" is OK. > But it shouldn't be necessary. > I remain firmly in the position that there should be NO content type specification of any time. I believe strongly that WS should be (is) a transport protocol and must by content agnostic. I'm willing to trade a little purity for a little convenience, but I think it would have been better handled at the end-points (WS clients/servers) rather than as part of the protocol. I would drop the text/binary distinction, have all frames be opaque (and presumably "binary") and expect the WS using applications to know/determine content type on their own. --0016364d1c1fe64d2004aaa04a35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
model, which provides a perfect channel for = this sort of coordination. =A0The server is effectively talking to itself. =A0Thus, no need for any form of negotiation...the server is no longer interacting with the browser, it's interacting with itself.

Please clarify. =A0 If you're saying what I think you'= re saying, I'm must disagree.


I took that to mean: The typical use case for WS will be for a web server app that serves a Javascript-enabled web page to a browser.=A0 Since the Javascript code is coming from the server it will be talking to, it shouldn't typically be very hard to keep them in sync.=A0 This is opposed to use as a Web API for general applications that might involve code from multiple unrelated parties.=A0 Because this may be the first widely available web (server/protocol/security model) protocol for applications, it would be good to be friendly to the JS page and general cases.

Ye= p, I completely missed the point. =A0 =A0I agree with your=A0explanation. = =A0 =A0The server extrudes part of the code onto the browser. =A0 A renderi= ng front-end.=A0 =A0 =A0This will be a common use case.

Another use case I suspect will be equally common is wh= ere Websockets becomes a conduit for messages. =A0 =A0The client-agents wil= l process these messages in their own fashion. =A0 =A0The server then becom= es a resource api (ie. service).


<= div class=3D"gmail_quote">

The text frame hack is simply a nod to common use=A0convenience. =A0 (And an unnecessary one at that, IMHO)

A flag to indicate something like "Content-Type: application/UTF-8= " is OK.=A0 But it shouldn't be necessary.
I remain firmly in the position that there should be NO content= type specification of any time. =A0 I believe strongly that WS should be (= is) a transport protocol and must by content agnostic.

I'm willing to trade a little purity for a little= =A0convenience, but=A0I think it would have been better handled at the end-= points (WS clients/servers) rather than as part of the protocol.=A0

I would drop the text/binary distinction, have all frames be opa= que (and presumably "binary") and expect the WS using application= s to know/determine content type on their own.

--0016364d1c1fe64d2004aaa04a35-- From ibc@aliax.net Tue Aug 16 07:37: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 80A9421F87C5 for ; Tue, 16 Aug 2011 07:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJa4C1tg6ogY for ; Tue, 16 Aug 2011 07:37:18 -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 F06DA21F8797 for ; Tue, 16 Aug 2011 07:37:17 -0700 (PDT) Received: by qyk34 with SMTP id 34so1394973qyk.10 for ; Tue, 16 Aug 2011 07:38:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.173.207 with SMTP id q15mr2992542qaz.278.1313505486271; Tue, 16 Aug 2011 07:38:06 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 07:38:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Aug 2011 16:38:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Connection header allows multi value separated by COMMA 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, 16 Aug 2011 14:37:18 -0000 2011/8/16 Takeshi Yoshino : > It's allowed.=C2=A0Section 5.1 also implies that by saying ""Connection" = header > whose value MUST=C2=A0include the "Upgrade" token" (not "is" like "Upgrad= e" > header but "include"). > E.g. if=C2=A0we allow reuse of the TCP connection for new HTTP request or= even > more WebSocket handshake attempt=C2=A0after unsuccessful handshaking, hav= ing > keep-alive token together (as=C2=A0Firefox Aurora does) might make sense. > A few of possible combinations may make sense, but maybe most doesn't sin= ce > after handshaking it's no longer HTTP. I think we don't have to prohibit > multiple values in it, but rather should have some text to explain how to > handle such multi-value Connection header for interoperability if we deci= de > to use it. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Tue Aug 16 07:47: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 3671A21F8A95 for ; Tue, 16 Aug 2011 07:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z57d+4FxvXzG for ; Tue, 16 Aug 2011 07:47:07 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA3A21F8876 for ; Tue, 16 Aug 2011 07:47:07 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Tue, 16 Aug 2011 07:47:55 -0700 From: Tobias Oberstein To: Bob Gezelter Date: Tue, 16 Aug 2011 07:47:13 -0700 Thread-Topic: [hybi] Intermedaries: coalescing with interleaved control messages Thread-Index: AcxcIuxt/hqAEaE1QPywo4zc+a7Zbw== Message-ID: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 14:47:08 -0000 Qm9iLA0KDQpmcmFnbWVudGluZyBjb250cm9sIG1lc3NhZ2VzIGlzIGZvcmJpZGRlbiBhbmQgY29u dHJvbCBmcmFtZXMgY2FuIGhhdmUgYSBtYXguIHBheWxvYWQgb2YgMTI1IG9jdGV0cy4NCg0KTXkg cXVlc3Rpb24gaXM6DQoNCldoZW4gYW4gaW50ZXJtZWRpYXJ5IHJlY2VpdmVzDQoNCltNU0cxLWZy YWdtZW50MV0gW01TRzEtZnJhZ21lbnQyXSBbQ09OVFJPTC1mcmFtZV0gW01TRzEtZnJhZ21lbnQz XQ0KDQp3aGljaCBvZiB0aGUgZm9sbG93aW5nIGlzIGl0IGFsbG93ZWQgdG8gY29hbGVzY2UgaW50 byB3aGVuIGZvcndhcmRpbmc6DQoNCkMxLg0KW01TRzEtZnJhZ21lbnQxMl0gW0NPTlRST0wtIGZy YW1lXSBbTVNHMS1mcmFnbWVudDNdDQoNCkMyLg0KW01TRzEtZnJhZ21lbnQxMjNdIFtDT05UUk9M LSBmcmFtZV0NCiANCkMzLg0KW0NPTlRST0wtbWVzc2FnZV0gW01TRzEtZnJhZ21lbnQxMjNdDQoN CkM0Lg0KW01TRzEtZnJhZ21lbnQxXSBbQ09OVFJPTC0gZnJhbWVdIFtNU0cxLWZyYWdtZW50MjNd DQoNCj09DQoNCiJhbGxvd2VkIiA9IGFjY29yZGluZyB0byBydWxlcyBhcyBkZWZpbmVkIGJ5IHRo ZSBiYXNlIFdTIHNwZWMgd2l0aCBubyBhY3RpdmUgZXh0ZW5zaW9uDQoNClRvYmlhcw0KDQo+IC0t LS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBCb2IgR2V6ZWx0ZXIgW21h aWx0bzpnZXplbHRlckBybGdzYy5jb21dDQo+IEdlc2VuZGV0OiBEaWVuc3RhZywgMTYuIEF1Z3Vz dCAyMDExIDE2OjI2DQo+IEFuOiBUb2JpYXMgT2JlcnN0ZWluDQo+IENjOiBoeWJpQGlldGYub3Jn DQo+IEJldHJlZmY6IFBpbmcvUG9uZywgSW50ZXJtZWRpYXJpZXMsIE11bHRpcGxleGluZw0KPiAN Cj4gVG9iaWFzLA0KPiANCj4gSSBjYW5ub3QgZ2l2ZSB5b3UgYSBwcmVjaXNlIGNpdGF0aW9uIGF0 IHRoaXMgaW5zdGFudCwgYnV0IGl0IGhhcyBhbHdheXMgYmVlbiBteQ0KPiBhc3N1bXB0aW9uIHRo YXQgQ29udHJvbCBmcmFtZXMgd2VyZSBub3Qgb2YgdGhlIHNpemVzIHRoYXQgd291bGQgYmUgc3Vi amVjdA0KPiB0byBmdXJ0aGVyIGZyYWdtZW50YXRpb24uDQo+IA0KPiBJZiB0aGlzIGlzIG5vdCBz cGVjaWZpY2FsbHkgcHJvaGliaXRlZCwgSU1ITyBpdCBzaG91bGQgYmUuDQo+IA0KPiBUaGF0IHdv dWxkIGFkbWl0dGVkbHkgc29tZXdoYXQgdHJhbnNmb3JtIHRoZSBkaXNjdXNzaW9uIGZyb20gIk1h eGltdW0NCj4gZnJhbWUgc2l6ZSIgdG8gIk1pbmltdW0vTWF4aW11bSBmcmFtZSBzaXplIi4NCj4g DQo+IC0gQm9iIEdlemVsdGVyLCBodHRwOi8vd3d3LnJsZ3NjLmNvbQ0KDQo= From jat@google.com Tue Aug 16 07:52: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 483D421F8B53 for ; Tue, 16 Aug 2011 07:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.933 X-Spam-Level: X-Spam-Status: No, score=-105.933 tagged_above=-999 required=5 tests=[AWL=0.043, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMKx4Rkl1R9W for ; Tue, 16 Aug 2011 07:52:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 503E221F8B48 for ; Tue, 16 Aug 2011 07:52:58 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7GErhYd013350 for ; Tue, 16 Aug 2011 07:53:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313506424; bh=Rd8LWXQ5Mqu4kia1/y7i63o1LOw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=DE+HAnj50BRIvOp7X2AoIXVBgiOr9EsNprwpfNz+2X3VY/7kzAV14IVTU/ofpVAhP f5uwTBcOq4QOmYAGvCtuQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=GlV9bmPuRoDJ0+NGXBxdaYmB5hGLWU0UdFEkP8gycaxjOUfy/2QddpIT97IKGVNMs ZcZpscIWrVp4IHNCWKRgw== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by wpaz1.hot.corp.google.com with ESMTP id p7GErgk1028039 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 07:53:42 -0700 Received: by yxl11 with SMTP id 11so5139012yxl.35 for ; Tue, 16 Aug 2011 07:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Xc89wzSZjpOyK3omllA4yENTu250ewzcfPXkLURKtdw=; b=jRyKiNZkZVSZP3bR96i5OsfIcdJU6YZF51AN9WDx6MhUxHgy/2w5JXKGmtJKrkq/0K 2uw9ztM5DJn11iv0HJmQ== Received: by 10.151.21.9 with SMTP id y9mr5579848ybi.344.1313506422258; Tue, 16 Aug 2011 07:53:42 -0700 (PDT) Received: by 10.151.21.9 with SMTP id y9mr5579841ybi.344.1313506422136; Tue, 16 Aug 2011 07:53:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 16 Aug 2011 07:53:22 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Tue, 16 Aug 2011 10:53:22 -0400 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd4b2d6b3a20004aaa08b53 X-System-Of-Record: true Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 14:52:59 -0000 --000e0cd4b2d6b3a20004aaa08b53 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2011 at 10:47 AM, Tobias Oberstein When an intermediary receives > > > [MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame] [MSG1-fragment3] > > which of the following is it allowed to coalesce into when forwarding: > > C1. > [MSG1-fragment12] [CONTROL- frame] [MSG1-fragment3] > > C2. > [MSG1-fragment123] [CONTROL- frame] > > C3. > [CONTROL-message] [MSG1-fragment123] > > C4. > [MSG1-fragment1] [CONTROL- frame] [MSG1-fragment23] > > == > > "allowed" = according to rules as defined by the base WS spec with no > active extension > I don't believe the spec has anything to say about this currently, so I believe all of them would be allowed. Personally, I would think #1 should definitely be allowed, and that it might be useful for an intermediary that collected small frames to do #3 or #4. It seems you wouldn't want to delay a control frame while waiting for more frames in a message, so I would prefer to outlaw #2, but I don't feel strongly about it. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd4b2d6b3a20004aaa08b53 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 10:47 AM, Tobias Oberste= in=C2=A0When an intermediary receives

[MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame] [MSG1-fragment3]

which of the following is it allowed to coalesce into when forwarding:

C1.
[MSG1-fragment12] [CONTROL- frame] [MSG1-fragment3]

C2.
[MSG1-fragment123] [CONTROL- frame]

C3.
[CONTROL-message] [MSG1-fragment123]

C4.
[MSG1-fragment1] [CONTROL- frame] [MSG1-fragment23]

=3D=3D

"allowed" =3D according to rules as defined by the base WS spec w= ith no active extension

I don't bel= ieve the spec has anything to say about this currently, so I believe all of= them would be allowed. =C2=A0Personally, I would think #1 should definitel= y be allowed, and that it might be useful for an intermediary that collecte= d small frames to do #3 or #4. =C2=A0It seems you wouldn't want to dela= y a control frame while waiting for more frames in a message, so I would pr= efer to outlaw #2, but I don't feel strongly about it.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd4b2d6b3a20004aaa08b53-- From tobias.oberstein@tavendo.de Tue Aug 16 08:19: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 3359421F886A for ; Tue, 16 Aug 2011 08:19:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asj4hjc26k0C for ; Tue, 16 Aug 2011 08:19:56 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 36EAA21F8834 for ; Tue, 16 Aug 2011 08:19:55 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Tue, 16 Aug 2011 08:20:44 -0700 From: Tobias Oberstein To: John Tamplin Date: Tue, 16 Aug 2011 08:20:01 -0700 Thread-Topic: [hybi] Intermedaries: coalescing with interleaved control messages Thread-Index: AcxcJFFoVl6W1IUMQ+OrwzMCP8G/+AAAQUBw Message-ID: <634914A010D0B943A035D226786325D422C0B9A1AA@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D422C0B9A1AAEXVMBX02012ex_" MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:19:57 -0000 --_000_634914A010D0B943A035D226786325D422C0B9A1AAEXVMBX02012ex_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgY29uY2VybiBpcyB3cnQgdG8gdGhlIG9yZGVyaW5nIGd1YXJhbnRlZXMgKGlmIGFueSkgYmV0 d2VlbiBtZXNzYWdlcyBhbmQgY29udHJvbCBmcmFtZXMuDQoNCkMyIGNoYW5nZXMgdGhlIG9yZGVy IGluIHdoaWNoICJPbkNvbnRyb2wiIGFuZCAiT25NZXNzYWdlIiBoYW5kbGVycyB3b3VsZCBmaXJl IG9uIHRoZSByZWNlaXZpbmcgZW5kcG9pbnQuDQoNCm9yaWdpbmFsOg0KW01TRzEtZnJhZ21lbnQx XSBbQ09OVFJPTC1mcmFtZTFdIFtNU0cxLWZyYWdtZW50Ml0gW01TRzItZnJhZ21lbnQxXSBbQ09O VFJPTC1mcmFtZTJdIFtNU0cyLWZyYWdtZW50Ml0NCg0KYnkgQzIgPT4NCltNU0cxLWZyYWdtZW50 MV0gW01TRzEtZnJhZ21lbnQyXSBbQ09OVFJPTC1mcmFtZTFdIFtNU0cyLWZyYWdtZW50MV0gW01T RzItZnJhZ21lbnQyXSBbQ09OVFJPTC1mcmFtZTJdDQoNCmJ5IGNvYWxlc2NpbmcgPT4NCltNU0cx LWZyYWdtZW50MTJdIFtDT05UUk9MLWZyYW1lMV0gW01TRzItZnJhZ21lbnQxMl0gW0NPTlRST0wt ZnJhbWUyXQ0KDQo/PyA9Pg0KW01TRzEtZnJhZ21lbnQxMl0gW01TRzItZnJhZ21lbnQxMl0gW0NP TlRST0wtZnJhbWUxXSBbQ09OVFJPTC1mcmFtZTJdDQoNCj09DQoNCklmIHRoZSBzcGVjIGRvZXMg bm90IHJlcXVpcmUgYW55dGhpbmcgaW4gdGhpcyBhcmVhLCB0aGVuIHdlIGhhdmUgYWN0dWFsbHkg MiBjaGFubmVscyAoY29udHJvbC9kYXRhKSB3aXRoIHN0cmljdCBvcmRlcmluZw0Kd2l0aGluLCBi dXQgbm8gb3JkZXJpbmcgcmVsYXRpb25zaGlwIGJldHdlZW4/DQoNCg0KDQpWb246IEpvaG4gVGFt cGxpbiBbbWFpbHRvOmphdEBnb29nbGUuY29tXQ0KR2VzZW5kZXQ6IERpZW5zdGFnLCAxNi4gQXVn dXN0IDIwMTEgMTY6NTMNCkFuOiBUb2JpYXMgT2JlcnN0ZWluDQpDYzogQm9iIEdlemVsdGVyOyBo eWJpQGlldGYub3JnDQpCZXRyZWZmOiBSZTogW2h5YmldIEludGVybWVkYXJpZXM6IGNvYWxlc2Np bmcgd2l0aCBpbnRlcmxlYXZlZCBjb250cm9sIG1lc3NhZ2VzDQoNCk9uIFR1ZSwgQXVnIDE2LCAy MDExIGF0IDEwOjQ3IEFNLCBUb2JpYXMgT2JlcnN0ZWluIFdoZW4gYW4gaW50ZXJtZWRpYXJ5IHJl Y2VpdmVzDQoNCltNU0cxLWZyYWdtZW50MV0gW01TRzEtZnJhZ21lbnQyXSBbQ09OVFJPTC1mcmFt ZV0gW01TRzEtZnJhZ21lbnQzXQ0KDQp3aGljaCBvZiB0aGUgZm9sbG93aW5nIGlzIGl0IGFsbG93 ZWQgdG8gY29hbGVzY2UgaW50byB3aGVuIGZvcndhcmRpbmc6DQoNCkMxLg0KW01TRzEtZnJhZ21l bnQxMl0gW0NPTlRST0wtIGZyYW1lXSBbTVNHMS1mcmFnbWVudDNdDQoNCkMyLg0KW01TRzEtZnJh Z21lbnQxMjNdIFtDT05UUk9MLSBmcmFtZV0NCg0KQzMuDQpbQ09OVFJPTC1tZXNzYWdlXSBbTVNH MS1mcmFnbWVudDEyM10NCg0KQzQuDQpbTVNHMS1mcmFnbWVudDFdIFtDT05UUk9MLSBmcmFtZV0g W01TRzEtZnJhZ21lbnQyM10NCg0KPT0NCg0KImFsbG93ZWQiID0gYWNjb3JkaW5nIHRvIHJ1bGVz IGFzIGRlZmluZWQgYnkgdGhlIGJhc2UgV1Mgc3BlYyB3aXRoIG5vIGFjdGl2ZSBleHRlbnNpb24N Cg0KSSBkb24ndCBiZWxpZXZlIHRoZSBzcGVjIGhhcyBhbnl0aGluZyB0byBzYXkgYWJvdXQgdGhp cyBjdXJyZW50bHksIHNvIEkgYmVsaWV2ZSBhbGwgb2YgdGhlbSB3b3VsZCBiZSBhbGxvd2VkLiAg UGVyc29uYWxseSwgSSB3b3VsZCB0aGluayAjMSBzaG91bGQgZGVmaW5pdGVseSBiZSBhbGxvd2Vk LCBhbmQgdGhhdCBpdCBtaWdodCBiZSB1c2VmdWwgZm9yIGFuIGludGVybWVkaWFyeSB0aGF0IGNv bGxlY3RlZCBzbWFsbCBmcmFtZXMgdG8gZG8gIzMgb3IgIzQuICBJdCBzZWVtcyB5b3Ugd291bGRu J3Qgd2FudCB0byBkZWxheSBhIGNvbnRyb2wgZnJhbWUgd2hpbGUgd2FpdGluZyBmb3IgbW9yZSBm cmFtZXMgaW4gYSBtZXNzYWdlLCBzbyBJIHdvdWxkIHByZWZlciB0byBvdXRsYXcgIzIsIGJ1dCBJ IGRvbid0IGZlZWwgc3Ryb25nbHkgYWJvdXQgaXQuDQoNCi0tDQpKb2huIEEuIFRhbXBsaW4NClNv ZnR3YXJlIEVuZ2luZWVyIChHV1QpLCBHb29nbGUNCg== --_000_634914A010D0B943A035D226786325D422C0B9A1AAEXVMBX02012ex_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFu Zz1ERSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPk15IGNvbmNlcm4gaXMgd3J0IHRv IHRoZSBvcmRlcmluZyBndWFyYW50ZWVzIChpZiBhbnkpIGJldHdlZW4gbWVzc2FnZXMgYW5kIGNv bnRyb2wgZnJhbWVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+QzIgY2hhbmdlcyB0aGUgb3JkZXIgaW4g d2hpY2ggJnF1b3Q7T25Db250cm9sJnF1b3Q7IGFuZCAmcXVvdDtPbk1lc3NhZ2UmcXVvdDsgaGFu ZGxlcnMgd291bGQgZmlyZSBvbiB0aGUgcmVjZWl2aW5nIGVuZHBvaW50LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+b3JpZ2luYWw6PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltNU0cxLWZyYWdtZW50MV0gW0NPTlRST0wtZnJhbWUxXSBb TVNHMS1mcmFnbWVudDJdIFtNU0cyLWZyYWdtZW50MV0gW0NPTlRST0wtZnJhbWUyXSBbTVNHMi1m cmFnbWVudDJdIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+YnkgQzIgPSZndDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+W01TRzEtZnJh Z21lbnQxXSBbTVNHMS1mcmFnbWVudDJdIFtDT05UUk9MLWZyYW1lMV0gW01TRzItZnJhZ21lbnQx XSBbTVNHMi1mcmFnbWVudDJdIFtDT05UUk9MLWZyYW1lMl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPmJ5 IGNvYWxlc2NpbmcgPSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+W01TRzEtZnJhZ21lbnQxMl0gW0NPTlRST0wtZnJhbWUx XSBbTVNHMi1mcmFnbWVudDEyXSBbQ09OVFJPTC1mcmFtZTJdPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz4/ PyA9Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5bTVNHMS1mcmFnbWVudDEyXSBbTVNHMi1mcmFnbWVudDEyXSBbQ09OVFJP TC1mcmFtZTFdIFtDT05UUk9MLWZyYW1lMl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPj09PG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xv cjojMUY0OTdEJz5JZiB0aGUgc3BlYyBkb2VzIG5vdCByZXF1aXJlIGFueXRoaW5nIGluIHRoaXMg YXJlYSwgdGhlbiB3ZSBoYXZlIGFjdHVhbGx5IDIgY2hhbm5lbHMgKGNvbnRyb2wvZGF0YSkgd2l0 aCBzdHJpY3Qgb3JkZXJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+d2l0aGluLCBidXQgbm8gb3JkZXJpbmcgcmVsYXRpb25z aGlwIGJldHdlZW4/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSc+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+Vm9uOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiJz4gSm9obiBUYW1wbGluIFttYWlsdG86amF0QGdvb2dsZS5jb21dIDxicj48Yj5HZXNl bmRldDo8L2I+IERpZW5zdGFnLCAxNi4gQXVndXN0IDIwMTEgMTY6NTM8YnI+PGI+QW46PC9iPiBU b2JpYXMgT2JlcnN0ZWluPGJyPjxiPkNjOjwvYj4gQm9iIEdlemVsdGVyOyBoeWJpQGlldGYub3Jn PGJyPjxiPkJldHJlZmY6PC9iPiBSZTogW2h5YmldIEludGVybWVkYXJpZXM6IGNvYWxlc2Npbmcg d2l0aCBpbnRlcmxlYXZlZCBjb250cm9sIG1lc3NhZ2VzPG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48ZGl2Pjxw IGNsYXNzPU1zb05vcm1hbD5PbiBUdWUsIEF1ZyAxNiwgMjAxMSBhdCAxMDo0NyBBTSwgVG9iaWFz IE9iZXJzdGVpbiZuYnNwO1doZW4gYW4gaW50ZXJtZWRpYXJ5IHJlY2VpdmVzPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5bTVNHMS1mcmFnbWVudDFdIFtNU0cxLWZyYWdtZW50 Ml0gW0NPTlRST0wtZnJhbWVdIFtNU0cxLWZyYWdtZW50M108YnI+PGJyPndoaWNoIG9mIHRoZSBm b2xsb3dpbmcgaXMgaXQgYWxsb3dlZCB0byBjb2FsZXNjZSBpbnRvIHdoZW4gZm9yd2FyZGluZzo8 YnI+PGJyPkMxLjxicj5bTVNHMS1mcmFnbWVudDEyXSBbQ09OVFJPTC0gZnJhbWVdIFtNU0cxLWZy YWdtZW50M108YnI+PGJyPkMyLjxicj5bTVNHMS1mcmFnbWVudDEyM10gW0NPTlRST0wtIGZyYW1l XTxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxicj5DMy48YnI+W0NPTlRS T0wtbWVzc2FnZV0gW01TRzEtZnJhZ21lbnQxMjNdPGJyPjxicj5DNC48bzpwPjwvbzpwPjwvcD48 L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+W01TRzEtZnJhZ21lbnQxXSBbQ09OVFJPTC0gZnJhbWVd IFtNU0cxLWZyYWdtZW50MjNdPGJyPjxicj49PTxicj48YnI+JnF1b3Q7YWxsb3dlZCZxdW90OyA9 IGFjY29yZGluZyB0byBydWxlcyBhcyBkZWZpbmVkIGJ5IHRoZSBiYXNlIFdTIHNwZWMgd2l0aCBu byBhY3RpdmUgZXh0ZW5zaW9uPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+ PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+SSBkb24n dCBiZWxpZXZlIHRoZSBzcGVjIGhhcyBhbnl0aGluZyB0byBzYXkgYWJvdXQgdGhpcyBjdXJyZW50 bHksIHNvIEkgYmVsaWV2ZSBhbGwgb2YgdGhlbSB3b3VsZCBiZSBhbGxvd2VkLiAmbmJzcDtQZXJz b25hbGx5LCBJIHdvdWxkIHRoaW5rICMxIHNob3VsZCBkZWZpbml0ZWx5IGJlIGFsbG93ZWQsIGFu ZCB0aGF0IGl0IG1pZ2h0IGJlIHVzZWZ1bCBmb3IgYW4gaW50ZXJtZWRpYXJ5IHRoYXQgY29sbGVj dGVkIHNtYWxsIGZyYW1lcyB0byBkbyAjMyBvciAjNC4gJm5ic3A7SXQgc2VlbXMgeW91IHdvdWxk bid0IHdhbnQgdG8gZGVsYXkgYSBjb250cm9sIGZyYW1lIHdoaWxlIHdhaXRpbmcgZm9yIG1vcmUg ZnJhbWVzIGluIGEgbWVzc2FnZSwgc28gSSB3b3VsZCBwcmVmZXIgdG8gb3V0bGF3ICMyLCBidXQg SSBkb24ndCBmZWVsIHN0cm9uZ2x5IGFib3V0IGl0LiZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD4tLSA8YnI+Sm9obiBBLiBUYW1wbGluPGJyPlNvZnR3YXJlIEVu Z2luZWVyIChHV1QpLCBHb29nbGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9o dG1sPg== --_000_634914A010D0B943A035D226786325D422C0B9A1AAEXVMBX02012ex_-- From andy@warmcat.com Tue Aug 16 08:25: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 44A0C11E80A3 for ; Tue, 16 Aug 2011 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_05=-1.11, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMeJzoQ-HlZ0 for ; Tue, 16 Aug 2011 08:25:42 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id F272D11E808E for ; Tue, 16 Aug 2011 08:25:41 -0700 (PDT) Message-ID: <4E4A8C25.70305@warmcat.com> Date: Tue, 16 Aug 2011 16:26:29 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110816071515.ef1fc80126c74c6c202a919c41c7bb0b.e103bd8485.wbe@email03.secureserver.net> In-Reply-To: <20110816071515.ef1fc80126c74c6c202a919c41c7bb0b.e103bd8485.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org, gregw@intalio.com Subject: Re: [hybi] Sender-Receiver Latency 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, 16 Aug 2011 15:25:43 -0000 On 08/16/2011 03:15 PM, Somebody in the thread at some point said: > Concerning a message from Andy Green to Bruce > Atherton on Tue, 16 Aug 2011 06:43:50 +0100 > entitled "Re: [hybi] CONSENSUS CALL / Frame too big not possible to > occur" > > Breaking the latency discussion into sender vs. receiver latency is not, > IMHO, particularly constructive. There are multiple sets of queued > interfaces between when a sender application hands a message to the API > and when the response is received by the sender. > > It is this round-trip delay that is measured by the applicable timeout. > A huge frame (e.g., many seconds of channel time) causes a timeout, You are right. However, in the mail you're referring to, I am answering the proposal that an error code about frames being too big is needed to solve latency problems, with the observation that what's needed is timeouts and not the error. So it seems we are in agreement about it. > regardless of whether it interferes with the transmission of the > original request, or whether it delays the reverse direction response. > The next effect is the same: a failed request. This is the phenomenon > referred to in military communications circles as "a message not > received is was as if never sent" (For the literary minded, the quote is > from Edward Beach's "Dust on the Sea" (1972); similar references occur > in other places, both fiction and non-fiction). Curiously that sounds a dangerous approach for the military... the message may have been anyway intercepted and acted on by others. It's not quite the same as never having sent it. -Andy From gezelter@rlgsc.com Tue Aug 16 08:31: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 B6A2321F8906 for ; Tue, 16 Aug 2011 08:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.043 X-Spam-Level: X-Spam-Status: No, score=-1.043 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz4rtUBWQQ6g for ; Tue, 16 Aug 2011 08:31:44 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id 05D6D21F8C0D for ; Tue, 16 Aug 2011 08:31:43 -0700 (PDT) Received: (qmail 29076 invoked from network); 16 Aug 2011 15:32:32 -0000 Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 15:32:32 -0000 Received: (qmail 29597 invoked by uid 99); 16 Aug 2011 15:32:32 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816083231.ef1fc80126c74c6c202a919c41c7bb0b.50c0ccc1ed.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Tobias Oberstein" Date: Tue, 16 Aug 2011 08:32:31 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:31:44 -0000 Tobias,=0A=0AWithout having the time for a re-read at this instant, I will = presume=0Athat John's comments about no explicit binding (insofar as the pr= otocol=0Aspecification is concerned) between the data and control channels = in a=0Aconnection.=0A=0AAs a general matter, I would be reluctant to rely u= pon seeming=0Aconnections between the control and the data channels. The co= nnections=0Abetween control and data can conceivably be disconnected in any= number=0Aof ways (see my recent comment about "gateways"; I would not advo= cate=0Aattempting to clone and correspondingly coalesce control frames and= =0Atheir responses at gateways). =0A=0AEven within a single destination end= point, I do not see any reason for=0Apresuming a relationship between OnMes= sage and OnControl.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A=0A> ------= -- Original Message --------=0A> Subject: AW: [hybi] Intermedaries: coalesc= ing with interleaved control=0A> messages=0A> From: Tobias Oberstein =0A> Date: Tue, August 16, 2011 8:20 am=0A> To: John= Tamplin =0A> Cc: Bob Gezelter , "hybi@= ietf.org" =0A> =0A> =0A> My concern is wrt to the ordering g= uarantees (if any) between messages and control frames.=0A> =0A> =0A> =0A> = C2 changes the order in which "OnControl" and "OnMessage" handlers would fi= re on the receiving endpoint.=0A> =0A> =0A> =0A> original:=0A> =0A> [MSG1-f= ragment1] [CONTROL-frame1] [MSG1-fragment2] [MSG2-fragment1] [CONTROL-frame= 2] [MSG2-fragment2]=0A> =0A> =0A> =0A> by C2 =3D>=0A> =0A> [MSG1-fragment1]= [MSG1-fragment2] [CONTROL-frame1] [MSG2-fragment1] [MSG2-fragment2] [CONTR= OL-frame2]=0A> =0A> =0A> =0A> by coalescing =3D>=0A> =0A> [MSG1-fragment12]= [CONTROL-frame1] [MSG2-fragment12] [CONTROL-frame2]=0A> =0A> =0A> =0A> ?? = =3D>=0A> =0A> [MSG1-fragment12] [MSG2-fragment12] [CONTROL-frame1] [CONTROL= -frame2]=0A> =0A> =0A> =0A> =3D=3D=0A> =0A> =0A> =0A> If the spec does not = require anything in this area, then we have actually 2 channels (control/da= ta) with strict ordering=0A> =0A> within, but no ordering relationship betw= een?=0A> =0A> =0A> =0A> =0A> =0A> =0A> =0A> Von: John Tamplin [mailto:jat@g= oogle.com]=0A> =0A> Gesendet: Dienstag, 16. August 2011 16:53=0A> =0A> An: = Tobias Oberstein=0A> =0A> Cc: Bob Gezelter; hybi@ietf.org=0A> =0A> Betreff:= Re: [hybi] Intermedaries: coalescing with interleaved control messages=0A>= =0A> =0A> =0A> On Tue, Aug 16, 2011 at 10:47 AM, Tobias Oberstein When an = intermediary receives=0A> =0A> =0A> =0A> [MSG1-fragment1] [MSG1-fragment2] = [CONTROL-frame] [MSG1-fragment3]=0A> =0A> =0A> =0A> which of the following = is it allowed to coalesce into when forwarding:=0A> =0A> =0A> =0A> C1.=0A> = =0A> [MSG1-fragment12] [CONTROL- frame] [MSG1-fragment3]=0A> =0A> =0A> =0A>= C2.=0A> =0A> [MSG1-fragment123] [CONTROL- frame]=0A> =0A> =0A> =0A> C3.=0A= > =0A> [CONTROL-message] [MSG1-fragment123]=0A> =0A> =0A> =0A> C4.=0A> =0A>= [MSG1-fragment1] [CONTROL- frame] [MSG1-fragment23]=0A> =0A> =0A> =0A> =3D= =3D=0A> =0A> =0A> =0A> "allowed" =3D according to rules as defined by the b= ase WS spec with no active extension=0A> =0A> =0A> =0A> I don't believe the= spec has anything to say about this currently, so I believe all of them wo= uld be allowed. Personally, I would think #1 should definitely be allowed,= and that it might be useful for an intermediary that collected small frame= s to do #3 or #4. It seems you wouldn't want to delay a control frame whil= e waiting for more frames in a message, so I would prefer to outlaw #2, but= I don't feel strongly about it.=0A> =0A> =0A> =0A> --=0A> =0A> John A. Tam= plin=0A> =0A> Software Engineer (GWT), Google=0A From ibc@aliax.net Tue Aug 16 08:32: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 4F7EC21F8B7C for ; Tue, 16 Aug 2011 08:32: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eElftOsQJ5ol for ; Tue, 16 Aug 2011 08:32:12 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 572E821F8B05 for ; Tue, 16 Aug 2011 08:32:12 -0700 (PDT) Received: by gwb20 with SMTP id 20so17444gwb.31 for ; Tue, 16 Aug 2011 08:33:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.136.137 with SMTP id w9mr16289609yhi.112.1313508780544; Tue, 16 Aug 2011 08:33:00 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Tue, 16 Aug 2011 08:33:00 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 16 Aug 2011 17:33:00 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:32:13 -0000 2011/8/16 Tobias Oberstein : > When an intermediary receives > > [MSG1-fragment1] [MSG1-fragment2] [CONTROL-frame] [MSG1-fragment3] > > which of the following is it allowed to coalesce into when forwarding: > > C1. > [MSG1-fragment12] [CONTROL- frame] [MSG1-fragment3] > > C2. > [MSG1-fragment123] [CONTROL- frame] > > C3. > [CONTROL-message] [MSG1-fragment123] > > C4. > [MSG1-fragment1] [CONTROL- frame] [MSG1-fragment23] > > =3D=3D > > "allowed" =3D according to rules as defined by the base WS spec with no a= ctive extension If WS frames contain an "id" field (a random token value), and each frame belonging to same WS message has the same "id" value, then problem solved. --=20 I=C3=B1aki Baz Castillo From jat@google.com Tue Aug 16 08:36: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 E55F621F8C0D for ; Tue, 16 Aug 2011 08:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.765 X-Spam-Level: X-Spam-Status: No, score=-105.765 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlAmMZCdAi6f for ; Tue, 16 Aug 2011 08:36:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 19D2721F8BBA for ; Tue, 16 Aug 2011 08:36:33 -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 p7GFbIcZ008975 for ; Tue, 16 Aug 2011 08:37:18 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313509040; bh=qxGVzkCA/QJM8ziEhWYfUJt9bmc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=lmvRKXVeHqWIJaXITPA+/2A11vn7MP6iZd9PbhXbgnXBsiKjccpSon0X7811wIrvG 8k7qWI5QoM0yw/VLaTX/A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=CwQaeQba7tTxtkI+/SCbvBXvYVlFYlY4Dx6ROTD29jQ3NN8YT4vuOvHqTR0UzeDtJ 4GqL6fH+y6LV8OXBMpkuQ== Received: from gwj22 (gwj22.prod.google.com [10.200.10.22]) by wpaz33.hot.corp.google.com with ESMTP id p7GFbHTn025297 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 08:37:17 -0700 Received: by gwj22 with SMTP id 22so27136gwj.35 for ; Tue, 16 Aug 2011 08:37:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=p2pjWBRJWraBUJ6NpG+H5j+KU6BYXkQnwSPtDMB/Xsg=; b=PwhKOQaJbxEAtYLrBQ+eOkChSYrU40smbgvsCjntqd6pl3S28lcq1wqkgWsvOo4Ce8 MxIIS6AaR4KIY3mz7/cQ== Received: by 10.150.253.9 with SMTP id a9mr6189933ybi.230.1313509037457; Tue, 16 Aug 2011 08:37:17 -0700 (PDT) Received: by 10.150.253.9 with SMTP id a9mr6189919ybi.230.1313509037156; Tue, 16 Aug 2011 08:37:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 16 Aug 2011 08:36:57 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Tue, 16 Aug 2011 11:36:57 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001517475c9291ab5d04aaa127c3 X-System-Of-Record: true Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:36:35 -0000 --001517475c9291ab5d04aaa127c3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2011 at 11:33 AM, I=C3=B1aki Baz Castillo w= rote: > If WS frames contain an "id" field (a random token value), and each > frame belonging to same WS message has the same "id" value, then > problem solved. > No, that solves nothing about the order guarantees between control and data frames. I'm not sure exactly what it does solve, other than being able to say a particular frame was too large or providing an acknowledgement to eac= h frame (which would be completely undesired in many applications). It doesn't provide any basis for solving MUX, as you still need a channel id. --=20 John A. Tamplin Software Engineer (GWT), Google --001517475c9291ab5d04aaa127c3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 11:33 AM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
If WS frames contain an "id" field (a random token value), and ea= ch
frame belonging to same WS message has the same "id" value, then<= br> problem solved.

No, that solves nothing about the = order guarantees between control and data frames. =C2=A0I'm not sure ex= actly what it does solve, other than being able to say a particular frame w= as too large or providing an acknowledgement to each frame (which would be = completely undesired in many applications). =C2=A0It doesn't provide an= y basis for solving MUX, as you still need a channel id.

--
John A. Tamplin
Software Engineer (GWT), Google --001517475c9291ab5d04aaa127c3-- From gezelter@rlgsc.com Tue Aug 16 08:43: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 B0BEA21F89BA for ; Tue, 16 Aug 2011 08:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, RCVD_IN_NJABL_PROXY=1.643] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqk+M6lU7yzT for ; Tue, 16 Aug 2011 08:43:48 -0700 (PDT) Received: from smtpoutwbe08.prod.mesa1.secureserver.net (smtpoutwbe08.prod.mesa1.secureserver.net [208.109.78.210]) by ietfa.amsl.com (Postfix) with SMTP id 9BA9F21F8997 for ; Tue, 16 Aug 2011 08:43:44 -0700 (PDT) Received: (qmail 16175 invoked from network); 16 Aug 2011 15:44:31 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe08.prod.mesa1.secureserver.net with SMTP; 16 Aug 2011 15:44:31 -0000 Received: (qmail 10067 invoked by uid 99); 16 Aug 2011 15:44:31 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 68.161.195.197 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110816084430.ef1fc80126c74c6c202a919c41c7bb0b.9d85c82a79.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "hybi@ietf.org" Date: Tue, 16 Aug 2011 08:44:30 -0700 Mime-Version: 1.0 Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:43:48 -0000 Inaki and John,=0A=0AWith regards to message IDs, I concur with John. The m= essage ID is not=0Aneeded, except for a message-by-message acknowledgement,= which is an=0Aupper level applications-level protocol issue.=0A=0AIn the c= ase of a multiplexed connection, it does not affect the need for=0Aa sub-ch= annel identification number as part of each frame (as I have=0Astated frequ= ently, I believe that frame-by-frame multiplexing is the=0Abest of the alte= rnatives).=0A=0AI also note that I do not see an advantage to using random = message=0Anumbers. If forgery on a channel (or sub-channel) is a concern, t= he=0Acorrect solution is the use of digital signatures and appropriate=0Acr= yptographic methods.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A=0A> -----= --- Original Message --------=0A> Subject: Re: [hybi] Intermedaries: coales= cing with interleaved control=0A> messages=0A> From: John Tamplin =0A> Date: Tue, August 16, 2011 8:36 am=0A> To: I=C3=B1aki_Baz_Casti= llo =0A> Cc: Tobias Oberstein ,= =0A> "hybi@ietf.org" , Bob Gezelter =0A> =0A> =0A> On Tue, Aug 16, 2011 at 11:33 AM, I=C3=B1aki Baz Castillo= wrote:=0A> =0A> > If WS frames contain an "id" field (a ra= ndom token value), and each=0A> > frame belonging to same WS message has th= e same "id" value, then=0A> > problem solved.=0A> >=0A> =0A> No, that solve= s nothing about the order guarantees between control and data=0A> frames. = I'm not sure exactly what it does solve, other than being able to=0A> say a= particular frame was too large or providing an acknowledgement to each=0A>= frame (which would be completely undesired in many applications). It=0A> = doesn't provide any basis for solving MUX, as you still need a channel id.= =0A> =0A> -- =0A> John A. Tamplin=0A> Software Engineer (GWT), Google=0A From tobias.oberstein@tavendo.de Tue Aug 16 08:45:27 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 1227D11E8088 for ; Tue, 16 Aug 2011 08:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F3g1rytP8lea for ; Tue, 16 Aug 2011 08:45:26 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1E12421F8B48 for ; Tue, 16 Aug 2011 08:45:26 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 16 Aug 2011 08:46:14 -0700 From: Tobias Oberstein To: Bob Gezelter Date: Tue, 16 Aug 2011 08:45:30 -0700 Thread-Topic: AW: [hybi] Intermedaries: coalescing with interleaved control messages Thread-Index: AcxcKbo95If1nIjTSHCeUp75aLvnbgAALrjg Message-ID: <634914A010D0B943A035D226786325D422C0B9A1D7@EXVMBX020-12.exch020.serverdata.net> References: <20110816083231.ef1fc80126c74c6c202a919c41c7bb0b.50c0ccc1ed.wbe@email03.secureserver.net> In-Reply-To: <20110816083231.ef1fc80126c74c6c202a919c41c7bb0b.50c0ccc1ed.wbe@email03.secureserver.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:45:27 -0000 Qm9iLA0KDQppZiB0aGVyZSBhcmUgbm8gb3JkZXJpbmcgZ3VhcmFudGVlcyBiZXR3ZWVuIGNvbnRy b2wgZnJhbWVzIGFuZCBtZXNzYWdlcywNCnRoaXMgd291bGQgaGF2ZSBhIG51bWJlciBvZiBjb25z ZXF1ZW5jZXMuIE15IGZlZWxpbmcgaXMgaXQncyBiYWQuDQoNCkhlcmUgaXMgb25lIGV4YW1wbGUu IFRoZSBzcGVjOg0KDQo0LjUuMS4gIENsb3NlDQoNClRoZSBhcHBsaWNhdGlvbiBNVVNUIE5PVCBz ZW5kIGFueSBtb3JlIGRhdGEgZnJhbWVzIGFmdGVyIHNlbmRpbmcgYQ0KICAgY2xvc2UgZnJhbWUu DQoNClRoYXQgc2VlbXMgdG8gYmUgcG9pbnRsZXNzIHRoZW4sIHNpbmNlIGludGVybS4gbWlnaHQg cmVvcmRlciBDbG9zZSB3cnQNCnRvIGRhdGEuDQoNCjJuZCBleGFtcGxlOiBzb21lIGV4dGVuc2lv biB1c2VzIGNvbnRyb2wgZnJhbWVzIHRoYXQgcmVhbGx5IHJlbGF0ZXMgdG8NCmRhdGEgLi4gaS5l LiBhIE1VWCBleHQuIGRvaW5nIGNyZWRpdCByZXBsLg0KDQpTbyB3aXRob3V0IGFueSBvcmRlcmlu ZyBndWFyLiB0aGUgdXNlIG9mIHJlc2VydmVkIGNvbnRyb2wgb3Bjb2Rlcw0KY291bGQgYmUgbGlt aXRlZC4gDQoNCkluIGdlbmVyYWw6IGluIGEgbXVsdGktY2hhbm5lbCBtZXNzYWdpbmcgc3lzdGVt LCB3aGF0IGFyZSBjb25jZWl2YWJsZS9zYW5lDQpvcmRlcmluZyBndWFyYW50ZWVzIHRoYXQgY2Fu IGJlIG1hZGU/IE9yIGlzIGl0IGJhZCB0byBkbyBzbz8gVGhhdCBpcw0Kc3RyaWN0IG9yZGVyaW5n IGlzIGd1YXIuIHdpdGhpbiBlYWNoIGNoYW5uZWwsIGJ1dCBubyBndWFyLiB3aGF0c29ldmVyIGlz IG1hZGUNCmZvciBvcmRlcmluZyByZWxhdGlvbnNoaXAgYmV0d2VlbiBjaGFubmVscy4NCg0KDQo+ IC0tLS0tVXJzcHLDvG5nbGljaGUgTmFjaHJpY2h0LS0tLS0NCj4gVm9uOiBCb2IgR2V6ZWx0ZXIg W21haWx0bzpnZXplbHRlckBybGdzYy5jb21dDQo+IEdlc2VuZGV0OiBEaWVuc3RhZywgMTYuIEF1 Z3VzdCAyMDExIDE3OjMzDQo+IEFuOiBUb2JpYXMgT2JlcnN0ZWluDQo+IENjOiBoeWJpQGlldGYu b3JnOyBKb2huIFRhbXBsaW4NCj4gQmV0cmVmZjogUkU6IEFXOiBbaHliaV0gSW50ZXJtZWRhcmll czogY29hbGVzY2luZyB3aXRoIGludGVybGVhdmVkIGNvbnRyb2wNCj4gbWVzc2FnZXMNCj4gDQo+ IFRvYmlhcywNCj4gDQo+IFdpdGhvdXQgaGF2aW5nIHRoZSB0aW1lIGZvciBhIHJlLXJlYWQgYXQg dGhpcyBpbnN0YW50LCBJIHdpbGwgcHJlc3VtZSB0aGF0DQo+IEpvaG4ncyBjb21tZW50cyBhYm91 dCBubyBleHBsaWNpdCBiaW5kaW5nIChpbnNvZmFyIGFzIHRoZSBwcm90b2NvbA0KPiBzcGVjaWZp Y2F0aW9uIGlzIGNvbmNlcm5lZCkgYmV0d2VlbiB0aGUgZGF0YSBhbmQgY29udHJvbCBjaGFubmVs cyBpbiBhDQo+IGNvbm5lY3Rpb24uDQo+IA0KPiBBcyBhIGdlbmVyYWwgbWF0dGVyLCBJIHdvdWxk IGJlIHJlbHVjdGFudCB0byByZWx5IHVwb24gc2VlbWluZyBjb25uZWN0aW9ucw0KPiBiZXR3ZWVu IHRoZSBjb250cm9sIGFuZCB0aGUgZGF0YSBjaGFubmVscy4gVGhlIGNvbm5lY3Rpb25zIGJldHdl ZW4NCj4gY29udHJvbCBhbmQgZGF0YSBjYW4gY29uY2VpdmFibHkgYmUgZGlzY29ubmVjdGVkIGlu IGFueSBudW1iZXIgb2Ygd2F5cw0KPiAoc2VlIG15IHJlY2VudCBjb21tZW50IGFib3V0ICJnYXRl d2F5cyI7IEkgd291bGQgbm90IGFkdm9jYXRlDQo+IGF0dGVtcHRpbmcgdG8gY2xvbmUgYW5kIGNv cnJlc3BvbmRpbmdseSBjb2FsZXNjZSBjb250cm9sIGZyYW1lcyBhbmQgdGhlaXINCj4gcmVzcG9u c2VzIGF0IGdhdGV3YXlzKS4NCj4gDQo+IEV2ZW4gd2l0aGluIGEgc2luZ2xlIGRlc3RpbmF0aW9u IGVuZHBvaW50LCBJIGRvIG5vdCBzZWUgYW55IHJlYXNvbiBmb3INCj4gcHJlc3VtaW5nIGEgcmVs YXRpb25zaGlwIGJldHdlZW4gT25NZXNzYWdlIGFuZCBPbkNvbnRyb2wuDQo+IA0KPiAtIEJvYiBH ZXplbHRlciwgaHR0cDovL3d3dy5ybGdzYy5jb20NCj4gDQo+ID4gLS0tLS0tLS0gT3JpZ2luYWwg TWVzc2FnZSAtLS0tLS0tLQ0KPiA+IFN1YmplY3Q6IEFXOiBbaHliaV0gSW50ZXJtZWRhcmllczog Y29hbGVzY2luZyB3aXRoIGludGVybGVhdmVkIGNvbnRyb2wNCj4gPiBtZXNzYWdlcw0KPiA+IEZy b206IFRvYmlhcyBPYmVyc3RlaW4gPHRvYmlhcy5vYmVyc3RlaW5AdGF2ZW5kby5kZT4NCj4gPiBE YXRlOiBUdWUsIEF1Z3VzdCAxNiwgMjAxMSA4OjIwIGFtDQo+ID4gVG86IEpvaG4gVGFtcGxpbiA8 amF0QGdvb2dsZS5jb20+DQo+ID4gQ2M6IEJvYiBHZXplbHRlciA8Z2V6ZWx0ZXJAcmxnc2MuY29t PiwgImh5YmlAaWV0Zi5vcmciIDxoeWJpQGlldGYub3JnPg0KPiA+DQo+ID4NCj4gPiBNeSBjb25j ZXJuIGlzIHdydCB0byB0aGUgb3JkZXJpbmcgZ3VhcmFudGVlcyAoaWYgYW55KSBiZXR3ZWVuIG1l c3NhZ2VzDQo+IGFuZCBjb250cm9sIGZyYW1lcy4NCj4gPg0KPiA+DQo+ID4NCj4gPiBDMiBjaGFu Z2VzIHRoZSBvcmRlciBpbiB3aGljaCAiT25Db250cm9sIiBhbmQgIk9uTWVzc2FnZSIgaGFuZGxl cnMNCj4gd291bGQgZmlyZSBvbiB0aGUgcmVjZWl2aW5nIGVuZHBvaW50Lg0KPiA+DQo+ID4NCj4g Pg0KPiA+IG9yaWdpbmFsOg0KPiA+DQo+ID4gW01TRzEtZnJhZ21lbnQxXSBbQ09OVFJPTC1mcmFt ZTFdIFtNU0cxLWZyYWdtZW50Ml0gW01TRzItDQo+IGZyYWdtZW50MV0NCj4gPiBbQ09OVFJPTC1m cmFtZTJdIFtNU0cyLWZyYWdtZW50Ml0NCj4gPg0KPiA+DQo+ID4NCj4gPiBieSBDMiA9Pg0KPiA+ DQo+ID4gW01TRzEtZnJhZ21lbnQxXSBbTVNHMS1mcmFnbWVudDJdIFtDT05UUk9MLWZyYW1lMV0g W01TRzItDQo+IGZyYWdtZW50MV0NCj4gPiBbTVNHMi1mcmFnbWVudDJdIFtDT05UUk9MLWZyYW1l Ml0NCj4gPg0KPiA+DQo+ID4NCj4gPiBieSBjb2FsZXNjaW5nID0+DQo+ID4NCj4gPiBbTVNHMS1m cmFnbWVudDEyXSBbQ09OVFJPTC1mcmFtZTFdIFtNU0cyLWZyYWdtZW50MTJdIFtDT05UUk9MLQ0K PiBmcmFtZTJdDQo+ID4NCj4gPg0KPiA+DQo+ID4gPz8gPT4NCj4gPg0KPiA+IFtNU0cxLWZyYWdt ZW50MTJdIFtNU0cyLWZyYWdtZW50MTJdIFtDT05UUk9MLWZyYW1lMV0gW0NPTlRST0wtDQo+IGZy YW1lMl0NCj4gPg0KPiA+DQo+ID4NCj4gPiA9PQ0KPiA+DQo+ID4NCj4gPg0KPiA+IElmIHRoZSBz cGVjIGRvZXMgbm90IHJlcXVpcmUgYW55dGhpbmcgaW4gdGhpcyBhcmVhLCB0aGVuIHdlIGhhdmUN Cj4gPiBhY3R1YWxseSAyIGNoYW5uZWxzIChjb250cm9sL2RhdGEpIHdpdGggc3RyaWN0IG9yZGVy aW5nDQo+ID4NCj4gPiB3aXRoaW4sIGJ1dCBubyBvcmRlcmluZyByZWxhdGlvbnNoaXAgYmV0d2Vl bj8NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFZvbjogSm9obiBUYW1w bGluIFttYWlsdG86amF0QGdvb2dsZS5jb21dDQo+ID4NCj4gPiBHZXNlbmRldDogRGllbnN0YWcs IDE2LiBBdWd1c3QgMjAxMSAxNjo1Mw0KPiA+DQo+ID4gQW46IFRvYmlhcyBPYmVyc3RlaW4NCj4g Pg0KPiA+IENjOiBCb2IgR2V6ZWx0ZXI7IGh5YmlAaWV0Zi5vcmcNCj4gPg0KPiA+IEJldHJlZmY6 IFJlOiBbaHliaV0gSW50ZXJtZWRhcmllczogY29hbGVzY2luZyB3aXRoIGludGVybGVhdmVkIGNv bnRyb2wNCj4gPiBtZXNzYWdlcw0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIFR1ZSwgQXVnIDE2LCAy MDExIGF0IDEwOjQ3IEFNLCBUb2JpYXMgT2JlcnN0ZWluIFdoZW4gYW4NCj4gPiBpbnRlcm1lZGlh cnkgcmVjZWl2ZXMNCj4gPg0KPiA+DQo+ID4NCj4gPiBbTVNHMS1mcmFnbWVudDFdIFtNU0cxLWZy YWdtZW50Ml0gW0NPTlRST0wtZnJhbWVdIFtNU0cxLQ0KPiBmcmFnbWVudDNdDQo+ID4NCj4gPg0K PiA+DQo+ID4gd2hpY2ggb2YgdGhlIGZvbGxvd2luZyBpcyBpdCBhbGxvd2VkIHRvIGNvYWxlc2Nl IGludG8gd2hlbiBmb3J3YXJkaW5nOg0KPiA+DQo+ID4NCj4gPg0KPiA+IEMxLg0KPiA+DQo+ID4g W01TRzEtZnJhZ21lbnQxMl0gW0NPTlRST0wtIGZyYW1lXSBbTVNHMS1mcmFnbWVudDNdDQo+ID4N Cj4gPg0KPiA+DQo+ID4gQzIuDQo+ID4NCj4gPiBbTVNHMS1mcmFnbWVudDEyM10gW0NPTlRST0wt IGZyYW1lXQ0KPiA+DQo+ID4NCj4gPg0KPiA+IEMzLg0KPiA+DQo+ID4gW0NPTlRST0wtbWVzc2Fn ZV0gW01TRzEtZnJhZ21lbnQxMjNdDQo+ID4NCj4gPg0KPiA+DQo+ID4gQzQuDQo+ID4NCj4gPiBb TVNHMS1mcmFnbWVudDFdIFtDT05UUk9MLSBmcmFtZV0gW01TRzEtZnJhZ21lbnQyM10NCj4gPg0K PiA+DQo+ID4NCj4gPiA9PQ0KPiA+DQo+ID4NCj4gPg0KPiA+ICJhbGxvd2VkIiA9IGFjY29yZGlu ZyB0byBydWxlcyBhcyBkZWZpbmVkIGJ5IHRoZSBiYXNlIFdTIHNwZWMgd2l0aCBubw0KPiA+IGFj dGl2ZSBleHRlbnNpb24NCj4gPg0KPiA+DQo+ID4NCj4gPiBJIGRvbid0IGJlbGlldmUgdGhlIHNw ZWMgaGFzIGFueXRoaW5nIHRvIHNheSBhYm91dCB0aGlzIGN1cnJlbnRseSwgc28gSSBiZWxpZXZl DQo+IGFsbCBvZiB0aGVtIHdvdWxkIGJlIGFsbG93ZWQuICBQZXJzb25hbGx5LCBJIHdvdWxkIHRo aW5rICMxIHNob3VsZCBkZWZpbml0ZWx5DQo+IGJlIGFsbG93ZWQsIGFuZCB0aGF0IGl0IG1pZ2h0 IGJlIHVzZWZ1bCBmb3IgYW4gaW50ZXJtZWRpYXJ5IHRoYXQgY29sbGVjdGVkDQo+IHNtYWxsIGZy YW1lcyB0byBkbyAjMyBvciAjNC4gIEl0IHNlZW1zIHlvdSB3b3VsZG4ndCB3YW50IHRvIGRlbGF5 IGEgY29udHJvbA0KPiBmcmFtZSB3aGlsZSB3YWl0aW5nIGZvciBtb3JlIGZyYW1lcyBpbiBhIG1l c3NhZ2UsIHNvIEkgd291bGQgcHJlZmVyIHRvDQo+IG91dGxhdyAjMiwgYnV0IEkgZG9uJ3QgZmVl bCBzdHJvbmdseSBhYm91dCBpdC4NCj4gPg0KPiA+DQo+ID4NCj4gPiAtLQ0KPiA+DQo+ID4gSm9o biBBLiBUYW1wbGluDQo+ID4NCj4gPiBTb2Z0d2FyZSBFbmdpbmVlciAoR1dUKSwgR29vZ2xlDQoN Cg== From ibc@aliax.net Tue Aug 16 08:47: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 316BD21F8B6C for ; Tue, 16 Aug 2011 08:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNg9siQAxaMr for ; Tue, 16 Aug 2011 08:47:22 -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 968C621F8B63 for ; Tue, 16 Aug 2011 08:47:22 -0700 (PDT) Received: by yie12 with SMTP id 12so28869yie.31 for ; Tue, 16 Aug 2011 08:48:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.2.1 with SMTP id 1mr5324872yab.7.1313509691060; Tue, 16 Aug 2011 08:48:11 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Tue, 16 Aug 2011 08:48:10 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 16 Aug 2011 17:48:10 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:47:23 -0000 2011/8/16 John Tamplin : > On Tue, Aug 16, 2011 at 11:33 AM, I=C3=B1aki Baz Castillo = wrote: >> >> If WS frames contain an "id" field (a random token value), and each >> frame belonging to same WS message has the same "id" value, then >> problem solved. > > No, that solves nothing about the order guarantees between control and da= ta > frames. And why should be such order a problem? >=C2=A0I'm not sure exactly what it does solve, other than being able to > say a particular frame was too large ...which would solve a so long recent mail thread. > or providing an acknowledgement to each > frame (which would be completely undesired in many applications). I'm not suggesting it now :) > It doesn't provide any basis for solving MUX, as you still need a channel= id. I must read what MUX is. But for sure, using a id in each frame would allow that a very *big* WS message can be sent within N frames allowing other frames in parallel belonging to other WS messages. Of course, is the application who decides whether it can send, or not, two message in parallel. --=20 I=C3=B1aki Baz Castillo From jat@google.com Tue Aug 16 08:54: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 1F1B621F8B03 for ; Tue, 16 Aug 2011 08:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.761 X-Spam-Level: X-Spam-Status: No, score=-105.761 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9UJl3Xu+hII for ; Tue, 16 Aug 2011 08:54: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 E224D21F8A97 for ; Tue, 16 Aug 2011 08:54:11 -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 p7GFsxd4004059 for ; Tue, 16 Aug 2011 08:55:00 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313510100; bh=fSkyoSWnWz/HLKpy5OfzM6G7jTo=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=CZmumc5AibWZTHxsgkKwlRYbdatHYOyOp8J/HQMgti5++ZA6M2crKl54mXwFAStCk Mv5A6FX3MQApHbXYztobQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=WKUI+ZqvrCoebDSYFR8l/IwKoREhC3pi2+oWnqBGYjLV7TWnKdm5MIk8Nw14eZ7oz U5tFFJF6wf9/PAArY7NMA== Received: from gyh3 (gyh3.prod.google.com [10.243.50.195]) by hpaq1.eem.corp.google.com with ESMTP id p7GFsvhr019853 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 16 Aug 2011 08:54:58 -0700 Received: by gyh3 with SMTP id 3so31348gyh.9 for ; Tue, 16 Aug 2011 08:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Pnsn+Hdi1g3UDb29xBFFq3wDPAsnjBFCuBfRlotNt5Y=; b=CO1JdhJaeXiRPMH7yn4VgquH+t4+0bZlS2s5p4wfFXxo+ab52Yr2N4YjmztX8co2ic 4MN3BM7FbMsjqhvGlO5A== Received: by 10.150.150.34 with SMTP id x34mr8067ybd.59.1313510097372; Tue, 16 Aug 2011 08:54:57 -0700 (PDT) Received: by 10.150.150.34 with SMTP id x34mr8058ybd.59.1313510097138; Tue, 16 Aug 2011 08:54:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 16 Aug 2011 08:54:37 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Tue, 16 Aug 2011 11:54:37 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd6d02ebfb2de04aaa16673 X-System-Of-Record: true Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 15:54:19 -0000 --000e0cd6d02ebfb2de04aaa16673 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 16, 2011 at 11:48 AM, I=C3=B1aki Baz Castillo w= rote: > And why should be such order a problem? That was the entire subject of this particular thread. Regardless of the outcome of the discussion, the spec ought to be clear about what order guarantees are provided. > > I'm not sure exactly what it does solve, other than being able to > > say a particular frame was too large > > ...which would solve a so long recent mail thread. No, the debate has been about whether there should be such a "frame too large" error or should implementations be required to accept any legal frame. Being able to identify which frame is in error would be nice, but does not address this debate and does not justify the cost of including a message ID in every frame for something which is expected to be at best an unusual condition. > > It doesn't provide any basis for solving MUX, as you still need a chann= el > id. > > I must read what MUX is. But for sure, using a id in each frame would > allow that a very *big* WS message can be sent within N frames > allowing other frames in parallel belonging to other WS messages. Of > course, is the application who decides whether it can send, or not, > two message in parallel. Imagine two totally disconnected WebSocket connections sharing transport. For example, multiple tabs in a browser all connecting to the same server. These applications in different tabs should not know anything about each other and their traffic should be delivered only to the appropriate application, yet you want to reduce the number of connections to the server= . MUX is a way to let the browser (or equally some intermediary, say a cell provider or a corporate gateway) combine these separate connections into a single one while preserving all the semantics of individual connections. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd6d02ebfb2de04aaa16673 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2011 at 11:48 AM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
And why should be such order a problem?

Tha= t was the entire subject of this particular thread. =C2=A0Regardless of the= outcome of the discussion, the spec ought to be clear about what order gua= rantees are provided.
=C2=A0
>=C2=A0I'm not sure exactly what it does solve, other than being abl= e to
> say a particular frame was too large

...which would solve a so long recent mail thread.
<= br>
No, the debate has been about whether there should be such a = "frame too large" error or should implementations be required to = accept any legal frame. =C2=A0Being able to identify which frame is in erro= r would be nice, but does not address this debate and does not justify the = cost of including a message ID in every frame for something which is expect= ed to be at best an unusual condition.
=C2=A0
> It doesn't provide any basis for solving MUX, as you still need a = channel id.

I must read what MUX is. But for sure, using a id in each frame would=
allow that a very *big* WS message can be sent within N frames
allowing other frames in parallel belonging to other WS messages. Of
course, is the application who decides whether it can send, or not,
two message in parallel.

Imagine two totall= y disconnected WebSocket connections sharing transport. =C2=A0For example, = multiple tabs in a browser all connecting to the same server. =C2=A0These a= pplications in different tabs should not know anything about each other and= their traffic should be delivered only to the appropriate application, yet= you want to reduce the number of connections to the server. =C2=A0MUX is a= way to let the browser (or equally some intermediary, say a cell provider = or a corporate gateway) combine these separate connections into a single on= e while preserving all the semantics of individual connections.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd6d02ebfb2de04aaa16673-- From ibc@aliax.net Tue Aug 16 09:35: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 7367F11E80D9 for ; Tue, 16 Aug 2011 09:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zYCi+JqXomx for ; Tue, 16 Aug 2011 09:35:44 -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 EAFCD11E80C3 for ; Tue, 16 Aug 2011 09:35:43 -0700 (PDT) Received: by gyf3 with SMTP id 3so63250gyf.31 for ; Tue, 16 Aug 2011 09:36:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.174.35 with SMTP id w23mr17211518yhl.44.1313512592169; Tue, 16 Aug 2011 09:36:32 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Tue, 16 Aug 2011 09:36:32 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0B9A15F@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 16 Aug 2011 18:36:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Intermedaries: coalescing with interleaved control messages 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, 16 Aug 2011 16:35:44 -0000 2011/8/16 John Tamplin : >> I must read what MUX is. But for sure, using a id in each frame would >> allow that a very *big* WS message can be sent within N frames >> allowing other frames in parallel belonging to other WS messages. Of >> course, is the application who decides whether it can send, or not, >> two message in parallel. > > Imagine two totally disconnected WebSocket connections sharing transport. > =C2=A0For example, multiple tabs in a browser all connecting to the same = server. > =C2=A0These applications in different tabs should not know anything about= each > other and their traffic should be delivered only to the appropriate > application, yet you want to reduce the number of connections to the serv= er. > =C2=A0MUX is a way to let the browser (or equally some intermediary, say = a cell > provider or a corporate gateway) combine these separate connections into = a > single one while preserving all the semantics of individual connections. Thanks a lot for the explanation, got it. --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Tue Aug 16 10:07: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 E4EF921F8B6E for ; Tue, 16 Aug 2011 10:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.408 X-Spam-Level: X-Spam-Status: No, score=-2.408 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jYLhMksUdcfe for ; Tue, 16 Aug 2011 10:07:56 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 65BFA21F8B6C for ; Tue, 16 Aug 2011 10:07:56 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QtN88-0001tb-DN; Tue, 16 Aug 2011 10:08:44 -0700 Message-ID: <4E4AA422.10601@callenish.com> Date: Tue, 16 Aug 2011 10:08:50 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> In-Reply-To: <4E4A0396.6060303@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 17:07:57 -0000 On 15/08/2011 10:43 PM, "Andy Green (林安廸)" wrote: > On 08/16/2011 12:15 AM, Somebody in the thread at some point said: > >> >> You keep saying this, but that doesn't make it any less incorrect. A >> frame can be too large for any number of reasons: latency, denial of > > Evidently the "any number of reasons" you could come up with is two. > However if we think about what they mean to a receiver on a duplex > transport, they are not convincing as reasons for the receiving peer > to object to with "frame too big" concept. Your arguments seem to be descending into rhetoric. It is a shame that rhetoric and reality are orthogonal. Since I have mentioned other examples before in this and other threads, your statement is demonstrably false. Let me give an example I have mentioned before. It is usually a good implementation decision to model a protocol. The Websockets specification talks about connections and frames and messages and URLs. It does not talk about buffers or streams between layers. So it is a reasonable expectation that many people will implement Websockets with a Connection class and a Frame class and a Message class and a URL class. Given those classes, what is the simplest thing to do when gathering data from the connection class? Buffer within the Frame. So following the good design principles of modelling the spec and doing the simplest thing possible, it is highly likely that many people will opt for a design similar to mine with a limited maximum frame size. > >> service limitations, etc. Requirements for a particular situation trump >> the theoretical limits of a standard every time. So long as the standard >> does not require that all frame sizes be handled in the same way, it is >> a legitimate implementation decision to choose to handle a particular >> frame size by closing the connection. That behaviour is not broken nor >> bogus, it is completely conforming to the specification. Point me to ANY >> portion of the specification that prohibits it. > > These arguments are about what should appear in and should be removed > from the specification itself. Many times on the list we detected the > spec is broken or not self-consistent at the moment. So it's better > if we use logic, clear descriptions, honest argumentation without > handwaving to figure out what's good and bad as well as what the spec > seems to be intending. It is hard to understand what idea you intended to convey with this obfuscation. But let me go back to the point. The reason we have a specification is to allow compliant implementations to communicate. It is designed to facilitate interoperability. As I have described, there are going to be many people who choose to implement with a maximum frame size. These implementations will be in full conformance with the spec. The spec even goes so far as to explicitly allow closing the connection if a frame is too large, and even you do not disagree with that remaining. So these people will fully expect their conforming implementations to work with other implementations, only to find that there is a hidden gotcha not mentioned in the spec: that if another implementation sends a larger frame size there will be no way to interoperate with them. > >> >>> >>> Because frame processing is performed packet by packet, with the >>> single exception of this proposed frame signing extension, actually >>> the frame layer just deals with a packet at a time. >> >> It can do. It doesn't have to. There is nothing in the specification >> that requires that behaviour. As I have said many times before, and say >> here for the last time. > > That's right but it brings us full circle, you are standing up for the > right to make a crappy and fragile implementation when the good one is > simple and there's no reason not to use it. No. I am standing up for interoperability. Even if you get me to agree that it is crappy and fragile, I am just one person. This is not about your implementation or mine, it is about all the implementations that are going to be out there in the future. I want to make everyone able to communicate as simply as possible, and the cheapest, easiest way to accomplish that is with a maximum frame size. From andy@warmcat.com Tue Aug 16 10:23: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 5EF2121F8BEC for ; Tue, 16 Aug 2011 10:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.208 X-Spam-Level: X-Spam-Status: No, score=-2.208 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVlLOt1yoruD for ; Tue, 16 Aug 2011 10:23:37 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 6493421F8B8C for ; Tue, 16 Aug 2011 10:23:37 -0700 (PDT) Message-ID: <4E4AA7C8.8090205@warmcat.com> Date: Tue, 16 Aug 2011 18:24:24 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> <4E4AA422.10601@callenish.com> In-Reply-To: <4E4AA422.10601@callenish.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 17:23:38 -0000 On 08/16/2011 06:08 PM, Somebody in the thread at some point said: > On 15/08/2011 10:43 PM, "Andy Green (林安廸)" wrote: >> On 08/16/2011 12:15 AM, Somebody in the thread at some point said: >> >>> >>> You keep saying this, but that doesn't make it any less incorrect. A >>> frame can be too large for any number of reasons: latency, denial of >> >> Evidently the "any number of reasons" you could come up with is two. >> However if we think about what they mean to a receiver on a duplex >> transport, they are not convincing as reasons for the receiving peer >> to object to with "frame too big" concept. > > Your arguments seem to be descending into rhetoric. It is a shame that > rhetoric and reality are orthogonal. > > Since I have mentioned other examples before in this and other threads, > your statement is demonstrably false. Let me give an example I have > mentioned before. Sorry you quoted two statements: that you only gave two reasons inbetween "any number of reasons" and "etc", and that sender can't block a receiver from sending... which one are you telling me is "false"? I'm pretty sure they are both accurate. > It is usually a good implementation decision to model a protocol. The > Websockets specification talks about connections and frames and messages > and URLs. It does not talk about buffers or streams between layers. > > So it is a reasonable expectation that many people will implement > Websockets with a Connection class and a Frame class and a Message class > and a URL class. Given those classes, what is the simplest thing to do > when gathering data from the connection class? Buffer within the Frame. > > So following the good design principles of modelling the spec and doing > the simplest thing possible, it is highly likely that many people will > opt for a design similar to mine with a limited maximum frame size. Sorry you're talking about "good design principles" "usually a good implementation decision" here but you promised to "demonstrate" the falsity of something I said? >>> service limitations, etc. Requirements for a particular situation trump >>> the theoretical limits of a standard every time. So long as the standard >>> does not require that all frame sizes be handled in the same way, it is >>> a legitimate implementation decision to choose to handle a particular >>> frame size by closing the connection. That behaviour is not broken nor >>> bogus, it is completely conforming to the specification. Point me to ANY >>> portion of the specification that prohibits it. >> >> These arguments are about what should appear in and should be removed >> from the specification itself. Many times on the list we detected the >> spec is broken or not self-consistent at the moment. So it's better if >> we use logic, clear descriptions, honest argumentation without >> handwaving to figure out what's good and bad as well as what the spec >> seems to be intending. > > It is hard to understand what idea you intended to convey with this > obfuscation. But let me go back to the point. I see. Then let me explain it again ^^ What we're discussing is whether to add or remove stuff from the specification. So the current state of the specification, especially in the areas we are talking about changing is not a good argument without backing it up with some reasoning. Otherwise we would go around in circles every time we changed the spec since some pieces sometimes conflict others. In this case I mean "Point me to ANY portion of the specification that prohibits it" is not really convincing reason 'for' something when we're talking about changing the specification in this area maybe to outlaw it. > The reason we have a specification is to allow compliant implementations > to communicate. It is designed to facilitate interoperability. As I have > described, there are going to be many people who choose to implement > with a maximum frame size. These implementations will be in full Just curious, would anyone planning to have their implementation break at the frame layer based on frame size like to participate in a straw poll here? > conformance with the spec. The spec even goes so far as to explicitly > allow closing the connection if a frame is too large, and even you do > not disagree with that remaining. So these people will fully expect > their conforming implementations to work with other implementations, > only to find that there is a hidden gotcha not mentioned in the spec: > that if another implementation sends a larger frame size there will be > no way to interoperate with them. It's as I wrote, it would be a "crappy and fragile" implementation and you want the spec bent out of shape to service it, when no good reason has been brought forward to do it. >>>> Because frame processing is performed packet by packet, with the >>>> single exception of this proposed frame signing extension, actually >>>> the frame layer just deals with a packet at a time. >>> >>> It can do. It doesn't have to. There is nothing in the specification >>> that requires that behaviour. As I have said many times before, and say >>> here for the last time. >> >> That's right but it brings us full circle, you are standing up for the >> right to make a crappy and fragile implementation when the good one is >> simple and there's no reason not to use it. > > No. I am standing up for interoperability. Even if you get me to agree > that it is crappy and fragile, I am just one person. This is not about > your implementation or mine, it is about all the implementations that > are going to be out there in the future. I want to make everyone able to > communicate as simply as possible, and the cheapest, easiest way to > accomplish that is with a maximum frame size. Earlier you were going on about rhetoric... -Andy From stpeter@stpeter.im Tue Aug 16 10:40: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 E4D4411E80F3 for ; Tue, 16 Aug 2011 10:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=-0.172, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdkkMZZBPi3E for ; Tue, 16 Aug 2011 10:40:35 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 128E611E80DD for ; Tue, 16 Aug 2011 10:40:35 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id B3B694150D; Tue, 16 Aug 2011 11:43:19 -0600 (MDT) Message-ID: <4E4AABC1.8040509@stpeter.im> Date: Tue, 16 Aug 2011 11:41:21 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> In-Reply-To: <4E44C106.7020505@warmcat.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 16 Aug 2011 17:40:36 -0000 On 8/11/11 11:58 PM, "Andy Green (林安廸)" wrote: > On 08/12/2011 12:20 AM, Somebody in the thread at some point said: > >> As it stands, my preference is for #2, as I believe that resource >> limited implementations like what Bruce Atherton have described are >> valid and they need a defined error code to indicate the reason of the >> close. > > The choice in the consensus call is a false dichotomy... in fact we can > keep the error code and not implement the rest of the crap in #2 into > the spec if we like, they're not mutually exclusive. This is the "dark > art of argumentation" I referred to. Peter, did you come up with that > either-or yourself? You seem to think that the suggested choice was malicious. You might want to re-acquaint yourself with Hanlon's Razor. In fact the chairs and I worked out that text and I posted it to the list in an effort to further focus the discussion. Folks, we're here to work together toward consensus. That means listening to each other, understanding the issues that people raise, trying to achieve a common view of the technology we're developing, and formulating specification text that captures the consensus. Having just reviewed the thread to date, I must say it seems that we're not quite there yet. Peter -- Peter Saint-Andre https://stpeter.im/ From tobias.oberstein@tavendo.de Tue Aug 16 10:43:36 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 3E10921F8AFD for ; Tue, 16 Aug 2011 10:43:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-0.321, BAYES_00=-2.599, GB_ABOUTYOU=0.5, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ZezNsWokQ4f for ; Tue, 16 Aug 2011 10:43:35 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB6921F8AE4 for ; Tue, 16 Aug 2011 10:43:35 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 16 Aug 2011 10:44:24 -0700 From: Tobias Oberstein To: Bruce Atherton , =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= Date: Tue, 16 Aug 2011 10:43:41 -0700 Thread-Topic: [hybi] CONSENSUS CALL / Frame too big not possible to occur Thread-Index: AcxcNy3aRtPpTCeFT8mZQtuk+2XQ6wAAfuTw Message-ID: <634914A010D0B943A035D226786325D422C0B9A260@EXVMBX020-12.exch020.serverdata.net> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> <4E4AA422.10601@callenish.com> In-Reply-To: <4E4AA422.10601@callenish.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 17:43:36 -0000 PiBJdCBpcyB1c3VhbGx5IGEgZ29vZCBpbXBsZW1lbnRhdGlvbiBkZWNpc2lvbiB0byBtb2RlbCBh IHByb3RvY29sLiBUaGUNCj4gV2Vic29ja2V0cyBzcGVjaWZpY2F0aW9uIHRhbGtzIGFib3V0IGNv bm5lY3Rpb25zIGFuZCBmcmFtZXMgYW5kIG1lc3NhZ2VzDQo+IGFuZCBVUkxzLiBJdCBkb2VzIG5v dCB0YWxrIGFib3V0IGJ1ZmZlcnMgb3Igc3RyZWFtcyBiZXR3ZWVuIGxheWVycy4NCj4gDQo+IFNv IGl0IGlzIGEgcmVhc29uYWJsZSBleHBlY3RhdGlvbiB0aGF0IG1hbnkgcGVvcGxlIHdpbGwgaW1w bGVtZW50DQo+IFdlYnNvY2tldHMgd2l0aCBhIENvbm5lY3Rpb24gY2xhc3MgYW5kIGEgRnJhbWUg Y2xhc3MgYW5kIGEgTWVzc2FnZSBjbGFzcw0KPiBhbmQgYSBVUkwgY2xhc3MuIEdpdmVuIHRob3Nl IGNsYXNzZXMsIHdoYXQgaXMgdGhlIHNpbXBsZXN0IHRoaW5nIHRvIGRvIHdoZW4NCj4gZ2F0aGVy aW5nIGRhdGEgZnJvbSB0aGUgY29ubmVjdGlvbiBjbGFzcz8gQnVmZmVyIHdpdGhpbiB0aGUgRnJh bWUuDQo+IA0KPiBTbyBmb2xsb3dpbmcgdGhlIGdvb2QgZGVzaWduIHByaW5jaXBsZXMgb2YgbW9k ZWxsaW5nIHRoZSBzcGVjIGFuZCBkb2luZyB0aGUNCj4gc2ltcGxlc3QgdGhpbmcgcG9zc2libGUs IGl0IGlzIGhpZ2hseSBsaWtlbHkgdGhhdCBtYW55IHBlb3BsZSB3aWxsIG9wdCBmb3IgYSBkZXNp Z24NCj4gc2ltaWxhciB0byBtaW5lIHdpdGggYSBsaW1pdGVkIG1heGltdW0gZnJhbWUgc2l6ZS4N Cg0KU2luY2UgeW91IGFyZSBzbyBib2xkLCBteSBhbnN3ZXIgaXMgYWxzbzoNCg0KTm8sIGl0IGlz IG5vdCAicmVhc29uYWJsZSIgYW5kIG5vdCAiaGlnaGx5IGxpa2VseSIuDQoNCk5vIG9uZSB3b3Vs ZCBvcHQgZm9yIGEgYnJva2VuIGRlc2lnbiB0aGF0IGZvbGxvd3MgYSBuYWl2ZSBzY2hvb2xib29r DQpPTyBhcHByb2FjaCwgaW50cm9kdWNpbmcgYXJiaXRyYXJ5IGhhcmQtY29kZWQgbGltaXRzLg0K DQpBZ2FpbjogeW91IGNhbiBoYXZlIGEgc3RyZWFtaW5nIGltcGxlbWVudGF0aW9uLCB0aGF0IGJ5 IGRlZmF1bHQgYnVmZmVycw0KdXAgdG8gZnJhbWVzLCBhbmQgZnVydGhlciB0byBtZXNzYWdlcy4g VGhlbiwgeW91ciB1c2VycyBoYXZlIHRoZSBjb252ZW5pZW5jZQ0Kb2YgYSBtZXNzYWdlLWJhc2Vk IEFQSSBmb3IgZ2VuZXJhbCB1c2UsIGJ1dCBjYW4gb3ZlcnJpZGUgdGhlIGRlZmF1bHQgYnVmZmVy aW5nDQp0byBnZXQgYXQgdGhlIGZyYW1lIG9yIHN0cmVhbWluZyBsZXZlbC4NCg0KPiBOby4gSSBh bSBzdGFuZGluZyB1cCBmb3IgaW50ZXJvcGVyYWJpbGl0eS4gRXZlbiBpZiB5b3UgZ2V0IG1lIHRv IGFncmVlDQo+IHRoYXQgaXQgaXMgY3JhcHB5IGFuZCBmcmFnaWxlLCBJIGFtIGp1c3Qgb25lIHBl cnNvbi4gVGhpcyBpcyBub3QgYWJvdXQNCj4geW91ciBpbXBsZW1lbnRhdGlvbiBvciBtaW5lLCBp dCBpcyBhYm91dCBhbGwgdGhlIGltcGxlbWVudGF0aW9ucyB0aGF0DQoNCkl0IGlzIGFib3V0IHlv dXJzLiBBcyBpdCBzdGFuZHMsIEFuZHkncyBhbmQgbWluZSBjYW4gdGFsayB0byBlYWNoIG90aGVy DQphcyB3ZWxsIGFzIEZpcmVmb3ggYW5kIENocm9tZSAuLi4gdXNpbmcgYW55IGZyYW1lIHNpemUg dXAgdG8gMl42My4NCg0KPiBhcmUgZ29pbmcgdG8gYmUgb3V0IHRoZXJlIGluIHRoZSBmdXR1cmUu IEkgd2FudCB0byBtYWtlIGV2ZXJ5b25lIGFibGUgdG8NCj4gY29tbXVuaWNhdGUgYXMgc2ltcGx5 IGFzIHBvc3NpYmxlLCBhbmQgdGhlIGNoZWFwZXN0LCBlYXNpZXN0IHdheSB0bw0KPiBhY2NvbXBs aXNoIHRoYXQgaXMgd2l0aCBhIG1heGltdW0gZnJhbWUgc2l6ZS4NCg0KTm8sIGl0J3Mgbm90LiBU aGUgY2hlYXBlc3Qgd2F5IGlzOiBmaXggeW91ciBicm9rZW4gaW1wbGVtZW50YXRpb24uDQoNCg== From bruce@callenish.com Tue Aug 16 10:50: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 0759411E808E for ; Tue, 16 Aug 2011 10:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.255 X-Spam-Level: X-Spam-Status: No, score=-2.255 tagged_above=-999 required=5 tests=[AWL=-0.256, BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1ljRhU3XbNl for ; Tue, 16 Aug 2011 10:50:00 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 969F611E8088 for ; Tue, 16 Aug 2011 10:50:00 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QtNmq-0006v3-Mx; Tue, 16 Aug 2011 10:50:48 -0700 Message-ID: <4E4AADFE.9090006@callenish.com> Date: Tue, 16 Aug 2011 10:50:54 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> In-Reply-To: <20110815111840.ef1fc80126c74c6c202a919c41c7bb0b.4702e321e4.wbe@email03.secureserver.net> 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] Binary/Text Distinction 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, 16 Aug 2011 17:50:01 -0000 On 15/08/2011 11:18 AM, Bob Gezelter wrote: > I agree with I?aki that the distinction between text/binary data is > unnecessary. Similarly, I agree with Dave Endicott's and I?aki's > comments about the mixing of different classes of functionality in the > WebSocket protocol. > > As has been observed, the WebSocket protocol is payload-agnostic. > Regardless of the politics, it is thus emphatically NOT an applications > protocol. It is a protocol that provides a foundational service layered > on top of another transport protocol (e.g. TCP). Agreed. However, it does provide the ability to specify an application protocol through the subprotocol header. To my mind, this is where any distinction between a binary or text message or stream belongs: on the connection itself, not on individual frame/message opcodes. Having said that, I don't think this nit is large enough to hold up getting the protocol out the door, warts and all. From andy@warmcat.com Tue Aug 16 10:51: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 5885D11E808E for ; Tue, 16 Aug 2011 10:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.211 X-Spam-Level: X-Spam-Status: No, score=-2.211 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pSUKwaWu5OF for ; Tue, 16 Aug 2011 10:51:07 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCC111E8088 for ; Tue, 16 Aug 2011 10:51:06 -0700 (PDT) Message-ID: <4E4AAE3A.7030902@warmcat.com> Date: Tue, 16 Aug 2011 18:51:54 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im> In-Reply-To: <4E4AABC1.8040509@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 16 Aug 2011 17:51:09 -0000 On 08/16/2011 06:41 PM, Somebody in the thread at some point said: > > > On 8/11/11 11:58 PM, "Andy Green (林安廸)" wrote: >> On 08/12/2011 12:20 AM, Somebody in the thread at some point said: >> >>> As it stands, my preference is for #2, as I believe that resource >>> limited implementations like what Bruce Atherton have described are >>> valid and they need a defined error code to indicate the reason of the >>> close. >> >> The choice in the consensus call is a false dichotomy... in fact we can >> keep the error code and not implement the rest of the crap in #2 into >> the spec if we like, they're not mutually exclusive. This is the "dark >> art of argumentation" I referred to. Peter, did you come up with that >> either-or yourself? > > You seem to think that the suggested choice was malicious. You might > want to re-acquaint yourself with Hanlon's Razor. Actually I asked if you came up with that either-or yourself, because actually the two options are not mutually exclusive and they were formed from Greg's, well, observation. > In fact the chairs and I worked out that text and I posted it to the > list in an effort to further focus the discussion. In that case you are right, we are not quite there yet. > Folks, we're here to work together toward consensus. That means > listening to each other, understanding the issues that people raise, > trying to achieve a common view of the technology we're developing, and > formulating specification text that captures the consensus. Having just > reviewed the thread to date, I must say it seems that we're not quite > there yet. I've been on the list a while and I most time "consensus" is really elusive. Just look at this consensus call, it's split about 50:50. Other times there has been a "raging consensus" about masking, were you around during the "how much crypto is enough" wars? I guess some issues must be "is black black?" type questions but most of them are not. When they are not, the issues have to be argued through. If the people who don't agree with the people who are speaking loudest, or speaking from the centre of gravity of the group stay silent, wrong decisions will be made. In short you can't arrive at an accurate consensus without the argumentation step. You would be better off focused on keeping the argument honest rather than trying to pretend it is not necessary. -Andy From stpeter@stpeter.im Tue Aug 16 10:58: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 2E80121F8A71 for ; Tue, 16 Aug 2011 10:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFQqAw8cWezu for ; Tue, 16 Aug 2011 10:58:05 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 7ECF621F8A35 for ; Tue, 16 Aug 2011 10:58:05 -0700 (PDT) Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A5EDD4150D; Tue, 16 Aug 2011 12:00:50 -0600 (MDT) Message-ID: <4E4AAFDD.6080902@stpeter.im> Date: Tue, 16 Aug 2011 11:58:53 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im> <4E4AAE3A.7030902@warmcat.com> In-Reply-To: <4E4AAE3A.7030902@warmcat.com> X-Enigmail-Version: 1.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 16 Aug 2011 17:58:06 -0000 On 8/16/11 11:51 AM, "Andy Green (林安廸)" wrote: > On 08/16/2011 06:41 PM, Somebody in the thread at some point said: >> >> >> On 8/11/11 11:58 PM, "Andy Green (林安廸)" wrote: >>> On 08/12/2011 12:20 AM, Somebody in the thread at some point said: >>> >>>> As it stands, my preference is for #2, as I believe that resource >>>> limited implementations like what Bruce Atherton have described are >>>> valid and they need a defined error code to indicate the reason of the >>>> close. >>> >>> The choice in the consensus call is a false dichotomy... in fact we can >>> keep the error code and not implement the rest of the crap in #2 into >>> the spec if we like, they're not mutually exclusive. This is the "dark >>> art of argumentation" I referred to. Peter, did you come up with that >>> either-or yourself? >> >> You seem to think that the suggested choice was malicious. You might >> want to re-acquaint yourself with Hanlon's Razor. > > Actually I asked if you came up with that either-or yourself, because > actually the two options are not mutually exclusive and they were formed > from Greg's, well, observation. > >> In fact the chairs and I worked out that text and I posted it to the >> list in an effort to further focus the discussion. > > In that case you are right, we are not quite there yet. > >> Folks, we're here to work together toward consensus. That means >> listening to each other, understanding the issues that people raise, >> trying to achieve a common view of the technology we're developing, and >> formulating specification text that captures the consensus. Having just >> reviewed the thread to date, I must say it seems that we're not quite >> there yet. > > I've been on the list a while and I most time "consensus" is really > elusive. Sadly, yes. The issues are difficult and often the discussion has been contentious, but we've managed to hold together this far. I'd hate to see us break apart over something as minor as error code 1004. :) > Just look at this consensus call, it's split about 50:50. Other times > there has been a "raging consensus" about masking, were you around > during the "how much crypto is enough" wars? I guess some issues must > be "is black black?" type questions but most of them are not. > > When they are not, the issues have to be argued through. If the people > who don't agree with the people who are speaking loudest, or speaking > from the centre of gravity of the group stay silent, wrong decisions > will be made. > > In short you can't arrive at an accurate consensus without the > argumentation step. You would be better off focused on keeping the > argument honest rather than trying to pretend it is not necessary. Me specifically, or everyone? I completely agree that each one of us has a responsibility to understand the issues that other people raise here, and that people who raise such issues need to clearly describe the issue and explain the reasons for considering the issue. Ideally, people would propose text that can be incorporated into the spec. Unfortunately, only Len Holgate has proposed text of late. Replies to his message might help us move forward. Peter -- Peter Saint-Andre https://stpeter.im/ From andy@warmcat.com Tue Aug 16 11:46: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 669D921F8BB9 for ; Tue, 16 Aug 2011 11:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.214 X-Spam-Level: X-Spam-Status: No, score=-2.214 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G0svoBjoJYng for ; Tue, 16 Aug 2011 11:46:19 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id AC69821F8BB7 for ; Tue, 16 Aug 2011 11:46:18 -0700 (PDT) Message-ID: <4E4ABB28.8020009@warmcat.com> Date: Tue, 16 Aug 2011 19:47:04 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Peter Saint-Andre References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im> <4E4AAE3A.7030902@warmcat.com> <4E4AAFDD.6080902@stpeter.im> In-Reply-To: <4E4AAFDD.6080902@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 16 Aug 2011 18:46:19 -0000 On 08/16/2011 06:58 PM, Somebody in the thread at some point said: > >> I've been on the list a while and I most time "consensus" is really >> elusive. > > Sadly, yes. The issues are difficult and often the discussion has been > contentious, but we've managed to hold together this far. I'd hate to > see us break apart over something as minor as error code 1004. :) That error code's welcome to stay by me, although I have explained at length why it is useless. It's the rest of the frame mtu stuff trying to ride into the spec on its coat-tails that is really objectionable. >> Just look at this consensus call, it's split about 50:50. Other times >> there has been a "raging consensus" about masking, were you around >> during the "how much crypto is enough" wars? I guess some issues must >> be "is black black?" type questions but most of them are not. >> >> When they are not, the issues have to be argued through. If the people >> who don't agree with the people who are speaking loudest, or speaking >> from the centre of gravity of the group stay silent, wrong decisions >> will be made. >> >> In short you can't arrive at an accurate consensus without the >> argumentation step. You would be better off focused on keeping the >> argument honest rather than trying to pretend it is not necessary. > > Me specifically, or everyone? All of us are in the same boat. > I completely agree that each one of us has a responsibility to > understand the issues that other people raise here, and that people who > raise such issues need to clearly describe the issue and explain the > reasons for considering the issue. Ideally, people would propose text > that can be incorporated into the spec. Unfortunately, only Len Holgate > has proposed text of late. Replies to his message might help us move > forward. However because of what has been proposed by others, I am trying to keep stuff out of the spec and like it as it is in this area. It's not going to yield new text then but try to keep bloat out of the spec. This is also a vital part of "moving forward". -Andy From bruce@callenish.com Tue Aug 16 11:46: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 AE1FC21F8BB9 for ; Tue, 16 Aug 2011 11:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3WKXBYX9fC2 for ; Tue, 16 Aug 2011 11:46:44 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC2F21F8BB7 for ; Tue, 16 Aug 2011 11:46:44 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QtOfk-0000TE-6X; Tue, 16 Aug 2011 11:47:32 -0700 Message-ID: <4E4ABB4A.7000502@callenish.com> Date: Tue, 16 Aug 2011 11:47:38 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Tobias Oberstein References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> <4E4AA422.10601@callenish.com> <634914A010D0B943A035D226786325D422C0B9A260@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A260@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=UTF-8; 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] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 18:46:44 -0000 On 16/08/2011 10:43 AM, Tobias Oberstein wrote: >> It is usually a good implementation decision to model a protocol. The >> Websockets specification talks about connections and frames and messages >> and URLs. It does not talk about buffers or streams between layers. >> >> So it is a reasonable expectation that many people will implement >> Websockets with a Connection class and a Frame class and a Message class >> and a URL class. Given those classes, what is the simplest thing to do when >> gathering data from the connection class? Buffer within the Frame. >> >> So following the good design principles of modelling the spec and doing the >> simplest thing possible, it is highly likely that many people will opt for a design >> similar to mine with a limited maximum frame size. > Since you are so bold, my answer is also: > > No, it is not "reasonable" and not "highly likely". You may be right. I could be completely wrong about people using this design. What would be the impact of a maximum frame size in that case? Since using max frame size would be completely optional, that would mean no one would ever send out the header. And that would mean many implementations would never bother coding to react to it. Some might. Those implementations would then have a tested mechanism for fragmenting messages, which would come in handy when adopting an extension that required reduced frame sizes like Heartbeat or Mux. Now consider the consequences if you are wrong and there are a number of implementations with a maximum frame size but no way to indicate it. You would have situations where everything seemed to be compatible, messages flow smoothly from one end to another, when suddenly, unexpectedly things fail. The code may already have deployed into production. It may be extremely rare to fail, and depending on circumstances it may be difficult to figure out why things fail. Or you may have purchased a product with a WS implementation that completely fails to work with yours. You may know why, but it doesn't help you in getting things to work properly. >> are going to be out there in the future. I want to make everyone able to >> communicate as simply as possible, and the cheapest, easiest way to >> accomplish that is with a maximum frame size. > No, it's not. The cheapest way is: fix your broken implementation. Given the behaviour of Firefox, if there is no maximum frame size communication in the spec then I will change my implementation because requirements will have changed. I'll be one of the lucky ones, because I will be aware of the issue. In the interests of interoperability, if there is no ability to communicate a maximum frame size then I suggest that the spec make it explicit that an implementation that refuses a frame for being too large is non-compliant. At least give people a fighting chance. From ibc@aliax.net Tue Aug 16 13:50: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 5C95221F8ACC for ; Tue, 16 Aug 2011 13:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W26M3eVGbIUY for ; Tue, 16 Aug 2011 13:50:33 -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 9A23121F8AC9 for ; Tue, 16 Aug 2011 13:50:33 -0700 (PDT) Received: by qyk34 with SMTP id 34so1645942qyk.10 for ; Tue, 16 Aug 2011 13:51:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.199.136 with SMTP id es8mr251266qab.28.1313527882600; Tue, 16 Aug 2011 13:51:22 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Tue, 16 Aug 2011 13:51:22 -0700 (PDT) In-Reply-To: <20110816073401.ef1fc80126c74c6c202a919c41c7bb0b.f02db904ba.wbe@email03.secureserver.net> References: <20110816073401.ef1fc80126c74c6c202a919c41c7bb0b.f02db904ba.wbe@email03.secureserver.net> Date: Tue, 16 Aug 2011 22:51:22 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] "Intermediaries" 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, 16 Aug 2011 20:50:34 -0000 2011/8/16 Bob Gezelter : > I would like to suggest that as a group, we be far more precise about > our usage of the term "intermediaries". > > A device that terminates a WebSocket protocol connection underlying > transport connection (e.g., TCP link) is most properly referred to as a > "gateway". In a multiplexed context, such a device might also forward > the contained sub-channels to different physical endpoints, functioning > as a traffic director or proxy. > > A device that seemingly transparently inspects (and possibly interferes > with) the transport stream WITHOUT being the endpoint of the transport > connection is a very different beast. It is hardly a proxy. > > These two devices (and I DO NOT claim that the above is an exhaustive > taxonomy) are far different in their issues and implications. > > For example, consider the meaning of PING/PONG in the above cases. For > one thing, it is clear that a multiplexed implementation requires a > sub-channel PING/PONG, or an explicit note that an application using a > channel is responsible for ascertaining the state of its correspondent > through a similar, applications level construct (preferably the latter, > the only assurance that an application endpoint is actually functioning > is a response from the application itself, not a response from the > remote API). Good comment. I agree, the term "intermediary" is too much used in the draft and the maillist without nobody specifying what it is exactly. --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Tue Aug 16 14:29: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 B9AAF11E80AA for ; Tue, 16 Aug 2011 14:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tg14r5wlfiNV for ; Tue, 16 Aug 2011 14:29:44 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5F11E80A8 for ; Tue, 16 Aug 2011 14:29:44 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QtRDU-0007AW-Fk; Tue, 16 Aug 2011 14:30:32 -0700 Message-ID: <4E4AE17F.4020807@callenish.com> Date: Tue, 16 Aug 2011 14:30:39 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> In-Reply-To: <4E4A0396.6060303@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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] CONSENSUS CALL / Frame too big not possible to occur 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, 16 Aug 2011 21:29:45 -0000 On 15/08/2011 10:43 PM, "Andy Green (林安廸)" wrote: > > The problems with latency if the transmitting peer sends a big frame > are all at the sender. The receiver can asynchronously send frames > any time; the error you like to send relies on that. So the only > latency that gets stretched is that of the sender being able to send a > new frame while he's still going on with the old one. No. The issue for me concerning latency is implementing a heartbeat. I know, I've heard it before on this list. "That's an extension issue. Make the extension define the maximum frame size." There is actually an argument that can be made for this. The heartbeat extension knows the timing of the heartbeat and can adjust the frame size accordingly. There is a downside, though. It means more coupling between the extension and the core implementation. Right now each part of my implementation passes information up to the next through a chain of responsibility with a single method call in the interface. That API becomes more complicated if the extension has to be able to configure the framing layer (which it previously had no direct knowledge of) as well. Ordinarily protocol specifications give people the right to decide on which tradeoffs make sense to them. In my opinion, a protocol which is specified in such a way as to severely limit the options for implementers is overly constrained. Ironically, in this case the over-constraint comes from NOT specifying something that would allow for a greater variety of implementations to work together. From andy@warmcat.com Tue Aug 16 23:00: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 59C9511E8083 for ; Tue, 16 Aug 2011 23:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.217 X-Spam-Level: X-Spam-Status: No, score=-2.217 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-mhz-mHiV+Z for ; Tue, 16 Aug 2011 23:00:39 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 8D13011E8073 for ; Tue, 16 Aug 2011 23:00:39 -0700 (PDT) Message-ID: <4E4B5935.4000804@warmcat.com> Date: Wed, 17 Aug 2011 07:01:25 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> <4E4AE17F.4020807@callenish.com> In-Reply-To: <4E4AE17F.4020807@callenish.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL / Heartbeat vs keepalive 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, 17 Aug 2011 06:00:40 -0000 On 08/16/2011 10:30 PM, Somebody in the thread at some point said: > On 15/08/2011 10:43 PM, "Andy Green (林安廸)" wrote: >> >> The problems with latency if the transmitting peer sends a big frame >> are all at the sender. The receiver can asynchronously send frames any >> time; the error you like to send relies on that. So the only latency >> that gets stretched is that of the sender being able to send a new >> frame while he's still going on with the old one. > > No. The issue for me concerning latency is implementing a heartbeat. > > I know, I've heard it before on this list. "That's an extension issue. > Make the extension define the maximum frame size." There is actually an > argument that can be made for this. The heartbeat extension knows the > timing of the heartbeat and can adjust the frame size accordingly. > > There is a downside, though. It means more coupling between the Alright, knowing your server is dead is a reasonable thing to want. There's an issue with this scheme you also have to face, what constitutes a reasonable max "hogging the channel" fragment size is dependent on the minimum bandwidth that channel can be expected to experience. That can vary widely depending on the physical transport and even dynamically. > extension and the core implementation. Right now each part of my > implementation passes information up to the next through a chain of > responsibility with a single method call in the interface. That API > becomes more complicated if the extension has to be able to configure > the framing layer (which it previously had no direct knowledge of) as well. > > Ordinarily protocol specifications give people the right to decide on > which tradeoffs make sense to them. In my opinion, a protocol which is > specified in such a way as to severely limit the options for > implementers is overly constrained. Ironically, in this case the > over-constraint comes from NOT specifying something that would allow for > a greater variety of implementations to work together. It is possible to exclude too much. But another way to break it is to be too lassaiz-faire and include anything until the simplest explanation of the protocol must include bandwidth estimation, negotiation of frame sizes and so on which actually can be eliminated. Actually really good protocols just do the needful once it's understood what that minimum set is. "Heartbeat" was discussed in some good threads some months ago under the name "keep alive". The proposal there was to allow the client or server to shutdown a link if the peer had actually gone away, to be able to tell the difference between your conversation partner falling silent for a bit or having dropped dead. During that discussion, I realized (I think proposed but can't remember) that incoming traffic of any kind is evidence of life, meaning you do not need to issue a PING to stimulate incoming traffic until you did not hear anything from the remote side for some threshold time. If you take that approach, it's true you are open to taking endless babble as evidence of all being well (same as with actual heartbeat the heartbeat extension may respond while the actual server side is dead), but otherwise because you regard any incoming traffic as telling you about remote peer state you can detect if the server is dead just fine without having to get into frame fragmentation issues at all. -Andy From ibc@aliax.net Wed Aug 17 01:10: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 61CB621F8A36 for ; Wed, 17 Aug 2011 01:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNonGidEeUoD for ; Wed, 17 Aug 2011 01:10:11 -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 C1CF621F8A35 for ; Wed, 17 Aug 2011 01:10:11 -0700 (PDT) Received: by qyk34 with SMTP id 34so1881879qyk.10 for ; Wed, 17 Aug 2011 01:10:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.199.136 with SMTP id es8mr806044qab.28.1313568641139; Wed, 17 Aug 2011 01:10:41 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Wed, 17 Aug 2011 01:10:41 -0700 (PDT) Date: Wed, 17 Aug 2011 10:10:41 +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] Test suite for WebSocket servers? 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, 17 Aug 2011 08:10:12 -0000 Hi, there is a powerful test suite for WebSocket clients but, is there any WebSocket client to test a WS server? This is, I'm building a WS server and would like a WS client performing several "standard" tests (I mean more than sending a Ping and expecting a Pong). Thanks a lot. --=20 I=C3=B1aki Baz Castillo From andy@warmcat.com Wed Aug 17 01:17: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 A576221F8562 for ; Wed, 17 Aug 2011 01:17:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mdNzYNqMoWJ6 for ; Wed, 17 Aug 2011 01:17:12 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id E785D21F8560 for ; Wed, 17 Aug 2011 01:17:11 -0700 (PDT) Message-ID: <4E4B7938.80504@warmcat.com> Date: Wed, 17 Aug 2011 09:18:00 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Test suite for WebSocket servers? 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, 17 Aug 2011 08:17:12 -0000 On 08/17/2011 09:10 AM, Somebody in the thread at some point said: > Hi, there is a powerful test suite for WebSocket clients but, is there > any WebSocket client to test a WS server? This is, I'm building a WS > server and would like a WS client performing several "standard" tests > (I mean more than sending a Ping and expecting a Pong). libwebsockets has a "fraggle" test that tests both sides can cope with random messages composed of random number of random sized frames. http://git.warmcat.com/cgi-bin/cgit/libwebsockets/tree/test-server/test-fraggle.c I dunno what a standard test would look like without it being bound to a particular protocol. And then you need to be careful you're not testing the code just in that protocol and can expect the same good results on another non-test protocol. -Andy From ibc@aliax.net Wed Aug 17 01:24: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 EF6AA21F8686 for ; Wed, 17 Aug 2011 01:24:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.635 X-Spam-Level: X-Spam-Status: No, score=-2.635 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Musl8UDPu5MH for ; Wed, 17 Aug 2011 01:24:25 -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 4646721F8B0F for ; Wed, 17 Aug 2011 01:24:25 -0700 (PDT) Received: by qyk35 with SMTP id 35so466295qyk.10 for ; Wed, 17 Aug 2011 01:25:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.20 with SMTP id g20mr787820qac.178.1313569515198; Wed, 17 Aug 2011 01:25:15 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Wed, 17 Aug 2011 01:25:15 -0700 (PDT) In-Reply-To: <4E4B7938.80504@warmcat.com> References: <4E4B7938.80504@warmcat.com> Date: Wed, 17 Aug 2011 10:25:15 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Test suite for WebSocket servers? 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, 17 Aug 2011 08:24:26 -0000 2011/8/17 "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" : > libwebsockets has a "fraggle" test that tests both sides can cope with > random messages composed of random number of random sized frames. > > http://git.warmcat.com/cgi-bin/cgit/libwebsockets/tree/test-server/test-f= raggle.c Great, thanks a lot. > I dunno what a standard test would look like without it being bound to a > particular protocol. =C2=A0And then you need to be careful you're not tes= ting the > code just in that protocol and can expect the same good results on anothe= r > non-test protocol. Well, I mean application agnostic tests, like sending invalid FIN/opcode and expecting a remote connection close, or sending opcode=3D1 (UTF-8 text) and sending invalid UTF-8 in the application payload. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From andy@warmcat.com Wed Aug 17 01:40: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 5076F21F884C for ; Wed, 17 Aug 2011 01:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.223 X-Spam-Level: X-Spam-Status: No, score=-2.223 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbupFre-B7kZ for ; Wed, 17 Aug 2011 01:40:41 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id CABA221F883A for ; Wed, 17 Aug 2011 01:40:40 -0700 (PDT) Message-ID: <4E4B7EBA.4030103@warmcat.com> Date: Wed, 17 Aug 2011 09:41:30 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E4B7938.80504@warmcat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Test suite for WebSocket servers? 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, 17 Aug 2011 08:40:41 -0000 On 08/17/2011 09:25 AM, Somebody in the thread at some point said: > Well, I mean application agnostic tests, like sending invalid > FIN/opcode and expecting a remote connection close, or sending > opcode=1 (UTF-8 text) and sending invalid UTF-8 in the application > payload. That's not a bad idea at all. -Andy From ibc@aliax.net Wed Aug 17 01:49: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 7ABC921F8A23 for ; Wed, 17 Aug 2011 01:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vl-Dx2IuqZ3S for ; Wed, 17 Aug 2011 01:49: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 B90EE21F8A4D for ; Wed, 17 Aug 2011 01:48:59 -0700 (PDT) Received: by qwc23 with SMTP id 23so522767qwc.31 for ; Wed, 17 Aug 2011 01:49:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.174.208 with SMTP id u16mr773232qaz.328.1313570990158; Wed, 17 Aug 2011 01:49:50 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Wed, 17 Aug 2011 01:49:50 -0700 (PDT) In-Reply-To: <4E4B7EBA.4030103@warmcat.com> References: <4E4B7938.80504@warmcat.com> <4E4B7EBA.4030103@warmcat.com> Date: Wed, 17 Aug 2011 10:49:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: =?UTF-8?B?QW5keSBHcmVlbiAo5p6X5a6J5bu4KQ==?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Test suite for WebSocket servers? 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, 17 Aug 2011 08:49:00 -0000 2011/8/17 "Andy Green (=E6=9E=97=E5=AE=89=E5=BB=B8)" : >> Well, I mean application agnostic tests, like sending invalid >> FIN/opcode and expecting a remote connection close, or sending >> opcode=3D1 (UTF-8 text) and sending invalid UTF-8 in the application >> payload. > > That's not a bad idea at all. We need reference WS servers for testing WS clients, and reference WS clients for testing WS servers. The chicken or the egg? :) --=20 I=C3=B1aki Baz Castillo From tyoshino@google.com Wed Aug 17 02:26: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 A40D021F87C5 for ; Wed, 17 Aug 2011 02:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.761 X-Spam-Level: X-Spam-Status: No, score=-105.761 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s9sks5KX8Qx for ; Wed, 17 Aug 2011 02:26:44 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0B26C21F8797 for ; Wed, 17 Aug 2011 02:26:43 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7H9RXgN025697 for ; Wed, 17 Aug 2011 02:27:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313573254; bh=FUEVoJQp/wJFgQYX/8h7+QFmJbc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=V6YgQEzvUR2PFcFxcLb5ZcXWIIGPwFqYmnM9ZCE5yriG7gWOcIXu2p5Zs8kcLKqA+ uQRCtwgyPAvqu3UDiVcAQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Lrz08rxbMxdfuakCQaBg/hZeaxAcIFwnEj9TaeRs1dApGwTHO+6ao8deetOs1gq9u tgG2R1YeONnYCbCBY7mgA== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by hpaq14.eem.corp.google.com with ESMTP id p7H9RVZg020972 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 17 Aug 2011 02:27:32 -0700 Received: by ywf9 with SMTP id 9so652102ywf.32 for ; Wed, 17 Aug 2011 02:27:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cq7R1LJW3kmfKT2hr4J2ITipj0WQO0SYv6iKe2o/fVU=; b=XEV4Pw3o3R9udKNObOAl9k3TQ1h8DQd3nDPt++jn29VBdjIydHVK01RGKyZW+StxC5 TabZDJZktVJXFZIj2bSA== Received: by 10.91.67.20 with SMTP id u20mr787895agk.163.1313573251211; Wed, 17 Aug 2011 02:27:31 -0700 (PDT) Received: by 10.91.67.20 with SMTP id u20mr787857agk.163.1313573249110; Wed, 17 Aug 2011 02:27:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.32.2 with HTTP; Wed, 17 Aug 2011 02:27:09 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Wed, 17 Aug 2011 18:27:09 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001485f7c132e651ea04aab01a13 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 17 Aug 2011 09:26:44 -0000 --001485f7c132e651ea04aab01a13 Content-Type: text/plain; charset=ISO-8859-1 So, the problem is that seeing this sentence, it's not very clear how much grammar (all or only some rules from them) is borrowed from RFC2616. (Just IMO, it's natural to think that we should take into account all of RFC2616 section 2.) "this section is using ABNF syntax/rules from [RFC2616]" LWS, CHAR, CTL, separator, etc. are in the dependency tree from the rules that appear in the WebSocket spec section 9.1 (#rule, *rule, etc.), but implied *LWS rule is out of the dependency tree. Changing the text to "this section is using ABNF syntax/rules from [RFC2616] including "implied *LWS" rule" would be better? I'm fine with this. ---- I just found existing thread where this is discussed. http://www.ietf.org/mail-archive/web/hybi/current/msg07728.html http://www.ietf.org/mail-archive/web/hybi/current/msg07729.html http://www.ietf.org/mail-archive/web/hybi/current/msg07730.html (your post) http://www.ietf.org/mail-archive/web/hybi/current/msg07737.html I agree that we should just inherit all the grammar defined in RFC2616 section 2 to interpret the extension header. Thanks, Takeshi --001485f7c132e651ea04aab01a13 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
So, the problem is that seeing this sentence, it's not very clear = how much grammar (all or only some rules from them) is borrowed from RFC261= 6. (Just IMO, it's natural to think that we should take into account al= l of RFC2616 section 2.)

"this section is using ABNF syntax/rules from [RFC= 2616]"

LWS, CHAR, CTL, separator, etc. are in= the dependency tree from the rules that appear in the WebSocket spec secti= on 9.1 (#rule, *rule, etc.), but implied *LWS rule is out of the dependency= tree. Changing the text to

"this section is using ABNF syntax/rules from= [RFC2616] including "implied *LWS" rule"
would be better? I'm fine with this.

----

I just found existing thread where this = is discussed.
http://www.ietf.org/mail-archive/web/hybi/current/msg07729.html
http://www.ietf.org/mail-archive/web/hybi/current/msg07737.html

I agree that we should just inherit all the grammar= defined in RFC2616 section 2 to interpret the extension header.

Thanks,
Takeshi

--001485f7c132e651ea04aab01a13-- From alexey.melnikov@isode.com Wed Aug 17 02:32: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 3A33921F85AA for ; Wed, 17 Aug 2011 02:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bh0nUiP0MLRB for ; Wed, 17 Aug 2011 02:32:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 6B13521F859F for ; Wed, 17 Aug 2011 02:32:36 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 17 Aug 2011 10:33:25 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E4B8ADF.8090208@isode.com> Date: Wed, 17 Aug 2011 10:33:19 +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: Takeshi Yoshino References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 17 Aug 2011 09:32:37 -0000 Takeshi Yoshino wrote: > So, the problem is that seeing this sentence, it's not very clear how > much grammar (all or only some rules from them) is borrowed from > RFC2616. (Just IMO, it's natural to think that we should take into > account all of RFC2616 section 2.) > > "this section is using ABNF syntax/rules from [RFC2616]" > > LWS, CHAR, CTL, separator, etc. are in the dependency tree from the > rules that appear in the WebSocket spec section 9.1 (#rule, *rule, > etc.), but implied *LWS rule is out of the dependency tree. Changing > the text to > > "this section is using ABNF syntax/rules from [RFC2616] including > "implied *LWS" rule" Actually, I've already done this in my copy of -11-to-be. > would be better? I'm fine with this. > > ---- > > I just found existing thread where this is discussed. > http://www.ietf.org/mail-archive/web/hybi/current/msg07728.html > http://www.ietf.org/mail-archive/web/hybi/current/msg07729.html > http://www.ietf.org/mail-archive/web/hybi/current/msg07730.html (your > post) > http://www.ietf.org/mail-archive/web/hybi/current/msg07737.html > > I agree that we should just inherit all the grammar defined in RFC2616 > section 2 to interpret the extension header. > > Thanks, > Takeshi From ibc@aliax.net Wed Aug 17 02:33: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 CBFF421F8AC3 for ; Wed, 17 Aug 2011 02:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZmQxIJl-atHh for ; Wed, 17 Aug 2011 02:33:02 -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 3EF9D21F859F for ; Wed, 17 Aug 2011 02:33:02 -0700 (PDT) Received: by qwc23 with SMTP id 23so544055qwc.31 for ; Wed, 17 Aug 2011 02:33:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.20 with SMTP id g20mr851513qac.178.1313573632652; Wed, 17 Aug 2011 02:33:52 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Wed, 17 Aug 2011 02:33:52 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Aug 2011 11:33:52 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 17 Aug 2011 09:33:02 -0000 2011/8/17 Takeshi Yoshino : > So, the problem is that seeing this sentence, it's not very clear how muc= h > grammar (all or only some rules from them) is borrowed from RFC2616. (Jus= t > IMO, it's natural to think that we should take into account all of RFC261= 6 > section 2.) > "this section is using ABNF syntax/rules from [RFC2616]" > LWS, CHAR, CTL, separator, etc. are in the dependency tree from the rules > that appear in the WebSocket spec section 9.1 (#rule, *rule, etc.), but > implied *LWS rule is out of the dependency tree. Changing the text to > "this section is using ABNF syntax/rules from [RFC2616] including "implie= d > *LWS" rule" > would be better? I'm fine with this. Honestly I didn't know the "implied *LWS" rule in RFC 2616, but indeed it exists: implied *LWS The grammar described by this specification is word-based. Except where noted otherwise, linear white space (LWS) can be included between any two adjacent words (token or quoted-string), and between adjacent words and separators, without changing the interpretation of a field. At least one delimiter (LWS and/or separators) MUST exist between any two tokens (for the definition of "token" below), since they would otherwise be interpreted as a single token. What to say, I don't like it. An ABNF grammar should not require other text interpretation. For example, SIP protocol inherits from HTTP (SIP messages are very similar to HTTP messages) but the ABNF grammar in RFC 3261 (SIP) implies *nothing*. In fact it defines the following elements: STAR =3D SWS "*" SWS ; asterisk SLASH =3D SWS "/" SWS ; slash EQUAL =3D SWS "=3D" SWS ; equal LPAREN =3D SWS "(" SWS ; left parenthesis RPAREN =3D SWS ")" SWS ; right parenthesis RAQUOT =3D ">" SWS ; right angle quote LAQUOT =3D SWS "<"; left angle quote COMMA =3D SWS "," SWS ; comma SEMI =3D SWS ";" SWS ; semicolon COLON =3D SWS ":" SWS ; colon LDQUOT =3D SWS DQUOTE; open double quotation mark RDQUOT =3D DQUOTE SWS ; close double quotation mark and the rest of the grammar use them (in some cases in which LWS is allowed= ). --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 17 02:36: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 8C5EA21F8ACA for ; Wed, 17 Aug 2011 02:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zq4jPHZsau0w for ; Wed, 17 Aug 2011 02:36:12 -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 0E7F021F86BC for ; Wed, 17 Aug 2011 02:36:11 -0700 (PDT) Received: by qyk35 with SMTP id 35so494454qyk.10 for ; Wed, 17 Aug 2011 02:37:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.27.20 with SMTP id g20mr854488qac.178.1313573822427; Wed, 17 Aug 2011 02:37:02 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Wed, 17 Aug 2011 02:37:02 -0700 (PDT) In-Reply-To: <4E4B8ADF.8090208@isode.com> References: <4E4B8ADF.8090208@isode.com> Date: Wed, 17 Aug 2011 11:37:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] draft-10: ABNF error in section 9.1 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, 17 Aug 2011 09:36:12 -0000 2011/8/17 Alexey Melnikov : >> "this section is using ABNF syntax/rules from [RFC2616] including "impli= ed >> *LWS" rule" > > Actually, I've already done this in my copy of -11-to-be. In some aspects, WS draft seems oriented to people with no knowledge in HTTP (or in RFC 2616 more precisely), so I would not rely in references to sections in RFC 2616. I strongly prefer avoiding RFC-2616's "implied *LWS" in websocket draft. Making the ABNF grammar strict is much better for implementors. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 17 02:45: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 6302521F8A95 for ; Wed, 17 Aug 2011 02:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3XGZLn7TFXN for ; Wed, 17 Aug 2011 02:45: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 4696E21F8839 for ; Wed, 17 Aug 2011 02:45:18 -0700 (PDT) Received: by qwc23 with SMTP id 23so550154qwc.31 for ; Wed, 17 Aug 2011 02:46:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.17.212 with SMTP id t20mr916796qaa.228.1313574368738; Wed, 17 Aug 2011 02:46:08 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Wed, 17 Aug 2011 02:46:08 -0700 (PDT) In-Reply-To: <20110816073401.ef1fc80126c74c6c202a919c41c7bb0b.f02db904ba.wbe@email03.secureserver.net> References: <20110816073401.ef1fc80126c74c6c202a919c41c7bb0b.f02db904ba.wbe@email03.secureserver.net> Date: Wed, 17 Aug 2011 11:46:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] "Intermediaries" 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, 17 Aug 2011 09:45:23 -0000 2011/8/16 Bob Gezelter : > A device that seemingly transparently inspects (and possibly interferes > with) the transport stream WITHOUT being the endpoint of the transport > connection is a very different beast. It is hardly a proxy. In the case of SIP protocol, this would be a SIP proxy, which can act on signalling level (by inspecting headers or adding new more) but never at application level (which is carried within SIP request/response body). > A device that terminates a WebSocket protocol connection underlying > transport connection (e.g., TCP link) is most properly referred to as a > "gateway". In a multiplexed context, such a device might also forward > the contained sub-channels to different physical endpoints, functioning > as a traffic director or proxy. In the case of SIP, this would be a B2BUA (a server agent + a client agent). The server agent receives the requests from clients and inspects headers and body (application), and then it behaves as a new client (via the clietn agent) by sending the request (or not) to other location, or maybe by performing a protocol brigde (SIP to SS7 gateway for example). Still I want to know what "an intermediary" is in WebSocket protocol :) --=20 I=C3=B1aki Baz Castillo From len.holgate@gmail.com Wed Aug 17 04:50: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 A65E221F8B2C for ; Wed, 17 Aug 2011 04:50:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vZ-Vnj2Q1s2s for ; Wed, 17 Aug 2011 04:50:28 -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 2256821F8B2F for ; Wed, 17 Aug 2011 04:50:27 -0700 (PDT) Received: by wwf5 with SMTP id 5so597192wwf.13 for ; Wed, 17 Aug 2011 04:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=MxuXNceiq1GXLOCo+kjWURwAntG5VRLfGijATcvljTc=; b=Ra7adH8AwD3MK/polfkH7bCM7jArGoRE3Bk93FaQUfH3m64jdtnTZufsKTWpnXDaHR q5rr/GWd6HFYWnaaDmpb35TzsqLdlq6aOsugVbtkvIEcM9dQ/XLe7yMmXXKXnbavSPmw ZaeY3uTyd3fb4y+FcsGP7sVNwqIEmk5vXLmFc= Received: by 10.216.81.4 with SMTP id l4mr3963392wee.97.1313581876972; Wed, 17 Aug 2011 04:51:16 -0700 (PDT) Received: from Venus ([212.39.11.114]) by mx.google.com with ESMTPS id ga18sm842543wbb.39.2011.08.17.04.51.14 (version=SSLv3 cipher=OTHER); Wed, 17 Aug 2011 04:51:16 -0700 (PDT) From: "Len Holgate" To: "'\"Andy Green \(???\)\"'" , "'Peter Saint-Andre'" References: <4E43A719.50401@warmcat.com><4E440808.5030907@stpeter.im><4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im><4E4AAE3A.7030902@warmcat.com> <4E4AAFDD.6080902@stpeter.im> <4E4ABB28.8020009@warmcat.com> Date: Wed, 17 Aug 2011 12:51:01 +0100 Message-ID: <02d101cc5cd3$f175b620$c90aa8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E4ABB28.8020009@warmcat.com> Thread-Index: AcxcROz2JBugtdPxRuWdi5lum57KygAiPwTg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 17 Aug 2011 11:50:29 -0000 > However because of what has been proposed by others, I am > trying to keep > stuff out of the spec and like it as it is in this area. > It's not going > to yield new text then but try to keep bloat out of the spec. > This is > also a vital part of "moving forward". Fair enough, except that what I was proposing was a change to make it clearer that a message based api is not the only way. The existing wording tends to lead one down a path towards a 'whole message' API which is probably what leads people to think in terms of frame and message limits. If you want to "keep stuff out of the spec" then why not simply remove the comments in section 1.2 that imply that a message based approach is preferable. For your convenience, in my previous message I suggested.... Possibly reworking section 1.2 (especially) "A message is a complete unit of data at an application level, with the expectation that many or most applications implementing this protocol (such as web user agents) provide APIs in terms of sending and receiving messages. The WebSocket message does not necessarily correspond to a particular network layer framing, as a fragmented message may be coalesced, or vice versa, e.g. by an intermediary." And "The WebSocket protocol uses this framing so that specifications that use the WebSocket protocol can expose such connections using an event-based mechanism instead of requiring users of those specifications to implement buffering and piecing together of messages manually." To acknowledge that handling of large messages is most likely best done with a streaming interface rather than a message based interface (or removing the suggestion that the websocket protocol handler will provide complete messages) may mean that people wont forever be misunderstanding the design intentions and suggesting message and/or frame limits or implementing the protocol in such a way that they have inherent hidden limits. Len Holgate http://www.lenholgate.com http://www.serverframework.com From andy@warmcat.com Wed Aug 17 05:12: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 10DA721F861E for ; Wed, 17 Aug 2011 05:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.225 X-Spam-Level: X-Spam-Status: No, score=-2.225 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EubyO9f75le8 for ; Wed, 17 Aug 2011 05:12:07 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 327E421F85CE for ; Wed, 17 Aug 2011 05:12:06 -0700 (PDT) Message-ID: <4E4BB046.9000105@warmcat.com> Date: Wed, 17 Aug 2011 13:12:54 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Len Holgate References: <4E43A719.50401@warmcat.com><4E440808.5030907@stpeter.im><4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im><4E4AAE3A.7030902@warmcat.com> <4E4AAFDD.6080902@stpeter.im> <4E4ABB28.8020009@warmcat.com> <02d101cc5cd3$f175b620$c90aa8c0@Venus> In-Reply-To: <02d101cc5cd3$f175b620$c90aa8c0@Venus> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 17 Aug 2011 12:12:08 -0000 On 08/17/2011 12:51 PM, Somebody in the thread at some point said: >> However because of what has been proposed by others, I am >> trying to keep >> stuff out of the spec and like it as it is in this area. >> It's not going >> to yield new text then but try to keep bloat out of the spec. >> This is >> also a vital part of "moving forward". > > Fair enough, except that what I was proposing was a change to make it > clearer that a message based api is not the only way. The existing wording > tends to lead one down a path towards a 'whole message' API which is > probably what leads people to think in terms of frame and message limits. Sure. > If you want to "keep stuff out of the spec" then why not simply remove the Well, keep needless stuff out of the spec at least. > comments in section 1.2 that imply that a message based approach is > preferable. > > For your convenience, in my previous message I suggested.... > > Possibly reworking section 1.2 (especially) > > "A message is a complete unit of data at an application > level, with the expectation that many or most applications > implementing this protocol (such as web user agents) provide APIs in > terms of sending and receiving messages. The WebSocket message does > not necessarily correspond to a particular network layer framing, as > a fragmented message may be coalesced, or vice versa, e.g. by an > intermediary." > > And > > "The WebSocket protocol uses this framing so that specifications that > use the WebSocket protocol can expose such connections using an > event-based mechanism instead of requiring users of those > specifications to implement buffering and piecing together of > messages manually." The first one seems fine but the second one I am not sure it is capturing the deal with frames. AIUI frames are there to compartmentalize payload more or less arbitrarily in exactly the same way as TCP/IP packets do. The frames being of finite duration allows sharing of the connection resource for other different frame content by interleaving. These events you're talking about can equally well be generated by every packetload of message payload coming if you like, it does not require framing to do it. How about this kind of thing instead: "The websocket protocol uses framing only to allow interleaving of control or other extended frames to share the same connection with finite latency. Similar to how multiple TCP/IP packets may contain streaming payload but the size of packets or how they are fragmented is not predictable and shouldn't be relied on as being received in the same units it was sent, payload frame sizes are subject to manipulation by intermediaries and should just be regarded as more message payload, not as containing payload with meaningful boundaries at the start and end of the frame." > To acknowledge that handling of large messages is most likely best done with > a streaming interface rather than a message based interface (or removing the > suggestion that the websocket protocol handler will provide complete > messages) may mean that people wont forever be misunderstanding the design > intentions and suggesting message and/or frame limits or implementing the > protocol in such a way that they have inherent hidden limits. Right. Maybe it's a good step in that direction to explain received frame extents have no inherent meaning other than how many bytes follow and may be unrelated to transmitted frame extents, particularly may be bigger. -Andy From bruce@callenish.com Wed Aug 17 08:58: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 80C4621F8B08 for ; Wed, 17 Aug 2011 08:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhPAG9o3a4xS for ; Wed, 17 Aug 2011 08:58:07 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 0E85621F8AF0 for ; Wed, 17 Aug 2011 08:58:07 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QtiW5-0002HP-41; Wed, 17 Aug 2011 08:58:53 -0700 Message-ID: <4E4BE545.1030706@callenish.com> Date: Wed, 17 Aug 2011 08:59:01 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E44C106.7020505@warmcat.com> <634914A010D0B943A035D226786325D422BFBFC311@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422BFBFC31D@EXVMBX020-12.exch020.serverdata.net> <4E455919.3080101@callenish.com> <4E4637D0.2030500@warmcat.com> <4E49A895.6000509@callenish.com> <4E4A0396.6060303@warmcat.com> <4E4AE17F.4020807@callenish.com> <4E4B5935.4000804@warmcat.com> In-Reply-To: <4E4B5935.4000804@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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] CONSENSUS CALL / Heartbeat vs keepalive 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, 17 Aug 2011 15:58:07 -0000 On 16/08/2011 11:01 PM, "Andy Green (林安廸)" wrote: > > Alright, knowing your server is dead is a reasonable thing to want. > > There's an issue with this scheme you also have to face, what > constitutes a reasonable max "hogging the channel" fragment size is > dependent on the minimum bandwidth that channel can be expected to > experience. That can vary widely depending on the physical transport > and even dynamically. Believe me, I know. The application, which currently uses two web servers making requests to one another, is already deployed to hundreds of customers networks. > > It is possible to exclude too much. But another way to break it is to > be too lassaiz-faire and include anything until the simplest > explanation of the protocol must include bandwidth estimation, > negotiation of frame sizes and so on which actually can be > eliminated. Actually really good protocols just do the needful once > it's understood what that minimum set is. I don't disagree at all with this sentiment that the protocol should be kept as simple as possible, but I would add the clause "but no simpler". I get that adding a maximum frame size is unnecessary for you. I get that everything can be implemented using the tradeoffs you have chosen. I even get that those choices are good ones for generalized solutions, as proven by the fact that a number of people have opted for the same. But try to understand that not everyone is writing a generalized solution. For those people other tradeoffs can be more desirable. And in those situations, a maximum frame size can greatly aid in interoperability. So even if you don't need it, try to allow for the fact that others may. > > During that discussion, I realized (I think proposed but can't > remember) that incoming traffic of any kind is evidence of life, > meaning you do not need to issue a PING to stimulate incoming traffic > until you did not hear anything from the remote side for some > threshold time. That can be a good solution in some circumstances. It depends on requirements. In my situation, a heartbeat from each instance is rebroadcast to a cluster of nodes, as well as stored in a database so that a UI can display the time of the last heartbeat. If I did that every time a byte was received, the traffic would be ridiculous. If I had a disconnect between the original data and the notifications to the nodes and database then I would have more complication, more code, more places for things to fail. Since fault tolerance and high availability are critical, these would be bad choices in my case. But the point is there are more requirements out there than are dreamt of in your philosophy. A good protocol design would allow each to make their own decisions while still allowing interoperability. From tobias.oberstein@tavendo.de Wed Aug 17 09:04: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 8C53A21F8B4C for ; Wed, 17 Aug 2011 09:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1J7IUbMoAOxt for ; Wed, 17 Aug 2011 09:04:50 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id D563021F8AEE for ; Wed, 17 Aug 2011 09:04:49 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Wed, 17 Aug 2011 09:05:41 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Wed, 17 Aug 2011 09:04:57 -0700 Thread-Topic: WebSockets Test Suite / Browser Status Thread-Index: Acxc92QRIXNauIBYRvyCPqKOXil8Gg== Message-ID: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] WebSockets Test Suite / Browser Status 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, 17 Aug 2011 16:04:50 -0000 Regarding WS test suites for servers and browser status .. Cheers, Tobias 1. Autobahn WebSockets now (0.3.2) includes an automated test suite for both c= lients and servers. http://www.tavendo.de/autobahn/testsuite.html 2. The fixes for Chrome have landed on v15 .. all green now. http://www.tavendo.de/autobahn/testsuite/report/clients/index.html From ferg@caucho.com Wed Aug 17 09:07: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 858E221F85AB for ; Wed, 17 Aug 2011 09:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.389 X-Spam-Level: X-Spam-Status: No, score=-1.389 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5jZAGGvsOv0 for ; Wed, 17 Aug 2011 09:07:30 -0700 (PDT) Received: from nm28.bullet.mail.sp2.yahoo.com (nm28.bullet.mail.sp2.yahoo.com [98.139.91.98]) by ietfa.amsl.com (Postfix) with SMTP id 1ACB921F856C for ; Wed, 17 Aug 2011 09:07:30 -0700 (PDT) Received: from [98.139.91.68] by nm28.bullet.mail.sp2.yahoo.com with NNFMP; 17 Aug 2011 16:08:19 -0000 Received: from [98.139.91.43] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 17 Aug 2011 16:08:19 -0000 Received: from [127.0.0.1] by omp1043.mail.sp2.yahoo.com with NNFMP; 17 Aug 2011 16:08:19 -0000 X-Yahoo-Newman-Id: 5376.53622.bm@omp1043.mail.sp2.yahoo.com Received: (qmail 62504 invoked from network); 17 Aug 2011 16:08:18 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313597298; bh=H5zH1sUw+PJkULsug8U7JoKBkA5IX2w6tUC4F/WNwGs=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=Crat9cFBWFoggXRZmJ6NE3Llbzy68jDlvZUyguAOFQammO+HIy4x4EoEiId0wzHiCFwNs56yhQIdyFgHOpVLfPMVFybx1XbfNLuoGXFav71lUx8sv3kIR/WY4Ns530WnLuibak3QF4FlYDuxdDosohrGfoHGw5k1fYWnI/9efUk= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: BWggsw8VM1kW.OC2StqfmpY1heVcSB8oVgwgmcILu3GngzU DrNiPrH80vkRRaNtLGL5c9Ifn6KSxdgt1TVcNzj77WanlSHwK7Ahvmr02sUx dot6vRuktdMK1mKaOS9doQuS_j6y9bPWqGYuVWMP2HpbdHv9n_NZRcem49lm arICPmmWrOliFpoYrdmReGf6Do7QPY_jW5OJKE3JDbMO.Cjw5weUTKK2YrKo T3..TnuAqhTozcH3tF8xfY1vsyumtrPRr_wTYcZ.G7LjAjQ4UTJoddLs_qKI BKdmAyY_ldNxYpDoLI3yHRQoc8QGZq8KTxRFL2HjTnshbMAmay10LfCrByy5 sPM6EUg8W9AfHIgsurzO.8h0_wjvMb2V80Z_m_czYAENRyQb5UCKk6Y5pvDE O4lGHIc0NkFH9l8HlrtfS.BTYsMIY8XI- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp114.biz.mail.sp1.yahoo.com with SMTP; 17 Aug 2011 09:08:18 -0700 PDT Message-ID: <4E4BE772.5090307@caucho.com> Date: Wed, 17 Aug 2011 09:08:18 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <4E43A719.50401@warmcat.com><4E440808.5030907@stpeter.im><4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im><4E4AAE3A.7030902@warmcat.com> <4E4AAFDD.6080902@stpeter.im> <4E4ABB28.8020009@warmcat.com> <02d101cc5cd3$f175b620$c90aa8c0@Venus> <4E4BB046.9000105@warmcat.com> In-Reply-To: <4E4BB046.9000105@warmcat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 17 Aug 2011 16:07:30 -0000 On 08/17/2011 05:12 AM, "Andy Green (林安廸)" wrote: > On 08/17/2011 12:51 PM, Somebody in the thread at some point said: > > How about this kind of thing instead: > > "The websocket protocol uses framing only to allow interleaving of > control or other extended frames to share the same connection with > finite latency. Similar to how multiple TCP/IP packets may contain > streaming payload but the size of packets or how they are fragmented > is not predictable and shouldn't be relied on as being received in the > same units it was sent, payload frame sizes are subject to > manipulation by intermediaries and should just be regarded as more > message payload, not as containing payload with meaningful boundaries > at the start and end of the frame." Ulg. The only original purpose of frames was to avoid buffering an entire message before sending it. Frames were just for the purposes of fragmentation to allow for fixed-buffer senders, particularly for dynamic messages like serializing JSON. The interleaving capability is a side-benefit of the actual frame design, but it's not the purpose of the framing. (Or at least not the original purpose.) Mux is important, but it's not the reason for framing. At its heart, WebSockets is still about sending messages. -- Scott From gezelter@rlgsc.com Wed Aug 17 11:21: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 00DBF21F8C08 for ; Wed, 17 Aug 2011 11:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lVFO1sGciKou for ; Wed, 17 Aug 2011 11:21:54 -0700 (PDT) Received: from smtpoutwbe02.prod.mesa1.secureserver.net (smtpoutwbe02.prod.mesa1.secureserver.net [208.109.78.113]) by ietfa.amsl.com (Postfix) with SMTP id 1839B21F8BF9 for ; Wed, 17 Aug 2011 11:21:48 -0700 (PDT) Received: (qmail 18024 invoked from network); 17 Aug 2011 18:22:35 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe02.prod.mesa1.secureserver.net with SMTP; 17 Aug 2011 18:22:34 -0000 Received: (qmail 1581 invoked by uid 99); 17 Aug 2011 18:22:34 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 64.134.64.205 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110817112232.ef1fc80126c74c6c202a919c41c7bb0b.dae4e305f6.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "John Tamplin" Date: Wed, 17 Aug 2011 11:22:32 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 17 Aug 2011 18:21:56 -0000 John,=0A=0AFrom this message below, it would appear that you are reading th= e=0Aspecification to describe a protocol where frames within a message are = a=0Amix of text and binary frames, to wit:=0A=0A Message 1 Frame 0 Text= =0A Message 1 Frame 1 Text=0A Message 1 Frame 2 Binary=0A Messag= e 1 (FIN Bit) Frame 3 Text=0A=0AAm I interpreting your comments correctly?= =0A=0A- Bob Gezelter, http://www.rlgsc.com=0A=0A> -------- Original Message= --------=0A> Subject: Re: [hybi] Binary/Text Distinction=0A> From: John Ta= mplin =0A> Date: Tue, August 16, 2011 7:24 am=0A> To: Bob G= ezelter =0A> Cc: Bjoern Hoehrmann , = hybi@ietf.org=0A> =0A> =0A> On Tue, Aug 16, 2011 at 10:21 AM, Bob Gezelter = wrote:=0A> =0A> > My objection to the distinction is t= hat it does not, IMHO, belong in the=0A> > WebSocket protocol, it belongs i= n the next layer above the basic=0A> > WebSocket protocol transport layer.= =0A> =0A> =0A> Then you have to provide some way for JS apps to serialize/d= eserialize=0A> arbitrary mixes of text and binary data to a binary frame to= send in WS. It=0A> might be possible to standardize on such a thing and m= ake sure it is robust=0A> against hostile JS, but given how long WS has bee= n in development it seems=0A> prudent to avoid making such a mechanism a bl= ocker for deploying WS.=0A> =0A> -- =0A> John A. Tamplin=0A> Software Engin= eer (GWT), Google=0A From gezelter@rlgsc.com Wed Aug 17 11:35: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 A86E311E8089 for ; Wed, 17 Aug 2011 11:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QyneygztR7AU for ; Wed, 17 Aug 2011 11:35:32 -0700 (PDT) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id A7DD421F8B61 for ; Wed, 17 Aug 2011 11:35:32 -0700 (PDT) Received: (qmail 22149 invoked from network); 17 Aug 2011 18:36:23 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 17 Aug 2011 18:36:22 -0000 Received: (qmail 24022 invoked by uid 99); 17 Aug 2011 18:36:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 64.134.64.205 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Wed, 17 Aug 2011 11:36:21 -0700 Mime-Version: 1.0 Subject: [hybi] Framing Management Rationale 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, 17 Aug 2011 18:35:33 -0000 The other day, I registered my support for retaining the "Frame Too=0ALarge= " error and including a mechanism to declare maximum and minimum=0Aframe si= zes in each direction for WebSocket protocol connections. This=0Aposting is= my promised rationale on that support.=0A=0AThere have been several recent= comments made in favor of very large=0Aframe sizes. In particular, there w= as one comment suggesting that a=0Asingle huge frame would suffice for the = entirety of a telephone=0Aconversation. The stated goal was assuring perfor= mance by minimizing=0Aoverhead. This was accompanied by a reference to "sen= dfile." Presumably,=0Athe "sendfile" referenced is the LINUX sendfile() (de= scribed in the=0ALINUX man pages at=0Ahttp://www.kernel.org/doc/man-pages/o= nline/pages/man2/sendfile.2.html)=0Aas:=0A=0A "...Because this copying is d= one within the kernel, sendfile() is more=0Aefficient than the combination = of read(2) and write(2), which would=0Arequire transferring data to and fro= m user space."=0A=0AThis description is not directly translatable into a ne= twork context.=0Asendfile() does not eliminate all overhead of the disk fil= e operation,=0Athe man page only describes eliminating the outermost layer:= copying=0Adata to/from the user-mode process. In the network space, this i= s=0Aparticularly misleading. A WebSocket protocol API equivalent of=0Asendf= ile() would also have to do significant processing even while=0Asending an = entire, arbitrary file as a single frame. The frame, and=0Aindeed message o= verhead would not be significant in this case. With all=0Adue respect to th= e writer, such usage is not consistent with good use of=0Athe WebSocket pro= tocol, the underlying transport protocol (presently=0ATCP), or the physical= realities of network communications. It does,=0Ahowever, underscore the im= portance of carefully reviewing protocol=0Aproposals in full detail and dep= th. =0A=0AAdditionally, disk storage is not real-time telephony. A real-tim= e=0Aapplication (e.g., telephony) has two requirements: fidelity and minima= l=0Alatency. These goals are not compatible with large frame sizes. On the= =0Acontrary, relatively small frame and message sizes are best choices.=0A= =0AOf course, one can always circumvent framing by processing data as it=0A= comes in, by parsing the payload incrementally, and ignoring all of the=0Af= eatures of protocol-based framing with ones locally developed framing.=0ATh= is is effectively a bare TCP socket without protocol. Using the=0AWebSocket= protocol to implement such an approach is eliminating the=0AWebSocket prot= ocol from the operation in all but name, leaving what is=0Ain effect a bare= TCP connection with the extra overhead of the=0AWebSockets API (while not = infinite, extended duration frames obliterate=0Athe utility of PING/PONG an= d any future control extensions). Also, the=0Aability of the underlying net= work stack (e.g., TCP) to accept continuous=0Adata in the face of network c= onnectivity events is limited and will=0Afurther cause problems.=0A =0AIf s= tack traversal overhead is a major performance problem, the solution=0Alies= in modifications to the API implementation to permit queuing of=0Amultiple= records with a single API call (or upcall to the networking=0Astack), a te= chnique known as "blocking", which has been well-known in=0Acomputing since= the 1950=E2=80=99s.=0A=0AIndisputably, very small frame sizes sacrifice so= me efficiency; payload=0Ais small relative to overhead. Increasing frame si= ze provides space for=0Alarger payloads; dramatically increasing efficienc= y. However, the=0Aincrease in efficiency lessens in importance exponentiall= y as the frame=0Asize increases: 12 bytes of overhead/frame is 10% of a 128= -byte frame,=0Ait is less than 0.1% of a 12,800 (<2**14) byte frame. "Bandw= idth=0AEfficiency" is simply not a compelling argument for frame sizes in= =0Aexcess of 2**16. (The "Jumbo" frames on high-speed CSMA/CD networks=0A[e= .g., gigabit Ethernet] are an entirely different issue. They are used=0Anot= for efficiency at high speeds, but rather are required to maintain=0Athe i= ntegrity of the CSMA/CD arbitration scheme over the physical=0Anetwork.)=0A= =0AA simple review of the realities of transmitting data clearly shows that= =0Aany application where a 0.01% loss of performance is unacceptable is an= =0Aapplication that is simply waiting to fail. Basic queuing theory is=0Acl= ear: a 0.01% safety margin is far from adequate to allow for any=0Anon-uni= form behavior in the underlying transport layers. =0A=0AWebSocket protocol = is not a standalone protocol. Rather, the WebSocket=0Aprotocol is effective= ly a higher-level transport protocol, presently=0Alayered on a TCP/IP base.= Both protocols must be considered when=0Aassessing decisions such as frame= sizes. =0A=0AThe vision of using a "sendfile"-like mega-frame to enable ul= tra-low=0Aoverhead is a chimera for many different reasons. Simply put, the= re is=0Atremendous gain from the initial steps to increase frame size, howe= ver,=0Ain the end, the efficiency gained for each doubling of frame size is= =0Ahalf of the gain of the preceding step.=0A=0AThe related question is tha= t of frame size limits, and how they should=0Abe handled by the WebSocket p= rotocol. The operative questions are: What=0Aare the use cases of the WebSo= cket protocol? How do those use cases=0Arelate to decisions taken in the de= sign of other protocols (e.g., HTTP,=0ATCP)?=0A=0AWebSocket protocol connec= tions differ from HTTP connections, in that the=0Amajority of HTTP connecti= ons are limited in duration. By contrast, the=0AWebSocket protocol is inten= ded to provide a low-overhead facility for=0Acommunications in support of i= nteractive web applications. It is=0Areasonable to presume that WebSocket p= rotocol connections will have=0Alifetimes far longer than HTTP connections.= =0A=0AThe WebSocket protocol also enters a world different than that which= =0Agave rise to TCP. The growing importance of mobile and un-tethered=0Adev= ices raises the question of how protocol design changes affect=0Aperformanc= e and usability in a network context when the underlying=0Anetwork changes = during the life of a connection. =0A=0AWhile TCP provides a stream-interfac= e seemingly unconnected with the=0Aunderlying inherent packetization of IP,= the stream interface is an=0Aintellectual illusion of convenience. Perform= ance and network efficiency=0Aare inexorably linked to how the TCP data str= eam fits within underlying=0AIP packets. This phenomenon is even more famil= iar to those who have used=0Amessage-oriented protocols (e.g., DECnet=E2=80= =99s NSP). Simply put, if a=0Amessage fits within a single underlying packe= t, it will be far more=0Aefficient than a message that requires two packets= . While this may=0Aappear irrelevant when messages span many packets, it re= mains=0Asignificant in the aggregate. It is particularly significant when t= he=0Aindividual messages exchanged approximate the payload sizes of the=0Au= nderlying packets, when protocol overhead is included. In those cases,=0Ath= e removing a single byte, or a handful of bytes from a message can=0Anearly= double throughput.=0A=0AFrame-to-frame size variations are a also have sig= nificant potential to=0Acreate severe performance and resource problems. Bu= ffer allocation is=0Aone of the most costly operations in an operating syst= em=E2=80=99s repertoire.=0AConstant allocations/deallocation of varying siz= e memory blocks often=0Aleads to significant overhead processing and memory= pool fragmentation.=0AIt is true that the buffers in question reside in us= er memory space, and=0Aare managed by the JavaScript run-time environment (= at least when the=0Aintegral JavaScript WebSockets API is in use). However,= there are still=0Aissues. Garbage collection is one of the more expensive = operations, and=0Amemory pool fragmentation leads to increased virtual size= , which over=0Atime leads to resource shortages. Continuously varying frame= sizes is=0Anot likely to be an efficiency improvement in most cases, the r= eduction=0Ain frame overhead not withstanding. =0A=0AIt is for this reason = that I favor a dynamic adjustment mechanism for=0Aframe size within the Web= Socket protocol. Particularly with mobile=0Adevices, which may wander repea= tedly between underlying networks (e.g.,=0AGSM and WiFi), the ability to ad= just flow control configuration without=0Aneed to disrupt ongoing connectio= ns is an important capability.=0A=0ASuch an approach provides a facility th= at can also be used to adjust for=0Aasymmetrical bandwidth or performance b= etween the different dataflow=0Adirections.=0A=0AI will draft a proposal fo= r such a scheme and put it on the mailing=0Alist. Obviously, I will be happ= y to discuss the above.=0A=0A From jat@google.com Wed Aug 17 11:37: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 F3A9311E8089 for ; Wed, 17 Aug 2011 11:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.936 X-Spam-Level: X-Spam-Status: No, score=-105.936 tagged_above=-999 required=5 tests=[AWL=0.040, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zk6YAKEz4yyw for ; Wed, 17 Aug 2011 11:37:51 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BA06C11E8090 for ; Wed, 17 Aug 2011 11:37:49 -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 p7HIceaL027862 for ; Wed, 17 Aug 2011 11:38:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313606320; bh=3n6nBzp2YKE3GB+LIk2DOkaIeOA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=GThhs2uaqEQlxPhzZMfaui01x6UkO+9g6CJzsebzl0AmzuoUfWU9dUwBmbn2i+Cb8 zfb8Clkzu+K5acShI0gNA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=nImgdk3ll6Urax/6u8tXbgo2OyJZkAma9CVdUTNCf7vY22Stt9T2vDc1Ic5/y7Y16 5tbddFEzcuFY0T2UJEecw== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by hpaq7.eem.corp.google.com with ESMTP id p7HIbS1Q016400 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 17 Aug 2011 11:38:39 -0700 Received: by ywo7 with SMTP id 7so1317861ywo.39 for ; Wed, 17 Aug 2011 11:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=jzKLWZvf+EdCxABnGWN3bYDYwKZ9j0PF9fCok8fWd9Y=; b=nMFnqc9P6Q0Bk4rpZMf6JQJ02W3m3iGa8W+K1dgOR/0iZSwzEEnZJITf5Ed/00pFVV xFG2JUByFUx/Ikol1Czw== Received: by 10.151.118.20 with SMTP id v20mr1580462ybm.401.1313606319282; Wed, 17 Aug 2011 11:38:39 -0700 (PDT) Received: by 10.151.118.20 with SMTP id v20mr1580452ybm.401.1313606319117; Wed, 17 Aug 2011 11:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Wed, 17 Aug 2011 11:38:19 -0700 (PDT) In-Reply-To: <20110817112232.ef1fc80126c74c6c202a919c41c7bb0b.dae4e305f6.wbe@email03.secureserver.net> References: <20110817112232.ef1fc80126c74c6c202a919c41c7bb0b.dae4e305f6.wbe@email03.secureserver.net> From: John Tamplin Date: Wed, 17 Aug 2011 14:38:19 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=001e680f09fc06980604aab7ce74 X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 17 Aug 2011 18:37:52 -0000 --001e680f09fc06980604aab7ce74 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 17, 2011 at 2:22 PM, Bob Gezelter wrote: > From this message below, it would appear that you are reading the > specification to describe a protocol where frames within a message are a > mix of text and binary frames, to wit: > > Message 1 Frame 0 Text > Message 1 Frame 1 Text > Message 1 Frame 2 Binary > Message 1 (FIN Bit) Frame 3 Text > > Am I interpreting your comments correctly? No, message 1 might be binary and message 2 might be text. Within a message, the opcode is only on the first frame, so all frames of one message must be of the same type. -- John A. Tamplin Software Engineer (GWT), Google --001e680f09fc06980604aab7ce74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 17, 2011 at 2:22 PM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
>From this message below, it would appear that you are reading the
specification to describe a protocol where frames within a message are a mix of text and binary frames, to wit:

=C2=A0 =C2=A0Message 1 Frame 0 =C2=A0Text
=C2=A0 =C2=A0Message 1 Frame 1 =C2=A0Text
=C2=A0 =C2=A0Message 1 Frame 2 =C2=A0Binary
=C2=A0 =C2=A0Message 1 (FIN Bit) Frame 3 Text

Am I interpreting your comments correctly?

= No, message 1 might be binary and message 2 might be text. =C2=A0Within a m= essage, the opcode is only on the first frame, so all frames of one message= must be of the same type.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--001e680f09fc06980604aab7ce74-- From gezelter@rlgsc.com Wed Aug 17 11:43: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 699EB21F8B25 for ; Wed, 17 Aug 2011 11:43:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCQvW3RCM3yE for ; Wed, 17 Aug 2011 11:43:57 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id BD40521F8B10 for ; Wed, 17 Aug 2011 11:43:57 -0700 (PDT) Received: (qmail 11574 invoked from network); 17 Aug 2011 18:44:49 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 17 Aug 2011 18:44:48 -0000 Received: (qmail 31052 invoked by uid 99); 17 Aug 2011 18:44:48 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 64.134.64.205 User-Agent: Web-Based Email 5.5.15 Message-Id: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "John Tamplin" Date: Wed, 17 Aug 2011 11:44:45 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 17 Aug 2011 18:43:58 -0000 John,=0A=0AOk, I mis-read what you had written. However, you envision a con= nection=0Awhere some messages will be text, and other messages will be bina= ry, to=0Awit:=0A=0A Message 1 (Text)=0A Message 2 (Text)=0A Message 3= (Binary)=0A Message 4 (Text)=0A=0ACorrect?=0A=0A- Bob Gezelter, http://w= ww.rlgsc.com=0A=0A> -------- Original Message --------=0A> Subject: Re: [hy= bi] Binary/Text Distinction=0A> From: John Tamplin =0A> Dat= e: Wed, August 17, 2011 11:38 am=0A> To: Bob Gezelter = =0A> Cc: Bjoern Hoehrmann , hybi@ietf.org=0A> =0A> =0A> = On Wed, Aug 17, 2011 at 2:22 PM, Bob Gezelter wrote:= =0A> =0A> > From this message below, it would appear that you are reading t= he=0A> > specification to describe a protocol where frames within a message= are a=0A> > mix of text and binary frames, to wit:=0A> >=0A> > Message = 1 Frame 0 Text=0A> > Message 1 Frame 1 Text=0A> > Message 1 Frame 2= Binary=0A> > Message 1 (FIN Bit) Frame 3 Text=0A> >=0A> > Am I interpr= eting your comments correctly?=0A> =0A> =0A> No, message 1 might be binary = and message 2 might be text. Within a=0A> message, the opcode is only on t= he first frame, so all frames of one message=0A> must be of the same type.= =0A> =0A> -- =0A> John A. Tamplin=0A> Software Engineer (GWT), Google=0A From jat@google.com Wed Aug 17 11:49: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 BEEA121F8B3A for ; Wed, 17 Aug 2011 11:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.939 X-Spam-Level: X-Spam-Status: No, score=-105.939 tagged_above=-999 required=5 tests=[AWL=0.037, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mo6ZxUEdWnuF for ; Wed, 17 Aug 2011 11:49:26 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id F26BC21F8B10 for ; Wed, 17 Aug 2011 11:49:25 -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 p7HIoGP3002568 for ; Wed, 17 Aug 2011 11:50:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313607017; bh=dRkKEHWPYWtgw+IKNndbNIdFfCg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ukp5kJBHLYj3xmSFQ1ECC58SEkUtkLX3MhIAFYYFcDIutAGPQnd4p9/B78Fkx1Y4f ZfXcO5pWYoWP0RjlsyMtA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=TKXsCL1pjwHnFOeZ1uk9eQDc/wtdBjIXNh9dHtpIpt6PwSS/YvW0WVDv0WilpqzBY E/3rXNGAE9Gv1zf8Xxfzg== Received: from yie30 (yie30.prod.google.com [10.243.66.30]) by wpaz37.hot.corp.google.com with ESMTP id p7HIoBfJ007562 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 17 Aug 2011 11:50:15 -0700 Received: by yie30 with SMTP id 30so1149753yie.5 for ; Wed, 17 Aug 2011 11:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=WY2mVrXCvmI4uhiqivJvxeEmAmYZ2SCS/WK56e11bqI=; b=UhP7sVyefvf5l+RdlcCby9EWiE8phTtDJqQLrdIyxuBECRBy3OnKD+ZbB5Vxom3EJk 3UjLG+bteuWviF6KDxdg== Received: by 10.151.13.11 with SMTP id q11mr1565150ybi.173.1313607011262; Wed, 17 Aug 2011 11:50:11 -0700 (PDT) Received: by 10.151.13.11 with SMTP id q11mr1565144ybi.173.1313607011128; Wed, 17 Aug 2011 11:50:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Wed, 17 Aug 2011 11:49:50 -0700 (PDT) In-Reply-To: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> From: John Tamplin Date: Wed, 17 Aug 2011 14:49:50 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=000e0cd6a93e45d58404aab7f772 X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 17 Aug 2011 18:49:26 -0000 --000e0cd6a93e45d58404aab7f772 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 17, 2011 at 2:44 PM, Bob Gezelter wrote: > Ok, I mis-read what you had written. However, you envision a connection > where some messages will be text, and other messages will be binary, to > wit: > > Message 1 (Text) > Message 2 (Text) > Message 3 (Binary) > Message 4 (Text) > > Correct? Yes. Consider a hypothetical chat app: most messages are JSON-encoded chat data, status notifies, etc file transfers are done as binary If the connection has to be one or the other, then obviously it has to be binary, which means JS needs some way to encode its text as binary so it can be serialized into a combined message, and a way to extract UTF8 text from a piece of a binary message. That can certainly be done, but that would require a lot more effort crossing multiple groups to make that work. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd6a93e45d58404aab7f772 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 17, 2011 at 2:44 PM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
Ok, I mis-read what you had written. However, you envision a connection
where some messages will be text, and other messages will be binary, to
wit:

=C2=A0 Message 1 (Text)
=C2=A0 Message 2 (Text)
=C2=A0 Message 3 (Binary)
=C2=A0 Message 4 (Text)

Correct?

Yes. =C2=A0Consider a hypothetical= chat app:

most messages are JSON-encoded chat dat= a, status notifies, etc
file transfers are done as binary

If the connection has to be one or the other, then obviously= it has to be binary, which means JS needs some way to encode its text as b= inary so it can be serialized into a combined message, and a way to extract= UTF8 text from a piece of a binary message.

That can certainly be done, but that would require a lo= t more effort crossing multiple groups to make that work.
<= br>
--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd6a93e45d58404aab7f772-- From jat@google.com Wed Aug 17 12:11: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 52AB021F8B18 for ; Wed, 17 Aug 2011 12:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.307 X-Spam-Level: X-Spam-Status: No, score=-105.307 tagged_above=-999 required=5 tests=[AWL=-0.531, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cposi-yr9bdL for ; Wed, 17 Aug 2011 12:11:35 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id CFEC321F86C0 for ; Wed, 17 Aug 2011 12:11:16 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7HJC8sq017666 for ; Wed, 17 Aug 2011 12:12:08 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313608328; bh=SFnlWSDPzhcZEpAFYK6eQqpAyOU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dsVT7vB20Sb36ycRvnDr7GBGJ/qwQqEi26UC5y2p+t6Jk8+ietOuEpmisGcfzV8UR u0AswdMebY/8qs/UBRbKg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=pru6XW/bwPNpv8Bt+hfeNFO1d5Y0jEK045x5S41iGbfhtBj9M/fR+yujwwVDCdc2S oCbRR4lmg/FZxGk9DllCQ== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by hpaq3.eem.corp.google.com with ESMTP id p7HJBeie017761 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 17 Aug 2011 12:12:06 -0700 Received: by gyg4 with SMTP id 4so974485gyg.6 for ; Wed, 17 Aug 2011 12:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M7PvmgotIlvm8bN6CNd0K8yDeY0Ab6R2aPXjeNjkHMU=; b=jXUJ6aRKavDfJK6Z9B2I3u9YZ51CGN8jetnGOdjl80SHYK4xkAPVwQeOvQbhgGVr1N ukMnErNI8H3B4Ek1bO0Q== Received: by 10.151.25.12 with SMTP id c12mr1543998ybj.116.1313608326288; Wed, 17 Aug 2011 12:12:06 -0700 (PDT) Received: by 10.151.25.12 with SMTP id c12mr1543993ybj.116.1313608326126; Wed, 17 Aug 2011 12:12:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Wed, 17 Aug 2011 12:11:46 -0700 (PDT) In-Reply-To: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> From: John Tamplin Date: Wed, 17 Aug 2011 15:11:46 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=000e0cd293c2a71b1604aab84574 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Framing Management Rationale 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, 17 Aug 2011 19:11:37 -0000 --000e0cd293c2a71b1604aab84574 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 17, 2011 at 2:36 PM, Bob Gezelter wrote: > The stated goal was assuring performance by minimizing > overhead. This was accompanied by a reference to "sendfile." Presumably, > the "sendfile" referenced is the LINUX sendfile() (described in the > LINUX man pages at > http://www.kernel.org/doc/man-pages/online/pages/man2/sendfile.2.html) > as: > > "...Because this copying is done within the kernel, sendfile() is more > efficient than the combination of read(2) and write(2), which would > require transferring data to and from user space." > > This description is not directly translatable into a network context. > sendfile() does not eliminate all overhead of the disk file operation, > the man page only describes eliminating the outermost layer: copying > data to/from the user-mode process. In the network space, this is > particularly misleading. A WebSocket protocol API equivalent of > sendfile() would also have to do significant processing even while > sending an entire, arbitrary file as a single frame. The frame, and > indeed message overhead would not be significant in this case. With all > due respect to the writer, such usage is not consistent with good use of > the WebSocket protocol, the underlying transport protocol (presently > TCP), or the physical realities of network communications. It does, > however, underscore the importance of carefully reviewing protocol > proposals in full detail and depth. > It isn't just the overhead, but that the server can "fire and forget" the response. For example (ignoring error handling): void sendFileAsMessage(int sock, char* fname) { int fd = open(fname, O_RDONLY); size_t len = getFileLength(fd); writeWSHeader(sock, len, WS_BINARY); sendfile(sock, fd, NULL, len); close(fd); } and then you are done with that file and don't need to do anything further to have it sent. Obviously, masking breaks this on the client->server direction, but it seems likely that this would only be used on the server anyway. Note I was not the one advocating this use case as the reason for supporting 2^63-byte frames - just explaining the rationale as it was given. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd293c2a71b1604aab84574 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 17, 2011 at 2:36 PM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
The stated goal was assuring performance by minimizing
overhead. This was accompanied by a reference to "sendfile." Pres= umably,
the "sendfile" referenced is the LINUX sendfile() (described in t= he
LINUX man pages at
http://www.kernel.org/doc/man-pages/online/pages/m= an2/sendfile.2.html)
as:

=C2=A0"...Because this copying is done within the kernel, sendfile() i= s more
efficient than the combination of read(2) and write(2), which would
require transferring data to and from user space."

This description is not directly translatable into a network context.
sendfile() does not eliminate all overhead of the disk file operation,
the man page only describes eliminating the outermost layer: copying
data to/from the user-mode process. In the network space, this is
particularly misleading. A WebSocket protocol API equivalent of
sendfile() would also have to do significant processing even while
sending an entire, arbitrary file as a single frame. The frame, and
indeed message overhead would not be significant in this case. With all
due respect to the writer, such usage is not consistent with good use of the WebSocket protocol, the underlying transport protocol (presently
TCP), or the physical realities of network communications. It does,
however, underscore the importance of carefully reviewing protocol
proposals in full detail and depth.

It = isn't just the overhead, but that the server can "fire and forget&= quot; the response. =C2=A0For example (ignoring error handling):

void sendFileAsMessage(int sock, char* fname) {
= =C2=A0 int fd =3D open(fname, O_RDONLY);
=C2=A0 size_t len =3D ge= tFileLength(fd);
=C2=A0 writeWSHeader(sock, len, WS_BINARY);
=C2=A0 sendfile(sock, fd, NULL, len);
=C2=A0 close(fd);
}

and then you ar= e done with that file and don't need to do anything further to have it = sent. =C2=A0Obviously, masking breaks this on the client->server directi= on, but it seems likely that this would only be used on the server anyway.<= /div>

Note I was not the one advocating this use case as the = reason for supporting 2^63-byte frames - just explaining the rationale as i= t was given.

--
John A. Tamplin
Software E= ngineer (GWT), Google
--000e0cd293c2a71b1604aab84574-- From andy@warmcat.com Wed Aug 17 14:15: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 B32A121F8C13 for ; Wed, 17 Aug 2011 14:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.227 X-Spam-Level: X-Spam-Status: No, score=-2.227 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruXbxLAh73RG for ; Wed, 17 Aug 2011 14:15:08 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9D81F21F8C11 for ; Wed, 17 Aug 2011 14:15:07 -0700 (PDT) Message-ID: <4E4C2F8B.3070001@warmcat.com> Date: Wed, 17 Aug 2011 22:15:55 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110720 Thunderbird/5.0 MIME-Version: 1.0 To: Scott Ferguson References: <4E43A719.50401@warmcat.com><4E440808.5030907@stpeter.im><4E44C106.7020505@warmcat.com> <4E4AABC1.8040509@stpeter.im><4E4AAE3A.7030902@warmcat.com> <4E4AAFDD.6080902@stpeter.im> <4E4ABB28.8020009@warmcat.com> <02d101cc5cd3$f175b620$c90aa8c0@Venus> <4E4BB046.9000105@warmcat.com> <4E4BE772.5090307@caucho.com> In-Reply-To: <4E4BE772.5090307@caucho.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL / Resource limited implementations 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, 17 Aug 2011 21:15:08 -0000 On 08/17/2011 05:08 PM, Somebody in the thread at some point said: > On 08/17/2011 05:12 AM, "Andy Green (林安廸)" wrote: >> On 08/17/2011 12:51 PM, Somebody in the thread at some point said: >> >> How about this kind of thing instead: >> >> "The websocket protocol uses framing only to allow interleaving of >> control or other extended frames to share the same connection with >> finite latency. Similar to how multiple TCP/IP packets may contain >> streaming payload but the size of packets or how they are fragmented >> is not predictable and shouldn't be relied on as being received in the >> same units it was sent, payload frame sizes are subject to >> manipulation by intermediaries and should just be regarded as more >> message payload, not as containing payload with meaningful boundaries >> at the start and end of the frame." > > Ulg. > > The only original purpose of frames was to avoid buffering an entire > message before sending it. Frames were just for the purposes of > fragmentation to allow for fixed-buffer senders, particularly for > dynamic messages like serializing JSON. Fixed buffer senders continue to be fine. > The interleaving capability is a side-benefit of the actual frame > design, but it's not the purpose of the framing. (Or at least not the > original purpose.) Mux is important, but it's not the reason for framing. > > At its heart, WebSockets is still about sending messages. Sure but you can't send a message without sending at least one frame. Whatever the "original purpose" the issue Len and others have pointed out is we seem to have engendered implementations which are limited to fit one messages in one frame because of the potential for huge frame sizes, or fragile implementations which believe they should buffer a frame because it has some unitary meaning when they actually can't bank on that. Then we get these threads with people being defensive about their implementation. It's going to help if we sum up the reasoning and a good way for implementers to understand what the framing is doing and how to treat it I think. If there's anything wrong or can be improved with what I suggested I'm glad to hear it. -Andy From jmason@rim.com Wed Aug 17 14:25:47 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 1D3CB21F880C for ; Wed, 17 Aug 2011 14:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Va6H6WO9KSsU for ; Wed, 17 Aug 2011 14:25:46 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1A7FE21F8802 for ; Wed, 17 Aug 2011 14:25:45 -0700 (PDT) X-AuditID: 0a412830-b7c06ae0000054c0-4c-4e4c32043bb9 Received: from XHT105CNC.rim.net (xht105cnc.rim.net [10.65.12.216]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 62.3A.21696.4023C4E4; Wed, 17 Aug 2011 21:26:28 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT105CNC.rim.net ([fe80::24dd:699b:a19e:2bcc%11]) with mapi; Wed, 17 Aug 2011 17:26:36 -0400 From: Joe Mason To: =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Wed, 17 Aug 2011 17:26:35 -0400 Thread-Topic: [hybi] Test suite for WebSocket servers? Thread-Index: AcxcuXi5F0zMaPU8Rya/siUxQ/d/6wAatIDw Message-ID: References: <4E4B7938.80504@warmcat.com> <4E4B7EBA.4030103@warmcat.com> In-Reply-To: <4E4B7EBA.4030103@warmcat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsXC5chzQ5fFyMfP4MRlWYvNk6awWbx/uY3J Yvo+Gwdmj3MN79k9liz5yeSx+clp1gDmqAZGm8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE 5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpec n5KZl26r5Bnsr2thYWqpa6hkp4sEEv5xZ8w6rVlwh7Ni8ayzTA2Mezi7GDk5JARMJOb/vMwE YYtJXLi3nq2LkYtDSKCXSeLlvFOMEM5iRomGS0/YQarYBBQkPh9+ANYhIlAvcff1bzYQm1lA WeLqsRUsIDaLgKrEzO2fGUFsYQFTiebtvVD1ZhIXWqaxQthGEj+nfwObySvgIXHi8HZWiGXX GSWOnVwNNohTQFvi2Y9dYM2MQOd9P7WGCWKZuMStJ/OhzhaQWLLnPDOELSrx8vE/Voh6UYk7 7euBjuAAqteUWL9LH6JVUWJK90OovYISJ2c+YZnAKDYLydRZCB2zkHTMQtKxgJFlFaNgbkax gZlhcl6yXlFmrl5easkmRnDa0DDYwThhr9YhRgEORiUeXk5BHz8h1sSy4srcQ4wSHMxKIrxt CkAh3pTEyqrUovz4otKc1OJDjBbAgJvILMWdnA9MaXkl8cYGBigcJXHeMGkDPyGBdGA6yk5N LUgtgmll4uCUamDUib2ZJ/J4osOPpW3haXs/N29dHxD3XLvye/uj41fOzJdnM/81efIRaaZd Oxb/25zjxn3xdMPG2Pr3SoeNDu2zb9Vbq3Qp8PsE1ZMVs7nFdjlE7fBc0FJV9fOH0anCWAn+ SjGxQpVNcw/eCGi/6nSVid+mtU+h+OA8lUiWEPMJhnFXXJt/BigrsRRnJBpqMRcVJwIAZL5h cDQDAAA= Cc: "hybi@ietf.org" Subject: Re: [hybi] Test suite for WebSocket servers? 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, 17 Aug 2011 21:25:47 -0000 aHR0cDovL3d3dy50YXZlbmRvLmRlL2F1dG9iYWhuL3Rlc3RzdWl0ZS5odG1sIGluY2x1ZGVz IGEgc2VydmVyIHRlc3Qgc3VpdGUgdGhhdCBpbmNsdWRlcyBGSU4vb3Bjb2RlIHRlc3RzLCBi dXQgbm90IHRlc3RzIGZvciB2YWxpZCBVVEYtOC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpoeWJpLWJv dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiAiQW5keSBHcmVlbiAoPz8/KSINCj4g U2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMTcsIDIwMTEgNDo0MiBBTQ0KPiBUbzogScOxYWtp IEJheiBDYXN0aWxsbw0KPiBDYzogaHliaUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW2h5 YmldIFRlc3Qgc3VpdGUgZm9yIFdlYlNvY2tldCBzZXJ2ZXJzPw0KPiANCj4gT24gMDgvMTcv MjAxMSAwOToyNSBBTSwgU29tZWJvZHkgaW4gdGhlIHRocmVhZCBhdCBzb21lIHBvaW50IHNh aWQ6DQo+IA0KPiA+IFdlbGwsIEkgbWVhbiBhcHBsaWNhdGlvbiBhZ25vc3RpYyB0ZXN0cywg bGlrZSBzZW5kaW5nIGludmFsaWQNCj4gPiBGSU4vb3Bjb2RlIGFuZCBleHBlY3RpbmcgYSBy ZW1vdGUgY29ubmVjdGlvbiBjbG9zZSwgb3Igc2VuZGluZw0KPiA+IG9wY29kZT0xIChVVEYt OCB0ZXh0KSBhbmQgc2VuZGluZyBpbnZhbGlkIFVURi04IGluIHRoZSBhcHBsaWNhdGlvbg0K PiA+IHBheWxvYWQuDQo+IA0KPiBUaGF0J3Mgbm90IGEgYmFkIGlkZWEgYXQgYWxsLg0KPiAN Cj4gLUFuZHkNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBoeWJpIG1haWxpbmcgbGlzdA0KPiBoeWJpQGlldGYub3JnDQo+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaHliaQ0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRz KSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0 ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1j bGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBu b24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkg YW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVk LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxl YXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGlu Zm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJp YnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRl bmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwu DQo= From tobias.oberstein@tavendo.de Wed Aug 17 16:43: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 6847B11E8099 for ; Wed, 17 Aug 2011 16:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=-0.367, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AHxpJJVil1dC for ; Wed, 17 Aug 2011 16:43:38 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 652E311E807F for ; Wed, 17 Aug 2011 16:43:38 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Wed, 17 Aug 2011 16:44:30 -0700 From: Tobias Oberstein To: Joe Mason , "andy@warmcat.com" , =?iso-8859-1?Q?I=F1aki_Castillo?= Date: Wed, 17 Aug 2011 16:44:28 -0700 Thread-Topic: [hybi] Test suite for WebSocket servers? Thread-Index: AcxcuXi5F0zMaPU8Rya/siUxQ/d/6wAatIDwAATT5GM= Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_CA721EFC4964tobiasobersteintavendode_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Test suite for WebSocket servers? 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, 17 Aug 2011 23:43:39 -0000 --_000_CA721EFC4964tobiasobersteintavendode_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yep, there are only 3 test cases in UTF-8 handling currently. One of those caught 1 (fixed) bug in Chrome regarding UTF-8 handling. There should be more of course .. what exactly should be tested? i.e. here is a list a post of Greg some time ago: * UTF-8 Text 0000-007f: Send/receive text message with characters in code point range U+0000 to U+007F * UTF-8 Text 0080-07ff: Send/receive text message with characters in code point range U+0080 to U+07FF * UTF-8 Text 0800-ffff: Send/receive text message with characters in code point range U+0800 to U+FFFF * UTF-8 Text 010000-10ffff: Send/receive text message with characters in code point range U+010000 to U+10FFFF * Illegal bytes UTF-8: Send message with invalid UTF-8 byte sequence. Verify message is not received. * Illegal codes UTF-8: Send message with invalid UTF-8 code points. Verify message is not received. http://www.ietf.org/mail-archive/web/hybi/current/msg07975.html http://www.ietf.org/mail-archive/web/hybi/current/msg07995.html Is it possible to generate invalid code points / byte sequences _exhaustively_? How? On 17.08.11 23:26, "Joe Mason" wrote: http://www.tavendo.de/autobahn/testsuite.html includes a server test suite = that includes FIN/opcode tests, but not tests for valid UTF-8. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > "Andy Green (???)" > Sent: Wednesday, August 17, 2011 4:42 AM > To: I=F1aki Baz Castillo > Cc: hybi@ietf.org > Subject: Re: [hybi] Test suite for WebSocket servers? > > On 08/17/2011 09:25 AM, Somebody in the thread at some point said: > > > Well, I mean application agnostic tests, like sending invalid > > FIN/opcode and expecting a remote connection close, or sending > > opcode=3D1 (UTF-8 text) and sending invalid UTF-8 in the application > > payload. > > That's not a bad idea at all. > > -Andy > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful. _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi --_000_CA721EFC4964tobiasobersteintavendode_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [hybi] Test suite for WebSocket servers? Yep, there are only 3 test cases in UTF-8 handling currently.
One of those caught 1 (fixed) bug in Chrome regarding UTF-8 handling.
There should be more of course .. what exactly should be tested?

i.e. here is a list a post of Greg some time ago:

* UTF-8 Text 0000-007f: Send/receive text message with characters in
code point range  U+0000 to U+007F
* UTF-8 Text 0080-07ff: Send/receive text message with characters in
code point range  U+0080 to U+07FF
* UTF-8 Text 0800-ffff: Send/receive text message with characters in
code point range  U+0800 to U+FFFF
* UTF-8 Text 010000-10ffff: Send/receive text message with characters
in code point range  U+010000 to U+10FFFF
* Illegal bytes UTF-8: Send message with invalid UTF-8 byte sequence.
Verify message is not received.
* Illegal codes UTF-8: Send message with invalid UTF-8 code points.
Verify message is not received.

http://www.ietf.org/mail-archive/web/hybi/current/msg07975.html
http://www.ietf.org/mail-archive/web/hybi/current/msg07995.html

Is it possible to generate invalid code points / byte sequences
_exhaustively_? How?


On 17.08.11 23:26, "Joe Mason" <jma= son@rim.com> wrote:

http://www.tavendo.de/autobahn/testsuite.html includes a= server test suite that includes FIN/opcode tests, but not tests for valid = UTF-8.

> -----Original Message-----
> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On = Behalf Of
> "Andy Green (???)"
> Sent: Wednesday, August 17, 2011 4:42 AM
> To: Iñaki Baz Castillo
> Cc: hybi@ietf.org
> Subject: Re: [hybi] Test suite for WebSocket servers?
>
> On 08/17/2011 09:25 AM, Somebody in the thread at some point said:
>
> > Well, I mean application agnostic tests, like sending invalid
> > FIN/opcode and expecting a remote connection close, or sending > > opcode=3D1 (UTF-8 text) and sending invalid UTF-8 in the applicat= ion
> > payload.
>
> That's not a bad idea at all.
>
> -Andy
>
>
> _______________________________________________
> hybi mailing list
> hybi@ietf.org
> https://www.iet= f.org/mailman/listinfo/hybi

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential info= rmation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informati= on. Any use of this information by anyone other than the intended recipient= is prohibited. If you have received this transmission in error, please imm= ediately reply to the sender and delete this information from your system. = Use, dissemination, distribution, or reproduction of this transmission by u= nintended recipients is not authorized and may be unlawful.
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org= /mailman/listinfo/hybi

--_000_CA721EFC4964tobiasobersteintavendode_-- From gregw@intalio.com Wed Aug 17 18:38: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 796C021F86C3 for ; Wed, 17 Aug 2011 18:38:35 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31OcANZi-Ose for ; Wed, 17 Aug 2011 18:38:34 -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 AC9CD21F86C1 for ; Wed, 17 Aug 2011 18:38:34 -0700 (PDT) Received: by vxi29 with SMTP id 29so1646533vxi.31 for ; Wed, 17 Aug 2011 18:39:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.88.2 with SMTP id bc2mr140436vdb.162.1313631566871; Wed, 17 Aug 2011 18:39:26 -0700 (PDT) Received: by 10.52.183.229 with HTTP; Wed, 17 Aug 2011 18:39:26 -0700 (PDT) In-Reply-To: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> Date: Thu, 18 Aug 2011 11:39:26 +1000 Message-ID: From: Greg Wilkins To: Bob Gezelter Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 01:38:35 -0000 Bob, thanks for your analysis - a couple of points On 18 August 2011 04:36, Bob Gezelter wrote: > Of course, one can always circumvent framing by processing data as it > comes in, by parsing the payload incrementally, and ignoring all of the > features of protocol-based framing with ones locally developed framing. Is this really an allowable mode of operation? Currently we have nothing in the specification that says when an intermediary is required to forward data. I do not see any compulsion for an intermediary to forward bytes as they are received so any application that depended on the timely arrival of bytes within a websocket frame would be as fragile as current comet solutions that rely on streamed HTTP responses. If fact there is also no requirement for an intermediary to forward data on frame boundaries, as we allow intermediaries to aggregate frames, thus we implicitly allow them to delay sending one frame until the arrival of following frame(s). I think there is an implicit assumption, that perhaps we should make explicit, that intermediaries should forward as soon as possible after the receipt of a message boundary. With such an explicit requirement, it would then be clear that applications that want streaming telephony style communication should be using lots of little messages rather than lots of frames or data blocks within frames. > Continuously varying frame sizes is not likely to be an efficiency improvement in most > cases, the reduction in frame overhead not withstanding. In addition, a mismatch in buffer sizes between sender and receiver can result in significant inefficiencies. A sender with a larger buffer (and thus fragment size) may force a receiver with a smaller default buffer size to continually reallocate buffers. A sender with a small buff (and thus fragment size) may talk to a receiver with a large default buffer size, where much of that buffer is wasted because large frames are never received. Yes I know that implementations may be written to treat frames as streams and avoid the need to hold an entire frame in a single buffer. But regardless of that possibility, there will be implementations that will prefer to defer frame handling (including operations like unmasking, aggregation, extensions, utf-8 conversion) until an entire frame is received. My own implementation can handle any sized frames via a fixed sized receive buffer. But I don't know how large to make that receive buffer - if I guess 8k, but senders only ever send 2k frames, then I'm wasting 6k per connection. If I guess 2k, but senders use 8k frames, then I have the inefficiencies of doing 4x the "frame" handling that I need to. An application can set a max message size, but that is is unicode characters and may not reflect a max frame size well, specially if the sender is limiting their frames sizes. I think the ability to declare a max frame size is useful, even in the absence of a frame-too-large error. For my implementation, it would at least allow significant memory savings by right sizing the buffers. The specification explicitly allows senders to limit frame size by their own buffer size. If we allow such limits to exist, I fail to see the benefits of keeping those limits secret. I do understand Andy's concern that max frame size might be wink to poor receiver implementations - so how about a third option: An optional header to declare min/max frame size, but remove the frame-too-large error so as to indicate that implementations must be able to handle any frame size up to their max message size limit. From andy@warmcat.com Thu Aug 18 01:19: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 333B721F89CC for ; Thu, 18 Aug 2011 01:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.229 X-Spam-Level: X-Spam-Status: No, score=-2.229 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1MiyN7AYgrCv for ; Thu, 18 Aug 2011 01:19:53 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id AE72121F8906 for ; Thu, 18 Aug 2011 01:19:52 -0700 (PDT) Message-ID: <4E4CCB53.3080401@warmcat.com> Date: Thu, 18 Aug 2011 09:20:35 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110815 Thunderbird/5.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> In-Reply-To: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: hybi@ietf.org Subject: Re: [hybi] Framing Management Rationale / no allocation in frame processing layer X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:19:54 -0000 On 08/17/2011 07:36 PM, Somebody in the thread at some point said: > The other day, I registered my support for retaining the "Frame Too > Large" error and including a mechanism to declare maximum and minimum > frame sizes in each direction for WebSocket protocol connections. This > posting is my promised rationale on that support. Phew this is an enormous email Bob. Much of this email is talking about other stuff like sendfile. I would have thought if there's a good reason for websockets adding frame mtu you could sum it up in three short paragraphs. > There have been several recent comments made in favor of very large > frame sizes. In particular, there was one comment suggesting that a > single huge frame would suffice for the entirety of a telephone > conversation. The stated goal was assuring performance by minimizing > overhead. This was accompanied by a reference to "sendfile." Presumably, > the "sendfile" referenced is the LINUX sendfile() (described in the > LINUX man pages at > http://www.kernel.org/doc/man-pages/online/pages/man2/sendfile.2.html) > as: I agree sendfile and large frames don't hold any water for me either. Sendfile hides a lot of stuff under one simple API call, well, so does sending a websocket message in Javascript in one call. When you add in masking processing, introduction of huge latencies and that many times the payload is not coming from a file, it sounds like we should ignore it. > Of course, one can always circumvent framing by processing data as it > comes in, by parsing the payload incrementally, and ignoring all of the Before you can call that circumvention rather than "processing the frame payload optimally at frame layer" you need to explain what you think the framing is additionally "for" if not just a segmentation scheme allowing other frames to be interleaved. > Indisputably, very small frame sizes sacrifice some efficiency; payload > is small relative to overhead. Increasing frame size provides space for Right it's about the ratio of payload that's delivered inside the frame to the number of framing bytes. It's a game of diminishing returns though; the incremental efficiency for having a 65K frame size instead of 64K frame size is really very small. > larger payloads; dramatically increasing efficiency. However, the > increase in efficiency lessens in importance exponentially as the frame > size increases: 12 bytes of overhead/frame is 10% of a 128-byte frame, > it is less than 0.1% of a 12,800 (<2**14) byte frame. "Bandwidth > Efficiency" is simply not a compelling argument for frame sizes in > excess of 2**16. (The "Jumbo" frames on high-speed CSMA/CD networks > [e.g., gigabit Ethernet] are an entirely different issue. They are used > not for efficiency at high speeds, but rather are required to maintain > the integrity of the CSMA/CD arbitration scheme over the physical > network.) Again this is a whole other subject that explaining the need for frame mtu, but again, I agree with you 2^63 frames are either worthless or evil depending on how you look at it. > A simple review of the realities of transmitting data clearly shows that > any application where a 0.01% loss of performance is unacceptable is an > application that is simply waiting to fail. Basic queuing theory is OK so I learn from that not to sweat, eg, 64K frame size or 65K. (More stuff about sendfile snipped) > The related question is that of frame size limits, and how they should Alright! It's here! > be handled by the WebSocket protocol. The operative questions are: What > are the use cases of the WebSocket protocol? How do those use cases > relate to decisions taken in the design of other protocols (e.g., HTTP, > TCP)? The operative question is what does introducing maximum frame size concept buy us when we look at real-world implementations of the frame processing code that currently don't need it. Even Greg's telling thismorning that he is using the robust packet buffer spill to message processing scheme you referred to as "circumvention" and I believe that is optimal. > WebSocket protocol connections differ from HTTP connections, in that the > majority of HTTP connections are limited in duration. By contrast, the > WebSocket protocol is intended to provide a low-overhead facility for > communications in support of interactive web applications. It is > reasonable to presume that WebSocket protocol connections will have > lifetimes far longer than HTTP connections. Okie. > The WebSocket protocol also enters a world different than that which > gave rise to TCP. The growing importance of mobile and un-tethered > devices raises the question of how protocol design changes affect > performance and usability in a network context when the underlying > network changes during the life of a connection. That really confused me, I think you're talking about the network performance for that link varying over time. It sounded like you meant automatic network handoff, like 3G -> wlan and you're suddenly on a different network. > message-oriented protocols (e.g., DECnet’s NSP). Simply put, if a > message fits within a single underlying packet, it will be far more > efficient than a message that requires two packets. While this may Sounds reasonable at IP layer. Of course, if your message can fit in your actual mtu at that layer is up to the protocol and the payload. > appear irrelevant when messages span many packets, it remains > significant in the aggregate. It is particularly significant when the > individual messages exchanged approximate the payload sizes of the > underlying packets, when protocol overhead is included. In those cases, > the removing a single byte, or a handful of bytes from a message can > nearly double throughput. Hum well, it can eliminate ACK RTT at least. If the messages was tiny, like one byte, then yes not having to do the extra framing will be significant advantage. So... this is an argument for introduction of frame mtu... how? > Frame-to-frame size variations are a also have significant potential to > create severe performance and resource problems. Buffer allocation is > one of the most costly operations in an operating system’s repertoire. > Constant allocations/deallocation of varying size memory blocks often Er... what? The OS does not know a websocket frame from its elbow. All it sees is a bunch of packets coming. > leads to significant overhead processing and memory pool fragmentation. > It is true that the buffers in question reside in user memory space, and There are no buffers dependent on frame size necessary in userland or anywhere else. I'll sum this up and explain it again in a moment for you. > are managed by the JavaScript run-time environment (at least when the > integral JavaScript WebSockets API is in use). However, there are still > issues. Garbage collection is one of the more expensive operations, and > memory pool fragmentation leads to increased virtual size, which over > time leads to resource shortages. Continuously varying frame sizes is > not likely to be an efficiency improvement in most cases, the reduction > in frame overhead not withstanding. Yeah garbage collection is expensive but this is nothing to do with the issue due to your wrong idea above. > It is for this reason that I favor a dynamic adjustment mechanism for > frame size within the WebSocket protocol. Particularly with mobile > devices, which may wander repeatedly between underlying networks (e.g., > GSM and WiFi), the ability to adjust flow control configuration without > need to disrupt ongoing connections is an important capability. OK. The mail is over and I can describe what seems to be the mistake at the end in the bit that's relevant. If you read Greg's reply he tells you: ''...My own implementation can handle any sized frames via a fixed sized receive buffer. ...'' [1] The point is he has written the critical frame processing code at hand as have I. What he's explaining to you is that there is no per-frame malloc or whatever you had in mind for the frame processing which is the basis of your suddenly jumping to a frame mtu being necessary due to "memory fragmentation" and "garbage collection". No allocations are happening in frame layer at all. Instead at the frame processing layer, there's a fixed size buffer allocated either on the stack frame or static if it's done singlethreaded. That buffer size is unrelated to the size of websocket frames expected to appear. So, you could set it to 64K or 4K or what you think is good according to how many packets might be waiting in the OS to fill it; in singlethreaded method like libwebsockets there's only one of them in the whole library instance so the size is not critical resourcewise. You read() packet content into that buffer, parse out the headers bytewise so you don't care if they straddle a buffer boundary, and pass the remainder of the buffer or the frame payload in there up to the message handling layer, via a pointer in my case. The message handler says, "oh, nice, xyz bytes more message came, I shall take care of that". And if there is more left in the fixed buffer, or more packets waiting without blocking, then we go around again passing that payload up to the message layer. That is why I say frame size, framing as a whole has no meaning outside of stripping it off and immediately passing the payload up as message payload. We should have language to actively discourage assumption that received frame sizes or start and end have anything to do with what was sent to avoid fragility from intermediaries doing their legit thing. Nowhere in there does negotiation of max frame size buy us anything. Even if you want framing to react dynamically to throughput conditions, with control frame latency in mind, that's something the sender and intermediary senders can monitor and do themselves without any negotiation with the receiver. -Andy [1] Greg goes on to wonder what size that buffer should be, but so long as it's much larger than the mtu of the underlying transport (not frame mtu) and can dump out much of the packets the OS has pending in kernel memory already for us, the size should not be critical for performance. From tobias.oberstein@tavendo.de Thu Aug 18 01:54: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 7A31521F875E for ; Thu, 18 Aug 2011 01:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.507 X-Spam-Level: X-Spam-Status: No, score=-2.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zix9-rFAV7Q5 for ; Thu, 18 Aug 2011 01:54:39 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9FE21F874F for ; Thu, 18 Aug 2011 01:54:39 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Thu, 18 Aug 2011 01:55:32 -0700 From: Tobias Oberstein To: Greg Wilkins , Bob Gezelter Date: Thu, 18 Aug 2011 01:55:30 -0700 Thread-Topic: [hybi] Framing Management Rationale Thread-Index: AcxdR7GQs6c+qiFkQ7OaFFROs/3ldwAPOM0E Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 08:54:40 -0000 > Currently we have nothing in the specification that says when an > intermediary is required to forward data. I do not see any I totally agree: there should be something in the spec. > compulsion for an intermediary to forward bytes as they are received > so any application that depended on the timely arrival of bytes within > a websocket frame would be as fragile as current comet solutions that > rely on streamed HTTP responses. >=20 > If fact there is also no requirement for an intermediary to forward > data on frame boundaries, as we allow intermediaries to aggregate > frames, thus we implicitly allow them to delay sending one frame until > the arrival of following frame(s). >=20 > I think there is an implicit assumption, that perhaps we should make > explicit, that intermediaries should forward as soon as possible after > the receipt of a message boundary. With such an explicit > requirement, it would then be clear that applications that want > streaming telephony style communication should be using lots of little > messages rather than lots of frames or data blocks within frames. So streaming an audio file will mean you cannot have "audio file" =3D "message", have the data sent in small frames, and the audio playback start immediately, since interm. might buffer the whole file? So I need to invent my own fragmentation and put those fragments into little WS messages? Then why do we have message fragmentation in WS at all? From ibc@aliax.net Thu Aug 18 07:43: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 5574D21F8B8A for ; Thu, 18 Aug 2011 07:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMjNMLfwOzrB for ; Thu, 18 Aug 2011 07:43:47 -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 6F50F21F8B89 for ; Thu, 18 Aug 2011 07:43:47 -0700 (PDT) Received: by qwc23 with SMTP id 23so1738106qwc.31 for ; Thu, 18 Aug 2011 07:44:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.192.135 with SMTP id dq7mr677405qab.378.1313678680838; Thu, 18 Aug 2011 07:44:40 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Thu, 18 Aug 2011 07:44:40 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 18 Aug 2011 16:44:40 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSockets Test Suite / Browser Status X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 14:43:48 -0000 2011/8/17 Tobias Oberstein : > 1. > Autobahn WebSockets now (0.3.2) includes an automated test suite for both= clients and servers. > > http://www.tavendo.de/autobahn/testsuite.html Really nice. --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Thu Aug 18 09:25: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 8279B21F8B62 for ; Thu, 18 Aug 2011 09:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D4+qZTHYOcnt for ; Thu, 18 Aug 2011 09:25:28 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id DD4A521F8B5A for ; Thu, 18 Aug 2011 09:25:28 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qu5QE-000563-GT; Thu, 18 Aug 2011 09:26:22 -0700 Message-ID: <4E4D3D3A.1050800@callenish.com> Date: Thu, 18 Aug 2011 09:26:34 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: John Tamplin References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------040303010303080708080708" 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] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:25:29 -0000 This is a multi-part message in MIME format. --------------040303010303080708080708 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 17/08/2011 11:49 AM, John Tamplin wrote: > On Wed, Aug 17, 2011 at 2:44 PM, Bob Gezelter > wrote: > > Ok, I mis-read what you had written. However, you envision a > connection > where some messages will be text, and other messages will be > binary, to > wit: > > Message 1 (Text) > Message 2 (Text) > Message 3 (Binary) > Message 4 (Text) > > Correct? > > > Yes. Consider a hypothetical chat app: > > most messages are JSON-encoded chat data, status notifies, etc > file transfers are done as binary > > If the connection has to be one or the other, then obviously it has to > be binary, which means JS needs some way to encode its text as binary > so it can be serialized into a combined message, and a way to extract > UTF8 text from a piece of a binary message. > I think John's example and Bob's previous statement: > As has been observed, the WebSocket protocol is payload-agnostic. > Regardless of the politics, it is thus emphatically NOT an applications > protocol. can be resolved when one realizes that in the absence of a subprotocol header to define the application protocol, a default application-level subprotocol is in use. It is this default subprotocol that John wants to support the intermixing of UTF8 and binary messages differentiated by opcodes. Other subprotocols may mix binary and text in a single message and may differentiate different types of messages with different opcodes or message headers, but since browsers are unlikely to support anything other than the default subprotocol for some time to come, allowing them to choose to send either raw UTF8 or raw binary messages in the default subprotocol makes a lot of sense to me. --------------040303010303080708080708 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 17/08/2011 11:49 AM, John Tamplin wrote:
On Wed, Aug 17, 2011 at 2:44 PM, Bob Gezelter <gezelter@rlgsc.com> wrote:
Ok, I mis-read what you had written. However, you envision a connection
where some messages will be text, and other messages will be binary, to
wit:

  Message 1 (Text)
  Message 2 (Text)
  Message 3 (Binary)
  Message 4 (Text)

Correct?

Yes.  Consider a hypothetical chat app:

most messages are JSON-encoded chat data, status notifies, etc
file transfers are done as binary

If the connection has to be one or the other, then obviously it has to be binary, which means JS needs some way to encode its text as binary so it can be serialized into a combined message, and a way to extract UTF8 text from a piece of a binary message.


I think John's example and Bob's previous statement:

As has been observed, the WebSocket protocol is payload-agnostic.
Regardless of the politics, it is thus emphatically NOT an applications
protocol.

can be resolved when one realizes that in the absence of a subprotocol header to define the application protocol, a default application-level subprotocol is in use. It is this default subprotocol that John wants to support the intermixing of UTF8 and binary messages differentiated by opcodes.

Other subprotocols may mix binary and text in a single message and may differentiate different types of messages with different opcodes or message headers, but since browsers are unlikely to support anything other than the default subprotocol for some time to come, allowing them to choose to send either raw UTF8 or raw binary messages in the default subprotocol makes a lot of sense to me.

--------------040303010303080708080708-- From sdw@lig.net Thu Aug 18 09:55: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 889AE21F874E for ; Thu, 18 Aug 2011 09:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hsXZGfKA6uP for ; Thu, 18 Aug 2011 09:54:59 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id D5F3A21F8785 for ; Thu, 18 Aug 2011 09:54:59 -0700 (PDT) Received: from sdwmbp.local (ligemail.lig.net [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id BEE61AB5DB0 for ; Thu, 18 Aug 2011 10:06:41 -0700 (PDT) Message-ID: <4E4D442C.20405@lig.net> Date: Thu, 18 Aug 2011 09:56:12 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> In-Reply-To: <4E4D3D3A.1050800@callenish.com> Content-Type: multipart/alternative; boundary="------------040904050203010808000600" Subject: Re: [hybi] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 16:55:00 -0000 This is a multi-part message in MIME format. --------------040904050203010808000600 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/18/11 9:26 AM, Bruce Atherton wrote: > On 17/08/2011 11:49 AM, John Tamplin wrote: >> On Wed, Aug 17, 2011 at 2:44 PM, Bob Gezelter > wrote: >> >> Ok, I mis-read what you had written. However, you envision a connection >> where some messages will be text, and other messages will be binary, to >> wit: >> >> Message 1 (Text) >> Message 2 (Text) >> Message 3 (Binary) >> Message 4 (Text) >> >> Correct? >> >> >> Yes. Consider a hypothetical chat app: >> >> most messages are JSON-encoded chat data, status notifies, etc >> file transfers are done as binary >> >> If the connection has to be one or the other, then obviously it has to be binary, which means JS needs some way to encode its >> text as binary so it can be serialized into a combined message, and a way to extract UTF8 text from a piece of a binary message. >> > > I think John's example and Bob's previous statement: > >> As has been observed, the WebSocket protocol is payload-agnostic. >> Regardless of the politics, it is thus emphatically NOT an applications >> protocol. > > can be resolved when one realizes that in the absence of a subprotocol header to define the application protocol, a default > application-level subprotocol is in use. It is this default subprotocol that John wants to support the intermixing of UTF8 and > binary messages differentiated by opcodes. > > Other subprotocols may mix binary and text in a single message and may differentiate different types of messages with different > opcodes or message headers, but since browsers are unlikely to support anything other than the default subprotocol for some time > to come, allowing them to choose to send either raw UTF8 or raw binary messages in the default subprotocol makes a lot of sense to me. There are few well-designed message-oriented applications that wouldn't have a header (text or binary) on every message, with the payload being text, binary, or both. Going down the "we have to denote text in the protocol so the JS API is simpler / more efficient" path seems to lead to explicitly delineating header+type & body+type. Otherwise, while header(text)+body(text) is easy, header(text)+body(binary) forces the app JS to find and parse header(text) out of a binary payload anyway. The result either defeats the purpose of payload typing, or it puts pressure on app protocol construction to have pure text or binary message streams. In the example above, is the application sending a text message to "set up" the binary transfer, then just sending raw blocks of data? Or does each block of data have a header? If you don't reuse channels, you could just keep allocating new channels for raw transfer. Is that the intention? Is it right to cause the application designer to make that kind of decision because of a "limitation" of the protocol and API? Assuming a message can have multiple frames, as the spec indicates, and each frame could be text or binary, having per-frame text/binary opcodes/flag would probably work well enough for byte-aligned data. Having 4 byte opcode+length is larger than it needs to be, but not terribly expensive for typical applications. sdw --------------040904050203010808000600 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/18/11 9:26 AM, Bruce Atherton wrote:
On 17/08/2011 11:49 AM, John Tamplin wrote:
On Wed, Aug 17, 2011 at 2:44 PM, Bob Gezelter <gezelter@rlgsc.com> wrote:
Ok, I mis-read what you had written. However, you envision a connection
where some messages will be text, and other messages will be binary, to
wit:

  Message 1 (Text)
  Message 2 (Text)
  Message 3 (Binary)
  Message 4 (Text)

Correct?

Yes.  Consider a hypothetical chat app:

most messages are JSON-encoded chat data, status notifies, etc
file transfers are done as binary

If the connection has to be one or the other, then obviously it has to be binary, which means JS needs some way to encode its text as binary so it can be serialized into a combined message, and a way to extract UTF8 text from a piece of a binary message.


I think John's example and Bob's previous statement:

As has been observed, the WebSocket protocol is payload-agnostic.
Regardless of the politics, it is thus emphatically NOT an applications
protocol.

can be resolved when one realizes that in the absence of a subprotocol header to define the application protocol, a default application-level subprotocol is in use. It is this default subprotocol that John wants to support the intermixing of UTF8 and binary messages differentiated by opcodes.

Other subprotocols may mix binary and text in a single message and may differentiate different types of messages with different opcodes or message headers, but since browsers are unlikely to support anything other than the default subprotocol for some time to come, allowing them to choose to send either raw UTF8 or raw binary messages in the default subprotocol makes a lot of sense to me.

There are few well-designed message-oriented applications that wouldn't have a header (text or binary) on every message, with the payload being text, binary, or both.  Going down the "we have to denote text in the protocol so the JS API is simpler / more efficient" path seems to lead to explicitly delineating header+type & body+type.  Otherwise, while header(text)+body(text) is easy, header(text)+body(binary) forces the app JS to find and parse header(text) out of a binary payload anyway.  The result either defeats the purpose of payload typing, or it puts pressure on app protocol construction to have pure text or binary message streams.

In the example above, is the application sending a text message to "set up" the binary transfer, then just sending raw blocks of data?  Or does each block of data have a header?  If you don't reuse channels, you could just keep allocating new channels for raw transfer.  Is that the intention?  Is it right to cause the application designer to make that kind of decision because of a "limitation" of the protocol and API?

Assuming a message can have multiple frames, as the spec indicates, and each frame could be text or binary, having per-frame text/binary opcodes/flag would probably work well enough for byte-aligned data.  Having 4 byte opcode+length is larger than it needs to be, but not terribly expensive for typical applications.

sdw

--------------040904050203010808000600-- From bruce@callenish.com Thu Aug 18 10:57: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 E9E0721F85A1 for ; Thu, 18 Aug 2011 10:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.644 X-Spam-Level: X-Spam-Status: No, score=-1.644 tagged_above=-999 required=5 tests=[AWL=-0.846, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbugfwmmnsRp for ; Thu, 18 Aug 2011 10:57:15 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 357C521F85C0 for ; Thu, 18 Aug 2011 10:57:15 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qu6r0-0001Ad-LM; Thu, 18 Aug 2011 10:58:06 -0700 Message-ID: <4E4D52BA.40105@callenish.com> Date: Thu, 18 Aug 2011 10:58:18 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Williams References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> <4E4D442C.20405@lig.net> In-Reply-To: <4E4D442C.20405@lig.net> Content-Type: multipart/alternative; boundary="------------040105000405020904010202" 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] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 17:57:16 -0000 This is a multi-part message in MIME format. --------------040105000405020904010202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 18/08/2011 9:56 AM, Stephen Williams wrote: > > There are few well-designed message-oriented applications that > wouldn't have a header (text or binary) on every message, with the > payload being text, binary, or both. Right. And in Websockets, that header can be the binary opcode. Or it can be an identifier within the payload. Or it can be a combination of both. In the default subprotocol, it will probably be a combination in many cases. The opcode indicates a broad category for interpreting the message (UTF8 or binary) and if further identification of the message type is needed it can be included in the message itself by the application. Given the constraints within the browser, this seems like a reasonable solution to use for the default. > Going down the "we have to denote text in the protocol so the JS API > is simpler / more efficient" path seems to lead to explicitly > delineating header+type & body+type. Otherwise, while > header(text)+body(text) is easy, header(text)+body(binary) forces the > app JS to find and parse header(text) out of a binary payload anyway. Which may well be the reason many people choose not to do things that way. Or they may decide that the complication is worth it. It is very hard to design a generic default application protocol that is all things to all people. This is always going to be a compromise. > The result either defeats the purpose of payload typing, or it puts > pressure on app protocol construction to have pure text or binary > message streams. If they want to use the default subprotocol then they are probably best to stick to pure text or pure binary with this scheme, yes. Do you have a suggestion that would allow things to be more flexible and allow interweaving text and binary in a single message? The only way I can see it is if browsers all supported some sort of IDL for messages, and that seems like a major complication that is not even in the domain of this WG. > > In the example above, is the application sending a text message to > "set up" the binary transfer, then just sending raw blocks of data? > Or does each block of data have a header? If you don't reuse > channels, you could just keep allocating new channels for raw > transfer. Is that the intention? Is it right to cause the > application designer to make that kind of decision because of a > "limitation" of the protocol and API? > > Assuming a message can have multiple frames, as the spec indicates, > and each frame could be text or binary, having per-frame text/binary > opcodes/flag would probably work well enough for byte-aligned data. > Having 4 byte opcode+length is larger than it needs to be, but not > terribly expensive for typical applications. I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation? If so, then even if I thought the leakage between layers was worth it, I don't see the point. In browsers where the default subprotocol is most important, the message is going to be delivered to the application layer as a single entity. Who cares how it was transported? --------------040105000405020904010202 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 18/08/2011 9:56 AM, Stephen Williams wrote:

There are few well-designed message-oriented applications that wouldn't have a header (text or binary) on every message, with the payload being text, binary, or both.

Right. And in Websockets, that header can be the binary opcode. Or it can be an identifier within the payload. Or it can be a combination of both.

In the default subprotocol, it will probably be a combination in many cases. The opcode indicates a broad category for interpreting the message (UTF8 or binary) and if further identification of the message type is needed it can be included in the message itself by the application. Given the constraints within the browser, this seems like a reasonable solution to use for the default.

  Going down the "we have to denote text in the protocol so the JS API is simpler / more efficient" path seems to lead to explicitly delineating header+type & body+type.  Otherwise, while header(text)+body(text) is easy, header(text)+body(binary) forces the app JS to find and parse header(text) out of a binary payload anyway.

Which may well be the reason many people choose not to do things that way. Or they may decide that the complication is worth it. It is very hard to design a generic default application protocol that is all things to all people. This is always going to be a compromise.

  The result either defeats the purpose of payload typing, or it puts pressure on app protocol construction to have pure text or binary message streams.

If they want to use the default subprotocol then they are probably best to stick to pure text or pure binary with this scheme, yes.

Do you have a suggestion that would allow things to be more flexible and allow interweaving text and binary in a single message? The only way I can see it is if browsers all supported some sort of IDL for messages, and that seems like a major complication that is not even in the domain of this WG.


In the example above, is the application sending a text message to "set up" the binary transfer, then just sending raw blocks of data?  Or does each block of data have a header?  If you don't reuse channels, you could just keep allocating new channels for raw transfer.  Is that the intention?  Is it right to cause the application designer to make that kind of decision because of a "limitation" of the protocol and API?

Assuming a message can have multiple frames, as the spec indicates, and each frame could be text or binary, having per-frame text/binary opcodes/flag would probably work well enough for byte-aligned data.  Having 4 byte opcode+length is larger than it needs to be, but not terribly expensive for typical applications.

I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation?

If so, then even if I thought the leakage between layers was worth it, I don't see the point. In browsers where the default subprotocol is most important, the message is going to be delivered to the application layer as a single entity. Who cares how it was transported?

--------------040105000405020904010202-- From sdw@lig.net Thu Aug 18 12:46: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 A87DD21F8C1D for ; Thu, 18 Aug 2011 12:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.367 X-Spam-Level: X-Spam-Status: No, score=-1.367 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_66=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ras4m2yqz0MH for ; Thu, 18 Aug 2011 12:46:58 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id 8D73721F8C1C for ; Thu, 18 Aug 2011 12:46:58 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id DCBF5AB5DB0; Thu, 18 Aug 2011 12:58:39 -0700 (PDT) Message-ID: <4E4D6C64.80206@lig.net> Date: Thu, 18 Aug 2011 12:47:48 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> <4E4D442C.20405@lig.net> <4E4D52BA.40105@callenish.com> In-Reply-To: <4E4D52BA.40105@callenish.com> Content-Type: multipart/alternative; boundary="------------050003050505020909050204" Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 19:46:59 -0000 This is a multi-part message in MIME format. --------------050003050505020909050204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/18/11 10:58 AM, Bruce Atherton wrote: > On 18/08/2011 9:56 AM, Stephen Williams wrote: >> ... >> The result either defeats the purpose of payload typing, or it puts pressure on app protocol construction to have pure text or >> binary message streams. > > If they want to use the default subprotocol then they are probably best to stick to pure text or pure binary with this scheme, yes. > > Do you have a suggestion that would allow things to be more flexible and allow interweaving text and binary in a single message? > The only way I can see it is if browsers all supported some sort of IDL for messages, and that seems like a major complication > that is not even in the domain of this WG. IDL, in general, is bad IMHO. Not needed here either. Since we've (thankfully) agreed that text=UTF8, a text frame and a binary frame containing UTF8 should have the same data. Signaling that a frame is text is just an optimization indicating that the frame should be valid UTF8. That is typing a range of data, not necessarily bounding a logical section of data. Some versions of the specification say something to the effect of: "a message is made up of one or more frames", and elsewhere that frames can be text or binary. Fragments of a frame all need to be of the same type I believe. However, it would make sense for multiple frames that are part of a message to be of different types. An application should only do this for big sections (header/body, chat text/image), not every other small field. Perhaps the default subprotocol don't need to care about messages vs. frames, although allowing an application to indicate logical message boundaries has all kinds of potential usage (logging, stats, routing/load balancing). But, doable in a layered / different subprotocol also. All of this is getting close to W3C EXI (Efficient XMl Interchange), a proposed standard and a group I was with in a deep way for several years. At this point, EXI would be nice to layer onto a very simple hybi/ws protocol. It solves the efficient data object representation / packaging problem well. While adding WS support to Javascript, "we" should consider integrating EXI for easy usage too. (Preferably with my extensions. ;-) ) And the N-tuple/RDF case needs to be solved well soon also. > >> >> In the example above, is the application sending a text message to "set up" the binary transfer, then just sending raw blocks of >> data? Or does each block of data have a header? If you don't reuse channels, you could just keep allocating new channels for >> raw transfer. Is that the intention? Is it right to cause the application designer to make that kind of decision because of a >> "limitation" of the protocol and API? >> >> Assuming a message can have multiple frames, as the spec indicates, and each frame could be text or binary, having per-frame >> text/binary opcodes/flag would probably work well enough for byte-aligned data. Having 4 byte opcode+length is larger than it >> needs to be, but not terribly expensive for typical applications. > > I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and > binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation? I was thinking that a app could say, in some fashion: start message, text frame, binary frame, end message. > > If so, then even if I thought the leakage between layers was worth it, I don't see the point. In browsers where the default > subprotocol is most important, the message is going to be delivered to the application layer as a single entity. Who cares how it > was transported? > Since UTF8(text) == UTF8(binary) at the byte level, the flagging is only an optimization of the API/library/language, right? Is there any difference in "transport" of text vs. binary other than the type flag? Other than a 1007 error if the "text" turns out not to be valid UTF8, don't see anything in the spec. Rather than a query/parse request/response, the API can simply put the text into a string / JSON-based object tree / DOM / etc. before the application asks. sdw -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer --------------050003050505020909050204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/18/11 10:58 AM, Bruce Atherton wrote:
On 18/08/2011 9:56 AM, Stephen Williams wrote:
...
  The result either defeats the purpose of payload typing, or it puts pressure on app protocol construction to have pure text or binary message streams.

If they want to use the default subprotocol then they are probably best to stick to pure text or pure binary with this scheme, yes.

Do you have a suggestion that would allow things to be more flexible and allow interweaving text and binary in a single message? The only way I can see it is if browsers all supported some sort of IDL for messages, and that seems like a major complication that is not even in the domain of this WG.

IDL, in general, is bad IMHO.  Not needed here either.  Since we've (thankfully) agreed that text=UTF8, a text frame and a binary frame containing UTF8 should have the same data.  Signaling that a frame is text is just an optimization indicating that the frame should be valid UTF8.  That is typing a range of data, not necessarily bounding a logical section of data.

Some versions of the specification say something to the effect of: "a message is made up of one or more frames", and elsewhere that frames can be text or binary.  Fragments of a frame all need to be of the same type I believe.  However, it would make sense for multiple frames that are part of a message to be of different types.  An application should only do this for big sections (header/body, chat text/image), not every other small field.  Perhaps the default subprotocol don't need to care about messages vs. frames, although allowing an application to indicate logical message boundaries has all kinds of potential usage (logging, stats, routing/load balancing).  But, doable in a layered / different subprotocol also.

All of this is getting close to W3C EXI (Efficient XMl Interchange), a proposed standard and a group I was with in a deep way for several years.  At this point, EXI would be nice to layer onto a very simple hybi/ws protocol.  It solves the efficient data object representation / packaging problem well.  While adding WS support to Javascript, "we" should consider integrating EXI for easy usage too.  (Preferably with my extensions.  ;-) )  And the N-tuple/RDF case needs to be solved well soon also.



In the example above, is the application sending a text message to "set up" the binary transfer, then just sending raw blocks of data?  Or does each block of data have a header?  If you don't reuse channels, you could just keep allocating new channels for raw transfer.  Is that the intention?  Is it right to cause the application designer to make that kind of decision because of a "limitation" of the protocol and API?

Assuming a message can have multiple frames, as the spec indicates, and each frame could be text or binary, having per-frame text/binary opcodes/flag would probably work well enough for byte-aligned data.  Having 4 byte opcode+length is larger than it needs to be, but not terribly expensive for typical applications.

I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation?

I was thinking that a app could say, in some fashion: start message, text frame, binary frame, end message.


If so, then even if I thought the leakage between layers was worth it, I don't see the point. In browsers where the default subprotocol is most important, the message is going to be delivered to the application layer as a single entity. Who cares how it was transported?

Since UTF8(text) == UTF8(binary) at the byte level, the flagging is only an optimization of the API/library/language, right?  Is there any difference in "transport" of text vs. binary other than the type flag?  Other than a 1007 error if the "text" turns out not to be valid UTF8, don't see anything in the spec.  Rather than a query/parse request/response, the API can simply put the text into a string / JSON-based object tree / DOM / etc. before the application asks.

sdw
--
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer

--------------050003050505020909050204-- From ferg@caucho.com Thu Aug 18 13:30: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 48C8111E8073 for ; Thu, 18 Aug 2011 13:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzd7H60nGn40 for ; Thu, 18 Aug 2011 13:30:08 -0700 (PDT) Received: from nm12-vm0.bullet.mail.ac4.yahoo.com (nm12-vm0.bullet.mail.ac4.yahoo.com [98.139.53.198]) by ietfa.amsl.com (Postfix) with SMTP id 32EFE21F8A23 for ; Thu, 18 Aug 2011 13:30:08 -0700 (PDT) Received: from [98.139.52.195] by nm12.bullet.mail.ac4.yahoo.com with NNFMP; 18 Aug 2011 20:31:00 -0000 Received: from [98.139.52.185] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 18 Aug 2011 20:31:00 -0000 Received: from [127.0.0.1] by omp1068.mail.ac4.yahoo.com with NNFMP; 18 Aug 2011 20:31:00 -0000 X-Yahoo-Newman-Id: 136455.31354.bm@omp1068.mail.ac4.yahoo.com Received: (qmail 97882 invoked from network); 18 Aug 2011 20:30:59 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1313699459; bh=zQzhAq8///76l7HKpUu4zqb5OKOePhuhbrAIBxGNoXc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=xJV7ahoF4o8vgJO1W2deCWd3wgJj6OoqDRaDAuqHKFoDXJ+ktvPEg9LmtHfm+rDnCJUib5r0oE9YObPMuwXLwH+WsUjPdU4dXWR3EXGRBIXpHtTFA18xOlnnyft0hNrS5s2yQ6EXBu239H19lDos8m7D4HvaeEP4QcHyYtzRlik= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 1pu2gkUVM1mX5SmSkwCddByeEGtrvnffmKPiV4YXm.kokvU yboFnTsREY4gZq_Y9QQH4cQHI5forfdmPR.cbwXPu0jj..JIuaZaimB_r6wp uHVDYwv_R32SW4XOFg7JF.8zI3XLdabbYqXkXm.9YsHanqLOMrzeqVh3SisW 7MDjHAWB6gNp4HN5WonbVjGMoKgDW_dqVGaG_OJFjRwFxLqLYuw6vumaEYNq ElWktcbzkNDweQFe4MSmbo9xK0SpWqzyFQcxR_8gRS4t7yX5kEJ.jSpqUvbH ruXKcgsc9BvjYJaS0l4QEVVCYRVix_NAZilYPmObIxtKUKNxgaZfPVI6mk3O Yg1HiScD_MbbL6liTZm_sI0QC1pP0_2bOuCB8otwgD2EUQiyYzPdkzvDSNoW 5wLH..jPyHwelhvbDefMbLv7RZrk0bag- X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp113.biz.mail.mud.yahoo.com with SMTP; 18 Aug 2011 13:30:59 -0700 PDT Message-ID: <4E4D7682.1000003@caucho.com> Date: Thu, 18 Aug 2011 13:30:58 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> <4E4D442C.20405@lig.net> <4E4D52BA.40105@callenish.com> <4E4D6C64.80206@lig.net> In-Reply-To: <4E4D6C64.80206@lig.net> Content-Type: multipart/alternative; boundary="------------040508050909040308090203" Subject: Re: [hybi] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:30:09 -0000 This is a multi-part message in MIME format. --------------040508050909040308090203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/18/2011 12:47 PM, Stephen Williams wrote: > > I was thinking that a app could say, in some fashion: start message, > text frame, binary frame, end message. But that breaks the whole concept of the message/frame in WebSockets. Messages have semantic content (i.e. are meaningful to the application.) Frames do not have semantic content. They're just a pragmatic requirement due to buffering requirements. Since they are invisible to the application, the application cannot use frames to split a message up into parts like multipart mime. If an application needs binary/text in chunks, it either needs to send multiple messages, or one big message encoded using its own multipart-mime equivalent. > > Since UTF8(text) == UTF8(binary) at the byte level, the flagging is > only an optimization of the API/library/language, right? Is there any > difference in "transport" of text vs. binary other than the type > flag? Other than a 1007 error if the "text" turns out not to be valid > UTF8, don't see anything in the spec. Well, as a pragmatic matter, the UTF-8 hard requirement has value in itself, because encoding issues always come up when you have a binary-only layers. And avoiding those issues beforehand is a good thing. If you have text=UTF-8, the discussion ends. If you don't, each application tries to invent encoding types like application/iso-8859-1 vs application/utf-8 or a CORBA-like per-message encodings in a misguided attempt at efficiency or flexibility. Or more likely, something like the PHP nightmare of not realizing that US-ASCII isn't sufficient. Strictly speaking the text/binary distinction isn't necessary, but many years of painful, purposeless text-encoding code over many projects suggests setting a fixed utf-8 encoding up front is a very nice, easy decision. Since it's not strictly necessary, I'd be okay with binary-only -- it does simplify my API. But text messages and the utf-8 encoding does have value. -- Scott --------------040508050909040308090203 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/18/2011 12:47 PM, Stephen Williams wrote:

I was thinking that a app could say, in some fashion: start message, text frame, binary frame, end message.

But that breaks the whole concept of the message/frame in WebSockets.

Messages have semantic content (i.e. are meaningful to the application.)

Frames do not have semantic content. They're just a pragmatic requirement due to buffering requirements. Since they are invisible to the application, the application cannot use frames to split a message up into parts like multipart mime.

If an application needs binary/text in chunks, it either needs to send multiple messages, or one big message encoded using its own multipart-mime equivalent.

Since UTF8(text) == UTF8(binary) at the byte level, the flagging is only an optimization of the API/library/language, right?  Is there any difference in "transport" of text vs. binary other than the type flag?  Other than a 1007 error if the "text" turns out not to be valid UTF8, don't see anything in the spec.

Well, as a pragmatic matter, the UTF-8 hard requirement has value in itself, because encoding issues always come up when you have a binary-only layers. And avoiding those issues beforehand is a good thing.

If you have text=UTF-8, the discussion ends.

If you don't, each application tries to invent encoding types like application/iso-8859-1 vs application/utf-8 or a CORBA-like per-message encodings in a misguided attempt at efficiency or flexibility. Or more likely, something like the PHP nightmare of not realizing that US-ASCII isn't sufficient.

Strictly speaking the text/binary distinction isn't necessary, but many years of painful, purposeless text-encoding code over many projects suggests setting a fixed utf-8 encoding up front is a very nice, easy decision. Since it's not strictly necessary, I'd be okay with binary-only -- it does simplify my API. But text messages and the utf-8 encoding does have value.

-- Scott

--------------040508050909040308090203-- From tyoshino@google.com Thu Aug 18 13:40: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 57EA521F8B33 for ; Thu, 18 Aug 2011 13:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.316 X-Spam-Level: X-Spam-Status: No, score=-105.316 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V8OznBKXJ6oX for ; Thu, 18 Aug 2011 13:40:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 001D321F8B53 for ; Thu, 18 Aug 2011 13:40:16 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7IKfAJx008419 for ; Thu, 18 Aug 2011 13:41:11 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313700071; bh=RKwcq+bEJAB0djue5Wl4raS1/mU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TNUuA0KVlHe5jjeQxuqI1bCF4wY2ThuqB5LcUtGLmH5eAlbERkOqergRY2EDtvALf sY8Z5ue7h4P/GZFIGDawQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=CONmYPVODLyj37Ur8IWmk/YGgov0fPOsqLS/1lasxPuHPGB9bDRtQgHnn8ZZsPxJA nVOkKlu9hkCTGm8bAe8aQ== Received: from yxi11 (yxi11.prod.google.com [10.190.3.11]) by hpaq14.eem.corp.google.com with ESMTP id p7IKeTDW023670 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 18 Aug 2011 13:41:09 -0700 Received: by yxi11 with SMTP id 11so2387002yxi.39 for ; Thu, 18 Aug 2011 13:41:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=R4wzeXFr3mPv48mXu6iWQP/i+rY/XG3zTQGxn0m1Kjc=; b=RTICa/fFCzeszxbmc1hPIRYaYO4p9l+FjXR+prtzXpzZN0QpVQj+RPluySZaob85uN 3LWtUYNocsfYGQsE2Szg== Received: by 10.150.114.16 with SMTP id m16mr44862ybc.399.1313700069424; Thu, 18 Aug 2011 13:41:09 -0700 (PDT) Received: by 10.150.114.16 with SMTP id m16mr44854ybc.399.1313700069219; Thu, 18 Aug 2011 13:41:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Thu, 18 Aug 2011 13:40:49 -0700 (PDT) In-Reply-To: References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> From: Takeshi Yoshino Date: Fri, 19 Aug 2011 05:40:49 +0900 Message-ID: To: John Tamplin Content-Type: multipart/alternative; boundary=000e0cd5d0eaf79f4504aacda1a6 X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 20:40:18 -0000 --000e0cd5d0eaf79f4504aacda1a6 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Aug 18, 2011 at 03:49, John Tamplin wrote: > Yes. Consider a hypothetical chat app: > > most messages are JSON-encoded chat data, status notifies, etc > file transfers are done as binary > > If the connection has to be one or the other, then obviously it has to be > binary, which means JS needs some way to encode its text as binary so it can > be serialized into a combined message, and a way to extract UTF8 text from a > piece of a binary message. > Serialization from DOMString to binary message can be done just by overloading send() interface as the current API spec does. The problems is receiving. Without text/binary distinction in protocol, MessageEvent.data has to be binary object. The server need to signal the application layer of the client side whether a certain frame contains data should be interpreted as text or binary in advance like this: var handle_as_binary = false; onmessage = function(evt) { if (handle_as_binary) { // Read evt.data as Blob/TypedArray directly and handle it. // If it indicates the next message is also binary, keep handle_as_binary true. Otherwise set it to false. } else { // e.g. assume evt.data contains text by default and handle it. var text = ConvertToString(evt.data); // This can be .as_text() or something as David suggested // If it indicates the next message is binary, set handle_as_binary to true. } } or we might embed some additional header in payload to switch handling onmessage = function(evt) { var tmp_view = new Uint8Array(evt.data); if (tmp_view[0] & 0x01 == 0x00) { // e.g. LSB indicates type. Here it's Text // Convert the rest of tmp_view to DOMString var text = ConvertToString(evt.data.slice(1)); } else { // Binary // Handle as binary event } } Yes, it works. As it's cumbersome for text only users to perform conversion, we'd extend binaryType to receiveType and add "text" type (or let binaryType == null mean "text") to force received data decoded as text into DOMString and specify it as default. And ask those who are interested in binary to set receiveType to "blob" or "arraybuffer" and write some code like above. ---- That said, I agree with Greg. On Tue, Aug 16, 2011 at 09:10, Greg Wilkins wrote: > The cost now is just the allocation of an opcode and a bit of split > personality in the APIs - which is a price that I'm prepared to pay to > avoid another round of design by war of attrition. > +1 Removal of text opcode - complicates JS code for text/binary mixed use case - delays UTF-8 decoding and requires unnecessary allocation of Blob/TypeArray object (if we take as_text() approach, not object but allocation of memory for holding non-decoded data) for text/binary mixed use case - requires rearrangement of opcode (maybe revoke 0x02 and let 0x01 generic data frame type) (this change is not so painful for those who haven't exposed binary API) - (API side change may kept minimal by making binaryType = null to force decoding as text.) while just saving one opcode space (sorry if i'm missing something else important already discussed. there're too much traffic on the list recently) I'd prefer just taking in text opcode as a predefined/convenient content type indication method out of application layer. Thanks, Takeshi --000e0cd5d0eaf79f4504aacda1a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 18, 2011 at 03:49, John Tamplin <jat@google.com><= /span> wrote:
Yes. =A0Consider a hypoth= etical chat app:

most messages are JSON-enco= ded chat data, status notifies, etc
file transfers are done as bi= nary

If the connection has to be one or the other, then obviously= it has to be binary, which means JS needs some way to encode its text as b= inary so it can be serialized into a combined message, and a way to extract= UTF8 text from a piece of a binary message.

Serialization from DOMString to bina= ry message can be done just by overloading send() interface as the current = API spec does. The problems is receiving.=A0Without text/binary distinction= in protocol, MessageEvent.data has to be binary object. The server need to= signal the application layer of the client side whether a certain frame co= ntains data should be interpreted as text or binary in advance like this:

var handle_as_binary =3D false;
onmessage =3D= function(evt) {
=A0 if (handle_as_binary) {
=A0 =A0 //= Read evt.data as Blob/TypedArray directly and handle it.
=A0 =A0= // If it indicates the next message is also binary, keep handle_as_binary = true. Otherwise set it to false.
=A0 } else {
=A0 =A0 // e.g. assume evt.data contains text b= y default and handle it.
=A0 =A0 var text =3D ConvertToString(evt= .data); =A0// This can be .as_text() or something as David suggested
<= div>=A0 =A0 // If it indicates the next message is binary, set handle_as_bi= nary to true.
=A0 }
}

or we might embed some addi= tional header in payload to switch handling

o= nmessage =3D function(evt) {
=A0 var tmp_view =3D new Uint8Array(= evt.data);
=A0 if (tmp_view[0] & 0x01 =3D=3D 0x00) { =A0// e.g. LSB indicates= type. Here it's Text
=A0 =A0 // Convert the rest of tmp_view= to DOMString
=A0 =A0 var text =3D ConvertToString(evt.data.slice= (1));
=A0 } else { =A0// Binary
=A0 =A0 // Handle as binary event
=
=A0 }
}

Yes, it works.
<= div>
As it's cumbersome for text only users to perform co= nversion, we'd extend=A0binaryType to receiveType and add "text&qu= ot; type (or let binaryType =3D=3D null mean "text") to force rec= eived data decoded as text into DOMString and specify it as default. And as= k those who are interested in binary to set receiveType to "blob"= or "arraybuffer" and write some code like above.

----

That said, I agree with G= reg.

On Tue, Aug 16, 2011 at 09:10, Greg Wilkins= =A0<gregw@intalio= .com>=A0wrote:
The cost now is just the allocation of an opcode and a bi= t of split
personality in the APIs - which is a price that I'm pre= pared to pay to
avoid another round of design by war of attrition.

+1

Removal = of text opcode

- complicates JS code for text/bina= ry mixed use case
- delays UTF-8 decoding and requires unnecessar= y allocation of Blob/TypeArray object (if we take as_text() approach, not o= bject but allocation of memory for holding non-decoded data) for text/binar= y mixed use case
- requires rearrangement of opcode (maybe revoke 0x02 and let 0x01 gen= eric data frame type) (this change is not so painful for those who haven= 9;t exposed binary API)
-=A0(API side change may kept minimal by = making binaryType =3D null to force decoding as text.)

while just saving one opcode space (sorry if i'm mi= ssing something else important already discussed. there're too much tra= ffic on the list recently)

I'd prefer just tak= ing in text opcode as a predefined/convenient content type indication metho= d out of application layer.

Thanks,
Takeshi
--000e0cd5d0eaf79f4504aacda1a6-- From bruce@callenish.com Thu Aug 18 15:36:05 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 1FFEF21F8B3E for ; Thu, 18 Aug 2011 15:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzZ6Uoy23p63 for ; Thu, 18 Aug 2011 15:36:04 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 35A9B21F8B35 for ; Thu, 18 Aug 2011 15:36:04 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QuBCq-00085R-1G; Thu, 18 Aug 2011 15:36:56 -0700 Message-ID: <4E4D9414.1080107@callenish.com> Date: Thu, 18 Aug 2011 15:37:08 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Stephen Williams References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> <4E4D442C.20405@lig.net> <4E4D52BA.40105@callenish.com> <4E4D6C64.80206@lig.net> In-Reply-To: <4E4D6C64.80206@lig.net> Content-Type: multipart/alternative; boundary="------------040709050001000101030102" 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] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:36:05 -0000 This is a multi-part message in MIME format. --------------040709050001000101030102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 18/08/2011 12:47 PM, Stephen Williams wrote: > > Some versions of the specification say something to the effect of: "a > message is made up of one or more frames", and elsewhere that frames > can be text or binary. Fragments of a frame all need to be of the > same type I believe. There are no fragments of frames visible to Websockets, although you could argue that TCP packets fill that role. Rather, frames are fragments of messages. It would be more correct to say that messages are text or binary, rather than frames. Frames within a message have only one text/binary opcode defined on the first frame, and the rest of the frames in a message have the continuation opcode. At least that is how it is currently defined. > However, it would make sense for multiple frames that are part of a > message to be of different types. An application should only do this > for big sections (header/body, chat text/image), not every other small > field. Perhaps the default subprotocol don't need to care about > messages vs. frames, although allowing an application to indicate > logical message boundaries has all kinds of potential usage (logging, > stats, routing/load balancing). But, doable in a layered / different > subprotocol also. Not sure what you mean about an application indicating logical message boundaries. That is how the spec is currently defined. The application layer sends and receives messages. Perhaps it is my use of the definition of subprotocol which is confusing, because so far as I know I'm one of the few who uses this feature of Websockets. The default subprotocol as defined for browsers is very simple to allow the layering of further application protocols on top, ones which are not identified by the subprotocol header but are defined implicitly by the application. So you can have a chat protocol, a video streaming protocol, a conference calling protocol, almost anything at all sitting on top of the default subprotocol, and the only way to differentiate between these is based on how the application is implemented. This is how things have to work in the browser. In contrast, if you control both the client and the server you can declare a subprotocol on the connection and provide for marshalling and unmarshalling specific types of messages based on the subprotocol declared. I don't know if anyone other than myself does this. So if I wanted raw types similar to the default subprotocol, I might define utf8-message, utf8-stream, binary-message, and binary-stream as subprotocols. If I wanted either binary or text in the same connection, I might have mixed-message and mixed-stream, where the opcode differentiated between the types. The default protocol in browsers is equivalent to mixed-message. In my case the message types are much more specific, of course. > > All of this is getting close to W3C EXI (Efficient XMl Interchange), This looks like it would make a good application-level protocol if you wanted to send a SAX-like stream across Websockets in an efficient way. Apologies if I am mischaracterizing EXI, I have just glanced at it now. If you use a custom client, you could define an EXI subprotocol and have a message type that is an EXI stream. If you want to use a browser client you need to use the default subprotocol, and since EXI requires bit manipulation you would probably use a binary message. Then you could encode/decode between the binary message and the EXI stream with Javascript on the client and any way you wanted on the server. Your examples of N-Tuples and RDF could also be subprotocols or layered on the default subprotocol. All that is needed is to implement them. >> I don't know if I am understanding you correctly. Are you saying that >> if an application-level protocol wants to combine text and binary in >> a single message, it should somehow indicate to the Websockets layer >> how it should do fragmentation? > > I was thinking that a app could say, in some fashion: start message, > text frame, binary frame, end message. Right, but frames are not visible at the application level. They disappear by then. Better to have a sequence of Websocket messages that the application aggregates back into the larger message structure you want. --------------040709050001000101030102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 18/08/2011 12:47 PM, Stephen Williams wrote:

Some versions of the specification say something to the effect of: "a message is made up of one or more frames", and elsewhere that frames can be text or binary.  Fragments of a frame all need to be of the same type I believe.

There are no fragments of frames visible to Websockets, although you could argue that TCP packets fill that role. Rather, frames are fragments of messages.

It would be more correct to say that messages are text or binary, rather than frames. Frames within a message have only one text/binary opcode defined on the first frame, and the rest of the frames in a message have the continuation opcode. At least that is how it is currently defined.

  However, it would make sense for multiple frames that are part of a message to be of different types.  An application should only do this for big sections (header/body, chat text/image), not every other small field.  Perhaps the default subprotocol don't need to care about messages vs. frames, although allowing an application to indicate logical message boundaries has all kinds of potential usage (logging, stats, routing/load balancing).  But, doable in a layered / different subprotocol also.

Not sure what you mean about an application indicating logical message boundaries. That is how the spec is currently defined. The application layer sends and receives messages.

Perhaps it is my use of the definition of subprotocol which is confusing, because so far as I know I'm one of the few who uses this feature of Websockets. The default subprotocol as defined for browsers is very simple to allow the layering of further application protocols on top, ones which are not identified by the subprotocol header but are defined implicitly by the application.

So you can have a chat protocol, a video streaming protocol, a conference calling protocol, almost anything at all sitting on top of the default subprotocol, and the only way to differentiate between these is based on how the application is implemented. This is how things have to work in the browser.

In contrast, if you control both the client and the server you can declare a subprotocol on the connection and provide for marshalling and unmarshalling specific types of messages based on the subprotocol declared. I don't know if anyone other than myself does this.

So if I wanted raw types similar to the default subprotocol, I might define utf8-message, utf8-stream, binary-message, and binary-stream as subprotocols. If I wanted either binary or text in the same connection, I might have mixed-message and mixed-stream, where the opcode differentiated between the types. The default protocol in browsers is equivalent to mixed-message.

In my case the message types are much more specific, of course.


All of this is getting close to W3C EXI (Efficient XMl Interchange),

This looks like it would make a good application-level protocol if you wanted to send a SAX-like stream across Websockets in an efficient way. Apologies if I am mischaracterizing EXI, I have just glanced at it now.

If you use a custom client, you could define an EXI subprotocol and have a message type that is an EXI stream. If you want to use a browser client you need to use the default subprotocol, and since EXI requires bit manipulation you would probably use a binary message. Then you could encode/decode between the binary message and the EXI stream with Javascript on the client and any way you wanted on the server.

Your examples of N-Tuples and RDF could also be subprotocols or layered on the default subprotocol. All that is needed is to implement them.

I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation?

I was thinking that a app could say, in some fashion: start message, text frame, binary frame, end message.

Right, but frames are not visible at the application level. They disappear by then. Better to have a sequence of Websocket messages that the application aggregates back into the larger message structure you want.

--------------040709050001000101030102-- From gregw@intalio.com Thu Aug 18 15:52: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 3C23A21F884C for ; Thu, 18 Aug 2011 15:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDnRSY1wD3qx for ; Thu, 18 Aug 2011 15:52:30 -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 A4E7A21F8841 for ; Thu, 18 Aug 2011 15:52:30 -0700 (PDT) Received: by vxi29 with SMTP id 29so2633292vxi.31 for ; Thu, 18 Aug 2011 15:53:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.236 with SMTP id o12mr1297504vdg.497.1313708005238; Thu, 18 Aug 2011 15:53:25 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Thu, 18 Aug 2011 15:53:25 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Aug 2011 08:53:25 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 22:52:31 -0000 On 18 August 2011 18:55, Tobias Oberstein wrote: > So streaming an audio file will mean you cannot have "audio file" = > "message", have the data sent in small frames, and the audio > playback start immediately, since interm. might buffer the whole file? > So I need to invent my own fragmentation and put those fragments into > little WS messages? > Then why do we have message fragmentation in WS at all? We have fragments so an implementation may flush a buffer before it knows the full size of a message. We also have fragments so that future MUX implementations can avoid channel occupancy. We don't have fragments to communicate some kind of semantic boundary within a message. cheers From tobias.oberstein@tavendo.de Thu Aug 18 16:08: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 B05C111E80CC for ; Thu, 18 Aug 2011 16:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KwWYgZh1iMOp for ; Thu, 18 Aug 2011 16:08:35 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 1515C11E80BC for ; Thu, 18 Aug 2011 16:08:35 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Thu, 18 Aug 2011 16:09:30 -0700 From: Tobias Oberstein To: Greg Wilkins Date: Thu, 18 Aug 2011 16:09:28 -0700 Thread-Topic: [hybi] Framing Management Rationale Thread-Index: Acxd+aXHahs+SCOUReiXdAK1BaS+0gAAjs6Y Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:08:35 -0000 >> So streaming an audio file will mean you cannot have "audio file" =3D >> "message", have the data sent in small frames, and the audio >> playback start immediately, since interm. might buffer the whole file? >> So I need to invent my own fragmentation and put those fragments into >> little WS messages? >> Then why do we have message fragmentation in WS at all? >=20 > We have fragments so an implementation may flush a buffer before it > knows the full size of a message. > We also have fragments so that future MUX implementations can avoid > channel occupancy. >=20 > We don't have fragments to communicate some kind of semantic boundary > within a message. Yes to all three, but how does that relate to the example? > If fact there is also no requirement for an intermediary to forward > data on frame boundaries, as we allow intermediaries to aggregate > frames, thus we implicitly allow them to delay sending one frame until > the arrival of following frame(s). > > I think there is an implicit assumption, that perhaps we should make > explicit, that intermediaries should forward as soon as possible after > the receipt of a message boundary. With such an explicit No, they should forward _frames_ as soon as possible. Ideally, they should forward even data within frames as soon as possible. Moreover they should not "abuse" their right to coalesce frames to introduce unnecessary/unwante= d delays. > requirement, it would then be clear that applications that want > streaming telephony style communication should be using lots of little > messages rather than lots of frames or data blocks within frames. From jat@google.com Thu Aug 18 16:08: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 86E4921F8A58 for ; Thu, 18 Aug 2011 16:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.941 X-Spam-Level: X-Spam-Status: No, score=-105.941 tagged_above=-999 required=5 tests=[AWL=0.035, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK3EHe7VAR8x for ; Thu, 18 Aug 2011 16:08:56 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B431221F8A57 for ; Thu, 18 Aug 2011 16:08:55 -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 p7IN9h0o005906 for ; Thu, 18 Aug 2011 16:09:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1313708986; bh=2TwfNFavxayO05ojLwPeaFrzPfU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=PBUIPFtJNrg0bM8foiG/j9xrIjRN7I6toIC1nzywUwX63rLxbqfv+jf8MPzQ1+h3k lJt1/udPhpmcr3D536Byg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ZxW9hh4vTre61TN7/njMURt3Yu0Pg57r1DAk/FUTOuTVKZ19M1YcbALh2MS1q1DZL Z/bSZc+ydJ+cEa4Ul8psg== Received: from yxj19 (yxj19.prod.google.com [10.190.3.83]) by wpaz29.hot.corp.google.com with ESMTP id p7IN8Zpm006604 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 18 Aug 2011 16:09:42 -0700 Received: by yxj19 with SMTP id 19so2402092yxj.33 for ; Thu, 18 Aug 2011 16:09:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SN0hXJgSovInCvbXPnIxN+Z84/2kpzfp59Ep1EUUPfY=; b=P6UVCjBBwI6WvyJ377r0/+kDl4MzCYkkU0JzvZqedkTs0qlTUWlq0vCzfdaxEsBaEi 5OHJtcqCQSYLaAZlFXZQ== Received: by 10.151.59.14 with SMTP id m14mr116349ybk.401.1313708982283; Thu, 18 Aug 2011 16:09:42 -0700 (PDT) Received: by 10.151.59.14 with SMTP id m14mr116344ybk.401.1313708982132; Thu, 18 Aug 2011 16:09:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Thu, 18 Aug 2011 16:09:22 -0700 (PDT) In-Reply-To: <4E4D9414.1080107@callenish.com> References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> <4E4D442C.20405@lig.net> <4E4D52BA.40105@callenish.com> <4E4D6C64.80206@lig.net> <4E4D9414.1080107@callenish.com> From: John Tamplin Date: Thu, 18 Aug 2011 19:09:22 -0400 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=00151750ebe437e1e004aacfb5fb X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:08:56 -0000 --00151750ebe437e1e004aacfb5fb Content-Type: text/plain; charset=UTF-8 On Thu, Aug 18, 2011 at 6:37 PM, Bruce Atherton wrote: > Right, but frames are not visible at the application level. They disappear > by then. Better to have a sequence of Websocket messages that the > application aggregates back into the larger message structure you want. > And more importantly, framing is allowed to be changed beneath the application. An intermediary may refragment (such as when mutliplexing), or the WebSocket layer may send a message in arbitrary frames as it sees fit. -- John A. Tamplin Software Engineer (GWT), Google --00151750ebe437e1e004aacfb5fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 18, 2011 at 6:37 PM, Bruce Atherton = <bruce@callenis= h.com> wrote:
=20 =20 =20
Right, but fr= ames are not visible at the application level. They disappear by then. Better to have a sequence of Websocket messages that the application aggregates back into the larger message structure you want.

And mor= e importantly, framing is allowed to be changed beneath the application. = =C2=A0An intermediary may refragment (such as when mutliplexing), or the We= bSocket layer may send a message in arbitrary frames as it sees fit.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--00151750ebe437e1e004aacfb5fb-- From gregw@intalio.com Thu Aug 18 16:36: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 819A111E80B7 for ; Thu, 18 Aug 2011 16:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDm0LB8lhIlH for ; Thu, 18 Aug 2011 16:36:10 -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 4E51511E8073 for ; Thu, 18 Aug 2011 16:36:07 -0700 (PDT) Received: by vxi29 with SMTP id 29so2659751vxi.31 for ; Thu, 18 Aug 2011 16:36:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.94.139 with SMTP id dc11mr1347873vdb.28.1313710616435; Thu, 18 Aug 2011 16:36:56 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Thu, 18 Aug 2011 16:36:56 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Aug 2011 09:36:56 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:36:10 -0000 On 19 August 2011 09:09, Tobias Oberstein wro= te: >>> So streaming an audio file will mean you cannot have "audio file" =3D >>> "message", have the data sent in small frames, and the audio >>> playback start immediately, since interm. might buffer the whole file? >>> So I need to invent my own fragmentation and put those fragments into >>> little WS messages? >>> Then why do we have message fragmentation in WS at all? >> >> We =A0have fragments so an implementation may flush a buffer before it >> knows the full size of a message. >> We also have fragments so that future MUX implementations can avoid >> channel occupancy. >> >> We don't have fragments to communicate some kind of semantic boundary >> within a message. > > Yes to all three, but how does that relate to the example? Frames should not be exposed to an application layer, so any audio streaming application will not be able to send data in WS fragments. However an audio application can send messages. So an audio application could get an audio stream and break it into 125 bytes binary messages and pass each of those to it's WS API. Each would be sent as a message (probably as a single frame). The other end would receive each of these messages and add the binary content to it's audio play buffer. Framing overhead will be 2 bytes per 125 bytes of data. Alternately the app could use larger byte messages and attempt to optimise for TCP/IP MTU , with an overhead of 4 bytes per ~1500 bytes of data. >> If fact there is also no requirement for an intermediary to forward >> data on frame boundaries, as we allow intermediaries to aggregate >> frames, thus we implicitly allow them to delay sending one frame until >> the arrival of following frame(s). >> >> I think there is an implicit assumption, that perhaps we should make >> explicit, that intermediaries should forward as soon as possible after >> the receipt of a message boundary. =A0 With such an explicit > > No, they should forward _frames_ as soon as possible. Ideally, they shoul= d > forward even data within frames as soon as possible. Moreover they should > not "abuse" their right to coalesce frames to introduce unnecessary/unwan= ted > delays. But that is contradictory. How can an intermediary coalesce fragments without delaying the first fragment. Also, I see no reason for an intermediary to forward on data. If it is receiving a stream of 1B TCP/IP packets, then there is a lot to be gained from shielding the application servers from such inefficient traffic. Batching data in a latency vs throughput tradeoff can be a very good thing to do for many applications. There can also be a case for forwarding bytes ASAP, but I don't think that any WS application should be written to rely on such path optimisations. cheers From theturtle32@gmail.com Thu Aug 18 16:51: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 985C821F8A66 for ; Thu, 18 Aug 2011 16:51:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.431 X-Spam-Level: X-Spam-Status: No, score=-3.431 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbryNr1cOgge for ; Thu, 18 Aug 2011 16:51:56 -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 9DBDE21F8A64 for ; Thu, 18 Aug 2011 16:51:56 -0700 (PDT) Received: by bkar4 with SMTP id r4so2182799bka.31 for ; Thu, 18 Aug 2011 16:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HKhhXLT7Ue61jUr/0tEX7h8sBYKz5aNUakzjlscgFbo=; b=QAv7Lj4tlB86GR6lsVLPtVgpM1hJYDCf4g5V3NEI8J5HkdUPGDnqtqWA866WFeJ19b UAJ2ZeDNvwVIgRMH2OiXrZqdWCsPKFxNHg/SLYB6GAgjy7LIqQ2wRAun1GeVdrvT7h5f 6WokjJKYO8vlOa+222Gv0YP/mjycZ+e75XZzE= MIME-Version: 1.0 Received: by 10.205.64.79 with SMTP id xh15mr631285bkb.240.1313711570545; Thu, 18 Aug 2011 16:52:50 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Thu, 18 Aug 2011 16:52:50 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 18 Aug 2011 16:52:50 -0700 Message-ID: From: Brian To: Tobias Oberstein Content-Type: multipart/alternative; boundary=bcaec5430f147fea0d04aad04f18 Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSockets Test Suite / Browser Status X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Aug 2011 23:51:57 -0000 --bcaec5430f147fea0d04aad04f18 Content-Type: text/plain; charset=ISO-8859-1 Very nice! The test suite helped me identify and fix a few bugs in my implementation. All the tests now pass for WebSocket-Node except about 5 of the performance related ones. Turns out my implementation doesn't do so well with large messages sent with small frame sizes, but seems to do much better with larger frame sizes. I guess I have some optimization to do with handling smaller fragments. Results compared with Autobahn: http://worlize.github.com/WebSocket-Node/test-report/servers/ Brian On Wed, Aug 17, 2011 at 9:04 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Regarding WS test suites for servers and browser status .. > > Cheers, > Tobias > > 1. > Autobahn WebSockets now (0.3.2) includes an automated test suite for both > clients and servers. > > http://www.tavendo.de/autobahn/testsuite.html > > 2. > The fixes for Chrome have landed on v15 .. all green now. > > http://www.tavendo.de/autobahn/testsuite/report/clients/index.html > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --bcaec5430f147fea0d04aad04f18 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Very nice! =A0The test suite helped me identify and fix a few bugs in my im= plementation. =A0All the tests now pass for WebSocket-Node except about 5 o= f the performance related ones. =A0Turns out my implementation doesn't = do so well with large messages sent with small frame sizes, but seems to do= much better with larger frame sizes. =A0I guess I have some optimization t= o do with handling smaller fragments.

Results compared with Autobahn:

Brian


On Wed, Aug 1= 7, 2011 at 9:04 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> w= rote:
Regarding WS test suites for servers and br= owser status ..

Cheers,
Tobias

1.
Autobahn WebSockets now (0.3.2) includes an automated test suite for both c= lients and servers.

http://www.tavendo.de/autobahn/testsuite.html

2.
The fixes for Chrome have landed on v15 .. all green now.

http://www.tavendo.de/autobahn/testsuite/report/clien= ts/index.html

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

--bcaec5430f147fea0d04aad04f18-- From sdw@lig.net Thu Aug 18 17:11: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 DABDB21F8862 for ; Thu, 18 Aug 2011 17:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQAhlLfVMB9O for ; Thu, 18 Aug 2011 17:11:48 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id 963C621F871C for ; Thu, 18 Aug 2011 17:11:48 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 83179AB5DB0; Thu, 18 Aug 2011 17:23:30 -0700 (PDT) Message-ID: <4E4DAA7D.1020901@lig.net> Date: Thu, 18 Aug 2011 17:12:45 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 MIME-Version: 1.0 To: Bruce Atherton References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> <4E4D3D3A.1050800@callenish.com> <4E4D442C.20405@lig.net> <4E4D52BA.40105@callenish.com> <4E4D6C64.80206@lig.net> <4E4D9414.1080107@callenish.com> In-Reply-To: <4E4D9414.1080107@callenish.com> Content-Type: multipart/alternative; boundary="------------050209080209070906080606" Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction 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, 19 Aug 2011 00:11:50 -0000 This is a multi-part message in MIME format. --------------050209080209070906080606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Thanks for the clarification. It's somewhat bad for applications to be required to have all-text or all-binary messages or streams. Sophisticated apps will just go all binary most likely. Binary bit twiddling is possible with Javascript, java, etc. It's the bulk operations that are important to be intrinsic in some fashion, like load these bytes into a string or parse as JSON/XML/base65, etc. It seems like a mistake to confine browser / web server usage of websockets to a single "default subprotocol". Why wouldn't or shouldn't a particular Javascript web application be able to use a different subprotocol? Of course layering should work even over the default subprotocol. I have no problem hiding low-level and fragment frames from applications. However, if there's going to be typing of or in messages, it might not be bad to have sub-messages / message segments that have individual type but are considered a single message. With the current API, it seems that an application that has both text and binary needs should either A) send everything as binary and parse out the segments or B) send separate actual messages for the segments of actual messages that may be text vs. binary. sdw On 8/18/11 3:37 PM, Bruce Atherton wrote: > On 18/08/2011 12:47 PM, Stephen Williams wrote: >> >> Some versions of the specification say something to the effect of: "a message is made up of one or more frames", and elsewhere >> that frames can be text or binary. Fragments of a frame all need to be of the same type I believe. > > There are no fragments of frames visible to Websockets, although you could argue that TCP packets fill that role. Rather, frames > are fragments of messages. > > It would be more correct to say that messages are text or binary, rather than frames. Frames within a message have only one > text/binary opcode defined on the first frame, and the rest of the frames in a message have the continuation opcode. At least that > is how it is currently defined. > >> However, it would make sense for multiple frames that are part of a message to be of different types. An application should >> only do this for big sections (header/body, chat text/image), not every other small field. Perhaps the default subprotocol don't >> need to care about messages vs. frames, although allowing an application to indicate logical message boundaries has all kinds of >> potential usage (logging, stats, routing/load balancing). But, doable in a layered / different subprotocol also. > > Not sure what you mean about an application indicating logical message boundaries. That is how the spec is currently defined. The > application layer sends and receives messages. > > Perhaps it is my use of the definition of subprotocol which is confusing, because so far as I know I'm one of the few who uses > this feature of Websockets. The default subprotocol as defined for browsers is very simple to allow the layering of further > application protocols on top, ones which are not identified by the subprotocol header but are defined implicitly by the application. > > So you can have a chat protocol, a video streaming protocol, a conference calling protocol, almost anything at all sitting on top > of the default subprotocol, and the only way to differentiate between these is based on how the application is implemented. This > is how things have to work in the browser. > > In contrast, if you control both the client and the server you can declare a subprotocol on the connection and provide for > marshalling and unmarshalling specific types of messages based on the subprotocol declared. I don't know if anyone other than > myself does this. > > So if I wanted raw types similar to the default subprotocol, I might define utf8-message, utf8-stream, binary-message, and > binary-stream as subprotocols. If I wanted either binary or text in the same connection, I might have mixed-message and > mixed-stream, where the opcode differentiated between the types. The default protocol in browsers is equivalent to mixed-message. > > In my case the message types are much more specific, of course. > >> >> All of this is getting close to W3C EXI (Efficient XMl Interchange), > > This looks like it would make a good application-level protocol if you wanted to send a SAX-like stream across Websockets in an > efficient way. Apologies if I am mischaracterizing EXI, I have just glanced at it now. > > If you use a custom client, you could define an EXI subprotocol and have a message type that is an EXI stream. If you want to use > a browser client you need to use the default subprotocol, and since EXI requires bit manipulation you would probably use a binary > message. Then you could encode/decode between the binary message and the EXI stream with Javascript on the client and any way you > wanted on the server. > > Your examples of N-Tuples and RDF could also be subprotocols or layered on the default subprotocol. All that is needed is to > implement them. > >>> I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and >>> binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation? >> >> I was thinking that a app could say, in some fashion: start message, text frame, binary frame, end message. > > Right, but frames are not visible at the application level. They disappear by then. Better to have a sequence of Websocket > messages that the application aggregates back into the larger message structure you want. > -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer --------------050209080209070906080606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Thanks for the clarification.

It's somewhat bad for applications to be required to have all-text or all-binary messages or streams.  Sophisticated apps will just go all binary most likely.

Binary bit twiddling is possible with Javascript, java, etc.  It's the bulk operations that are important to be intrinsic in some fashion, like load these bytes into a string or parse as JSON/XML/base65, etc.

It seems like a mistake to confine browser / web server usage of websockets to a single "default subprotocol".  Why wouldn't or shouldn't a particular Javascript web application be able to use a different subprotocol?  Of course layering should work even over the default subprotocol.

I have no problem hiding low-level and fragment frames from applications.  However, if there's going to be typing of or in messages, it might not be bad to have sub-messages / message segments that have individual type but are considered a single message.  With the current API, it seems that an application that has both text and binary needs should either A) send everything as binary and parse out the segments or B) send separate actual messages for the segments of actual messages that may be text vs. binary.

sdw

On 8/18/11 3:37 PM, Bruce Atherton wrote:
On 18/08/2011 12:47 PM, Stephen Williams wrote:

Some versions of the specification say something to the effect of: "a message is made up of one or more frames", and elsewhere that frames can be text or binary.  Fragments of a frame all need to be of the same type I believe.

There are no fragments of frames visible to Websockets, although you could argue that TCP packets fill that role. Rather, frames are fragments of messages.

It would be more correct to say that messages are text or binary, rather than frames. Frames within a message have only one text/binary opcode defined on the first frame, and the rest of the frames in a message have the continuation opcode. At least that is how it is currently defined.

  However, it would make sense for multiple frames that are part of a message to be of different types.  An application should only do this for big sections (header/body, chat text/image), not every other small field.  Perhaps the default subprotocol don't need to care about messages vs. frames, although allowing an application to indicate logical message boundaries has all kinds of potential usage (logging, stats, routing/load balancing).  But, doable in a layered / different subprotocol also.

Not sure what you mean about an application indicating logical message boundaries. That is how the spec is currently defined. The application layer sends and receives messages.

Perhaps it is my use of the definition of subprotocol which is confusing, because so far as I know I'm one of the few who uses this feature of Websockets. The default subprotocol as defined for browsers is very simple to allow the layering of further application protocols on top, ones which are not identified by the subprotocol header but are defined implicitly by the application.

So you can have a chat protocol, a video streaming protocol, a conference calling protocol, almost anything at all sitting on top of the default subprotocol, and the only way to differentiate between these is based on how the application is implemented. This is how things have to work in the browser.

In contrast, if you control both the client and the server you can declare a subprotocol on the connection and provide for marshalling and unmarshalling specific types of messages based on the subprotocol declared. I don't know if anyone other than myself does this.

So if I wanted raw types similar to the default subprotocol, I might define utf8-message, utf8-stream, binary-message, and binary-stream as subprotocols. If I wanted either binary or text in the same connection, I might have mixed-message and mixed-stream, where the opcode differentiated between the types. The default protocol in browsers is equivalent to mixed-message.

In my case the message types are much more specific, of course.


All of this is getting close to W3C EXI (Efficient XMl Interchange),

This looks like it would make a good application-level protocol if you wanted to send a SAX-like stream across Websockets in an efficient way. Apologies if I am mischaracterizing EXI, I have just glanced at it now.

If you use a custom client, you could define an EXI subprotocol and have a message type that is an EXI stream. If you want to use a browser client you need to use the default subprotocol, and since EXI requires bit manipulation you would probably use a binary message. Then you could encode/decode between the binary message and the EXI stream with Javascript on the client and any way you wanted on the server.

Your examples of N-Tuples and RDF could also be subprotocols or layered on the default subprotocol. All that is needed is to implement them.

I don't know if I am understanding you correctly. Are you saying that if an application-level protocol wants to combine text and binary in a single message, it should somehow indicate to the Websockets layer how it should do fragmentation?

I was thinking that a app could say, in some fashion: start message, text frame, binary frame, end message.

Right, but frames are not visible at the application level. They disappear by then. Better to have a sequence of Websocket messages that the application aggregates back into the larger message structure you want.



--
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com LinkedIn: http://sdw.st/in V:650-450-UNIX (8649) V:866.SDW.UNIX V:703.371.9362 F:703.995.0407 AIM:sdw Skype:StephenDWilliams Yahoo:sdwlignet Resume: http://sdw.st/gres Personal: http://sdw.st facebook.com/sdwlig twitter.com/scienteer
--------------050209080209070906080606-- From tobias.oberstein@tavendo.de Fri Aug 19 00:05: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 681D55E8007 for ; Fri, 19 Aug 2011 00:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RshVa6TuNT5b for ; Fri, 19 Aug 2011 00:05:47 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 747245E8003 for ; Fri, 19 Aug 2011 00:05:47 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Fri, 19 Aug 2011 00:06:42 -0700 From: Tobias Oberstein To: Brian Date: Fri, 19 Aug 2011 00:06:41 -0700 Thread-Topic: [hybi] WebSockets Test Suite / Browser Status Thread-Index: AcxeAfORkhPROLdOQE+KpgYF0yG2MQAPJgKs Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSockets Test Suite / Browser Status 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, 19 Aug 2011 07:05:48 -0000 > Very nice! =A0The test suite helped me identify and fix a few bugs in my > implementation. =A0All the tests now pass for WebSocket-Node except about= 5 of cool! nice to hear that is has some value. =20 > the performance related ones. =A0Turns out my implementation doesn't do s= o well > with large messages sent with small frame sizes, but seems to do much bet= ter > with larger frame sizes. =A0I guess I have some optimization to do with h= andling > smaller fragments. >=20 > Results compared with Autobahn: >=20 > http://worlize.github.com/WebSocket-Node/test-report/servers/ interesting: for the performance tests (apart from heavily fragmented/chopped up ones), your implementation is twice as fast. that was under equal conditions? and that is node.js/v8? could you point me to the place in your code that does the demasking? i'd be interested, since that's the bottleneck in my code .. did already experiment with a couple of options. something which is trivial to do performant in C isn't the same with Python. From theturtle32@gmail.com Fri Aug 19 00:46: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 DEA4321F8841 for ; Fri, 19 Aug 2011 00:46:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.459 X-Spam-Level: X-Spam-Status: No, score=-3.459 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jm+xd6QO0Q8f for ; Fri, 19 Aug 2011 00:46:30 -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 8270921F883A for ; Fri, 19 Aug 2011 00:46:29 -0700 (PDT) Received: by bkar4 with SMTP id r4so2424698bka.31 for ; Fri, 19 Aug 2011 00:47:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ILR7c7gRMfPwRdlWJiU70/p/xwnR8dYhVv8QJwwiQkA=; b=YiqCorkAmKYBz50s6vYiaf9vqfWkDux05GR484uWHq88Advd8ivGsZpgQPMuCfk4k+ PZmzunN090kK14CsaetOmo4AbuWqRXkkL19u9n7UoU+PGWB1tgacpRM5yHmGi2aSFO5k t+NktK8qr+hRdirIfqIuIwuX7hXB5jt+PywZQ= MIME-Version: 1.0 Received: by 10.204.136.79 with SMTP id q15mr230088bkt.136.1313740039272; Fri, 19 Aug 2011 00:47:19 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Fri, 19 Aug 2011 00:47:19 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Aug 2011 00:47:19 -0700 Message-ID: From: Brian To: Tobias Oberstein Content-Type: multipart/alternative; boundary=0015174bf02e5e3a7e04aad6f04e Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSockets Test Suite / Browser Status 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, 19 Aug 2011 07:46:31 -0000 --0015174bf02e5e3a7e04aad6f04e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Aug 19, 2011 at 12:06 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > > Results compared with Autobahn: > > > > http://worlize.github.com/WebSocket-Node/test-report/servers/ > > interesting: for the performance tests (apart from heavily > fragmented/chopped up ones), your implementation is twice as fast. > > that was under equal conditions? and that is node.js/v8? > My implementation is indeed for node.js/v8. Yes, equal conditions. I ran the Autobahn echo server on port 9000 and my echo server on port 8080, then configured fuzzing_client_spec.json to test both consecutively. The tests were run on my MacBook Pro (Summer 2009): Core 2 Duo 2.66 GHz 8GB Memory Mac OS X 10.7.1 Python v2.7.1 Node.js v0.4.10 My echo server is here: https://github.com/Worlize/WebSocket-Node/blob/master/test/echo-server.js > could you point me to the place in your code that does the demasking? > Sure. Here it is: https://github.com/Worlize/WebSocket-Node/blob/996c70e442a35dfc8c61e55e5afa7ca0b319afd4/lib/WebSocketFrame.js#L146 > i'd be interested, since that's the bottleneck in my code .. did already > experiment with a couple of options. something which is trivial to do > performant in C isn't the same with Python. > Interesting. I think the bottleneck in my code is memory allocations and buffer copying. :-/ Probably going to refactor how I'm receiving bytes off the wire, add a streaming interface, and refactor my frame aggregation code to use the streaming interface. Cheers, Brian --0015174bf02e5e3a7e04aad6f04e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Aug 19, 2011 at 12:06 AM, Tobias Oberste= in <tob= ias.oberstein@tavendo.de> wrote:
> Results compared with Autobahn:
>
> http://worlize.github.com/WebSocket-Node/test-report/= servers/

interesting: for the performance tests (apart from heavily
fragmented/chopped up ones), your implementation is twice as fast.

that was under equal conditions? and that is node.js/v8?

My implementation is indeed for node.js/v8.
Yes= , equal conditions. =A0I ran the Autobahn echo server on port 9000 and my e= cho server on port 8080, then configured fuzzing_client_spec.json to test b= oth consecutively. =A0The tests were run on my MacBook Pro (Summer 2009):

Core 2 Duo 2.66 GHz
8GB Memory
Mac = OS X 10.7.1
Python v2.7.1
Node.js v0.4.10
My echo server is here:

=A0
could you point me to the place in your code that does the demasking?

Sure. =A0Here it is:

=A0
i'd be interested, since that's the bottleneck in my code .. did al= ready
experiment with a couple of options. something which is trivial to do
performant in C isn't the same with Python.

Interesting. =A0I think the bottleneck in my code is memory alloca= tions and buffer copying. =A0:-/ =A0Probably going to refactor how I'm = receiving bytes off the wire, add a streaming interface, and refactor my fr= ame aggregation code to use the streaming interface.


Cheers,
Brian

--0015174bf02e5e3a7e04aad6f04e-- From tobias.oberstein@tavendo.de Fri Aug 19 03:26: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 930B921F8AF7 for ; Fri, 19 Aug 2011 03:26:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.13 X-Spam-Level: X-Spam-Status: No, score=-1.13 tagged_above=-999 required=5 tests=[AWL=-1.297, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AyarGs2XHQNr for ; Fri, 19 Aug 2011 03:26:42 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id A85C821F8A69 for ; Fri, 19 Aug 2011 03:26:42 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Fri, 19 Aug 2011 03:27:38 -0700 From: Tobias Oberstein To: Takeshi Yoshino , John Tamplin Date: Fri, 19 Aug 2011 03:26:50 -0700 Thread-Topic: [hybi] Binary/Text Distinction Thread-Index: Acxd5zF132QEns1xQ42bpOscDsSUxAAb7r7A Message-ID: <634914A010D0B943A035D226786325D422C0B9AD38@EXVMBX020-12.exch020.serverdata.net> References: <20110817114445.ef1fc80126c74c6c202a919c41c7bb0b.991ef41dc9.wbe@email03.secureserver.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 19 Aug 2011 10:26:43 -0000 I would like to attempt at a concrete use case: "exchange WebGL scene data via WebSockets" to gain more insight. =3D=3D >From the WebGL spec: 5.12 ArrayBuffer and Typed Arrays Vertex, index, texture, and other data is transferred to the WebGL implemen= tation using the ArrayBuffer and views defined in the Typed Array specifica= tion [TYPEDARRAYS]. All of the typed array views except Float64Array may be= used in conjunction with WebGL; OpenGL ES 2.0, and therefore WebGL, does n= ot support double-precision floating-point data. http://www.khronos.org/registry/webgl/specs/1.0/#5.12 =3D=3D Consider the following var scene =3D {}; scene.objects =3D []; scene.objects[0] =3D {id: 100, label: "tiger", vertices: new Ar= rayBuffer(4 * 3 * 5) }; var view =3D new Float32Array(scene.objects[0].vertices); for (i =3D 0; i < view.length; ++i) view[i] =3D 100 * i; console.log(scene); console.log(JSON.stringify(scene)); a "fake scene" with a vertex list containing 5 triples of floats (bare with= me .. it's fake, but I guess you get what I mean). Ideally, I would for sending just do websocket.send(JSON.stringify(scene)) and for receiving onmessage(e) { scene =3D JSON.parse(e.data); } to roundtrip, and be done. =3D=3D That won't work today .. the output of JSON.stringify(scene) Firefox {"objects":[{"id":100,"label":"tiger","vertices":{}}]} Chrome {"objects":[{"id":100,"label":"tiger","vertices":{"byteLength":60}}]} Apparantly, the JSON object behaves differently when marshaling JS ArrayBuf= fers. Both behaviors of course are somewhat insufficient at what we try. =3D=3D Here are 2 options: 1) Extend JSON (the serialization format) for having a "binary string" type (i= .e. base64 encoded string, but enclosed in brackets, like vs "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vd" The former could be used to automatically marshal/demarshal JavaScript Arra= yBuffer's This has nothing to do with WebSockets, but with JSON (the format) and with= how the JSON (the JS object) in JS works. 2) Marshal/demarshal JS ArrayBuffers as {"ArrayBuffer": "TWFuIGlzIGRpc3Rpbmd1aXNoZWQsIG5vd"} and have some magic built into the JS JSON object so that it can do the rig= ht thing when it encounters a JSON dict with a single key that is equal to "ArrayBuffer". Again, that has nothing to do with WebSockets, but only how the JSON object= in JS works. =3D=3D I think the use case is valid, but it should not be solved in the WebSocket= s protocol by introducing "mixed text/binary" / "structured" messages. From tobias.oberstein@tavendo.de Fri Aug 19 03:35:47 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 E715E21F8802 for ; Fri, 19 Aug 2011 03:35:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMJteIIOKZp5 for ; Fri, 19 Aug 2011 03:35:47 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id D931221F886A for ; Fri, 19 Aug 2011 03:35:46 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Fri, 19 Aug 2011 03:36:43 -0700 From: Tobias Oberstein To: Greg Wilkins Date: Fri, 19 Aug 2011 03:35:56 -0700 Thread-Topic: [hybi] Framing Management Rationale Thread-Index: Acxd/7pZiYYlEP6WSZKBP86fkaYXwAAWuydg Message-ID: <634914A010D0B943A035D226786325D422C0B9AD39@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Framing Management Rationale 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, 19 Aug 2011 10:35:48 -0000 >>>> So streaming an audio file will mean you cannot have "audio file" =3D= =20 >>>> "message", have the data sent in small frames, and the audio=20 >>>> playback start immediately, since interm. might buffer the whole file? >>>> So I need to invent my own fragmentation and put those fragments=20 >>>> into little WS messages? >>>> Then why do we have message fragmentation in WS at all? >>> >>> We =A0have fragments so an implementation may flush a buffer before it= =20 >>> knows the full size of a message. >>> We also have fragments so that future MUX implementations can avoid=20 >>> channel occupancy. >>> >>> We don't have fragments to communicate some kind of semantic boundary=20 >>> within a message. >> >> Yes to all three, but how does that relate to the example? >Frames should not be exposed to an application layer, so any audio streami= ng application will not be able to send data in WS fragments. Frames should not be exposed, but that does not imply that an application c= annot stream. InputStream is =3D new InputStream("myaudio.mp3"); ws.sendBinaryMessage(is); The latter returns immediately, the underlying WebSockets implementation ju= st pulls the input stream (in arbitrary chops), generates frames and pushes data out= on TCP. It's a question of API, not protocol. >> If fact there is also no requirement for an intermediary to forward=20 >> data on frame boundaries, as we allow intermediaries to aggregate=20 >> frames, thus we implicitly allow them to delay sending one frame=20 >> until the arrival of following frame(s). >> >> I think there is an implicit assumption, that perhaps we should make=20 >> explicit, that intermediaries should forward as soon as possible=20 >> after the receipt of a message boundary. =A0 With such an explicit > > No, they should forward _frames_ as soon as possible. Ideally, they=20 > should forward even data within frames as soon as possible. Moreover=20 > they should not "abuse" their right to coalesce frames to introduce=20 > unnecessary/unwanted delays. > But that is contradictory. How can an intermediary coalesce fragments wi= thout delaying the first fragment. Yes, that's why I've said "should" and "not abuse". What is the value of allowing intermediaries to coalesce frames? I can see the benfit some might have to fragment, but coalesce .. what's th= e use case for intermediaries? From gregw@intalio.com Fri Aug 19 04:27: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 36B0C21F8A30 for ; Fri, 19 Aug 2011 04:27:49 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47M4inQ6TviC for ; Fri, 19 Aug 2011 04:27:48 -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 9A7BB21F8761 for ; Fri, 19 Aug 2011 04:27:48 -0700 (PDT) Received: by vws12 with SMTP id 12so2892743vws.31 for ; Fri, 19 Aug 2011 04:28:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.26.236 with SMTP id o12mr1867019vdg.497.1313753321484; Fri, 19 Aug 2011 04:28:41 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Fri, 19 Aug 2011 04:28:41 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0B9AD39@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9AD39@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 19 Aug 2011 21:28:41 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Framing Management Rationale 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, 19 Aug 2011 11:27:49 -0000 On 19 August 2011 20:35, Tobias Oberstein wrote: > Frames should not be exposed, but that does not imply that an application cannot stream. > > InputStream is = new InputStream("myaudio.mp3"); > ws.sendBinaryMessage(is); > > The latter returns immediately, the underlying WebSockets implementation just pulls > the input stream (in arbitrary chops), generates frames and pushes data out on TCP. > > It's a question of API, not protocol. Except that we currently don't know if the protocol is required to expedite frame delivery. An implementation might read the entire input stream to create a single frame message containing the entire mp3. > What is the value of allowing intermediaries to coalesce frames? > I can see the benfit some might have to fragment, but coalesce .. what's the use case for intermediaries? Consider an intermediary that is muxing many different connections (from clients) onto a smaller number of connections to an application server. This is often done in HTTP now to reduce the number on connections on the application server. The Mux will fragment large inbound and outbound messages to small frames in order to avoid channel occupancy. However there is no reason that the outbound messages should be sent in small frames and there may be some benefits in aggregating back to larger frames, specially if there is some other per frame extension involved. Conversely, inbound messages might arrive in many tiny frames due to some other transport/client limitation, an intermediary might aggregate those into an entire message before forwarding to the application server - so the server does not need to deal with any IO on a channel until the entire message has arrived at the gateway and only has the LAN to cross. regards From jamie@shareable.org Fri Aug 19 12:45: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 9616D21F8B73 for ; Fri, 19 Aug 2011 12:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFO5NB7rk5NW for ; Fri, 19 Aug 2011 12:45:55 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id D4E1421F8B6E for ; Fri, 19 Aug 2011 12:45:54 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QuV1j-0003KV-NN; Fri, 19 Aug 2011 20:46:47 +0100 Date: Fri, 19 Aug 2011 20:46:47 +0100 From: Jamie Lokier To: John Tamplin Message-ID: <20110819194647.GE11512@jl-vm1.vm.bytemark.co.uk> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Framing Management Rationale 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, 19 Aug 2011 19:45:55 -0000 John Tamplin wrote: > On Wed, Aug 17, 2011 at 2:36 PM, Bob Gezelter <[1]gezelter@rlgsc.com> > wrote: > > The stated goal was assuring performance by minimizing > overhead. This was accompanied by a reference to "sendfile." > Presumably, > the "sendfile" referenced is the LINUX sendfile() (described in the > LINUX man pages at > [2]http://www.kernel.org/doc/man-pages/online/pages/man2/sendfile.2. > html) Most server OSes have an equivalent function, sendfile() is just the Linux name for it. It's not a Linux feature, it wasn't even first. >  "...Because this copying is done within the kernel, sendfile() is > more efficient than the combination of read(2) and write(2), which would > require transferring data to and from user space." > This description is not directly translatable into a network > context. sendfile() does not eliminate all overhead of the disk file > operation, The man page is misleading. sendfile() does eliminate most of the copying done in software. But that's not really the point, because copying isn't slow on modern systems. The other performance characteristic is that it *shares memory* among large numbers of sockets. It applies to dynamically produced messages too -- not just files. An application which generates transient data in memory and will broadcast the same large data fragments to many WS clients, can use sendfile() on a shared memory file, or its relative vmsplice(), to use the same memory buffers in the queued of large numbers of outgoing sockets. And these are just what current OSes provide. > the man page only describes eliminating the outermost layer: copying > data to/from the user-mode process. Yes, but the man page doesn't cover all the salient characteristics. > In the network space, this is > particularly misleading. A WebSocket protocol API equivalent of > sendfile() would also have to do significant processing even while > sending an entire, arbitrary file as a single frame. >From the server to client, because there's no masking in that direction, it can share the memory. (Or has the WS spec changed on this again?) At the level of (server) WebSocket APIs, you don't necessarily need any more API for the implementation to be using these techniques underneath its normal sending and buffering procedures. Yes it does significant processing, but less than you might think. In particular, it does not have to process every TCP packet -- that is offloaded to the network card these days. > The frame, and indeed message overhead would not be significant > in this case That's precisely the point. > With all due respect to the writer, such usage is > not consistent with good use of the WebSocket protocol, the > underlying transport protocol (presently TCP), or the physical > realities of network communications. With respect, good use of WebSocket protocol is unknown at this point. Sendfile-like mechanisms work well with TCP, largely because server-level network hardware provides acceleration for it. > Note I was not the one advocating this use case as the reason > for supporting 2^63-byte frames - just explaining the rationale > as it was given. sendfile() is *not* the reason for 2^63 frames. Please don't perpetuate that myth. That accolade belongs to "no rarely exercised code branch due to arbitrary but occasionally reached limit". For sendfile, 2^24 would be plenty. The sendfile rationale is that 2^16 limit is a bit small if there's no good reason for it (being, after all, the size of a single TCP packet over jumbo frames ethernet.) Whether sendfile, or indeed larger than 2^16 frames, are useful will be found by implementation experience, and changes in the net over the coming years. The point was to not rule out a plausible implementation strategy, especially where large numbers of clients connect to few servers, in the absence of a good reason. -- Jamie From jamie@shareable.org Fri Aug 19 13:11:05 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 86D6821F8B4B for ; Fri, 19 Aug 2011 13:11:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laXupgnpjwfE for ; Fri, 19 Aug 2011 13:11:02 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB4421F8ACA for ; Fri, 19 Aug 2011 13:11:02 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QuVQ5-0003OJ-65; Fri, 19 Aug 2011 21:11:57 +0100 Date: Fri, 19 Aug 2011 21:11:57 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110819201157.GF11512@jl-vm1.vm.bytemark.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Framing Management Rationale 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, 19 Aug 2011 20:11:05 -0000 Greg Wilkins wrote: > Frames should not be exposed to an application layer, so any audio > streaming application will not be able to send data in WS fragments. > However an audio application can send messages. So an audio > application could get an audio stream and break it into 125 bytes > binary messages and pass each of those to it's WS API. Each would be > sent as a message (probably as a single frame). The other end would > receive each of these messages and add the binary content to it's > audio play buffer. > > Framing overhead will be 2 bytes per 125 bytes of data. Alternately > the app could use larger byte messages and attempt to optimise for > TCP/IP MTU , with an overhead of 4 bytes per ~1500 bytes of data. WS design means streaming applications which don't need WS message boundaries must create artificial boundaries just for this purpose and do their own fragmentation layer in the app, and an intermediary is forbidden from coalescing those, even though some applications would be happy to have them coalesced. I.e. those apps have to invent their own app-level fragmentation protocol on top of WS. I'm thinking of anything that looks like byte-stream-over-WebSocket, which if you think about it, includes MP3-over-WebSocket. > On 19 August 2011 09:09, Tobias Oberstein wrote: > > No, they should forward _frames_ as soon as possible. Ideally, they should > > forward even data within frames as soon as possible. Moreover they should > > not "abuse" their right to coalesce frames to introduce unnecessary/unwanted > > delays. It's worse than that: They can't safely forward partial frame data at all, as the remainder of the frame to be forwarded may not arrive in a useful time, and then the intermediary is stuck, if it needs to send a control (shutdown, error, MUX...). For control frames to work properly, an intermediary MUST either delay whole frames, or refragment to what it has available on sending. Like TCP and HTTP chunked encoding do. > But that is contradictory. How can an intermediary coalesce fragments > without delaying the first fragment. Easily. I believe the smart way is coalescing when the previous outgoing fragment hasn't left the system, be it contention, receiver flow control, or just not yet got around to scheduling the previous transmit yet. In other words, look at the outgoing queue. An intermediary like that would get rid of _all_ fragment boundaries as soon as it receives the data, and it would insert new fragment boundaries when it sends data to represent the amount available in the send buffer at that moment. > Also, I see no reason for an intermediary to forward on data. If it > is receiving a stream of 1B TCP/IP packets, then there is a lot to be > gained from shielding the application servers from such inefficient > traffic. Batching data in a latency vs throughput tradeoff can be a > very good thing to do for many applications. Yes. But that argument also applies when you get a fragment boundary. The received fragment boundary gives no useful information about the efficiency of the next hop. And since it also has no behaviour the app can depend on, there is no reason to do anything with it other than discarding it, and regenerate fragments when sending according to real-time send buffer size. Fragment boundaries should be treated like HTTP chunks or TCP segments. Something to be discarded when you receive the data, even if you're an intermediary. They only exist so the remote sender has a way to inject something other than more bytes of the same message. > There can also be a case for forwarding bytes ASAP, but I don't think > that any WS application should be written to rely on such path > optimisations. I agree, which is why I asked for the forwarding behaviour to be flagged explicitly in each frame, so things like byte-stream-over-Websocket don't have to invent their _own_ intermediary-unfriendly fragmentation layer on top of WS messages. All the best, -- Jamie From jamie@shareable.org Fri Aug 19 13:37: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 BAB7811E80C6 for ; Fri, 19 Aug 2011 13:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lN-EbABSQU81 for ; Fri, 19 Aug 2011 13:37:09 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id D70C321F886A for ; Fri, 19 Aug 2011 13:37:08 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QuVpL-0003QZ-3A; Fri, 19 Aug 2011 21:38:03 +0100 Date: Fri, 19 Aug 2011 21:38:03 +0100 From: Jamie Lokier To: Greg Wilkins Message-ID: <20110819203803.GG11512@jl-vm1.vm.bytemark.co.uk> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Framing Management Rationale 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, 19 Aug 2011 20:37:09 -0000 Greg Wilkins wrote: > My own implementation can handle any sized frames via a fixed sized > receive buffer. But I don't know how large to make that receive > buffer - if I guess 8k, but senders only ever send 2k frames, then I'm > wasting 6k per connection. If I guess 2k, but senders use 8k frames, > then I have the inefficiencies of doing 4x the "frame" handling that I > need to. An application can set a max message size, but that is is > unicode characters and may not reflect a max frame size well, > specially if the sender is limiting their frames sizes. That doesn't make sense. If sender has 8k of data for you, it will send 4 x 2k frames or 1 x 8k frame, depending on "max frame size". Either way, your efficient buffer size is 8k bytes, which you then parse into frames, and pass around for any special processing. If you are receiving from the socket 2k bytes at a time when there's 8k available (whether in multiple fragments or one), not only is that inefficient, and it doesn't help you anyway because you will still have fragment boundaries unaligned with the your buffer. > For my implementation, it would at least allow significant memory > savings by right sizing the buffers. I don't see how it helps, because the "right size" buffers are whatever will receive the incoming socket bytes in the fewest socket-receive operations with minimal wasted space -- which depends on the byte rate of the sender (relative to receive socket-read rate), which is not affected by the fragment size. You may well take the received byte stream (received as blocks of bytes from the socket) and split it into WS fragments, maybe copying them into separate fragment buffers if you are doing fancy processing, or to keep the code simple. But when you do that parse & split, you know *exactly* the "right size" to allocate for each fragment. (There are strategies for efficiently limiting unused buffer space at the blocks-received-from-socket level, but that's another topic.) > I think the ability to declare a max frame size is useful, even in the > absence of a frame-too-large error. I agree, it is a sensible option, but not for the "right size buffer" reason. It's for the "keep it reasonable for my application doesn't like working on big buffers" reason. Very similar to TCP MSS, and invisible to applications in the same way. Except WS "max frame size" should be hop-by-hop (unlike TCP MSS) -- there is no point in it being end-to-end, as fragments themselves are hop-by-hop. > The specification explicitly allows senders to limit frame size by > their own buffer size. If we allow such limits to exist, I fail to > see the benefits of keeping those limits secret. But do make it hop-by-hop. It would be silly if the final receiver limited the frame size for hops other than the last one; there is no efficiency gain from that. > I do understand Andy's concern that max frame size might be wink to > poor receiver implementations - so how about a third option: An > optional header to declare min/max frame size, but remove the > frame-too-large error so as to indicate that implementations must be > able to handle any frame size up to their max message size limit. Who's min/max frame size goes in the header? Intermediary 1, intermediary 2, or the end receiver? All the best, -- Jamie From jamie@shareable.org Fri Aug 19 13:54: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 0833811E80B2 for ; Fri, 19 Aug 2011 13:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u213Y9g31nik for ; Fri, 19 Aug 2011 13:54:00 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id E68B311E80A1 for ; Fri, 19 Aug 2011 13:53:58 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QuW5c-0003US-6c; Fri, 19 Aug 2011 21:54:52 +0100 Date: Fri, 19 Aug 2011 21:54:52 +0100 From: Jamie Lokier To: =?utf-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= Message-ID: <20110819205452.GH11512@jl-vm1.vm.bytemark.co.uk> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> <4E4CCB53.3080401@warmcat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4E4CCB53.3080401@warmcat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Framing Management Rationale / no allocation in frame processing layer 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, 19 Aug 2011 20:54:01 -0000 "Andy Green (林安廸)" wrote: > On 08/17/2011 07:36 PM, Somebody in the thread at some point said: > If you read Greg's reply he tells you: > > ''...My own implementation can handle any sized frames via a fixed sized > receive buffer. ...'' [1] > > The point is he has written the critical frame processing code at > hand as have I. What he's explaining to you is that there is no > per-frame malloc or whatever you had in mind for the frame > processing which is the basis of your suddenly jumping to a frame > mtu being necessary due to "memory fragmentation" and "garbage > collection". No allocations are happening in frame layer at all. > > Instead at the frame processing layer, there's a fixed size buffer > allocated either on the stack frame or static if it's done > singlethreaded. That buffer size is unrelated to the size of > websocket frames expected to appear. So, you could set it to 64K or > 4K or what you think is good according to how many packets might be > waiting in the OS to fill it; in singlethreaded method like > libwebsockets there's only one of them in the whole library instance > so the size is not critical resourcewise. > > You read() packet content into that buffer, parse out the headers > bytewise so you don't care if they straddle a buffer boundary, and > pass the remainder of the buffer or the frame payload in there up to > the message handling layer, via a pointer in my case. The message > handler says, "oh, nice, xyz bytes more message came, I shall take > care of that". And if there is more left in the fixed buffer, or > more packets waiting without blocking, then we go around again > passing that payload up to the message layer. Well put. > That is why I say frame size, framing as a whole has no meaning > outside of stripping it off and immediately passing the payload up > as message payload. We should have language to actively discourage > assumption that received frame sizes or start and end have anything > to do with what was sent to avoid fragility from intermediaries > doing their legit thing. I agree completely - any "meaning" of the frame boundary should be actively encouraged, and examples should show frame boundaries being stripped at the point they are received, so nothing else sees them. That includes intermediaries receiving frames to be forwarded. They should strip away received boundaries straight away, and introduce _their own_ frame boundaries on the sending side. Frames are fundamentally a hop-by-hop concept -- or they should be. Messages are the end-to-end concept. This is exactly the same as HTTP's chunked encoding (hop-by-hop) and HTTP messages (end-to-end). (Don't confuse this with TCP's segments that live end-to-end and are hidden at the final receiver. That's the wrong example.) > Nowhere in there does negotiation of max frame size buy us anything. > Even if you want framing to react dynamically to throughput > conditions, with control frame latency in mind, that's something the > sender and intermediary senders can monitor and do themselves > without any negotiation with the receiver. I agree completely. Each sender's job is to decide where to insert frame boundaries. This includes intermediary senders. Consequently, frames cannot have any application-dependent meaning -- including any aspect of dependable timing. Really that leaves only two extremes for forwarding guarantees: Eagerly forward each byte subject to local buffering optimisations (like HTTP CONNECT proxies used for HTTPS must do), or permit delaying up to a message boundary. There are heuristics, policies and "best practice" options in the middle. They might be what happens (given it is not specified, and cannot be entirely specified in the real world of TCP.) But whatever, they should not care about fragment boundaries; those should be stripped as soon as received. (In my humble opinion of course :-) All the best, -- Jamie From sh@defuze.org Fri Aug 19 15:08:11 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 13F3E11E8082 for ; Fri, 19 Aug 2011 15:08:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.676 X-Spam-Level: X-Spam-Status: No, score=-2.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_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvJQKL4EtXhB for ; Fri, 19 Aug 2011 15:08:10 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6522F21F8BCB for ; Fri, 19 Aug 2011 15:08:10 -0700 (PDT) Received: by pzk33 with SMTP id 33so9206090pzk.18 for ; Fri, 19 Aug 2011 15:09:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.187.3 with SMTP id k3mr112925wff.233.1313791747966; Fri, 19 Aug 2011 15:09:07 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Fri, 19 Aug 2011 15:09:07 -0700 (PDT) X-Originating-IP: [82.229.61.197] In-Reply-To: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> Date: Sat, 20 Aug 2011 00:09:07 +0200 Message-ID: From: Sylvain Hellegouarch To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd2dd0672460004aae2faf3 Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSockets Test Suite / Browser Status 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, 19 Aug 2011 22:08:11 -0000 --000e0cd2dd0672460004aae2faf3 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 17, 2011 at 6:04 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Regarding WS test suites for servers and browser status .. > > Cheers, > Tobias > > 1. > Autobahn WebSockets now (0.3.2) includes an automated test suite for both > clients and servers. > > http://www.tavendo.de/autobahn/testsuite.html > > 2. > The fixes for Chrome have landed on v15 .. all green now. > > http://www.tavendo.de/autobahn/testsuite/report/clients/index.html > > > Thanks a lot Tobias. Your test suite is very useful. I've found a few issues with my WebSocket support in ws4py [1]. Now all the tests pass against the CherryPy server aside from some performance tests which I need to address. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach [1] https://github.com/Lawouach/WebSocket-for-Python --000e0cd2dd0672460004aae2faf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 17, 2011 at 6:04 PM, Tobias = Oberstein <tobias.oberstein@tavendo.de> wrote:
Regarding WS test suites for servers and browser status ..

Cheers,
Tobias

1.
Autobahn WebSockets now (0.3.2) includes an automated test suite for both c= lients and servers.

http://www.tavendo.de/autobahn/testsuite.html

2.
The fixes for Chrome have landed on v15 .. all green now.

http://www.tavendo.de/autobahn/testsuite/report/clien= ts/index.html




Thanks a lot Tobias= . Your test suite is very useful. I've found a few issues with my WebSo= cket support in ws4py [1]. Now all the tests pass against the CherryPy serv= er aside from some performance tests which I need to address.

--
- Sylvain
= http://www.defuze.org
http:/= /twitter.com/lawouach

--000e0cd2dd0672460004aae2faf3-- From webmaster@zaphoyd.com Fri Aug 19 14:55:36 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 371FF21F8B39 for ; Fri, 19 Aug 2011 14:55:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIWia8ouCErZ for ; Fri, 19 Aug 2011 14:55:35 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1F17E21F8B1B for ; Fri, 19 Aug 2011 14:55:35 -0700 (PDT) Received: from belgaer.uchicago.edu ([128.135.45.61]:63064) by sh78.surpasshosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QuX3E-0003YK-Oe for hybi@ietf.org; Fri, 19 Aug 2011 17:56:29 -0400 From: Peter H Thorson Mime-Version: 1.0 (Apple Message framework v1244.3) Content-Type: multipart/alternative; boundary="Apple-Mail=_97F29EB3-717E-4AB4-A1D4-55166C456E45" Date: Fri, 19 Aug 2011 16:56:27 -0500 In-Reply-To: To: hybi@ietf.org References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> Message-Id: <16EE6DAE-806C-4311-83B1-6974A2B813EB@zaphoyd.com> X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Fri, 19 Aug 2011 15:33:16 -0700 Subject: Re: [hybi] WebSockets Test Suite / Browser Status 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, 19 Aug 2011 21:56:35 -0000 --Apple-Mail=_97F29EB3-717E-4AB4-A1D4-55166C456E45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 2011-Aug-18, at 18:52, Brian wrote: > Very nice! The test suite helped me identify and fix a few bugs in my = implementation. All the tests now pass for WebSocket-Node except about = 5 of the performance related ones. Turns out my implementation doesn't = do so well with large messages sent with small frame sizes, but seems to = do much better with larger frame sizes. I guess I have some = optimization to do with handling smaller fragments. >=20 > Results compared with Autobahn: >=20 > http://worlize.github.com/WebSocket-Node/test-report/servers/ >=20 > Brian >=20 >=20 > On Wed, Aug 17, 2011 at 9:04 AM, Tobias Oberstein = wrote: > Regarding WS test suites for servers and browser status .. >=20 > Cheers, > Tobias >=20 > 1. > Autobahn WebSockets now (0.3.2) includes an automated test suite for = both clients and servers. >=20 > http://www.tavendo.de/autobahn/testsuite.html >=20 > 2. > The fixes for Chrome have landed on v15 .. all green now. >=20 > http://www.tavendo.de/autobahn/testsuite/report/clients/index.html >=20 I want to second this, this server test suite found a number of = oversights for me to fix and has been very helpful overall for debugging = a websocket server. For anyone interested, here is a report done of the autobahn server vs = my websocketpp server written in C++ using boost asio's asynchronous = networking library. So far my effort has been focused on correctness and = clarity and less on performance. Unsurprisingly, unmasking in C++ seems = to be less a bottleneck than the rest of the frame header and network io = overhead. http://zaphoyd.com/websocketpp/autobahn-report/ Lastly, can you clarify the difference between fragments and "chops", is = the difference just that the chops are very small? Thanks again, Peter= --Apple-Mail=_97F29EB3-717E-4AB4-A1D4-55166C456E45 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Very nice! =  The test suite helped me identify and fix a few bugs in my = implementation.  All the tests now pass for WebSocket-Node except = about 5 of the performance related ones.  Turns out my = implementation doesn't do so well with large messages sent with small = frame sizes, but seems to do much better with larger frame sizes. =  I guess I have some optimization to do with handling smaller = fragments.

Results compared with = Autobahn:

<= br>
Brian

I want to = second this, this server test suite found a number of oversights for me = to fix and has been very helpful overall for debugging a websocket = server.

For anyone interested, here is a report = done of the autobahn server vs my websocketpp server written in C++ = using boost asio's asynchronous networking library. So far my effort has = been focused on correctness and clarity and less on = performance. Unsurprisingly, unmasking in C++ seems to be less a = bottleneck than the rest of the frame header and network io = overhead.


Lastly, = can you clarify the difference between fragments and "chops", is the = difference just that the chops are very = small?

Thanks = again,

Peter
= --Apple-Mail=_97F29EB3-717E-4AB4-A1D4-55166C456E45-- From theturtle32@gmail.com Fri Aug 19 16:20: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 3FE9421F8B7D for ; Fri, 19 Aug 2011 16:20:09 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7w4CR0H8obm for ; Fri, 19 Aug 2011 16:20:08 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 704BD21F8B79 for ; Fri, 19 Aug 2011 16:20:08 -0700 (PDT) Received: by pzk33 with SMTP id 33so9352832pzk.18 for ; Fri, 19 Aug 2011 16:21:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=IRLFm2BMHS/qBOR/IcQP33bWYgISzdLltmI/PU1ENHA=; b=BV9ggsdSEYnLzkWABZWRjpTCEnxzFducXcYFi2o9pExc30l8tHi/r0cUZBFRxGSnX4 UDMSmH9RTlmhlr2PtmI1oOHXSGojLSlyNGBw23MUXu/OCBgSCXFnRf440pJiJ446gr3b NpbCu4kRtOHeP6Us3j5sug3YirKs2MZfWGazw= Received: by 10.142.215.10 with SMTP id n10mr150976wfg.290.1313796066404; Fri, 19 Aug 2011 16:21:06 -0700 (PDT) Received: from [192.168.1.78] (cpe-98-148-229-193.socal.res.rr.com [98.148.229.193]) by mx.google.com with ESMTPS id d4sm2694601pbe.68.2011.08.19.16.21.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Aug 2011 16:21:04 -0700 (PDT) References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> <16EE6DAE-806C-4311-83B1-6974A2B813EB@zaphoyd.com> In-Reply-To: <16EE6DAE-806C-4311-83B1-6974A2B813EB@zaphoyd.com> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-1-481411649 Message-Id: <7999EC29-FD8C-4C97-B86D-2B3EA894DB28@gmail.com> X-Mailer: iPhone Mail (8J2) From: Brian McKelvey Date: Fri, 19 Aug 2011 16:20:54 -0700 To: Peter H Thorson Cc: "hybi@ietf.org" Subject: Re: [hybi] WebSockets Test Suite / Browser Status 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, 19 Aug 2011 23:20:09 -0000 --Apple-Mail-1-481411649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii As far as I can tell, chops are referring to the underlying tcp packet size.= Sent from my iPhone On Aug 19, 2011, at 2:56 PM, Peter H Thorson wrote: > On 2011-Aug-18, at 18:52, Brian wrote: >=20 >> Very nice! The test suite helped me identify and fix a few bugs in my im= plementation. All the tests now pass for WebSocket-Node except about 5 of t= he performance related ones. Turns out my implementation doesn't do so well= with large messages sent with small frame sizes, but seems to do much bette= r with larger frame sizes. I guess I have some optimization to do with hand= ling smaller fragments. >>=20 >> Results compared with Autobahn: >>=20 >> http://worlize.github.com/WebSocket-Node/test-report/servers/ >>=20 >> Brian >>=20 >>=20 >> On Wed, Aug 17, 2011 at 9:04 AM, Tobias Oberstein wrote: >> Regarding WS test suites for servers and browser status .. >>=20 >> Cheers, >> Tobias >>=20 >> 1. >> Autobahn WebSockets now (0.3.2) includes an automated test suite for both= clients and servers. >>=20 >> http://www.tavendo.de/autobahn/testsuite.html >>=20 >> 2. >> The fixes for Chrome have landed on v15 .. all green now. >>=20 >> http://www.tavendo.de/autobahn/testsuite/report/clients/index.html >>=20 >=20 > I want to second this, this server test suite found a number of oversights= for me to fix and has been very helpful overall for debugging a websocket s= erver. >=20 > For anyone interested, here is a report done of the autobahn server vs my w= ebsocketpp server written in C++ using boost asio's asynchronous networking l= ibrary. So far my effort has been focused on correctness and clarity and les= s on performance. Unsurprisingly, unmasking in C++ seems to be less a bottle= neck than the rest of the frame header and network io overhead. >=20 > http://zaphoyd.com/websocketpp/autobahn-report/ >=20 > Lastly, can you clarify the difference between fragments and "chops", is t= he difference just that the chops are very small? >=20 > Thanks again, >=20 > Peter > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --Apple-Mail-1-481411649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
As far as I can tell, chops are referri= ng to the underlying tcp packet size.

Sent from my iPhone

On Aug 19, 2011, at 2:56 PM, Peter H Thorson <webmaster@zaphoyd.com> wrote:

On 2011-Aug-18, at 18:52, Brian= wrote:

Very nice!  The test suite helped me identify and fix a few bugs= in my implementation.  All the tests now pass for WebSocket-Node excep= t about 5 of the performance related ones.  Turns out my implementation= doesn't do so well with large messages sent with small frame sizes, but see= ms to do much better with larger frame sizes.  I guess I have some opti= mization to do with handling smaller fragments.

Results compared with Autobahn:


=
Brian


On Wed, Aug 17= , 2011 at 9:04 AM, Tobias Oberstein <= tobias.oberstein@tavendo.de> wrote:
Regarding WS test suites for servers and b= rowser status ..

Cheers,
Tobias

1.
Autobahn WebSockets now (0.3.2) includes an automated test suite for both cl= ients and servers.

= http://www.tavendo= .de/autobahn/testsuite.html

2.
The fixes for Chrome have landed on v15 .. all green now.

http://www.tavendo.de/autobahn/testsuite/report/clie= nts/index.html


I want to seco= nd this, this server test suite found a number of oversights for me to fix a= nd has been very helpful overall for debugging a websocket server.

For anyone interested, here is a report done of the autobahn= server vs my websocketpp server written in C++ using boost asio's asynchron= ous networking library. So far my effort has been focused on correctness and= clarity and less on performance. Unsurprisingly, unmasking in C++ seem= s to be less a bottleneck than the rest of the frame header and network io o= verhead.

Lastly, can you clarify the difference between fragments and "c= hops", is the difference just that the chops are very small?

<= /div>
Thanks again,

Peter
____________________________________= ___________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi
= --Apple-Mail-1-481411649-- From ibc@aliax.net Sat Aug 20 05:00: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 E1EAE21F8876 for ; Sat, 20 Aug 2011 05:00:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vnlvPg5xKz3j for ; Sat, 20 Aug 2011 05:00:44 -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 33A5221F87F0 for ; Sat, 20 Aug 2011 05:00:43 -0700 (PDT) Received: by qyk35 with SMTP id 35so1502604qyk.10 for ; Sat, 20 Aug 2011 05:01:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr170187qcc.292.1313841701525; Sat, 20 Aug 2011 05:01:41 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Sat, 20 Aug 2011 05:01:41 -0700 (PDT) In-Reply-To: <20110819194647.GE11512@jl-vm1.vm.bytemark.co.uk> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> <20110819194647.GE11512@jl-vm1.vm.bytemark.co.uk> Date: Sat, 20 Aug 2011 14:01:41 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jamie Lokier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 12:00:45 -0000 2011/8/19 Jamie Lokier : >> =C2=A0 =C2=A0 =C2=A0In the network space, this is >> =C2=A0 =C2=A0 =C2=A0particularly misleading. A WebSocket protocol API eq= uivalent of >> =C2=A0 =C2=A0 =C2=A0sendfile() would also have to do significant process= ing even while >> =C2=A0 =C2=A0 =C2=A0sending an entire, arbitrary file as a single frame. > > From the server to client, because there's no masking in that > direction, it can share the memory. =C2=A0(Or has the WS spec changed on > this again?) Are we assuming plain WebSocket? if the connection uses TLS/SSL (wss://) then all this discussion is useless, am I right? --=20 I=C3=B1aki Baz Castillo From jamie@shareable.org Sat Aug 20 06:43: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 ACE2E21F8A23 for ; Sat, 20 Aug 2011 06:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7O6ExWBa+s6 for ; Sat, 20 Aug 2011 06:43:20 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3292721F884C for ; Sat, 20 Aug 2011 06:43:20 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QulqQ-0007wP-Qe; Sat, 20 Aug 2011 14:44:14 +0100 Date: Sat, 20 Aug 2011 14:44:14 +0100 From: Jamie Lokier To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo Message-ID: <20110820134414.GC14899@jl-vm1.vm.bytemark.co.uk> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> <20110819194647.GE11512@jl-vm1.vm.bytemark.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Framing Management Rationale X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 13:43:20 -0000 Iñaki Baz Castillo wrote: > 2011/8/19 Jamie Lokier : > >>      In the network space, this is > >>      particularly misleading. A WebSocket protocol API equivalent of > >>      sendfile() would also have to do significant processing even while > >>      sending an entire, arbitrary file as a single frame. > > > > From the server to client, because there's no masking in that > > direction, it can share the memory.  (Or has the WS spec changed on > > this again?) > > Are we assuming plain WebSocket? if the connection uses TLS/SSL > (wss://) then all this discussion is useless, am I right? Yes, with an exception when TLS/SSL is added/removed at an intermediary (e.g. offloaded to front-ends in a server farm). The intermediaries also have to forward every byte on TLS hops, and can't refragment, so the other part of this discussion about buffer/timing/fragments does not apply either. Intermediaries will still delay (if only because TCP does and internal schedule decisions) but purely heuristically. However, this does not rule out MUXing multiple TLS streams in principle! Although the MUX designs we have seen, and the natural TLS binding for WebSocket, cannot do that. -- Jamie From tobias.oberstein@tavendo.de Sat Aug 20 09:00: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 B460221F8713 for ; Sat, 20 Aug 2011 09:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCxu0T3XjJKR for ; Sat, 20 Aug 2011 09:00:27 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id DB94621F86BC for ; Sat, 20 Aug 2011 09:00:26 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Sat, 20 Aug 2011 09:01:25 -0700 From: Tobias Oberstein To: Peter H Thorson , "hybi@ietf.org" , Sylvain Hellegouarch , Brian McKelvey , =?iso-2022-jp?B?IkFuZHkgR3JlZW4gKBskQk5TMEJXLxsoQiki?= Date: Sat, 20 Aug 2011 09:00:34 -0700 Thread-Topic: [hybi] WebSockets Test Suite / Browser Status Thread-Index: AcxewCSt1vYeve/CQkynYIh8uZZ3MAAit1cw Message-ID: <634914A010D0B943A035D226786325D422C0D5C957@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> <16EE6DAE-806C-4311-83B1-6974A2B813EB@zaphoyd.com> In-Reply-To: <16EE6DAE-806C-4311-83B1-6974A2B813EB@zaphoyd.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D422C0D5C957EXVMBX02012ex_" MIME-Version: 1.0 Subject: Re: [hybi] WebSockets Test Suite / Browser Status X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Aug 2011 16:00:28 -0000 --_000_634914A010D0B943A035D226786325D422C0D5C957EXVMBX02012ex_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable I'm trying to answer/comment all recent mails regarding the topic in one ma= il, since I'm a bit afraid that this thread could be seen as OT. I apologize. So if there are further questions specifically related to Autobahn Testsuit= e, I'm inviting you to join http://groups.google.com/group/autobahnws If you have doubts regarding test case behavior, that should still get to t= his list, when it's doubts routed in the spec or interpretation thereof i.e. =3D=3D That said, I'm glad that the little tool finds practical use. I think protocol conformance, and by that interoperability is import for We= bSockets to reach broad adoption. I really want to see WebSockets suceed. I also think that for adoption, there is the user side - developers _using_= WS implementations. We should make things easy and transparent for them. So, since a couple of you already posted links to test reports, and I think= that users of your libraries might be interested in that, but also other information (like fea= tures in general), I've started a http://en.wikipedia.org/wiki/User:Oberstet/Comparison_of_WebSocket_implemen= tations where we can include pointers to test results. This page is not meant as a shootout of any kind =1B$B!D=1B(B there are so = many factors involved that there is enough room for many implementations. I.e. Sylvain's impl. is= Python as is (currently) Autobahn, but his has no external deps., mine has Twisted= - which is both an adv. and disadv. depending on how you look at it. IMHO having a Wikipedia page can serve well as a neutral ground to host suc= h stuff. Goal is to make information there correct, fair and comprehensive - serving= implementors and users. Please edit that / add your stuff =1B$B!D=1B(B it's not published yet, _any= one_ can edit it. Feel free to add more comparison aspects, criticise or discuss using the Wi= kipedia discussion feature. Cheers, Tobias =3D=3D @Andy: I've added libwebsockets, but left everything as ?. I added, since your's is both on http://en.wikipedia.org/wiki/Websockets#Li= braries and you are on this list. If it's unwelcome, drop me a line. If not, but you're too lazy, give me the= facts rgd. libwebsockets, I'll hack it into the awkward Wiki syntax. I think libwebsockets should really b= e there .. @Sylvain: As said above, it's very useful to have a no-frills, low-entry barrier, no-= dependencies WS Python client library. When I get that right, there is the _option_ of running within Tornado/Cher= ryPy? If so, the Wikipage is wrong .. pls help .. @Brian: Node.js is obviously important .. pls come on board and help with the Wikip= age. @Peter: 1. C++/ASIO vs poor little Python/Twisted .. unfair fight;) No, indeed interes= ting to see the relative performance! 2. Fragments/Chops fragments =3D payload of WS frames of a fragmented WS message chops =3D "bytes on wire" Chopped tests serve 2 purposes: a) The idea is to stress the implementation along three axis: message size,= fragment size and chop size. b) The intention with chops additionally is: test whether the implementatio= n is agnostic to in what chops it receives bytes. It must be "TCP clean". Caution: strictly controlling the chops which get on the wire is hard to ne= xt impossible. I probably post something on a yet-to-be-written Autobahn FAQ. Practically, the deal is: if you see some case red for the chopped tests, s= omething is buggy with the implementation. If it's green, that does not necessarily mean it is TCP= clean. 3. the Wikipedia comparison I have not included any pointers to your report/impl. since I guess it's co= mmercial, and I don't know your plans. If you want it there, feel free of course to include it th= ough. Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von Pe= ter H Thorson Gesendet: Freitag, 19. August 2011 23:56 An: hybi@ietf.org Betreff: Re: [hybi] WebSockets Test Suite / Browser Status On 2011-Aug-18, at 18:52, Brian wrote: Very nice! The test suite helped me identify and fix a few bugs in my impl= ementation. All the tests now pass for WebSocket-Node except about 5 of th= e performance related ones. Turns out my implementation doesn't do so well= with large messages sent with small frame sizes, but seems to do much bett= er with larger frame sizes. I guess I have some optimization to do with ha= ndling smaller fragments. Results compared with Autobahn: http://worlize.github.com/WebSocket-Node/test-report/servers/ Brian On Wed, Aug 17, 2011 at 9:04 AM, Tobias Oberstein > wrote: Regarding WS test suites for servers and browser status .. Cheers, Tobias 1. Autobahn WebSockets now (0.3.2) includes an automated test suite for both c= lients and servers. http://www.tavendo.de/autobahn/testsuite.html 2. The fixes for Chrome have landed on v15 .. all green now. http://www.tavendo.de/autobahn/testsuite/report/clients/index.html I want to second this, this server test suite found a number of oversights = for me to fix and has been very helpful overall for debugging a websocket s= erver. For anyone interested, here is a report done of the autobahn server vs my w= ebsocketpp server written in C++ using boost asio's asynchronous networking= library. So far my effort has been focused on correctness and clarity and = less on performance. Unsurprisingly, unmasking in C++ seems to be less a bo= ttleneck than the rest of the frame header and network io overhead. http://zaphoyd.com/websocketpp/autobahn-report/ Lastly, can you clarify the difference between fragments and "chops", is th= e difference just that the chops are very small? Thanks again, Peter --_000_634914A010D0B943A035D226786325D422C0D5C957EXVMBX02012ex_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

I'm trying = to answer/comment all recent mails regarding the topic in one mail, since I= 'm a

bit afraid that this = thread could be seen as OT. I apologize.

 

So i= f there are further questions specifically related to Autobahn Testsuite, I= 'm inviting you

to join http://groups.google.co= m/group/autobahnws

 

If you have doubts reg= arding test case behavior, that should still get to this list, when it's

doubts routed in the spec or= interpretation thereof i.e.

 

=3D=3D

 

That said, I'm glad that the little tool finds practic= al use.

 <= /span>

I think protocol conformance, and by = that interoperability is import for WebSockets to reach

broad adoption. I really want to see WebSocke= ts suceed.

 

I also think that for adoption, th= ere is the user side - developers _using_ WS implementations.

 

We should make things easy and transparent for them.<= /o:p>

 

So, since a couple of you already posted links to = test reports, and I think that users of your

libraries might be interested in that, but also other i= nformation (like features in general),

I've started a

 

http://en.wikipedia.org/wiki/User:Oberstet/Comparison_of_WebSocket_imple= mentations

 =

where we can include pointers = to test results.

&nbs= p;

This page is not meant as a = shootout of any kind =1B$B!D=1B(B there are so many factors involved

that there is enough room for ma= ny implementations. I.e. Sylvain's impl. is Python

as is (currently) Autobahn, but his has no externa= l deps., mine has Twisted - which

is both an adv. and disadv. depending on how you look at it.

 

IMHO having a Wikipedia page can serve well as a ne= utral ground to host such stuff.

=  

Goal is to m= ake information there correct, fair and comprehensive - serving implementor= s

and users.

 

Please edit that / add your stuff =1B$B!D=1B(B it's not pu= blished yet, _anyone_ can edit it.

Feel free to add more comparison aspects, criticise or discuss usi= ng the Wikipedia

discussio= n feature.

 

Cheers,

Tobias

 

=3D=3D

 

@Andy:

I've added libwebsockets, but left everything as ?.

I added, since your's is both on http://en.wikipedia.org/wi= ki/Websockets#Libraries and you are on this list.

=

If it's unwelcome, drop me a line. If not, but = you're too lazy, give me the facts rgd. libwebsockets, I'll

hack it into the awkward Wiki syntax. I t= hink libwebsockets should really be there ..

 

@Sylvain:

As said above, = it's very useful to have a no-frills, low-entry barrier, no-dependencies WS= Python client library.

Wh= en I get that right, there is the _option_ of running within Tornado/Cherry= Py? If so, the Wikipage is

wrong .. pls help ..

 

@Brian:

Node.js is obviously important .. pls com= e on board and help with the Wikipage.

 

@Pet= er:

1.

C++/ASIO vs poor little Python/Twisted .. unf= air fight;) No, indeed interesting to see the relative performance!

 

2.

= Fragments/Chops

fragments = =3D payload of WS frames of a fragmented WS message

chops =3D "bytes on wire"

 

Chopped tests serve 2 purposes:

 

a) The idea is to stress the implementation along three axis: message s= ize, fragment size and chop size.

 

b) The inte= ntion with chops additionally is: test whether the implementation is agnost= ic to in what

chops it rec= eives bytes. It must be "TCP clean".

 

Caution: strictly controlling the chops which get on the wire is hard to = next impossible. I probably

post something on a yet-to-be-written Autobahn FAQ.

=

 

Practically, the deal is: if you see some case red for the chopped= tests, something is buggy with

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>the implementation. If it's green, that does not necessarily mean it = is TCP clean.

 <= /o:p>

3. the Wikipedia comparison

I have not included any point= ers to your report/impl. since I guess it's commercial, and I don't

know your plans. If you want it t= here, feel free of course to include it though.

 

 

 

Von:= hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von = Peter H Thorson
Gesendet: Freitag, 19. August 2011 23:56
<= b>An: hybi@ietf.org
Betreff: Re: [hybi] WebSockets Test Suite= / Browser Status

 

On 2011-Aug-18, at 18:52, Brian wrote:



<= o:p>

Very nice! =  The test suite helped me identify and fix a few bugs in my implementa= tion.  All the tests now pass for WebSocket-Node except about 5 of the= performance related ones.  Turns out my implementation doesn't do so = well with large messages sent with small frame sizes, but seems to do much = better with larger frame sizes.  I guess I have some optimization to d= o with handling smaller fragments.

 

Results compared with Autobahn:

&n= bsp;

 = ;

Bri= an

 =

On Wed, Au= g 17, 2011 at 9:04 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:

Regarding WS test suites for serv= ers and browser status ..

Cheers,
Tobias

1.
Autobahn We= bSockets now (0.3.2) includes an automated test suite for both clients and = servers.

http://www.tavendo.de/autobahn/testsuite.html

2= .
The fixes for Chrome have landed on v15 .. all green now.

http://www.tavendo.de/autobahn/testsuite/report/clients/in= dex.html

 

I want to second this, this server test suite fou= nd a number of oversights for me to fix and has been very helpful overall f= or debugging a websocket server.

 

For anyone interested, here is a = report done of the autobahn server vs my websocketpp server written in C++ = using boost asio's asynchronous networking library. So far my effort has be= en focused on correctness and clarity and less on performance. Unsurpr= isingly, unmasking in C++ seems to be less a bottleneck than the rest of th= e frame header and network io overhead.

 

<= p class=3DMsoNormal style=3D'margin-left:35.4pt'>http://zaphoyd.com/websocketpp/autobahn-r= eport/

 

Lastly, can you clarify the difference between frag= ments and "chops", is the difference just that the chops are very= small?

 

Thanks again,

 

Peter

= = --_000_634914A010D0B943A035D226786325D422C0D5C957EXVMBX02012ex_-- From gregw@intalio.com Sun Aug 21 03:43: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 D77FE21F8A58 for ; Sun, 21 Aug 2011 03:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.922 X-Spam-Level: X-Spam-Status: No, score=-2.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pd3ObJO-aeBV for ; Sun, 21 Aug 2011 03:43:31 -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 4FB4021F8A23 for ; Sun, 21 Aug 2011 03:43:31 -0700 (PDT) Received: by vxi29 with SMTP id 29so4529960vxi.31 for ; Sun, 21 Aug 2011 03:44:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr1171431vdb.246.1313923472695; Sun, 21 Aug 2011 03:44:32 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Sun, 21 Aug 2011 03:44:32 -0700 (PDT) In-Reply-To: <20110819203803.GG11512@jl-vm1.vm.bytemark.co.uk> References: <20110817113621.ef1fc80126c74c6c202a919c41c7bb0b.59f4eef878.wbe@email03.secureserver.net> <20110819203803.GG11512@jl-vm1.vm.bytemark.co.uk> Date: Sun, 21 Aug 2011 20:44:32 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Framing Management Rationale 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, 21 Aug 2011 10:43:31 -0000 On 20 August 2011 06:38, Jamie Lokier wrote: > Greg Wilkins wrote: >> I do understand Andy's concern that max frame size might be wink to >> poor receiver implementations - so how about a third option: =A0An >> optional header to declare min/max frame size, but remove the >> frame-too-large error so as to indicate that implementations must be >> able to handle any frame size up to their max message size limit. > > Who's min/max frame size goes in the header? > Intermediary 1, intermediary 2, or the end receiver? I totally agree that frame size should be hop by hop, so any min/max frame size received would only be applicable for the adjacent hop. cheers From ibc@aliax.net Sun Aug 21 04: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 8424521F8ACC for ; Sun, 21 Aug 2011 04:32:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMtKTxNOrSYz for ; Sun, 21 Aug 2011 04:32: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 DE37821F8ACA for ; Sun, 21 Aug 2011 04:31:59 -0700 (PDT) Received: by qwc23 with SMTP id 23so3255119qwc.31 for ; Sun, 21 Aug 2011 04:33:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.133 with SMTP id v5mr666012qcb.178.1313926381460; Sun, 21 Aug 2011 04:33:01 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Sun, 21 Aug 2011 04:33:00 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Sun, 21 Aug 2011 04:33:00 -0700 (PDT) In-Reply-To: References: <20110816073401.ef1fc80126c74c6c202a919c41c7bb0b.f02db904ba.wbe@email03.secureserver.net> Date: Sun, 21 Aug 2011 13:33:00 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: multipart/alternative; boundary=0016364269ad3a5d9c04ab02536e Cc: hybi@ietf.org Subject: Re: [hybi] "Intermediaries" 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, 21 Aug 2011 11:32:00 -0000 --0016364269ad3a5d9c04ab02536e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable El 16/08/2011 22:51, "I=C3=B1aki Baz Castillo" escribi=C3= =B3: > Good comment. I agree, the term "intermediary" is too much used in the > draft and the maillist without nobody specifying what it is exactly. Please. Could someone explain what an intermediary is in the context of ws? For example I expect that a common http proxy wont be ws aware so it will treat ws frames as binary data. So other mail threads talking about "intermediary's max frame" does not apply here. So I assume that the term intermediary refers more to a ws aware entity which receives ws frames from a client (the client performed the ws handshake against this intermediary) and later resends the ws messages to other entities, perhaps re-framing them. But still I dont think the client performs ws handhake against an intermediary, or does it? Could somebody clarify it PLEASE? This is critical in order to understand other subjects discussed in other mail threads and current description of "intermediary" is too vague. Thanks a lot. --0016364269ad3a5d9c04ab02536e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


El 16/08/2011 22:51, "I=C3=B1aki Baz Castillo" <ibc@aliax.net> escribi=C3=B3:

> Good comment. I agree, the term "intermediary" is too muc= h used in the
> draft and the maillist without nobody specifying what it is exactly.

Please. Could someone explain what an intermediary is in the context of = ws?

For example I expect that a common http proxy wont be ws aware so it wil= l treat ws frames as binary data. So other mail threads talking about "= ;intermediary's max frame" does not apply here.

So I assume that the term intermediary refers more to a ws aware entity = which receives ws frames from a client (the client performed the ws handsha= ke against this intermediary) and later resends the ws messages to other en= tities, perhaps re-framing them.

But still I dont think the client performs ws handhake against an interm= ediary, or does it?

Could somebody clarify it PLEASE? This is critical in order to understan= d other subjects discussed in other mail threads and current description of= "intermediary" is too vague.

Thanks a lot.

--0016364269ad3a5d9c04ab02536e-- From sh@defuze.org Sun Aug 21 07:15: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 1514E21F8A23 for ; Sun, 21 Aug 2011 07:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X-z121a0Jlt for ; Sun, 21 Aug 2011 07:15:44 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0681121F8841 for ; Sun, 21 Aug 2011 07:15:43 -0700 (PDT) Received: by pzk33 with SMTP id 33so13882217pzk.18 for ; Sun, 21 Aug 2011 07:16:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.187.3 with SMTP id k3mr942129wff.233.1313936203603; Sun, 21 Aug 2011 07:16:43 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Sun, 21 Aug 2011 07:16:43 -0700 (PDT) X-Originating-IP: [82.229.61.197] In-Reply-To: <634914A010D0B943A035D226786325D422C0D5C957@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0B9A5E4@EXVMBX020-12.exch020.serverdata.net> <16EE6DAE-806C-4311-83B1-6974A2B813EB@zaphoyd.com> <634914A010D0B943A035D226786325D422C0D5C957@EXVMBX020-12.exch020.serverdata.net> Date: Sun, 21 Aug 2011 16:16:43 +0200 Message-ID: From: Sylvain Hellegouarch To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd2dd06ac600904ab049c88 Cc: "hybi@ietf.org" , Peter H Thorson Subject: Re: [hybi] WebSockets Test Suite / Browser Status 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, 21 Aug 2011 14:15:45 -0000 --000e0cd2dd06ac600904ab049c88 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable > ** ** > > That said, I'm glad that the little tool finds practical use.**** > > ** ** > > I think protocol conformance, and by that interoperability is import for > WebSockets to reach**** > > broad adoption. I really want to see WebSockets suceed.**** > > ** ** > > I also think that for adoption, there is the user side - developers _usin= g_ > WS implementations.**** > > ** ** > > We should make things easy and transparent for them.**** > > ** ** > > So, since a couple of you already posted links to test reports, and I thi= nk > that users of your**** > > libraries might be interested in that, but also other information (like > features in general),**** > > I've started a**** > > ** ** > > > http://en.wikipedia.org/wiki/User:Oberstet/Comparison_of_WebSocket_implem= entations > **** > > ** ** > > where we can include pointers to test results.**** > > ** ** > > This page is not meant as a shootout of any kind =85 there are so many > factors involved**** > > that there is enough room for many implementations. I.e. Sylvain's impl. = is > Python**** > > as is (currently) Autobahn, but his has no external deps., mine has Twist= ed > - which**** > > is both an adv. and disadv. depending on how you look at it.**** > > ** ** > > IMHO having a Wikipedia page can serve well as a neutral ground to host > such stuff.**** > > ** ** > > Goal is to make information there correct, fair and comprehensive - servi= ng > implementors**** > > and users.**** > > ** ** > > Please edit that / add your stuff =85 it's not published yet, _anyone_ ca= n > edit it.**** > > Feel free to add more comparison aspects, criticise or discuss using the > Wikipedia**** > > discussion feature. > That's a great resource and I like the idea. I'll add more details about ws4py. @Sylvain:**** > > As said above, it's very useful to have a no-frills, low-entry barrier, > no-dependencies WS Python client library.**** > > When I get that right, there is the _option_ of running within > Tornado/CherryPy? If so, the Wikipage is**** > > wrong .. pls help ..**** > > ** > Will do. By the way, here are the latest results of ws4py (CherryPy server) against Autobahn. http://www.defuze.org/oss/ws4py/testreports/servers/cherrypy/ --=20 - Sylvain http://www.defuze.org http://twitter.com/lawouach --000e0cd2dd06ac600904ab049c88 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

=A0

That = said, I'm glad that the little tool finds practical use.<= /span>

=A0

I thi= nk protocol conformance, and by that interoperability is import for WebSock= ets to reach

broad adoption. I really want to see WebSoc= kets suceed.

=A0

I also think that for adoption, there is the user side - = developers _using_ WS implementations.

=A0

We should make things easy and transparent for them.

=A0

So, since a couple of you already posted links to test re= ports, and I think that users of your

libra= ries might be interested in that, but also other information (like features= in general),

I've started a

=A0

http://en.wikipedia= .org/wiki/User:Oberstet/Comparison_of_WebSocket_implementations<= u>

=A0

where we can include pointers to test results.<= /u>

=A0

This page is not meant as a shootout of any kind =85 ther= e are so many factors involved

that = there is enough room for many implementations. I.e. Sylvain's impl. is = Python

as is (currently) Autobahn, but his has no extern= al deps., mine has Twisted - which

is bo= th an adv. and disadv. depending on how you look at it.

= =A0

IMHO = having a Wikipedia page can serve well as a neutral ground to host such stu= ff.

=A0

Goal = is to make information there correct, fair and comprehensive - serving impl= ementors

and users.

=A0

Please edit that / add your stuff =85 it's not publis= hed yet, _anyone_ can edit it.

Feel = free to add more comparison aspects, criticise or discuss using the Wikiped= ia

discussion feature.



That's a gr= eat resource and I like the idea. I'll add more details about ws4py.


@Sylvain:

As said above, it's very useful to have a no-frills, low-entry barrie= r, no-dependencies WS Python client library.

When = I get that right, there is the _option_ of running within Tornado/CherryPy?= If so, the Wikipage is

wrong .. pls help ..

=A0



Will do.
By the way, here are the latest results of ws4py (Cherr= yPy server) against Autobahn.=A0


--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach
--000e0cd2dd06ac600904ab049c88-- From ibc@aliax.net Sun Aug 21 08:42: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 2368E21F8785 for ; Sun, 21 Aug 2011 08:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0v49cIsDwbx for ; Sun, 21 Aug 2011 08:42:39 -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 9771D21F8563 for ; Sun, 21 Aug 2011 08:42:39 -0700 (PDT) Received: by qyk35 with SMTP id 35so1815160qyk.10 for ; Sun, 21 Aug 2011 08:43:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.31.67 with SMTP id x3mr746561qcc.292.1313941128143; Sun, 21 Aug 2011 08:38:48 -0700 (PDT) Received: by 10.229.184.1 with HTTP; Sun, 21 Aug 2011 08:38:48 -0700 (PDT) In-Reply-To: References: Date: Sun, 21 Aug 2011 17:38:48 +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: Re: [hybi] Comments about draft 10 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, 21 Aug 2011 15:42:40 -0000 Hi, in my previous two mails in this thread I've reported several issues/bugs in the draft (revision 10). Some of them could be valid and others invalid but, could the authors please provide more feedback when issues are reported? Regards. --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Sun Aug 21 18:00: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 A945221F84FD for ; Sun, 21 Aug 2011 18:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kTA5J54Dusru for ; Sun, 21 Aug 2011 18:00:25 -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 F152D21F84F9 for ; Sun, 21 Aug 2011 18:00:24 -0700 (PDT) Received: by vxi29 with SMTP id 29so4863929vxi.31 for ; Sun, 21 Aug 2011 18:01:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.5 with SMTP id z5mr1670719vde.112.1313974888254; Sun, 21 Aug 2011 18:01:28 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Sun, 21 Aug 2011 18:01:28 -0700 (PDT) In-Reply-To: <4E440808.5030907@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Mon, 22 Aug 2011 11:01:28 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 22 Aug 2011 01:00:25 -0000 On 12 August 2011 02:49, Peter Saint-Andre wrote: > This is your Area Director speaking. I would very much like to issue an > IESG ballot for our base document in the near future. The WG needs to > decide this matter in order for us to proceed. See below for details. > > Apparently there is a disconnect in the specification: as currently > written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size. > > Therefore, as your Area Director, I am requesting a consensus call on > the following alternative. > > 1. Remove error code 1004 "Frame Too Large". > > or > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > its maximum frame size, and specify that an implementation SHOULD NOT > send frames larger than the maximum frame size signalled by its peer. I think this ballet has got a little lost. However, in case anybody is still actually counting, I'd like to change my vote from #2 to an unconditional #1 - remove the frame-too-large close code. In addition to that, I think that we should also: a) add a message-too-large close code b) define some optional headers (or control packet) to give advice/hints on a hop-by-hop basis of the maximal frame size that should be sent and the preferred frame size to be received But regardless for support for these proposals, I think we should remove frame-too-large. regards From sh@defuze.org Mon Aug 22 00:48: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 3BB6A21F8AB9 for ; Mon, 22 Aug 2011 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rWR6l--lPI+5 for ; Mon, 22 Aug 2011 00:48:42 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id EDFBF21F8A66 for ; Mon, 22 Aug 2011 00:48:41 -0700 (PDT) Received: by pzk33 with SMTP id 33so15912754pzk.18 for ; Mon, 22 Aug 2011 00:49:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.187.3 with SMTP id k3mr1373307wff.233.1313999377018; Mon, 22 Aug 2011 00:49:37 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Mon, 22 Aug 2011 00:49:36 -0700 (PDT) X-Originating-IP: [195.101.247.164] In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Mon, 22 Aug 2011 09:49:36 +0200 Message-ID: From: Sylvain Hellegouarch To: Greg Wilkins Content-Type: multipart/alternative; boundary=000e0cd2dd061a302e04ab135256 Cc: hybi@ietf.org Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) 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, 22 Aug 2011 07:48:43 -0000 --000e0cd2dd061a302e04ab135256 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 22, 2011 at 3:01 AM, Greg Wilkins wrote: > On 12 August 2011 02:49, Peter Saint-Andre wrote: > > This is your Area Director speaking. I would very much like to issue an > > IESG ballot for our base document in the near future. The WG needs to > > decide this matter in order for us to proceed. See below for details. > > > > Apparently there is a disconnect in the specification: as currently > > written, an implementation can reject a frame because it is too big > > (error code 1004), but it can't signal its maximum frame size. > > > > Therefore, as your Area Director, I am requesting a consensus call on > > the following alternative. > > > > 1. Remove error code 1004 "Frame Too Large". > > > > or > > > > 2. Retain error code 1004, add an OPTIONAL way for an entity to signal > > its maximum frame size, and specify that an implementation SHOULD NOT > > send frames larger than the maximum frame size signalled by its peer. > > I think this ballet has got a little lost. However, in case anybody > is still actually counting, I'd like to change my vote from #2 to an > unconditional #1 - remove the frame-too-large close code. > > In addition to that, I think that we should also: > a) add a message-too-large close code > b) define some optional headers (or control packet) to give > advice/hints on a hop-by-hop basis of the maximal frame size that > should be sent and the preferred frame size to be received > > I am not in favour of #2 for the added complexity. Since the initial motivation for framing was to allow bytes to be sent as soon as available, we may end up in a situation where all the bytes have been sent in various frames before the endpoint had a chance to receive and process them all. If it fails because a frame is too large and indicates to the emitter the max-size, it won't be that useful since this will mean the original sender have to re-send the whole message which it may not have at hand any longer. Since frames are not identified, there's no way to send from the frame that failed either way. Therefore if a message must be sent again in its entirety, we might as well not bother with frame size. >From a transport protocol perspective, #2 makes sense but from an application protocol perspective, I'd say it makes things more complex. As I understand it, WS is still considered as an application protocol right? -- - Sylvain http://www.defuze.org http://twitter.com/lawouach --000e0cd2dd061a302e04ab135256 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Aug 22, 2011 at 3:01 AM, Greg Wi= lkins <gregw@intalio.com> wrote:
On 12 August 2011 02:49, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> This is your Area Director speaking. I would very much like to issue a= n
> IESG ballot for our base document in the near future. The WG needs to<= br> > decide this matter in order for us to proceed. See below for details.<= br> >
> Apparently there is a disconnect in the specification: as c= urrently
> written, an implementation can reject a frame because it is too big > (error code 1004), but it can't signal its maximum frame size.
>
> Therefore, as your Area Director, I am requesting a consensus call on<= br> > the following alternative.
>
> 1. Remove error code 1004 "Frame Too Large".
>
> or
>
> 2. Retain error code 1004, add an OPTIONAL way for an entity to signal=
> its maximum frame size, and specify that an implementation SHOULD NOT<= br> > send frames larger than the maximum frame size signalled by its peer.<= br>
I think this ballet has got a little lost. =A0 However, in case anybo= dy
is still actually counting, I'd like to change my vote from #2 to an unconditional #1 - remove the frame-too-large close code.

In addition to that, I think that we should also:
a) add a message-too-large close code
b) define some optional headers (or control packet) to give
advice/hints on a hop-by-hop basis of the maximal frame size that
should be sent and the preferred frame size to be received


I am not in favour of #2 for the added complexity. = Since the initial motivation for framing was to allow bytes to be sent as s= oon as available, we may end up in a situation where all the bytes have bee= n sent in various frames before the endpoint had a chance to receive and pr= ocess them all. If it fails because a frame is too large and indicates to t= he emitter the max-size, it won't be that useful since this will mean t= he original sender have to re-send the whole message which it may not have = at hand any longer. Since frames are not identified, there's no way to = send from the frame that failed either way. Therefore if a message must be = sent again in its entirety, we might as well not bother with frame size.=A0=

From a transport protocol perspective, #2 makes sense b= ut from an application protocol perspective, I'd say it makes things mo= re complex. As I understand it, WS is still considered as an application pr= otocol right?
=A0
--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach
--000e0cd2dd061a302e04ab135256-- From gezelter@rlgsc.com Mon Aug 22 03:00: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 562E321F8AD3 for ; Mon, 22 Aug 2011 03:00: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCulEbZ-Qr4q for ; Mon, 22 Aug 2011 03:00:49 -0700 (PDT) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id CD14C21F8ACA for ; Mon, 22 Aug 2011 03:00:46 -0700 (PDT) Received: (qmail 11350 invoked from network); 22 Aug 2011 10:01:46 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 10:01:46 -0000 Received: (qmail 28526 invoked by uid 99); 22 Aug 2011 10:01:46 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822030144.ef1fc80126c74c6c202a919c41c7bb0b.0e36e0ae77.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@IETF.ORG Date: Mon, 22 Aug 2011 03:01:44 -0700 Mime-Version: 1.0 Cc: greg@intalio.com Subject: [hybi] Framing (hybi Digest, Vol 30, Issue 69) 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, 22 Aug 2011 10:00:50 -0000 Date: Sun, 21 Aug 2011 20:44:32 +1000=0AFrom: Greg Wilkins =0ATo: Hybi =0ASubject: Re: [hybi] Framing Management Rat= ionale=0AMessage-ID:=0A=0AContent-Type: text/plain; charset=3DISO-8859-1=0A=0A>On = 20 August 2011 06:38, Jamie Lokier wrote:=0A>=0A>> Gr= eg Wilkins wrote:=0A>>> I do understand Andy's concern that max frame size = might be wink to=0A>>> poor receiver implementations - so how about a third= option: ?An=0A>>> optional header to declare min/max frame size, but remov= e the=0A>>> frame-too-large error so as to indicate that implementations mu= st be=0A>>> able to handle any frame size up to their max message size limi= t.=0A>>=0A>> Who's min/max frame size goes in the header?=0A>> Intermediary= 1, intermediary 2, or the end receiver?=0A>=0A>I totally agree that frame = size should be hop by hop, so any min/max=0A>frame size received would only= be applicable for the adjacent hop.=0A>=0A>cheers=0A>=0A>=0A>-------------= -----------------=0A=0A From gezelter@rlgsc.com Mon Aug 22 03:03: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 E088F21F8B04 for ; Mon, 22 Aug 2011 03:03:13 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3GQ9eR7hE9IQ for ; Mon, 22 Aug 2011 03:03:13 -0700 (PDT) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by ietfa.amsl.com (Postfix) with SMTP id 6705F21F8B00 for ; Mon, 22 Aug 2011 03:03:13 -0700 (PDT) Received: (qmail 11059 invoked from network); 22 Aug 2011 10:04:14 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 10:04:14 -0000 Received: (qmail 30328 invoked by uid 99); 22 Aug 2011 10:04:14 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822030413.ef1fc80126c74c6c202a919c41c7bb0b.c94016a25c.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Bob Gezelter" Date: Mon, 22 Aug 2011 03:04:13 -0700 Mime-Version: 1.0 Cc: hybi@IETF.ORG Subject: [hybi] Errata: RE: Framing (hybi Digest, Vol 30, Issue 69) 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, 22 Aug 2011 10:03:14 -0000 To all,=0A=0AMy apologies. Finger slipped, hit "Send" rather than "Save"=0A= =0A- Bob Gezelter=0A=0A> -------- Original Message --------=0A> Subject: Fr= aming (hybi Digest, Vol 30, Issue 69)=0A> From: "Bob Gezelter" =0A> Date: Mon, August 22, 2011 3:01 am=0A> To: hybi@IETF.ORG=0A> C= c: greg@intalio.com, jamie@shareable.org=0A> =0A> =0A> Date: Sun, 21 Aug 20= 11 20:44:32 +1000=0A> From: Greg Wilkins =0A> To: Hybi <= hybi@ietf.org>=0A> Subject: Re: [hybi] Framing Management Rationale=0A> Mes= sage-ID:=0A> =0A> Content-Type: text/plain; charset=3DISO-8859-1=0A> =0A> >On 20 A= ugust 2011 06:38, Jamie Lokier wrote:=0A> >=0A> >> Gr= eg Wilkins wrote:=0A> >>> I do understand Andy's concern that max frame siz= e might be wink to=0A> >>> poor receiver implementations - so how about a t= hird option: ?An=0A> >>> optional header to declare min/max frame size, but= remove the=0A> >>> frame-too-large error so as to indicate that implementa= tions must be=0A> >>> able to handle any frame size up to their max message= size limit.=0A> >>=0A> >> Who's min/max frame size goes in the header?=0A>= >> Intermediary 1, intermediary 2, or the end receiver?=0A> >=0A> >I total= ly agree that frame size should be hop by hop, so any min/max=0A> >frame si= ze received would only be applicable for the adjacent hop.=0A> >=0A> >cheer= s=0A> >=0A> >=0A> >------------------------------=0A From gezelter@rlgsc.com Mon Aug 22 04:00: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 E063F21F8B02 for ; Mon, 22 Aug 2011 04:00:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FYxd33gCsdw for ; Mon, 22 Aug 2011 04:00:49 -0700 (PDT) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id 3F6F121F8565 for ; Mon, 22 Aug 2011 04:00:49 -0700 (PDT) Received: (qmail 4635 invoked from network); 22 Aug 2011 11:01:50 -0000 Received: from unknown (HELO localhost) (72.167.218.132) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 11:01:49 -0000 Received: (qmail 13464 invoked by uid 99); 22 Aug 2011 11:01:49 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Mon, 22 Aug 2011 04:01:48 -0700 Mime-Version: 1.0 Cc: Bjoern Hoehrmann Subject: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 11:00:50 -0000 @Steve:=0A=0AUTF-8 text !=3D UTF-8 binary (actually, "UTF-8" binary is a mi= snomer).=0A=0AThis is likely redundant for many, but UTF-8 is identical to = text, so=0Along as the text is composed of the 128 characters in the USASCI= I 7-bit=0Acode. For 8-bit characters with a decimal value exceeding 127, th= e=0Aresult is a multiple byte encoding as defined by RFC 3629. Wikipedia ha= s=0Aa good quick reference to UTF-8 (with chart or illegal characters) at= =0Ahttp://en.wikipedia.org/wiki/Utf-8.=0A=0AThe strength of UTF-8 is that i= t permits backwards compatibility with=0AUSASCII-7 while providing encoding= of non-ASCII characters. This is why=0Ait is becoming a IETF standard. How= ever, it is not good for representing=0Abinary data that has not been first= encoded into a printable subset=0A(e.g., Base 64, MIME).=0A=0AAs one who h= as often been involved in transferring large volumes of=0Adata, requiring M= IME'ification represents a significant loss of=0Aeffective bandwidth.=0A=0A= (Everyone)=0A=0AI have long ago stated, and my preference remains for the W= ebSocket=0Aprotocol to be defined as "UTF-8 for control messages (per IETF= =0Aconvention) and "8-bit binary transparent" for the actual data channel.= =0AThe case of an application that wants to send some messages in UTF-8 and= =0Asome in binary is to me, not a compelling case for support within the=0A= WebSocket protocol. It is an appropriate provision in an applications=0Alev= el protocol that uses the WebSocket protocol as its underlying=0Atransport.= =0A=0AThe argument that "JavaScript does not support binary" is, IMHO, with= out=0Asignificant merit. Typed arrays are used in other HTML5 features (e.g= .,=0AWebGL) and are supported by current versions of browsers (see=0Ahttps:= //developer.mozilla.org/en/JavaScript_typed_arrays under=0Asubheading "Spec= ification"). =0A=0AIt has been mentioned that "most applications will not n= eed to exchange=0Aanything but text messages". This is an unproven (and unp= rovable)=0Aassertion. It is also true that what is true in the aggregate wi= ll most=0Alikely not apply to individual application implementers. =0A=0AA = small mezzanine protocol (layered on top of the WebSockets API, using=0Athe= WebSocket protocol for transport) can easily serve those=0Aimplementers th= at wish to have a text-only connection. It is thus=0Aunnecessary to place t= hat support within the WebSocket protocol.=0A=0AThat I am suggesting a chan= ge in the WebSockets API is unclear. There is=0Aalready a need to distingui= sh Text from Binary at the level of the API,=0AI merely suggest that the di= stinction be handled somewhat differently=0Athan is currently envisioned.= =0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From ibc@aliax.net Mon Aug 22 04:19: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 43EF521F8AAC for ; Mon, 22 Aug 2011 04:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.638 X-Spam-Level: X-Spam-Status: No, score=-2.638 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lF3pm0613mOD for ; Mon, 22 Aug 2011 04:19:38 -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 AEDF821F85B9 for ; Mon, 22 Aug 2011 04:19:38 -0700 (PDT) Received: by qyk35 with SMTP id 35so2118525qyk.10 for ; Mon, 22 Aug 2011 04:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr1218483qci.223.1314012043144; Mon, 22 Aug 2011 04:20:43 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 04:20:42 -0700 (PDT) In-Reply-To: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> Date: Mon, 22 Aug 2011 13:20:42 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 11:19:39 -0000 2011/8/22 Bob Gezelter : > The argument that "JavaScript does not support binary" is, IMHO, without > significant merit. It seems a joke for a protocol specification. There is life out of HTTP and JavaScript. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 22 04:38:47 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 3D9F821F8B1C for ; Mon, 22 Aug 2011 04:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RSqJIMSiY1JE for ; Mon, 22 Aug 2011 04:38:46 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 033C221F8B01 for ; Mon, 22 Aug 2011 04:38:44 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Mon, 22 Aug 2011 04:39:47 -0700 From: Tobias Oberstein To: Bob Gezelter , "hybi@ietf.org" Date: Mon, 22 Aug 2011 04:38:58 -0700 Thread-Topic: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) Thread-Index: Acxguuz2Pnqr8lkpTsSmo0xz5JuK7QAAswJw Message-ID: <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> In-Reply-To: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 11:38:47 -0000 Bob, > It has been mentioned that "most applications will not need to exchange a= nything but text messages". This is an unproven (and unprovable) assertion.= It is also true that what is true in the aggregate will most likely not ap= ply to individual application implementers.=20 It's indeed pointless to talk about proofs in this context, since the contr= ary (that most applications will want to only exchange binary messages) is = also unprovable. Here is my view: =20 Assumption 1: Most WS clients will be browsers. Assumption 2: Most (JavaScript) WS apps running in the browser will exchang= e small, JSON encoded messages. JSON is UTF-8-based. IMHO we should avoid anything which makes that use case less workable/conve= nient. You can of course question those assumptions .. >A small mezzanine protocol (layered on top of the WebSockets API, using th= e WebSocket protocol for transport) can easily serve those implementers tha= t wish to have a text-only connection. It is thus unnecessary to place that= support within the WebSocket protocol. >That I am suggesting a change in the WebSockets API is unclear. There is a= lready a need to distinguish Text from Binary at the level of the API, I me= rely suggest that the distinction be handled somewhat differently than is c= urrently envisioned. It works today .. it is good enough .. why change? There is a different issue (unrelated to WS protocol .. see my other post):= =20 There is upcoming support for typed array (ArrayBuffer and typed array view= s over that) in JS. How is that transported in JSON payload and made transparent in the JSON.st= ringify/parse marshaling/demarshaling API? Tobias From ibc@aliax.net Mon Aug 22 05:25: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 018ED21F855D for ; Mon, 22 Aug 2011 05:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSutKLJGPyhn for ; Mon, 22 Aug 2011 05:25:40 -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 78F8821F853E for ; Mon, 22 Aug 2011 05:25:40 -0700 (PDT) Received: by qyk35 with SMTP id 35so2146769qyk.10 for ; Mon, 22 Aug 2011 05:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr1258680qci.223.1314015999207; Mon, 22 Aug 2011 05:26:39 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 05:26:39 -0700 (PDT) Date: Mon, 22 Aug 2011 14:26:39 +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] Close frame from webbrowser after close frame from server 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, 22 Aug 2011 12:25:41 -0000 Hi, my WS server (just starting it) does not terminate the TCP connection after sending a "close" frame to the client. I've realized that Google Chrome 15.0.854.0-dev sends a "close" frame upon receipt a "close" frame from the WS server and then the browser closes the TCP connection., but Firefox 8 does not send such "close" frame and directly closes the TCP connection. As per WS specification both seem valid behaviors but, shouldn't the spec mandate (or make more recommended) a more specific behaviour? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 05:48: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 8F45D21F8B30 for ; Mon, 22 Aug 2011 05:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kzttXOyrvvip for ; Mon, 22 Aug 2011 05:48:12 -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 E235B21F8B29 for ; Mon, 22 Aug 2011 05:48:11 -0700 (PDT) Received: by qyk35 with SMTP id 35so2157668qyk.10 for ; Mon, 22 Aug 2011 05:49:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr1261496qch.299.1314017356364; Mon, 22 Aug 2011 05:49:16 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 05:49:16 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 14:49:16 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 12:48:12 -0000 2011/8/22 Tobias Oberstein : >> It has been mentioned that "most applications will not need to exchange = anything but text messages". This is an unproven (and unprovable) assertion= . It is also true that what is true in the aggregate will most likely not a= pply to individual application implementers. > > It's indeed pointless to talk about proofs in this context, since the con= trary (that most applications will want to only exchange binary messages) i= s also unprovable. > > Here is my view: > > Assumption 1: Most WS clients will be browsers. > Assumption 2: Most (JavaScript) WS apps running in the browser will excha= nge small, JSON encoded messages. > > JSON is UTF-8-based. > > IMHO we should avoid anything which makes that use case less workable/con= venient. This must be a joke. A protocol specification design based on currently programming habits (mostly by developers with no more knowledge other than a few JavaScript and HTML). Great. Have you considered that many smartphone apps could/would use WS protocol as a standard mechanism to communicate with the servers? will you expect that smartphones apps are mainly coded in JavaScript and they mostly use JSON for "everything"??? Let me say that assuming JavaScript and JSON "just because you expect that" as a key for a protocol design seems really amateur. >>A small mezzanine protocol (layered on top of the WebSockets API, using t= he WebSocket protocol for transport) can easily serve those implementers th= at wish to have a text-only connection. It is thus unnecessary to place tha= t support within the WebSocket protocol. >>That I am suggesting a change in the WebSockets API is unclear. There is = already a need to distinguish Text from Binary at the level of the API, I m= erely suggest that the distinction be handled somewhat differently than is = currently envisioned. > > It works today .. it is good enough .. why change? "What" is working today? WebSockets? If a WS protocol has been negotiated during the WS handshake, both the client and the server *alreay* know the kind of data they can send via WS messages/frames (as such data must conform to the negotiated WS protocol). Why should such frames indicate "binary" or "text"? it's redundant information and provides NOTHING. It also leaves the door open for stupic issues like: - If I split a WS UTF-8 message in two frames, should each frame contain pure UTF-8 data? or can I split a multibyte UTF-8 symbol in both frames (so the data in each frame would be non valid UTF-8 text)? - Should the receiver check the encoding of the received message to ensure it's UTF-8 before sending the message to the application layer? WHY? > There is upcoming support for typed array (ArrayBuffer and typed array vi= ews over that) in JS. I don't care JS. There is more life out of JavaScript and HTML. > How is that transported in JSON payload and made transparent in the JSON.= stringify/parse marshaling/demarshaling API? Nobody making WS spec should care that. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 22 05:58: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 4FE9A21F85EC for ; Mon, 22 Aug 2011 05:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jbEF9GFE+P-B for ; Mon, 22 Aug 2011 05:58:58 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id BABCE21F85C7 for ; Mon, 22 Aug 2011 05:58:57 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 22 Aug 2011 06:00:02 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 22 Aug 2011 05:59:14 -0700 Thread-Topic: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) Thread-Index: Acxgyek95m0HqsSoQf6JlGj1p3gL2QAAGRwQ Message-ID: <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 12:58:58 -0000 Pkl0IGFsc28gbGVhdmVzIHRoZSBkb29yIG9wZW4gZm9yIHN0dXBpYyBpc3N1ZXMgbGlrZToNCj4N Cj4tIElmIEkgc3BsaXQgYSBXUyBVVEYtOCBtZXNzYWdlIGluIHR3byBmcmFtZXMsIHNob3VsZCBl YWNoIGZyYW1lIGNvbnRhaW4gcHVyZSBVVEYtOCBkYXRhPyBvciBjYW4gSSBzcGxpdCBhIG11bHRp Ynl0ZSBVVEYtOCBzeW1ib2wgaW4gYm90aCBmcmFtZXMgKHNvIHRoZSBkYXRhIGluIGVhY2ggZnJh bWUgd291bGQgYmUgbm9uIHZhbGlkIFVURi04IHRleHQpPw0KDQpBIGZyYW1lIGZyb20gYSB2YWxp ZCwgZnJhZ21lbnRlZCBVVEYtOCBtZXNzYWdlIGNhbiBlbmQgKG9yIHN0YXJ0LCBjb25zZXF1ZW50 bHkpIHdpdGhpbiB0aGUgVVRGLTggZW5jb2Rpbmcgb2YgYSBzaW5nbGUgVW5pY29kZSBjb2RlIHBv aW50Lg0KSW4gdGhhdCBjYXNlIHRoZSBmcmFtZSBieSBpdHNlbGYgaXMgb25seSB2YWxpZCBVVEYt OCB1cCB0byB0aGF0IGxhc3QgY29kZSBwb2ludCAob3IgZnJvbSB0aGUgZmlyc3QgY29tcGxldGUg ZW5jb2RlZCBjb2RlIHBvaW50KS4NCg0KPg0KPi0gU2hvdWxkIHRoZSByZWNlaXZlciBjaGVjayB0 aGUgZW5jb2Rpbmcgb2YgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgdG8gZW5zdXJlIGl0J3MgVVRGLTgg YmVmb3JlIHNlbmRpbmcgdGhlIG1lc3NhZ2UgdG8gdGhlIGFwcGxpY2F0aW9uIGxheWVyPw0KPldI WT8NCg0KWWVzLCBpdCBtdXN0IGRvIHRoYXQuIEZyb20gdGhlIHNwZWM6DQoNCiIiIg0KOC4xLiAg SGFuZGxpbmcgRXJyb3JzIGluIFVURi04IEVuY29kZWQgRGF0YQ0KDQogICBXaGVuIGFuIGVuZHBv aW50IGlzIHRvIGludGVycHJldCBhIGJ5dGUgc3RyZWFtIGFzIFVURi04IGJ1dCBmaW5kcw0KICAg dGhhdCB0aGUgYnl0ZSBzdHJlYW0gaXMgbm90IGluIGZhY3QgYSB2YWxpZCBVVEYtOCBzdHJlYW0s IHRoYXQNCiAgIGVuZHBvaW50IE1VU1QgX0ZhaWwgdGhlIFdlYlNvY2tldCBDb25uZWN0aW9uXy4N CiIiIg0KDQpUaGUgc3BlYyBkb2VzIG5vdCBzYXkgd2hldGhlciB0aGlzIGNoZWNrIG11c3QgYmUg ZG9uZSBhcyBzb29uIGFzIHBvc3NpYmxlLg0KDQpBIHN0cmljdCBpbXBsZW1lbnRhdGlvbiB3aWxs IGZhaWwgYXMgc29vbiBhcyBwb3NzaWJsZS4NCg0KV2hlbiBhIGZyYW1lIGVuZCBvbiBhbiBVbmlj b2RlIGNvZGUgcG9pbnQsIHRoYXQgY2hlY2sgY2FuIGJlIGRvbmUgcGVyIGZyYW1lLg0KDQpXaGVu IG5vdCwgaXQgY2FuIGJlIGRvbmUgYXQgbGVhc3Qgd2hlbiByZWNlaXZpbmcgdGhlIGZpcnN0IGJ5 dGVzIG9mIHRoZSBmb2xsb3cgdXAgZnJhbWUuDQoNCkZvciBVVEYtOCBhbnkgVW5pY29kZSBjb2Rl IHBvaW50IGhhcyBhbiBlbmNvZGluZyBvZiBsZW5ndGggPD0gNC4NCg0KU28gdGhpcyBpcyB0aGUg Imxvb2sgYWhlYWQiIHlvdSBuZWVkIHRvIGNoZWNrIFVURi04Lg0K From ibc@aliax.net Mon Aug 22 06:15: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 813AF21F8AC9 for ; Mon, 22 Aug 2011 06:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvWjcNt0n+V0 for ; Mon, 22 Aug 2011 06:15:51 -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 0220921F8A96 for ; Mon, 22 Aug 2011 06:15:50 -0700 (PDT) Received: by qwc23 with SMTP id 23so3729528qwc.31 for ; Mon, 22 Aug 2011 06:16:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr1256219qcq.261.1314019015697; Mon, 22 Aug 2011 06:16:55 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 06:16:55 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 15:16:55 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:15:51 -0000 2011/8/22 Tobias Oberstein : >>- If I split a WS UTF-8 message in two frames, should each frame contain = pure UTF-8 data? or can I split a multibyte UTF-8 symbol in both frames (so= the data in each frame would be non valid UTF-8 text)? > > A frame from a valid, fragmented UTF-8 message can end (or start, consequ= ently) within the UTF-8 encoding of a single Unicode code point. > In that case the frame by itself is only valid UTF-8 up to that last code= point (or from the first complete encoded code point). Why should my WS *frame* parser be Unicode aware? it's insane. WS frame is not a text protocol (but a binary protocol). When retrieving the frame payload data I should just care about reading N bytes, rather than inspecting such data with an Unicode interpreter to check "invalid UTF-8 encoding". Apart from that, your assertion is not present in the draft, is it? --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Mon Aug 22 06:18: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 68A6221F8B28 for ; Mon, 22 Aug 2011 06:18:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqW3Ou5hc0nF for ; Mon, 22 Aug 2011 06:18:27 -0700 (PDT) Received: from smtpoutwbe09.prod.mesa1.secureserver.net (smtpoutwbe09.prod.mesa1.secureserver.net [208.109.78.21]) by ietfa.amsl.com (Postfix) with SMTP id A361121F8B0C for ; Mon, 22 Aug 2011 06:18:27 -0700 (PDT) Received: (qmail 25035 invoked from network); 22 Aug 2011 13:19:32 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe09.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 13:19:31 -0000 Received: (qmail 19386 invoked by uid 99); 22 Aug 2011 13:19:31 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> From: "Bob Gezelter" To: hybi@ietf.org Date: Mon, 22 Aug 2011 06:19:30 -0700 Mime-Version: 1.0 Cc: Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 13:18:28 -0000 Tobias,=0A=0AI have not looked into how JSON parse/marshaling is handling t= he typed=0Aarrays, particularly the question of uniformity across different= =0Abrowsers (or different versions of the same browser). However, IMHO,=0At= hat is at best a browser-related WebSockets API question, there remains=0An= o need to push that encoding/decoding issue into the WebSocket protocol=0Ai= tself.=0A=0AAs I have noted in the past, one of the few places that such a = dichotomy=0Ais associated with an IETF protocol is FTP. The reason for this= is=0Ahistorical, and still relevant in cross-platform contexts. When text= =0Afiles are transmitted between hosts, they are subject to transformations= =0Adesigned to "preserve" the textual content (e.g., character codes,=0Afor= matting, line breaks) across the transmission. By contrast, binary=0Afiles = are transmitted without change. =0A=0AThe transformations of "text" mode, w= hile often useful, have been the=0Asource of innumerable accidents and prob= lems since their advent. They=0Awere, and are necessary, but they should be= viewed with caution.=0A=0AIn the case of the WebSocket protocol, there is = little to be gained by=0Athe text/binary dichotomy (as I noted previously, = this is=0Astraightforward to implement as an "applications protocol"/unders= tanding=0Aat the level of the WebSocket API).=0A=0A- Bob Gezelter, http://w= ww.rlgsc.com=0A=0ATobias Oberstein wrote:=0A=0A>Bob,=0A=0A>> It has been me= ntioned that "most applications will not need to exchange anything but text= messages". =0A>>This is an unproven (and unprovable) assertion. It is also= true that what is true in the aggregate =0A>>will most likely not apply to= individual application implementers.=0A>=0A>It's indeed pointless to talk = about proofs in this context, since the contrary (that most applications wi= ll >want to only exchange binary messages) is also unprovable.=0A>=0A>Here = is my view:=0A>=0A>Assumption 1: Most WS clients will be browsers.=0A>Assum= ption 2: Most (JavaScript) WS apps running in the browser will exchange sma= ll, JSON encoded messages.=0A>=0A>JSON is UTF-8-based.=0A>=0A>IMHO we shoul= d avoid anything which makes that use case less workable/convenient.=0A>=0A= >You can of course question those assumptions ..=0A>=0A>>A small mezzanine = protocol (layered on top of the WebSockets API, using the WebSocket protoco= l =0A>>for transport) can easily serve those implementers that wish to have= a text-only connection. =0A>>It is thus unnecessary to place that support = within the WebSocket protocol.=0A>>=0A>>That I am suggesting a change in th= e WebSockets API is unclear. There is already a need to =0A>>distinguish Te= xt from Binary at the level of the API, I merely suggest that the distincti= on be =0A>>handled somewhat differently than is currently envisioned.=0A>= =0A>It works today .. it is good enough .. why change?=0A>=0A>There is a di= fferent issue (unrelated to WS protocol .. see my other post):=0A>=0A>There= is upcoming support for typed array (ArrayBuffer and typed array views ove= r that) in JS.=0A>=0A>How is that transported in JSON payload and made tran= sparent in the JSON.stringify/parse =0A>marshaling/demarshaling API?=0A>=0A= >Tobias=0A=0A=0A From phil127@gmail.com Mon Aug 22 06:19: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 1A7D021F8B28 for ; Mon, 22 Aug 2011 06:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQoSL+uzWRbW for ; Mon, 22 Aug 2011 06:19:38 -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 51EB621F8B0C for ; Mon, 22 Aug 2011 06:19:38 -0700 (PDT) Received: by bkar4 with SMTP id r4so4474750bka.31 for ; Mon, 22 Aug 2011 06:20:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=t3vCOvQAbfDg00WUfe2ljC8EyrzW+ovsORUz/tWmmmg=; b=p09oexJedABw1lp/HZ/aJsP4o+dwRCR/IGwgpOz/iDcS2GJGJyoLCm+RoCgoPQBhZx FKjboiTcAmvolGUDY1CSVF9VA3Tbfn6Cl6WzztZ97r4tfslYvVXVX1R7hQCrSzNLlVrK rhhr70b+jkPB4sBN9WRrEHdCv7fmtuH6Yn4eE= Received: by 10.204.156.152 with SMTP id x24mr886668bkw.263.1314019205845; Mon, 22 Aug 2011 06:20:05 -0700 (PDT) Received: from [212.201.74.103] (pptp-212-201-74-103.pptp.stw-bonn.de [212.201.74.103]) by mx.google.com with ESMTPS id n9sm1938493bkd.7.2011.08.22.06.20.04 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 06:20:04 -0700 (PDT) Message-ID: <4E52577A.9080905@gmail.com> Date: Mon, 22 Aug 2011 15:19:54 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:19:39 -0000 Am 22.08.2011 15:16, schrieb Iñaki Baz Castillo: > 2011/8/22 Tobias Oberstein : >>> - If I split a WS UTF-8 message in two frames, should each frame contain pure UTF-8 data? or can I split a multibyte UTF-8 symbol in both frames (so the data in each frame would be non valid UTF-8 text)? >> A frame from a valid, fragmented UTF-8 message can end (or start, consequently) within the UTF-8 encoding of a single Unicode code point. >> In that case the frame by itself is only valid UTF-8 up to that last code point (or from the first complete encoded code point). > Why should my WS *frame* parser be Unicode aware? it's insane. WS > frame is not a text protocol (but a binary protocol). When retrieving > the frame payload data I should just care about reading N bytes, > rather than inspecting such data with an Unicode interpreter to check > "invalid UTF-8 encoding". > > Apart from that, your assertion is not present in the draft, is it? > If WS frames *can* end inside a code pojnt, like he said, wouldn't that mean your frame parser does *not* have to care? (Which sounds like the reasoneable way to define it, IMO.) From ibc@aliax.net Mon Aug 22 06:27: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 1564621F8B04 for ; Mon, 22 Aug 2011 06:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.639 X-Spam-Level: X-Spam-Status: No, score=-2.639 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34ACBkOFGJ8g for ; Mon, 22 Aug 2011 06:27:44 -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 7FADC21F8B01 for ; Mon, 22 Aug 2011 06:27:44 -0700 (PDT) Received: by qwc23 with SMTP id 23so3736794qwc.31 for ; Mon, 22 Aug 2011 06:28:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr1291465qch.299.1314019729251; Mon, 22 Aug 2011 06:28:49 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 06:28:49 -0700 (PDT) In-Reply-To: <4E52577A.9080905@gmail.com> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> Date: Mon, 22 Aug 2011 15:28:49 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Philipp Serafin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:27:45 -0000 2011/8/22 Philipp Serafin : > If WS frames *can* end inside a code pojnt, like he said, wouldn't that > mean your frame parser does *not* have to care? (Which sounds like the > reasoneable way to define it, IMO.) Of course. My frame parser is just byte-aware and I just read N bytes (payload_length) from the frame payload data. This is how it MUST be IMHO. Unfortunatelly (and this is what I was trying to say in these mails) the WS draft seems to state that frames (with opcode=3D1) MUST contain valid UTF-8 data (not just the whole message, but each frame payload data). So if an UTF-8 multibyte symbol gets splited within two consecutive frames, each frame has invalid UTF-8 data. Is it an error then? or not? I know that Tobias says it's not an error, but honestly I don't find such assertion in the WS draft. PLEASE: Change the spec to say: "the *whole* message (after joining all the frames payload) MUST be UTF-8 in case the first frame has opcode=3D1." But even better: just remove the opcode "1" and "2" values and let just "1" (application data). The previously negotiated WS protocol *already* defines the kind o data being carried within WS messages. WS framing layer should not care about payload data encoding, not at all. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 06:31: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 E3ADC21F8B39 for ; Mon, 22 Aug 2011 06:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ChSsldUUy1q for ; Mon, 22 Aug 2011 06:31:18 -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 63ED421F8B37 for ; Mon, 22 Aug 2011 06:31:18 -0700 (PDT) Received: by qyk35 with SMTP id 35so2180184qyk.10 for ; Mon, 22 Aug 2011 06:32:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr1267529qcq.261.1314019943203; Mon, 22 Aug 2011 06:32:23 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 06:32:23 -0700 (PDT) In-Reply-To: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> Date: Mon, 22 Aug 2011 15:32:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 13:31:19 -0000 2011/8/22 Bob Gezelter : > The transformations of "text" mode, while often useful, have been the > source of innumerable accidents and problems since their advent. So ***great*** real case. WS authors, please, learn from the History (or you will repeat it). --=20 I=C3=B1aki Baz Castillo From jat@google.com Mon Aug 22 06:33: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 6F63721F8B39 for ; Mon, 22 Aug 2011 06:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.793 X-Spam-Level: X-Spam-Status: No, score=-105.793 tagged_above=-999 required=5 tests=[AWL=-0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOTaFT0HSx+a for ; Mon, 22 Aug 2011 06:33:37 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9A23121F8B37 for ; Mon, 22 Aug 2011 06:33:37 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p7MDYWJb029759 for ; Mon, 22 Aug 2011 06:34:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314020072; bh=qKa6ecrzICMZZ8E1VdSTLlZNT1U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=M9L8pDfuvdtbVvn9ajVkgvoqqU6bl0ALJYRhTVhKnbP+Pso5e9ulYvDT1zWD/p/6G LCoQb9yLMV52/fCNnqg2w== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=QIBPtPYBMZ/NMVckHQztUrvB7lk0HdT7SEymGKvmZr0KwhM8sJhGOl2+nPV6pW6KD /OmtoB5QRvA6lysaD8LKA== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by hpaq14.eem.corp.google.com with ESMTP id p7MDYQsr028290 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 06:34:30 -0700 Received: by ywf9 with SMTP id 9so4145513ywf.4 for ; Mon, 22 Aug 2011 06:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kfTgpQIncJf1SnHOm8vtIt4Ucwi46CkDqvhq7DK0AsY=; b=uLfLXGAjLn5V5clDTlwIFZaLgF79zGSEfClHnTagRLbbZJJT+KBbhxRp6mSrHURG2q Zfd/iehdKqRE+JfV+G3g== Received: by 10.151.25.12 with SMTP id c12mr2245991ybj.116.1314020070316; Mon, 22 Aug 2011 06:34:30 -0700 (PDT) Received: by 10.151.25.12 with SMTP id c12mr2245983ybj.116.1314020070169; Mon, 22 Aug 2011 06:34:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 06:34:10 -0700 (PDT) In-Reply-To: References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> From: John Tamplin Date: Mon, 22 Aug 2011 09:34:10 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd293c2829ca904ab182365 X-System-Of-Record: true Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:33:38 -0000 --000e0cd293c2829ca904ab182365 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 9:28 AM, I=C3=B1aki Baz Castillo wr= ote: > Of course. My frame parser is just byte-aware and I just read N bytes > (payload_length) from the frame payload data. This is how it MUST be > IMHO. > You can certainly do that, but then you may be doing extra buffering if you need to convert text to UTF16/etc -- instead you could convert each frame a= s it comes in and maintain state for the incomplete character at the end of a frame. > Unfortunatelly (and this is what I was trying to say in these mails) > the WS draft seems to state that frames (with opcode=3D1) MUST contain > valid UTF-8 data (not just the whole message, but each frame payload > data). So if an UTF-8 multibyte symbol gets splited within two > consecutive frames, each frame has invalid UTF-8 data. Is it an error > then? or not? > > I know that Tobias says it's not an error, but honestly I don't find > such assertion in the WS draft. > This has been discussed before -- framing can occur at arbitrary byte boundaries in the payload, which necessarily means that each frame does not contain only complete UTF8 characters. > PLEASE: Change the spec to say: "the *whole* message (after joining > all the frames payload) MUST be UTF-8 in case the first frame has > opcode=3D1." > Can you make a specific suggestion of what you think should be changed? --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd293c2829ca904ab182365 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 9:28 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
Of course. My frame parser is just byte-aware and I just read N bytes
(payload_length) from the frame payload data. This is how it MUST be
IMHO.

You can certainly do that, but th= en you may be doing extra buffering if you need to convert text to UTF16/et= c -- instead you could convert each frame as it comes in and maintain state= for the incomplete character at the end of a frame.
=C2=A0
Unfortunatelly (and this is what I was trying to say in these mails)
the WS draft seems to state that frames (with opcode=3D1) MUST contain
valid UTF-8 data (not just the whole message, but each frame payload
data). So if an UTF-8 multibyte symbol gets splited within two
consecutive frames, each frame has invalid UTF-8 data. Is it an error
then? or not?

I know that Tobias says it's not an error, but honestly I don't fin= d
such assertion in the WS draft.

This ha= s been discussed before -- framing can occur at arbitrary byte boundaries i= n the payload, which necessarily means that each frame does not contain onl= y complete UTF8 characters.
=C2=A0
PLEASE: Change the spec to say: "the *whole* message (after joining all the frames payload) MUST be UTF-8 in case the first frame has
opcode=3D1."

Can you make a speci= fic suggestion of what you think should be changed?
<= br>
--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd293c2829ca904ab182365-- From jat@google.com Mon Aug 22 06:34: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 4C01721F8B40 for ; Mon, 22 Aug 2011 06:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.787 X-Spam-Level: X-Spam-Status: No, score=-105.787 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TO3Br8hz8Us for ; Mon, 22 Aug 2011 06:34:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 56C4821F8B37 for ; Mon, 22 Aug 2011 06:34:49 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p7MDZrS8001718 for ; Mon, 22 Aug 2011 06:35:53 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314020153; bh=eN1Cw0+exGyO8/5vTKq7Aw9sOKU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=k0vzKCM40ru46NC1R6cn5Vm0o7z8LOMSI3Pa7h4g89Gpnpa8b1Fl71zhSbzqI8Z2r nB9UcWkl9AacLs3ZdLycw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=fAz/80FbUug1ucAL6qJTo/ts2KWiAcRnC7Pp0tmjVmmAhC0H8wNxZgjVtmrR3UoQc wgcKG3hfgN97yjAaWyf0w== Received: from ywb3 (ywb3.prod.google.com [10.192.2.3]) by hpaq5.eem.corp.google.com with ESMTP id p7MDYi3I009118 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 06:35:52 -0700 Received: by ywb3 with SMTP id 3so5727315ywb.1 for ; Mon, 22 Aug 2011 06:35:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rlbsEFPMTWTPUOdHDyUoIKxR3tAS+55UQ2xsugnvlo0=; b=oUkxIYgEQajtenXp7gAet+OT5w8cNEAaXtE8R3laTu4zlDRjP7TYS3ArQ/WoVwdYit UFDnS6gaRnpJk7nCNoDw== Received: by 10.150.253.9 with SMTP id a9mr2280991ybi.230.1314020152285; Mon, 22 Aug 2011 06:35:52 -0700 (PDT) Received: by 10.150.253.9 with SMTP id a9mr2280982ybi.230.1314020152149; Mon, 22 Aug 2011 06:35:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 06:35:32 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> From: John Tamplin Date: Mon, 22 Aug 2011 09:35:32 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001517475c9265889a04ab18286e X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 13:34:50 -0000 --001517475c9265889a04ab18286e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 9:32 AM, I=C3=B1aki Baz Castillo wr= ote: > 2011/8/22 Bob Gezelter : > > The transformations of "text" mode, while often useful, have been the > > source of innumerable accidents and problems since their advent. > > So ***great*** real case. > > WS authors, please, learn from the History (or you will repeat it). I don't think this proves what you think it does -- in fact, to me it argue= s for exactly what we have now, which is defining exactly how text messages are transported and represented, rather than leaving it up to each applcation. --=20 John A. Tamplin Software Engineer (GWT), Google --001517475c9265889a04ab18286e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 9:32 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
2011/8/22 Bob Gezelter <gezelter@r= lgsc.com>:
> The transformations of "text" mode, while = often useful, have been the
> source of innumerable accidents and problems since their advent.

So ***great*** real case.

WS authors, please, learn from the History (or you will repeat it).

I don't think this proves what you think it do= es -- in fact, to me it argues for exactly what we have now, which is defin= ing exactly how text messages are transported and represented, rather than = leaving it up to each applcation.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--001517475c9265889a04ab18286e-- From tobias.oberstein@tavendo.de Mon Aug 22 06:37:47 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 03E8F21F8B38 for ; Mon, 22 Aug 2011 06:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zYKTNuSWF1Pn for ; Mon, 22 Aug 2011 06:37:46 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 096B321F8B37 for ; Mon, 22 Aug 2011 06:37:46 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 22 Aug 2011 06:38:50 -0700 From: Tobias Oberstein To: Philipp Serafin , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 22 Aug 2011 06:38:02 -0700 Thread-Topic: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) Thread-Index: Acxgzk3DYVVGaGaVQp2NCny1IV6JEwAAAA1A Message-ID: <634914A010D0B943A035D226786325D422C0D5CA52@EXVMBX020-12.exch020.serverdata.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> In-Reply-To: <4E52577A.9080905@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:37:47 -0000 Pj4+PiAtIElmIEkgc3BsaXQgYSBXUyBVVEYtOCBtZXNzYWdlIGluIHR3byBmcmFtZXMsIHNob3Vs ZCBlYWNoIGZyYW1lIGNvbnRhaW4gcHVyZSBVVEYtOCBkYXRhPyBvciBjYW4gSSBzcGxpdCBhIG11 bHRpYnl0ZSBVVEYtOCBzeW1ib2wgaW4gYm90aCBmcmFtZXMgKHNvIHRoZSBkYXRhIGluIGVhY2gg ZnJhbWUgd291bGQgYmUgbm9uIHZhbGlkIFVURi04IHRleHQpPw0KPj4+IEEgZnJhbWUgZnJvbSBh IHZhbGlkLCBmcmFnbWVudGVkIFVURi04IG1lc3NhZ2UgY2FuIGVuZCAob3Igc3RhcnQsIGNvbnNl cXVlbnRseSkgd2l0aGluIHRoZSBVVEYtOCBlbmNvZGluZyBvZiBhIHNpbmdsZSBVbmljb2RlIGNv ZGUgcG9pbnQuDQo+Pj4gSW4gdGhhdCBjYXNlIHRoZSBmcmFtZSBieSBpdHNlbGYgaXMgb25seSB2 YWxpZCBVVEYtOCB1cCB0byB0aGF0IGxhc3QgY29kZSBwb2ludCAob3IgZnJvbSB0aGUgZmlyc3Qg Y29tcGxldGUgZW5jb2RlZCBjb2RlIHBvaW50KS4NCj4+IFdoeSBzaG91bGQgbXkgV1MgKmZyYW1l KiBwYXJzZXIgYmUgVW5pY29kZSBhd2FyZT8gaXQncyBpbnNhbmUuIFdTIA0KPj4gZnJhbWUgaXMg bm90IGEgdGV4dCBwcm90b2NvbCAoYnV0IGEgYmluYXJ5IHByb3RvY29sKS4gV2hlbiByZXRyaWV2 aW5nIA0KPj4gdGhlIGZyYW1lIHBheWxvYWQgZGF0YSBJIHNob3VsZCBqdXN0IGNhcmUgYWJvdXQg cmVhZGluZyBOIGJ5dGVzLCANCj4+IHJhdGhlciB0aGFuIGluc3BlY3Rpbmcgc3VjaCBkYXRhIHdp dGggYW4gVW5pY29kZSBpbnRlcnByZXRlciB0byBjaGVjayANCj4+ICJpbnZhbGlkIFVURi04IGVu Y29kaW5nIi4NCj4+DQo+PiBBcGFydCBmcm9tIHRoYXQsIHlvdXIgYXNzZXJ0aW9uIGlzIG5vdCBw cmVzZW50IGluIHRoZSBkcmFmdCwgaXMgaXQ/DQo+Pg0KPklmIFdTIGZyYW1lcyAqY2FuKiBlbmQg aW5zaWRlIGEgY29kZSBwb2pudCwgbGlrZSBoZSBzYWlkLCB3b3VsZG4ndCB0aGF0IG1lYW4geW91 ciBmcmFtZSBwYXJzZXIgZG9lcyAqbm90KiBoYXZlIHRvIGNhcmU/IChXaGljaCBzb3VuZHMgbGlr ZSB0aGUgcmVhc29uZWFibGUgd2F5IHRvIGRlZmluZSBpdCwgSU1PLikNCg0KaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1oeWJpLXRoZXdlYnNvY2tldHByb3RvY29sLTEwI3Bh Z2UtNDUNCg0KaXQgdGFsa3MgYWJvdXQgImJ5dGUgc3RyZWFtIg0KDQpmdXJ0aGVyOg0KLSB0aGUg c3BlYyBub3doZXJlIGZvcmJpZHMgYnJlYWtpbmcgdXAgYSB0ZXh0IG1lc3NhZ2Ugb24gbm9uLVVU Ri04IGNvZGUgcG9pbnQgYm91bmRhcmllcw0KLSBpbnRlcm1lZGlhcmllcyBjYW4gZnJhZ21lbnQg YXMgdGhleSBsaWtlIC0gYWdhaW4gbm93aGVyZSBpcyB3cml0dGVuIHRoZXknZCBuZWVkIHRvIGhv bm91ciBib3VuZGFyaWVzIG9mIFVURi04IGVuY29kZWQgVW5pY29kZSBjb2RlIHBvaW50cw0KDQp0 aGUgc3BlYyBkb2VzIG5vdCBtYWtlIGV4cGxpY2l0IGV2ZXJ5dGhpbmcgdGhhdCBpcyBsZWdhbCwg b2Z0ZW4gb25seSB3aGF0cyBpbGxlZ2FsLiBJdCB3b3VsZCBiZSBkYXVudGluZyBpZiB0aGUgZm9y bWVyIHdhcyBkb25lLiAoWW91IG1heSBzZW5kDQphIGJpbmFyeSBtZXNzYWdlIHdoZXJlIHRoZSBm aXJzdCBieXRlIGlzIHgwMCBvciB4MDEgb3IgeDAyIC4uLiAtLSBzZWVtcyBzaWxseSkNCg0KYWxz bzogd2l0aCBhIGxvb2stYWhlYWQgb2YgNCBieXRlcyB5b3UgY2FuIGNoZWNrIGZvciBpbnZhbGlk IFVURi04IGJ5dGUgc2VxdWVuY2VzIGluIGEgc3RyZWFtaW5nIGZhc2hpb24uIFlvdSBkb24ndCBu ZWVkIHRoZSB3aG9sZSBtZXNzYWdlLg0KDQo9PQ0KDQphbnl3YXk6IEkgZGlkbid0IHdyaXRlIHRo ZSBzcGVjIC4uIGp1c3QgbXkgaW50ZXJwcmV0YXRpb24gLi4gcHJvYmFibHkgdGhlIGF1dGhvcnMv ZWRpdG9ycyBvciBzb21lb25lIGVsc2UgY2FuIHNwZWFrIG91dA0K From gezelter@rlgsc.com Mon Aug 22 06:40: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 1A81021F8A4D for ; Mon, 22 Aug 2011 06:40: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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2PXX5LBcfbV for ; Mon, 22 Aug 2011 06:40:51 -0700 (PDT) Received: from smtpoutwbe04.prod.mesa1.secureserver.net (smtpoutwbe04.prod.mesa1.secureserver.net [208.109.78.206]) by ietfa.amsl.com (Postfix) with SMTP id 4683421F89CC for ; Mon, 22 Aug 2011 06:40:51 -0700 (PDT) Received: (qmail 27696 invoked from network); 22 Aug 2011 13:41:56 -0000 Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe04.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 13:41:56 -0000 Received: (qmail 6952 invoked by uid 99); 22 Aug 2011 13:41:56 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "John Tamplin" Date: Mon, 22 Aug 2011 06:41:54 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 13:40:52 -0000 John,=0A=0AWith all due respect, I must disagree.=0A=0AYou are correct that= what is in the record needs to be a matter of=0Aagreement between the send= er and the recipient.=0A=0AHowever, the WebSocket protocol is not, IMHO, th= e correct place for that=0Adistinction. It is a higher-level distinction, t= hat should be a=0A"protocol" between the respective WebSockets APIs. There = is no need for=0Athis distinction within the WebSocket protocol itself.=0A= =0AAdmittedly, the coincidence of the WebSockets API and the WebSocket=0Apr= otocol using similar names does contribute to a degree of "misspeak"=0Ahaza= rd.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A=0A> -------- Original Mess= age --------=0A> Subject: Re: [hybi] Binary/Text Distinction=0A> From: John= Tamplin =0A> Date: Mon, August 22, 2011 6:35 am=0A> To: I= =C3=B1aki_Baz_Castillo =0A> Cc: Bob Gezelter , hybi@ietf.org, Bjoern=0A> Hoehrmann =0A> = =0A> =0A> On Mon, Aug 22, 2011 at 9:32 AM, I=C3=B1aki Baz Castillo wrote:=0A> =0A> > 2011/8/22 Bob Gezelter :=0A> = > > The transformations of "text" mode, while often useful, have been the= =0A> > > source of innumerable accidents and problems since their advent.= =0A> >=0A> > So ***great*** real case.=0A> >=0A> > WS authors, please, lear= n from the History (or you will repeat it).=0A> =0A> =0A> I don't think thi= s proves what you think it does -- in fact, to me it argues=0A> for exactly= what we have now, which is defining exactly how text messages=0A> are tran= sported and represented, rather than leaving it up to each=0A> applcation.= =0A> =0A> -- =0A> John A. Tamplin=0A> Software Engineer (GWT), Google=0A From ibc@aliax.net Mon Aug 22 06:41: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 73F3521F8B29 for ; Mon, 22 Aug 2011 06:41:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELLhtnIFn+5k for ; Mon, 22 Aug 2011 06:41:02 -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 E0D1E21F89CC for ; Mon, 22 Aug 2011 06:41:01 -0700 (PDT) Received: by qyk35 with SMTP id 35so2185814qyk.10 for ; Mon, 22 Aug 2011 06:42:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr1274794qcq.261.1314020526740; Mon, 22 Aug 2011 06:42:06 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 06:42:05 -0700 (PDT) In-Reply-To: References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> Date: Mon, 22 Aug 2011 15:42:05 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:41:02 -0000 2011/8/22 John Tamplin : >> PLEASE: Change the spec to say: "the *whole* message (after joining >> all the frames payload) MUST be UTF-8 in case the first frame has >> opcode=3D1." > > Can you make a specific suggestion of what you think should be changed? Yes: --------------------------------------- 4.6. Data Frames Data frames (e.g. non-control frames) are identified by opcodes where the most significant bit of the opcode is 0. Currently defined opcodes for data frames include 0x1 (Text), 0x2 (Binary). Opcodes 0x3-0x7 are reserved for further non-control frames yet to be defined. Data frames carry application-layer or extension-layer data. The opcode determines the interpretation of the data: Text The payload data is text data encoded as UTF-8. ------------------------------------- That section is clearly speaking about payload data in a frame (a not about the whole message), and it states: "The payload data is text data encoded as UTF-8." This seems to say that the payload data within each frame MUST be a completely valid UTF-8 string (which is not true in the case I explained: a multibyte UTF-8 symbol splited in the end of a frame). So your previous assertion: "This has been discussed before -- framing can occur at arbitrary byte boundaries in the payload, which necessarily means that each frame does not contain only complete UTF8 characters." does not fit well with the draft text. It could be fixed by replacing: Text The payload data is text data encoded as UTF-8. with: Text The whole message (after reassembling all the payload data in the frames) is text data encoded as UTF-8. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 06:42: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 1BB8B21F8B43 for ; Mon, 22 Aug 2011 06:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.64 X-Spam-Level: X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlNr7-ZABnqb for ; Mon, 22 Aug 2011 06:42:27 -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 9145321F8B40 for ; Mon, 22 Aug 2011 06:42:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so3745990qwc.31 for ; Mon, 22 Aug 2011 06:43:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr1313767qci.223.1314020612277; Mon, 22 Aug 2011 06:43:32 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 06:43:32 -0700 (PDT) In-Reply-To: References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> Date: Mon, 22 Aug 2011 15:43:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:42:28 -0000 2011/8/22 I=C3=B1aki Baz Castillo : > It could be fixed by replacing: > > =C2=A0 Text > > =C2=A0 =C2=A0 =C2=A0The payload data is text data encoded as UTF-8. > > with: > > =C2=A0 Text > > =C2=A0 =C2=A0 =C2=A0The whole message (after reassembling all the payload= data in > the frames) is text data encoded as UTF-8. Also: 7.4.1. Defined Status Codes ---------------------------- 1007 1007 indicates that an endpoint is terminating the connection because it has received data that was supposed to be UTF-8 (such as in a text frame) that was in fact not valid UTF-8 [RFC3629]. ------------------------------ better: ---------------------------- 1007 1007 indicates that an endpoint is terminating the connection because it has received data that was supposed to be UTF-8 (such as in a text message) that was in fact not valid UTF-8 [RFC3629]. ------------------------------ --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 06:47:36 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 1363221F8B4A for ; Mon, 22 Aug 2011 06:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xbSi+KM3LsL for ; Mon, 22 Aug 2011 06:47:35 -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 7159121F8B47 for ; Mon, 22 Aug 2011 06:47:35 -0700 (PDT) Received: by qwc23 with SMTP id 23so3749071qwc.31 for ; Mon, 22 Aug 2011 06:48:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr1317779qci.223.1314020918780; Mon, 22 Aug 2011 06:48:38 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 06:48:38 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5CA52@EXVMBX020-12.exch020.serverdata.net> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> <634914A010D0B943A035D226786325D422C0D5CA52@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 15:48:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 13:47:36 -0000 2011/8/22 Tobias Oberstein : > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#page-4= 5 It says: When an endpoint is to interpret a byte stream as UTF-8 but finds that the byte stream is not in fact a valid UTF-8 stream, that endpoint MUST _Fail the WebSocket Connection_. > it talks about "byte stream" It does not specify nothing about "inspecting a frame payload data" or a "whole message". Nothing. > further: > - the spec nowhere forbids breaking up a text message on non-UTF-8 code p= oint boundaries Please read my two previous mails in which I point to sections forbiding it. Specially: --------------------------------------- 4.6. Data Frames Data frames (e.g. non-control frames) are identified by opcodes where the most significant bit of the opcode is 0. Currently defined opcodes for data frames include 0x1 (Text), 0x2 (Binary). Opcodes 0x3-0x7 are reserved for further non-control frames yet to be defined. Data frames carry application-layer or extension-layer data. The opcode determines the interpretation of the data: Text The payload data is text data encoded as UTF-8. ------------------------------------- > - intermediaries can fragment as they like - again nowhere is written the= y'd need to honour boundaries of UTF-8 encoded Unicode code points Sorry, but what the f*** is an intermediary? All the people here talks about "intermediaries" and nobody seems to explain "what it is". > the spec does not make explicit everything that is legal, often only what= s illegal. It would be daunting if the former was done. (You may send > a binary message where the first byte is x00 or x01 or x02 ... -- seems s= illy) > > also: with a look-ahead of 4 bytes you can check for invalid UTF-8 byte s= equences in a streaming fashion. You don't need the whole message. > > =3D=3D > > anyway: I didn't write the spec .. just my interpretation .. probably the= authors/editors or someone else can speak out Don't take me wrong but, what you are doing is looking for any argument in order to justify the draft text. Isn't easier just to improve it and make better? :) --=20 I=C3=B1aki Baz Castillo From sh@defuze.org Mon Aug 22 07:14: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 EA61121F8AFE for ; Mon, 22 Aug 2011 07:14:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.826 X-Spam-Level: X-Spam-Status: No, score=-2.826 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89+uSh52ZKWZ for ; Mon, 22 Aug 2011 07:14:42 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 31F0B21F853E for ; Mon, 22 Aug 2011 07:14:42 -0700 (PDT) Received: by pzk33 with SMTP id 33so16808508pzk.18 for ; Mon, 22 Aug 2011 07:15:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.44.135 with SMTP id e7mr128317pbm.386.1314022535595; Mon, 22 Aug 2011 07:15:35 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Mon, 22 Aug 2011 07:15:35 -0700 (PDT) X-Originating-IP: [195.101.247.164] In-Reply-To: References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> <634914A010D0B943A035D226786325D422C0D5CA52@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 16:15:35 +0200 Message-ID: From: Sylvain Hellegouarch To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=bcaec51dd1877607bf04ab18b6e5 Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 14:14:43 -0000 --bcaec51dd1877607bf04ab18b6e5 Content-Type: text/plain; charset=ISO-8859-1 > > > > > - intermediaries can fragment as they like - again nowhere is written > they'd need to honour boundaries of UTF-8 encoded Unicode code points > > Sorry, but what the f*** is an intermediary? All the people here talks > about "intermediaries" and nobody seems to explain "what it is". > > > I assume that unless clearly stated for a given scenario, it would mean "whatever may come in between two endpoints". In most cases, it doesn't seem to matter much what they are or what they do other than the fact they can interact with the frames. In fact I would consider best practices, among intermediary vendors, will arise when WS becomes common. I wouldn't expect the current spec to specify how they interact with WS. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach --bcaec51dd1877607bf04ab18b6e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


> - intermediaries can fragment as they like - again nowhere is written = they'd need to honour boundaries of UTF-8 encoded Unicode code points
Sorry, but what the f*** is an intermediary? All the people here talk= s
about "intermediaries" and nobody seems to explain "what it = is".


=A0

<= div>I assume that unless clearly stated for a given scenario, it would mean= "whatever may come in between two endpoints". In most cases, it = doesn't seem to matter much what they are or what they do other than th= e fact they can interact with the frames. In fact I would consider best pra= ctices, among intermediary vendors, will arise when WS becomes common. I wo= uldn't expect the current spec to specify how they interact with WS.
=A0
--
- Sylvain
h= ttp://www.defuze.org
http://= twitter.com/lawouach
--bcaec51dd1877607bf04ab18b6e5-- From tobias.oberstein@tavendo.de Mon Aug 22 07:16: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 D5AB621F8AF1 for ; Mon, 22 Aug 2011 07:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIAzgQH5xnoB for ; Mon, 22 Aug 2011 07:16:22 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 3905D21F8AD6 for ; Mon, 22 Aug 2011 07:16:22 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Mon, 22 Aug 2011 07:17:26 -0700 From: Tobias Oberstein To: Bob Gezelter , "hybi@ietf.org" Date: Mon, 22 Aug 2011 07:16:38 -0700 Thread-Topic: Binary/Text Distinction Thread-Index: AcxgziOfwnk7Sqy7TIGxZfHfYflfogABMbFA Message-ID: <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> In-Reply-To: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 14:16:22 -0000 PkkgaGF2ZSBub3QgbG9va2VkIGludG8gaG93IEpTT04gcGFyc2UvbWFyc2hhbGluZyBpcyBoYW5k bGluZyB0aGUgdHlwZWQgYXJyYXlzLCBwYXJ0aWN1bGFybHkgdGhlIHF1ZXN0aW9uIG9mIHVuaWZv cm1pdHkgYWNyb3NzIGRpZmZlcmVudCBicm93c2VycyAob3IgZGlmZmVyZW50IHZlcnNpb25zIG9m IHRoZSBzYW1lIGJyb3dzZXIpLiBIb3dldmVyLCBJTUhPLCB0aGF0IGlzIGF0IGJlc3QgYSBicm93 c2VyLXJlbGF0ZWQgV2ViU29ja2V0cyBBUEkgcXVlc3Rpb24sID50aGVyZSByZW1haW5zIG5vIG5l ZWQgdG8gcHVzaCB0aGF0IGVuY29kaW5nL2RlY29kaW5nIGlzc3VlIGludG8gdGhlIFdlYlNvY2tl dCBwcm90b2NvbCBpdHNlbGYuDQoNClRoaXMgd2Fzbid0IGEgc3VnZ2VzdGlvbiB0byBkaXNjdXNz IHRoYXQgaXNzdWUgb24gdGhpcyBsaXN0LiBJdCB3YXMgYSB3aW5rIHRvIHRha2UgdGhlIGJpZ2dl ciBwaWN0dXJlIGludG8gYWNjb3VudC4NCg0KPg0KPkFzIEkgaGF2ZSBub3RlZCBpbiB0aGUgcGFz dCwgb25lIG9mIHRoZSBmZXcgcGxhY2VzIHRoYXQgc3VjaCBhIGRpY2hvdG9teSBpcyBhc3NvY2lh dGVkIHdpdGggYW4gSUVURiBwcm90b2NvbCBpcyBGVFAuIFRoZSByZWFzb24gZm9yIHRoaXMgaXMg aGlzdG9yaWNhbCwgYW5kIHN0aWxsIHJlbGV2YW50IGluIGNyb3NzLXBsYXRmb3JtIGNvbnRleHRz LiBXaGVuIHRleHQgZmlsZXMgYXJlIHRyYW5zbWl0dGVkIGJldHdlZW4gaG9zdHMsIHRoZXkgYXJl IHN1YmplY3QgdG8gPnRyYW5zZm9ybWF0aW9ucyBkZXNpZ25lZCB0byAicHJlc2VydmUiIHRoZSB0 ZXh0dWFsIGNvbnRlbnQgKGUuZy4sIGNoYXJhY3RlciBjb2RlcywgZm9ybWF0dGluZywgbGluZSBi cmVha3MpIGFjcm9zcyB0aGUgdHJhbnNtaXNzaW9uLiBCeSBjb250cmFzdCwgYmluYXJ5IGZpbGVz IGFyZSB0cmFuc21pdHRlZCB3aXRob3V0IGNoYW5nZS4gDQo+DQo+VGhlIHRyYW5zZm9ybWF0aW9u cyBvZiAidGV4dCIgbW9kZSwgd2hpbGUgb2Z0ZW4gdXNlZnVsLCBoYXZlIGJlZW4gdGhlIHNvdXJj ZSBvZiBpbm51bWVyYWJsZSBhY2NpZGVudHMgYW5kIHByb2JsZW1zIHNpbmNlIHRoZWlyIGFkdmVu dC4gVGhleSB3ZXJlLCBhbmQgYXJlIG5lY2Vzc2FyeSwgYnV0IHRoZXkgc2hvdWxkIGJlIHZpZXdl ZCB3aXRoIGNhdXRpb24uDQoNCklNSE8sIHRoZXNlIGFyZSBpc3N1ZXMgZnJvbSB0aGUgcGFzdCAu LiBsdWNraWx5IHRvZGF5LCB3ZSBoYXZlIFVuaWNvZGUgYW5kIFVURi04DQoNCj4NCj5JbiB0aGUg Y2FzZSBvZiB0aGUgV2ViU29ja2V0IHByb3RvY29sLCB0aGVyZSBpcyBsaXR0bGUgdG8gYmUgZ2Fp bmVkIGJ5IHRoZSB0ZXh0L2JpbmFyeSBkaWNob3RvbXkgKGFzIEkgbm90ZWQgcHJldmlvdXNseSwg dGhpcyBpcyBzdHJhaWdodGZvcndhcmQgdG8gaW1wbGVtZW50IGFzIGFuICJhcHBsaWNhdGlvbnMg cHJvdG9jb2wiL3VuZGVyc3RhbmRpbmcgYXQgdGhlIGxldmVsIG9mIHRoZSBXZWJTb2NrZXQgQVBJ KS4NCg0KVGhlICJnYWluIiBpcyBzdXBwb3NlZCB0byBiZSBmb3Igb25lIG9mIHRoZSBtb3N0IGlt cG9ydGFudCB1c2UgY2FzZXM6DQoNCmNsaWVudCA9IGJyb3dzZXIgLyBtZXNzYWdlID0gSlNPTiAv IEpTT04gPSBVVEYtOA0KDQpIb25lc3RseSwgSSBzZWUgV1MgYXMgYSBfcHJhZ21hdGljXyBlZmZv cnQgdG8gYnJpbmcgdGhlIHdlYiB0byB0aGUgbmV4dCBsZXZlbC4NCg0KSWYgaXQgaGVscHMgd2l0 aCB0aGF0IGdvYWwgdG8gaGF2ZSB0ZXh0L2JpbmFyeSBwYXlsb2FkIHR5cGUgZGlzdGluY3Rpb24g aW4gdGhlIFdTIHByb3RvY29sLCBJIGFtIGZpbmUgd2l0aCB0aGF0LA0KZXZlbiBpZiB0aGF0IGlz IHNvbWVob3cgdW5jbGVhbiBmcm9tIGFuIGlkZWFsaXN0aWMgcHJvdG9jb2wgZGVzaWduIHZpZXcg KHRvIHdoaWNoIEkgYWdyZWUpLg0K From ibc@aliax.net Mon Aug 22 07:42: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 14B2521F8B7E for ; Mon, 22 Aug 2011 07:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2c7Ei2tzOND for ; Mon, 22 Aug 2011 07:42:52 -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 8100121F8B6C for ; Mon, 22 Aug 2011 07:42:52 -0700 (PDT) Received: by qyk35 with SMTP id 35so2226263qyk.10 for ; Mon, 22 Aug 2011 07:43:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr1330079qcq.261.1314024237386; Mon, 22 Aug 2011 07:43:57 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 07:43:57 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 16:43:57 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 14:42:53 -0000 2011/8/22 Tobias Oberstein : >>The transformations of "text" mode, while often useful, have been the sou= rce of innumerable accidents and problems since their advent. They were, an= d are necessary, but they should be viewed with caution. > > IMHO, these are issues from the past .. luckily today, we have Unicode an= d UTF-8 Upload/download a binary file (i.e. any custom app document) using FTP in "binary" / "text" mode and you will get different results (for example, a corrupted document). This issue still occurs today using FTP clients which "magically" auto-choose the binary or text transfer. >>In the case of the WebSocket protocol, there is little to be gained by th= e text/binary dichotomy (as I noted previously, this is straightforward to = implement as an "applications protocol"/understanding at the level of the W= ebSocket API). > > The "gain" is supposed to be for one of the most important use cases: > > client =3D browser / message =3D JSON / JSON =3D UTF-8 Thanks for ignoring my previous comment so I must write them again: client =3D browser / message =3D JSON / JSON =3D UTF-8 or client =3D smartphone app / message =3D WHATEVER / WHATEVER =3D WHICHEVER= _ENCODING > Honestly, I see WS as a _pragmatic_ effort to bring the web to the next l= evel. That's your error, you just see "web" here. WebSocket is not a "web" protocol, it's a network protocol. > If it helps with that goal to have text/binary payload type distinction i= n the WS protocol, I am fine with that, > even if that is somehow unclean from an idealistic protocol design view (= to which I agree). The main question here is: WHY do you state that any other design but the current ugly one would be worse or more difficult for WS implementation? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 07:49: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 8690721F8B22 for ; Mon, 22 Aug 2011 07:49:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltod4DsF72QZ for ; Mon, 22 Aug 2011 07:49:44 -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 E2BA921F8AED for ; Mon, 22 Aug 2011 07:49:43 -0700 (PDT) Received: by qyk35 with SMTP id 35so2231340qyk.10 for ; Mon, 22 Aug 2011 07:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr1364955qch.299.1314024648542; Mon, 22 Aug 2011 07:50:48 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 07:50:48 -0700 (PDT) In-Reply-To: References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> <634914A010D0B943A035D226786325D422C0D5CA52@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 16:50:48 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Sylvain Hellegouarch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 14:49:44 -0000 2011/8/22 Sylvain Hellegouarch : > I assume that unless clearly stated for a given scenario, it would mean > "whatever may come in between two endpoints". In most cases, it doesn't s= eem > to matter much what they are or what they do other than the fact they can > interact with the frames. In fact I would consider best practices, among > intermediary vendors, will arise when WS becomes common. I wouldn't expec= t > the current spec to specify how they interact with WS. Ok, so nobody here wants to waste time explaining what a WS intermediary is= . I imagine a simple HTTP proxy which forwards the WS GET handshake and 101 response, and then just forward received bytes (from client or server) being no WS aware at all, so it knows nothing about WS frames. Or it could be a real WS server which *performs* the handshake with the WS client, and later performs a new WS handshake with a remote WS server, then it receives frames and messages and forwards them (keeping the received frames or refactoring them) to the remote server. Or it could be a pseudo WS server which just forwards the initial GET handshake to a remote server, but later it inspects the WS frames and messages and, optionally, re-assembles them into new WS frames which are forwarded to the remote server. Ok, don't worry. I do know that nobody here will explain it. --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Mon Aug 22 07:57: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 3DDB921F8B45 for ; Mon, 22 Aug 2011 07:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZL3iGnfQkPm for ; Mon, 22 Aug 2011 07:57:16 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id A1D5921F8B37 for ; Mon, 22 Aug 2011 07:57:16 -0700 (PDT) Received: (qmail 21400 invoked from network); 22 Aug 2011 14:58:19 -0000 Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 14:58:19 -0000 Received: (qmail 17961 invoked by uid 99); 22 Aug 2011 14:58:19 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822075818.ef1fc80126c74c6c202a919c41c7bb0b.46b9b9406d.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "=?UTF-8?Q?I=C3=B1aki=5FBaz=5FCastillo?=" Date: Mon, 22 Aug 2011 07:58:18 -0700 Mime-Version: 1.0 Cc: Bjoern Hoehrmann , "hybi@ietf.org" Subject: [hybi] Taxonomy of WebSocket Intermediaries 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, 22 Aug 2011 14:57:17 -0000 Inaki,=0A=0AIndeed, the term "intermediary" covers a multitude of possibili= ties. =0A=0AI will try to find the time in the next week or so to put toget= her a=0Abrief taxonomy of "intermediaries".=0A=0AIf nothing else, a consist= ent taxonomy will make for a clearer=0Adiscussion.=0A=0A- Bob Gezelter, htt= p://www.rlgsc.com=0A From ibc@aliax.net Mon Aug 22 08:00: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 D55FA21F883A for ; Mon, 22 Aug 2011 08:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pouDb8s0oEMj for ; Mon, 22 Aug 2011 08:00:42 -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 3378E21F8801 for ; Mon, 22 Aug 2011 08:00:42 -0700 (PDT) Received: by qwc23 with SMTP id 23so3805695qwc.31 for ; Mon, 22 Aug 2011 08:01:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.204.5 with SMTP id fk5mr1546707qab.298.1314025306895; Mon, 22 Aug 2011 08:01:46 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 08:01:46 -0700 (PDT) In-Reply-To: <20110822075818.ef1fc80126c74c6c202a919c41c7bb0b.46b9b9406d.wbe@email03.secureserver.net> References: <20110822075818.ef1fc80126c74c6c202a919c41c7bb0b.46b9b9406d.wbe@email03.secureserver.net> Date: Mon, 22 Aug 2011 17:01:46 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , "hybi@ietf.org" Subject: Re: [hybi] Taxonomy of WebSocket Intermediaries 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, 22 Aug 2011 15:00:42 -0000 2011/8/22 Bob Gezelter : > Inaki, > > Indeed, the term "intermediary" covers a multitude of possibilities. > > I will try to find the time in the next week or so to put together a > brief taxonomy of "intermediaries". > > If nothing else, a consistent taxonomy will make for a clearer > discussion. Thanks Bob, I really appreciate it. --=20 I=C3=B1aki Baz Castillo From jat@google.com Mon Aug 22 08:01: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 42BDF21F8ABC for ; Mon, 22 Aug 2011 08:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.736 X-Spam-Level: X-Spam-Status: No, score=-105.736 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb1YOfNbEZlt for ; Mon, 22 Aug 2011 08:01:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id A13BE21F8801 for ; Mon, 22 Aug 2011 08:01:27 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p7MF2V1e008269 for ; Mon, 22 Aug 2011 08:02:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314025352; bh=SA98ODzD5twR2imAFNqSa5imX7A=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Mbk5OZyROrmc1lWq+EZ8o4sPvyipS4CP3UgwI+AKGgb/AIA4X4APJXtwBEPBnvB2g DbkCj0xCe+p7xqYHfcPzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ZfmN+TA9w/vHH8zh6fx3egU8Erm4bwMaADXGQdIHh0axeI0bvSz7sAbRetg5hXEbA OqF3OrzDzZfteuyBTebaA== Received: from yxl11 (yxl11.prod.google.com [10.190.3.203]) by hpaq5.eem.corp.google.com with ESMTP id p7MF2Toa016678 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 08:02:30 -0700 Received: by yxl11 with SMTP id 11so1312442yxl.6 for ; Mon, 22 Aug 2011 08:02:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bg+6hxr+WRgQumd50lmFc44cG0pzOdVWj9gJRBdO3Tc=; b=Z/sqRn57Nz9JSfY8RcZEz5GJ4jpRP2EzlLSmOhciElV7QQbtkYF0rQ26NuF2n8YIQS 5P14E0v3u5pvzPYi9vFg== Received: by 10.151.21.9 with SMTP id y9mr2341902ybi.344.1314025349359; Mon, 22 Aug 2011 08:02:29 -0700 (PDT) Received: by 10.151.21.9 with SMTP id y9mr2341890ybi.344.1314025349128; Mon, 22 Aug 2011 08:02:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 08:02:09 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Mon, 22 Aug 2011 11:02:09 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd4b2d62923b004ab195e95 X-System-Of-Record: true Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 15:01:28 -0000 --000e0cd4b2d62923b004ab195e95 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 10:43 AM, I=C3=B1aki Baz Castillo w= rote: > > Honestly, I see WS as a _pragmatic_ effort to bring the web to the next > level. > > That's your error, you just see "web" here. WebSocket is not a "web" > protocol, it's a network protocol. What exactly do you think motivated the design of WebSockets? For applications not running in a browser where potentially hostile code can execute, why isn't raw TCP or some existing protocol running on top of it sufficient? The reason WebSockets exists is to allow browsers to use it, hence "Web" in the name. Sure, it can be used for other things and they ma= y want to in the interest of interoperability, but that isn't the reason it exists. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd4b2d62923b004ab195e95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 10:43 AM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
> Honestly, I see WS as a _pragmatic_ effort to bring = the web to the next level.

That's your error, you just see "web" here. WebSocket i= s not a "web"
protocol, it's a network protocol.

What= exactly do you think motivated the design of WebSockets? =C2=A0For applica= tions not running in a browser where potentially hostile code can execute, = why isn't raw TCP or some existing protocol running on top of it suffic= ient? =C2=A0The reason WebSockets exists is to allow browsers to use it, he= nce "Web" in the name. =C2=A0Sure, it can be used for other thing= s and they may want to in the interest of interoperability, but that isn= 9;t the reason it exists.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd4b2d62923b004ab195e95-- From tobias.oberstein@tavendo.de Mon Aug 22 08:02: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 4460D21F8ABC for ; Mon, 22 Aug 2011 08:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShSnNHPkLa6f for ; Mon, 22 Aug 2011 08:02:07 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 8474121F8584 for ; Mon, 22 Aug 2011 08:02:07 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 22 Aug 2011 08:03:11 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 22 Aug 2011 08:02:23 -0700 Thread-Topic: [hybi] Binary/Text Distinction Thread-Index: Acxg2e5+nqSM1GR/QbGmXatlCs7ZmAAAI7bg Message-ID: <634914A010D0B943A035D226786325D422C0D5CB05@EXVMBX020-12.exch020.serverdata.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 15:02:08 -0000 PiA+PlRoZSB0cmFuc2Zvcm1hdGlvbnMgb2YgInRleHQiIG1vZGUsIHdoaWxlIG9mdGVuIHVzZWZ1 bCwgaGF2ZSBiZWVuIHRoZQ0KPiBzb3VyY2Ugb2YgaW5udW1lcmFibGUgYWNjaWRlbnRzIGFuZCBw cm9ibGVtcyBzaW5jZSB0aGVpciBhZHZlbnQuIFRoZXkNCj4gd2VyZSwgYW5kIGFyZSBuZWNlc3Nh cnksIGJ1dCB0aGV5IHNob3VsZCBiZSB2aWV3ZWQgd2l0aCBjYXV0aW9uLg0KPiA+DQo+ID4gSU1I TywgdGhlc2UgYXJlIGlzc3VlcyBmcm9tIHRoZSBwYXN0IC4uIGx1Y2tpbHkgdG9kYXksIHdlIGhh dmUgVW5pY29kZQ0KPiA+IGFuZCBVVEYtOA0KPiANCj4gVXBsb2FkL2Rvd25sb2FkIGEgYmluYXJ5 IGZpbGUgKGkuZS4gYW55IGN1c3RvbSBhcHAgZG9jdW1lbnQpIHVzaW5nIEZUUCBpbg0KPiAiYmlu YXJ5IiAvICJ0ZXh0IiBtb2RlIGFuZCB5b3Ugd2lsbCBnZXQgZGlmZmVyZW50IHJlc3VsdHMgKGZv ciBleGFtcGxlLCBhDQo+IGNvcnJ1cHRlZCBkb2N1bWVudCkuIFRoaXMgaXNzdWUgc3RpbGwgb2Nj dXJzIHRvZGF5IHVzaW5nIEZUUCBjbGllbnRzIHdoaWNoDQo+ICJtYWdpY2FsbHkiIGF1dG8tY2hv b3NlIHRoZSBiaW5hcnkgb3IgdGV4dCB0cmFuc2Zlci4NCg0KVGhlIHBvaW50IGlzOiB3aXRoIFVu aWNvZGUvVVRGLTggbGVhc3QgZGVub21pbmF0b3IgZm9yIHRleHQgaW4gdHJhbnNwb3J0LA0KdGhl cmUgaXMgbm8gbmVlZCBmb3IgY29udmVyc2lvbiwgYW5kIHRodXMgbm8gY29udmVyc2lvbiBwcm9i bGVtLg0KDQpJJ20gbm90IHRhbGtpbmcgYWJvdXQgYmluYXJ5LCB3aGljaCBzaG91bGQgbm90ICJj b252ZXJ0ZWQiIHRvIFVURi04DQpvYnZpb3VzbHkuDQoNCj4gPj5JbiB0aGUgY2FzZSBvZiB0aGUg V2ViU29ja2V0IHByb3RvY29sLCB0aGVyZSBpcyBsaXR0bGUgdG8gYmUgZ2FpbmVkIGJ5IHRoZQ0K PiB0ZXh0L2JpbmFyeSBkaWNob3RvbXkgKGFzIEkgbm90ZWQgcHJldmlvdXNseSwgdGhpcyBpcyBz dHJhaWdodGZvcndhcmQgdG8NCj4gaW1wbGVtZW50IGFzIGFuICJhcHBsaWNhdGlvbnMgcHJvdG9j b2wiL3VuZGVyc3RhbmRpbmcgYXQgdGhlIGxldmVsIG9mIHRoZQ0KPiBXZWJTb2NrZXQgQVBJKS4N Cj4gPg0KPiA+IFRoZSAiZ2FpbiIgaXMgc3VwcG9zZWQgdG8gYmUgZm9yIG9uZSBvZiB0aGUgbW9z dCBpbXBvcnRhbnQgdXNlIGNhc2VzOg0KPiA+DQo+ID4gY2xpZW50ID0gYnJvd3NlciAvIG1lc3Nh Z2UgPSBKU09OIC8gSlNPTiA9IFVURi04DQo+IA0KPiBUaGFua3MgZm9yIGlnbm9yaW5nIG15IHBy ZXZpb3VzIGNvbW1lbnQgc28gSSBtdXN0IHdyaXRlIHRoZW0gYWdhaW46DQo+IA0KPiAgIGNsaWVu dCA9IGJyb3dzZXIgLyBtZXNzYWdlID0gSlNPTiAvIEpTT04gPSBVVEYtOA0KPiANCj4gb3INCj4g DQo+ICAgY2xpZW50ID0gc21hcnRwaG9uZSBhcHAgLyBtZXNzYWdlID0gV0hBVEVWRVIgLyBXSEFU RVZFUiA9DQo+IFdISUNIRVZFUl9FTkNPRElORw0KDQpUaGF0J3MgZmluZS4gVXNlIHBheWxvYWQg dHlwZSBiaW5hcnkgYW5kIHRoZXJlIHlvdSBnby4NCg0KPiANCj4gDQo+ID4gSG9uZXN0bHksIEkg c2VlIFdTIGFzIGEgX3ByYWdtYXRpY18gZWZmb3J0IHRvIGJyaW5nIHRoZSB3ZWIgdG8gdGhlIG5l eHQNCj4gbGV2ZWwuDQo+IA0KPiBUaGF0J3MgeW91ciBlcnJvciwgeW91IGp1c3Qgc2VlICJ3ZWIi IGhlcmUuIFdlYlNvY2tldCBpcyBub3QgYSAid2ViIg0KPiBwcm90b2NvbCwgaXQncyBhIG5ldHdv cmsgcHJvdG9jb2wuDQo+IA0KPiANCj4gPiBJZiBpdCBoZWxwcyB3aXRoIHRoYXQgZ29hbCB0byBo YXZlIHRleHQvYmluYXJ5IHBheWxvYWQgdHlwZQ0KPiA+IGRpc3RpbmN0aW9uIGluIHRoZSBXUyBw cm90b2NvbCwgSSBhbSBmaW5lIHdpdGggdGhhdCwgZXZlbiBpZiB0aGF0IGlzIHNvbWVob3cNCj4g dW5jbGVhbiBmcm9tIGFuIGlkZWFsaXN0aWMgcHJvdG9jb2wgZGVzaWduIHZpZXcgKHRvIHdoaWNo IEkgYWdyZWUpLg0KPiANCj4gVGhlIG1haW4gcXVlc3Rpb24gaGVyZSBpczogV0hZIGRvIHlvdSBz dGF0ZSB0aGF0IGFueSBvdGhlciBkZXNpZ24gYnV0IHRoZQ0KPiBjdXJyZW50IHVnbHkgb25lIHdv dWxkIGJlIHdvcnNlIG9yIG1vcmUgZGlmZmljdWx0IGZvciBXUyBpbXBsZW1lbnRhdGlvbj8NCg0K SSBkaWQgbm90IHNheSB0aGF0Lg0KDQpJZiBXUyB3YXMgYW4gX2FjYWRlbWljXyBlbmRlYXZvdXIg SSB3b3VsZCBiZSBpbiB0aGUgY2xlYW5uZXNzIGNhbXAuDQoNCkxldCBtZSBwdXQgaXQgbGlrZSB0 aGlzOiBJIGRvbid0IHRoaW5rIHRoYXQgbW92aW5nIHRoZSBwYXlsb2FkIHR5cGUgb3V0IG9mIG9w Y29kZXMNCmludG8gc2F5IHN1YnByb3RvY29sIG5lZ290aWF0aW9uIGlzIGFuIGltcHJvdmVtZW50 IGluIHRlcm1zIG9mIHByb3RvY29sIGRlc2lnbg0KY2xlYW5uZXNzIGJpZyBlbm91Z2ggdG8gb3V0 d2VpZ2ggdGhlIGRlbGF5IG9mIFdTIHdpZGVzcHJlYWQgYWRvcHRpb24gYW5kDQpzZXQtYmFjayB0 aGF0IHN1Y2ggKHlldCBhbm90aGVyKSBmdW5kYW1lbnRhbCBjaGFuZ2UgdG8gV1Mgd291bGQgYnJp bmcuDQoNCkhvbmVzdGx5LCB3ZSBzaG91bGQgYWxsIHdvcmsgdG9nZXRoZXIgIHRvICJqdXN0IG1h a2UgaXQgaGFwcGVuIi4gVGhlcmUgYXJlDQoib3RoZXIiIGd1eXMgd2hvIHdvdWxkIGJlIG1vcmUg dGhhbiBoYXBweSB0byBzZWUgV1Mgc2luayBpbiBlbmRsZXNzDQpkZWJhdGVzIGFuZCBuZXZlciBo aXQgdGhlIHJvYWQuIFRoZXkgd291bGQgc2F5OiAic2VlLCB3ZSB0b2xkIHlvdSAtIHRoZXkNCmNo YW5nZSBzdHVmZiBhZ2FpbiIgLi4gIm5vdCByZWFkeSB5ZXQiIC4uICJoYWxmLWJha2VkIi4NCg0K SXMgaXQgcmVhbGx5IHdvcnRoIHRoYXQ/DQoNCj4gDQo+IC0tDQo+IEnDsWFraSBCYXogQ2FzdGls bG8NCj4gPGliY0BhbGlheC5uZXQ+DQo= From ibc@aliax.net Mon Aug 22 09:23: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 F114421F8B40 for ; Mon, 22 Aug 2011 09:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ge8sZZkFkQU9 for ; Mon, 22 Aug 2011 09:23:12 -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 50E6621F8B2D for ; Mon, 22 Aug 2011 09:23:12 -0700 (PDT) Received: by qyk34 with SMTP id 34so1460917qyk.10 for ; Mon, 22 Aug 2011 09:24:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr1473401qce.185.1314030256401; Mon, 22 Aug 2011 09:24:16 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 09:24:16 -0700 (PDT) Date: Mon, 22 Aug 2011 18:24:16 +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] About WebSocket extensions negotiation 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, 22 Aug 2011 16:23:13 -0000 The current way of negotiating extensions during WS handshake states that the client offers some capabilities it implements and the server decides which ones tu use within the WS connection. I don't like it too much as the client cannot *require* the usage of a specific extension but just "ask for it". I would like to propose a different mechanism as present in SIP protocol (but adapted to WebSocket): GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ=3D=3D Sec-WebSocket-Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 8 Sec-WebSocket-Supported: aaa, bbb, ccc Sec-WebSocket-Require: ddd, eee The server could decide whether to use or not the extensions listed in Sec-WebSocket-Supported, and MUST accept all the extensions in Sec-WebSocket-Require. In case the server does not understand some extension in Sec-WebSocket-Require, then it MUST reject the handshake with "HTTP/1.1 420 Bad Extension": http://tools.ietf.org/html/rfc3261#section-21.4.15 If all goes OK, the server replies 101 including a Sec-WebSocket-Require which MUST contain, at least, all the extensions the client wrote in its Sec-WebSocket-Require. The server can also include there extensions provided by the client in the Sec-WebSocket-Supported header (if it implements them and decides to use them). Even better, the server could require some extension "zzz". And in case such extension is not included in the client's Sec-WebSocket-Supported or Sec-WebSocket-Require headers, then the server MUST reject the handshake with "HTTP/1.1 421 Extension Required" (and a header Sec-WebSocket-Require the required extensions). http://tools.ietf.org/html/rfc3261#section-21.4.16 In the other side, if the client puts "aaa" in its Sec-WebSocket-Require and "aaa" is not present in such a header in the 101 response, or it contains an extension not supported by the client, then the client MUST close the WS connection. Yes, too late, I know. Regards. --=20 I=C3=B1aki Baz Castillo From ferg@caucho.com Mon Aug 22 09:55: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 D412321F8B21 for ; Mon, 22 Aug 2011 09:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.296 X-Spam-Level: X-Spam-Status: No, score=-2.296 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 63OAlwmgCHNm for ; Mon, 22 Aug 2011 09:55:15 -0700 (PDT) Received: from nm28-vm0.access.bullet.mail.mud.yahoo.com (nm28-vm0.access.bullet.mail.mud.yahoo.com [66.94.236.229]) by ietfa.amsl.com (Postfix) with SMTP id 0EE8721F84B7 for ; Mon, 22 Aug 2011 09:55:14 -0700 (PDT) Received: from [66.94.237.197] by nm28.access.bullet.mail.mud.yahoo.com with NNFMP; 22 Aug 2011 16:56:20 -0000 Received: from [98.139.221.63] by tm8.access.bullet.mail.mud.yahoo.com with NNFMP; 22 Aug 2011 16:56:20 -0000 Received: from [127.0.0.1] by smtp104.biz.mail.bf1.yahoo.com with NNFMP; 22 Aug 2011 16:56:20 -0000 X-Yahoo-Newman-Id: 125246.80513.bm@smtp104.biz.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: mHHucQUVM1lmAuGnBiBpSBBCYhw9d6HQok8v2zotLhJKBsl EsJS.nyL0_ljj0pwJ70BqO1fwecU3zwqy68Zm_.0yB0bTAre_rpbUeyHVz7b hDqYwRj18bfbjJ2a2InAGIY9LiHNzM5b7rlL.Tcoso.bguOLeVIAujNFxUkJ HQSjPik8KrBDud0tjZI1Ab4RvwMVBrOlgQ6VkCVZjLsS.J4SVpNfdHl7AqcN 6GOd2wOClIh4gj13qVHspeWthTLP6yEvbcd0A5D0EoKgnSw55CQv1Y9o9dOH jtQzvOsLNXoXVQTSM7tkadMHVqeiW_Pl3egBeKVtbDc0b0NOh72193RT5yOs 4FlcvIFUiL2ofzGLhXtSnCXE7Cesqm8lSsstu37rcqNAG31htz3dCTyNtGH5 iiUlp X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp104.biz.mail.bf1.yahoo.com with SMTP; 22 Aug 2011 09:56:19 -0700 PDT Message-ID: <4E528A2E.2070208@caucho.com> Date: Mon, 22 Aug 2011 09:56:14 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080903020008010403020409" Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 16:55:15 -0000 This is a multi-part message in MIME format. --------------080903020008010403020409 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 08/22/2011 06:35 AM, John Tamplin wrote: > On Mon, Aug 22, 2011 at 9:32 AM, Iñaki Baz Castillo > wrote: > > 2011/8/22 Bob Gezelter >: > > The transformations of "text" mode, while often useful, have > been the > > source of innumerable accidents and problems since their advent. > > So ***great*** real case. > > WS authors, please, learn from the History (or you will repeat it). > > > I don't think this proves what you think it does -- in fact, to me it > argues for exactly what we have now, which is defining exactly how > text messages are transported and represented, rather than leaving it > up to each applcation. +1 Text encoding complications are from underspecification or overgeneralization. WebSockets solves that problem upfront. Aesthetic arguments of "proper" layering aside (I like van Gogh, by the way), in actual practice, specifying One True Encoding is a great help to actual implementors. Leaving it to the application? Contrast Java and C where Java made text a first-class primitive, while C left text up to the application. I'll just leave it at mb*. XML - parsers have to support every encoding despite UTF-8 being sufficient. (Plus the encoding is selected after parsing several text characters in a default encoding and added BOM complications.) CORBA - you really don't want to know their text encoding system. The horror. PHP - utter nightmare trying to backpatch unicode into a system designed around 8-bit strings. HTTP - URLs and forms underspecified in their encodings. text/html can be any encoding. Painful. Servlet/JSP - problems descended from HTTP underspecification, but eventually defaulted to latin-1 (!) SOAP - the inverse problem, not properly dealing with binary encoding upfront. Painfully dealt with many years and revisions later. The counter example is FTP? That "text" mode isn't even modern unicode text. FTP "text" is an entirely different (and obsolete and broken) concept. It's irrelevant. -- Scott --------------080903020008010403020409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 08/22/2011 06:35 AM, John Tamplin wrote:
On Mon, Aug 22, 2011 at 9:32 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2011/8/22 Bob Gezelter <gezelter@rlgsc.com>:
> The transformations of "text" mode, while often useful, have been the
> source of innumerable accidents and problems since their advent.

So ***great*** real case.

WS authors, please, learn from the History (or you will repeat it).

I don't think this proves what you think it does -- in fact, to me it argues for exactly what we have now, which is defining exactly how text messages are transported and represented, rather than leaving it up to each applcation.

+1

Text encoding complications are from underspecification or overgeneralization. WebSockets solves that problem upfront. Aesthetic arguments of "proper" layering aside (I like van Gogh, by the way), in actual practice, specifying One True Encoding is a great help to actual implementors.

Leaving it to the application? Contrast Java and C where Java made text a first-class primitive, while C left text up to the application. I'll just leave it at mb*.

  XML - parsers have to support every encoding despite UTF-8 being sufficient. (Plus the encoding is selected after parsing several text characters in a default encoding and added BOM complications.)

  CORBA - you really don't want to know their text encoding system. The horror.

  PHP - utter nightmare trying to backpatch unicode into a system designed around 8-bit strings.

  HTTP - URLs and forms underspecified in their encodings. text/html can be any encoding. Painful.

  Servlet/JSP - problems descended from HTTP underspecification, but eventually defaulted to latin-1 (!)

  SOAP - the inverse problem, not properly dealing with binary encoding upfront. Painfully dealt with many years and revisions later.

The counter example is FTP? That "text" mode isn't even modern unicode text. FTP "text" is an entirely different (and obsolete and broken) concept. It's irrelevant.

-- Scott

--------------080903020008010403020409-- From jat@google.com Mon Aug 22 09:59: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 5682521F8C29 for ; Mon, 22 Aug 2011 09:59:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.781 X-Spam-Level: X-Spam-Status: No, score=-105.781 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8-YOsgsirhqH for ; Mon, 22 Aug 2011 09:59:14 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9656321F8C0E for ; Mon, 22 Aug 2011 09:59:14 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7MH0EkZ017955 for ; Mon, 22 Aug 2011 10:00:14 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314032415; bh=a1sKMllSOMnkWZnpuvfr9gLXEW0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=w/WAdtavglvJPNiFHOQwPOFzXpn28LDTWDnjsLNny44IS1kFdqKbxjz94X6JKigLA 6jGqieUvD464Nh8+nGyXw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=iL6K6hT+S4Zlg0LBhFbFC1rmthp7zDWt+vNQdAI8QfPdq6Vda8Je9eXX45jVaiVjT LuKg/8IbXWjRz0/X35i+A== Received: from gxk1 (gxk1.prod.google.com [10.202.11.1]) by wpaz1.hot.corp.google.com with ESMTP id p7MGxFtZ007994 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:00:13 -0700 Received: by gxk1 with SMTP id 1so3716968gxk.38 for ; Mon, 22 Aug 2011 10:00:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XPpWwEGcXnyNcCVv9Hmbr5O4JMiQiuWupQ9a2pjzI3Q=; b=yDk9VMzNq5mqhmv+Q5Kwq1oBsuI3e1dj09/4NKUGDN7tqZkoY5OGQqY9bkgXmrOZSQ 2lMjVAKXZilu0ikGp/Bw== Received: by 10.151.25.12 with SMTP id c12mr2485615ybj.116.1314032413308; Mon, 22 Aug 2011 10:00:13 -0700 (PDT) Received: by 10.151.25.12 with SMTP id c12mr2485608ybj.116.1314032413135; Mon, 22 Aug 2011 10:00:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 09:59:53 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Mon, 22 Aug 2011 12:59:53 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd293c23553c104ab1b03d6 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 16:59:15 -0000 --000e0cd293c23553c104ab1b03d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 12:24 PM, I=C3=B1aki Baz Castillo w= rote: > The current way of negotiating extensions during WS handshake states > that the client offers some capabilities it implements and the server > decides which ones tu use within the WS connection. > I don't like it too much as the client cannot *require* the usage of a > specific extension but just "ask for it". > The client can require it -- when it gets the response back from the server= , if it doesn't include any extensions that it requires, it closes the connection. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd293c23553c104ab1b03d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 12:24 PM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
The current way of negotiating extensions during WS handshake states
that the client offers some capabilities it implements and the server
decides which ones tu use within the WS connection.
I don't like it too much as the client cannot *require* the usage of a<= br> specific extension but just "ask for it".
The client can require it -- when it gets the response back fr= om the server, if it doesn't include any extensions that it requires, i= t closes the connection.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd293c23553c104ab1b03d6-- From tyoshino@google.com Mon Aug 22 10:05:05 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 E344221F8B90 for ; Mon, 22 Aug 2011 10:05:05 -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.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80texjlNm0jo for ; Mon, 22 Aug 2011 10:05:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id AE58521F8B85 for ; Mon, 22 Aug 2011 10:05:02 -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 p7MH66tE029782 for ; Mon, 22 Aug 2011 10:06:07 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314032767; bh=E9G1Lj4boRz+mgPPZLsWjOsMZ/k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IRbXoObKHRa79UTp1Kz4Z5hmAslr+i4335x+bFwOtn7tUHO0rVP9GQC1s1yr+nhon ohwsyxDt+iNfiC1KP0UDA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=M7BDT8HWxyvD5K5qPvkPFodJHALn3BTXzgaj5Vc8iSt4asTuEHsslPM2VcBRXF/mz rIGD9CW+aoDeLT7U0hV0A== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by wpaz29.hot.corp.google.com with ESMTP id p7MH5hvm001165 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:06:05 -0700 Received: by gxk7 with SMTP id 7so4612631gxk.7 for ; Mon, 22 Aug 2011 10:06:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qOlf/kT73OhyIEOFK8C6CED3ZczTuCgbTMp8TWNcfVI=; b=m8qHcQkABf+qusRaUMrYQzDg8jA127eHCWUAkylgZ/dG8SmZNludol4+ae/iQZdDYX w6RQwyKITtFPZO3rCOBQ== Received: by 10.150.40.15 with SMTP id n15mr2574529ybn.0.1314032765433; Mon, 22 Aug 2011 10:06:05 -0700 (PDT) Received: by 10.150.40.15 with SMTP id n15mr2574518ybn.0.1314032765161; Mon, 22 Aug 2011 10:06:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Mon, 22 Aug 2011 10:05:45 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 23 Aug 2011 02:05:45 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd5f2cc30cf5904ab1b18de X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 17:05:06 -0000 --000e0cd5f2cc30cf5904ab1b18de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 01:24, I=F1aki Baz Castillo wrote: > I don't like it too much as the client cannot *require* the usage of a > specific extension but just "ask for it". > This enables clients to tell the server "without extension X, I'll disconnect". IIUC, clients benefit from this if there's sort of extensions that servers can serve but are reluctant to accept (wanna reject if possible) because of resource requirement, etc. Right? Could you please list extensions that have this characteristics you have in your mind? > Even better, the server could require some extension "zzz". And in > case such extension is not included in the client's > Sec-WebSocket-Supported or Sec-WebSocket-Require headers, then the > server MUST reject the handshake with "HTTP/1.1 421 Extension > Required" (and a header Sec-WebSocket-Require the required > extensions). Same here. I understand the nuance but it needs justification for additional complexity. BTW, how about required parameter instead? Having two separate list of extensions complicates how (in which order) to apply them. Now the order of extensions listed in the Sec-WebSocket-Extensions is significant. Thanks, Takeshi --000e0cd5f2cc30cf5904ab1b18de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 01:24, I=F1aki Baz Casti= llo <ibc@aliax.net> wrote:
I don't like it too much as the client cannot *require* the usage of a<= br> specific extension but just "ask for it".
This enables clients to tell the server "without extensio= n X, I'll disconnect".

IIUC, clients bene= fit from this if there's sort of extensions that servers can serve but = are reluctant to accept (wanna reject if possible) because of resource requ= irement, etc. Right?

Could you please list extensions that have this charact= eristics you have in your mind?
=A0
Even better, the server could require some extension "zzz". And i= n
case such extension is not included in the client's
Sec-WebSocket-Supported or Sec-WebSocket-Require headers, then the
server MUST reject the handshake with "HTTP/1.1 421 Extension
Required" (and a header Sec-WebSocket-Require the required
extensions).=A0

Same here.

I understand the nuance but it needs justification for additional = complexity.

BTW, how about required parameter inst= ead? Having two separate list of extensions complicates how (in which order= ) to apply them. Now the order of extensions listed in the Sec-WebSocket-Ex= tensions is significant.

Thanks,
Takeshi
--000e0cd5f2cc30cf5904ab1b18de-- From tyoshino@google.com Mon Aug 22 10:07: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 CE96821F8888 for ; Mon, 22 Aug 2011 10:07:38 -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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IXQzyt1PMlC3 for ; Mon, 22 Aug 2011 10:07:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 18C4021F84D1 for ; Mon, 22 Aug 2011 10:07:37 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7MH8gRk010943 for ; Mon, 22 Aug 2011 10:08:42 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314032923; bh=Zc2tTYoiZ/FVh/+nfo5L6reRH68=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tYrhOteaO/7lO3oC1b75gGLNS4aH6vvlvsyT7KV133d7SC8DrNigGfxtMyQ7wiJkc 75rzdjJFa8Hjg1ROk5VCA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=GNkwnHS7jwo3ltDmFk3hKJc8naN3FWxWbE5HttkrJacJ379DPunAE8R4mmSKExQdj HhQXLNgqK5JDqesj1n6sw== Received: from gwb17 (gwb17.prod.google.com [10.200.2.17]) by hpaq3.eem.corp.google.com with ESMTP id p7MH6rm6031005 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:08:41 -0700 Received: by gwb17 with SMTP id 17so5167277gwb.1 for ; Mon, 22 Aug 2011 10:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+sacHXoDUXjFJjlTW3aCNAS35ZlssF8IQxSHsBJMXfc=; b=vAOct/fkvXpic9uavbviOcoj63+bmLVR3Br1QQ94nLwr4g3aAp3Yabejys591+9CUJ CK3FUJgbc3t5iRl4D9cA== Received: by 10.150.142.1 with SMTP id p1mr2695416ybd.57.1314032921427; Mon, 22 Aug 2011 10:08:41 -0700 (PDT) Received: by 10.150.142.1 with SMTP id p1mr2695407ybd.57.1314032921254; Mon, 22 Aug 2011 10:08:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Mon, 22 Aug 2011 10:08:21 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 23 Aug 2011 02:08:21 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cdf16c67e9a5204ab1b2172 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 17:07:38 -0000 --000e0cdf16c67e9a5204ab1b2172 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 23, 2011 at 02:05, Takeshi Yoshino wrote: > BTW, how about required parameter instead? Having two separate list of > extensions complicates how (in which order) to apply them. Now the order of > extensions listed in the Sec-WebSocket-Extensions is significant. > Clarification: required parameter -> "required" parameter I meant annotating each extension using extension parameter. --000e0cdf16c67e9a5204ab1b2172 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 02:05, Takeshi Yoshino <= span dir=3D"ltr"><tyoshino@google= .com> wrote:
BTW, how about required parame= ter instead? Having two separate list of extensions complicates how (in whi= ch order) to apply them. Now the order of extensions listed in the Sec-WebS= ocket-Extensions is significant.

Clarification: required parameter -&= gt; "required" parameter

I meant annotat= ing each extension using extension parameter.
--000e0cdf16c67e9a5204ab1b2172-- From phil127@gmail.com Mon Aug 22 10:21: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 6115721F8B72 for ; Mon, 22 Aug 2011 10:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.573 X-Spam-Level: X-Spam-Status: No, score=-3.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xg9y6i5Ii5k7 for ; Mon, 22 Aug 2011 10:21:12 -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 4932921F893C for ; Mon, 22 Aug 2011 10:21:12 -0700 (PDT) Received: by bkar4 with SMTP id r4so4670497bka.31 for ; Mon, 22 Aug 2011 10:22:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=2nYA0X3GmW0xGzT4KMDQoxiGCpdfqEh8PXM58hclCbY=; b=qeGN1lPyjnlxkoFgCX5uEHlasFgspgXXPAfQ7610J2cySaHiOCP2vLj1CgsTkpmHud 4pn+pr702LLlQKS9+59pL+wmtWRVFkLPZA+jUeZvrrcchOCEArkcDU4TzMlVeyaWgGQl VV4kPVFLFoG9u40Jm25lw03YZ5ql97uhcx5e4= Received: by 10.204.153.16 with SMTP id i16mr1080997bkw.46.1314033737071; Mon, 22 Aug 2011 10:22:17 -0700 (PDT) Received: from [212.201.75.127] (pptp-212-201-75-127.pptp.stw-bonn.de [212.201.75.127]) by mx.google.com with ESMTPS id r24sm1997371bkr.26.2011.08.22.10.22.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 10:22:16 -0700 (PDT) Message-ID: <4E52903D.7080706@gmail.com> Date: Mon, 22 Aug 2011 19:22:05 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: hybi@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.3 Content-Type: multipart/alternative; boundary="------------030200090903090700010509" Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 17:21:13 -0000 This is a multi-part message in MIME format. --------------030200090903090700010509 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 22.08.2011 19:05, schrieb Takeshi Yoshino: > > Even better, the server could require some extension "zzz". And in > case such extension is not included in the client's > Sec-WebSocket-Supported or Sec-WebSocket-Require headers, then the > server MUST reject the handshake with "HTTP/1.1 421 Extension > Required" (and a header Sec-WebSocket-Require the required > extensions). > > > Same here. > > I understand the nuance but it needs justification for additional > complexity. > This reminds me of some problems with the Accept header for HTTP that, I believe, Firefox developers had discovered. (If there is demand, I can try and find the related ticket again.) Basically they were reluctant to give plugins and extensions the abillity to add types to the Accept header and instead had set it to a fixed string. The rationale was, that the Accept header could grow huge in size if more and more extensions added their own content types there. If the header became too large, it would significantly add to HTTP overhead and cause problems with proxies that limit headers to a certain size. The overhead would be smaller for WS, since WS handshakes will be done significantly less frequent than ordinary HTTP requests. But with respect to proxies, requiring a client to announce ALL available extensions on every handshake could still eventually become a problem. An "extension required" code could solve this problem - Clients would only announce extensions that they want to negiotate or that they reasoneably expect the server requires. (due to heuristics). If a server requires an extension that is not listed, it would issue an "extension required" response and the client would try the handshake again, this time with the desired extension listed. (Provided the client supports it) The whole thing boils down to the question if we'll ever have so many official or proprietary extensions in use that header size could become a problem. --------------030200090903090700010509 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Am 22.08.2011 19:05, schrieb Takeshi Yoshino:

Even better, the server could require some extension "zzz". And in
case such extension is not included in the client's
Sec-WebSocket-Supported or Sec-WebSocket-Require headers, then the
server MUST reject the handshake with "HTTP/1.1 421 Extension
Required" (and a header Sec-WebSocket-Require the required
extensions). 

Same here.

I understand the nuance but it needs justification for additional complexity.

This reminds me of some problems with the Accept header for HTTP that, I believe, Firefox developers had discovered. (If there is demand, I can try and find the related ticket again.)
Basically they were reluctant to give plugins and extensions the abillity to add types to the Accept header and instead had set it to a fixed string. The rationale was, that the Accept header could grow huge in size if more and more extensions added their own content types there. If the header became too large, it would significantly add to HTTP overhead and cause problems with proxies that limit headers to a certain size.

The overhead would be smaller for WS, since WS handshakes will be done significantly less frequent than ordinary HTTP requests. But with respect to proxies, requiring a client to announce ALL available extensions on every handshake could still eventually become a problem.

An "extension required" code could solve this problem - Clients would only announce extensions that they want to negiotate or that they reasoneably expect the server requires. (due to heuristics). If a server requires an extension that is not listed, it would issue an "extension required" response and the client would try the handshake again, this time with the desired extension listed. (Provided the client supports it)

The whole thing boils down to the question if we'll ever have so many official or proprietary extensions in use that header size could become a problem.
--------------030200090903090700010509-- From phil127@gmail.com Mon Aug 22 10:22: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 3260721F8B78 for ; Mon, 22 Aug 2011 10:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[AWL=-0.128, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vR+kORMzzTcC for ; Mon, 22 Aug 2011 10:22:58 -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 6DEA321F8B72 for ; Mon, 22 Aug 2011 10:22:58 -0700 (PDT) Received: by bkar4 with SMTP id r4so4671930bka.31 for ; Mon, 22 Aug 2011 10:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=zDwSfGYtBbWlhfJO2t+BKNTJ2eyyww2BU9gifNy9iws=; b=Bh9QCdj0sYbeocQfQsyqf5RNdGGzYzYgO5bgSbAJ/bXy1rjn0AFmWDM/s5Y0XW1+Rs yLOMfXQWct2yga6ccdy4OUIQod5PB8ARZXyUcSzOvK1+HXQSyBOw+T3GI9bQqMkCdr18 wz7pee9Gz9tHSPuf00kTcAPfcS0l28OMy+T7c= Received: by 10.204.135.151 with SMTP id n23mr993287bkt.351.1314033843290; Mon, 22 Aug 2011 10:24:03 -0700 (PDT) Received: from [212.201.75.127] (pptp-212-201-75-127.pptp.stw-bonn.de [212.201.75.127]) by mx.google.com with ESMTPS id o20sm1733069bku.10.2011.08.22.10.24.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Aug 2011 10:24:02 -0700 (PDT) Message-ID: <4E5290A7.4010109@gmail.com> Date: Mon, 22 Aug 2011 19:23:51 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Hybi References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 17:22:59 -0000 Am 22.08.2011 15:28, schrieb Iñaki Baz Castillo: > 2011/8/22 Philipp Serafin : >> If WS frames *can* end inside a code pojnt, like he said, wouldn't that >> mean your frame parser does *not* have to care? (Which sounds like the >> reasoneable way to define it, IMO.) > Of course. My frame parser is just byte-aware and I just read N bytes > (payload_length) from the frame payload data. This is how it MUST be > IMHO. > > Unfortunatelly (and this is what I was trying to say in these mails) > the WS draft seems to state that frames (with opcode=1) MUST contain > valid UTF-8 data (not just the whole message, but each frame payload > data). So if an UTF-8 multibyte symbol gets splited within two > consecutive frames, each frame has invalid UTF-8 data. Is it an error > then? or not? > > I know that Tobias says it's not an error, but honestly I don't find > such assertion in the WS draft. > > PLEASE: Change the spec to say: "the *whole* message (after joining > all the frames payload) MUST be UTF-8 in case the first frame has > opcode=1." > > But even better: just remove the opcode "1" and "2" values and let > just "1" (application data). The previously negotiated WS protocol > *already* defines the kind o data being carried within WS messages. WS > framing layer should not care about payload data encoding, not at all. > I wasnt aware that the text of the spec is like this, my apologies. I agree, it should be changed. From jat@google.com Mon Aug 22 10:24: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 6E96821F8B9C for ; Mon, 22 Aug 2011 10:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.092, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lss9lT7P332f for ; Mon, 22 Aug 2011 10:24: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 C5F5B21F8B9B for ; Mon, 22 Aug 2011 10:24:56 -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 p7MHQ1Zl027282 for ; Mon, 22 Aug 2011 10:26:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314033962; bh=2WgFmIoQ/DN1sDNK5iChzJPgZP8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=vrrjOHLzpuotgm+d6/2+l4texylQjaBWCBWlFS61LMhWHZ9NHrysKw2z3IcGobMZm U5MfYAAWi9wRMVW0ZRAoQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=DXV2wbU/jn0MgHyz4TARxW8MxAMMxoWeQEPSpbcWgMfU9fOPMsrjNIlTth+PBR+8P 4w+FKUjSFBwZV4CCaIh5w== Received: from gwb11 (gwb11.prod.google.com [10.200.2.11]) by wpaz33.hot.corp.google.com with ESMTP id p7MHPprn011621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:26:00 -0700 Received: by gwb11 with SMTP id 11so3754234gwb.34 for ; Mon, 22 Aug 2011 10:26:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XJgeIMvqvV+IzrAMUqu1qKwW7RBIQ656sOXIUeJPC6c=; b=sH9s9t8Y4Qwm7VqJ3BkMudYNIBhcys2oCeIoI8BEPxVJxfvsY7lkyiz4ES4v8wPaXC 7OeyqSitANIN3ykT0dRg== Received: by 10.150.114.12 with SMTP id m12mr2751436ybc.287.1314033960256; Mon, 22 Aug 2011 10:26:00 -0700 (PDT) Received: by 10.150.114.12 with SMTP id m12mr2751428ybc.287.1314033960124; Mon, 22 Aug 2011 10:26:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 10:25:40 -0700 (PDT) In-Reply-To: <4E52903D.7080706@gmail.com> References: <4E52903D.7080706@gmail.com> From: John Tamplin Date: Mon, 22 Aug 2011 13:25:40 -0400 Message-ID: To: Philipp Serafin Content-Type: multipart/alternative; boundary=000e0cdf13ca6a7ff704ab1b5f83 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 17:24:57 -0000 --000e0cdf13ca6a7ff704ab1b5f83 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 22, 2011 at 1:22 PM, Philipp Serafin wrote: > The whole thing boils down to the question if we'll ever have so many > official or proprietary extensions in use that header size could become a > problem. > I don't see any reason we can't address it at the point that occurs, rather than now. It would simply be an optimization, and listing all the supported extensions would still work, so I think if it ever becomes a problem we could address it then. -- John A. Tamplin Software Engineer (GWT), Google --000e0cdf13ca6a7ff704ab1b5f83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 1:22 PM, Philipp Serafin= <phil127@gmail.c= om> wrote:
=20 =20 =20
The whole thing boils down to t= he question if we'll ever have so many official or proprietary extensions in use that header size could become a problem.

I d= on't see any reason we can't address it at the point that occurs, r= ather than now. =C2=A0It would simply be an optimization, and listing all t= he supported extensions would still work, so I think if it ever becomes a p= roblem we could address it then.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cdf13ca6a7ff704ab1b5f83-- From tyoshino@google.com Mon Aug 22 10:47: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 2622F21F8BAD for ; Mon, 22 Aug 2011 10:47:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.826 X-Spam-Level: X-Spam-Status: No, score=-105.826 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNIMMYGquJrg for ; Mon, 22 Aug 2011 10:47:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6354021F8574 for ; Mon, 22 Aug 2011 10:47:15 -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 p7MHmKF9002405 for ; Mon, 22 Aug 2011 10:48:20 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314035300; bh=pwUa/Q8d1sYJkgQiA7YI3FHJ5do=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=tzc82LcmoG6FMBsaPlH0ukVZm1TRXRrvsN56jdEUCoCEdrYlVhMoRRghzjIdd3LLf NaNdWkeD6smALTeMGr6aw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Mrye6K5B/IDfVVYD0Vm4evb3Jq/9P1ddDi8C5sEarvMMBGhD0xt4FSrGlwCsHDbiX x+ke9YXkboOVCayfmsLPw== Received: from gxk7 (gxk7.prod.google.com [10.202.11.7]) by hpaq12.eem.corp.google.com with ESMTP id p7MHmAwg001139 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:48:18 -0700 Received: by gxk7 with SMTP id 7so4975857gxk.35 for ; Mon, 22 Aug 2011 10:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1QyzcV3wQlJee0FJ4fpAGJUH1FKIR03B6UpIDaCXVRU=; b=szsqpL9PIZUHdrslRw/p4iHZM9uS6GZy3aRCXYmxUUZKd0keo5pWxpvHE08nEc/PXk aAoZYe5SR01HaXVuns9w== Received: by 10.150.142.1 with SMTP id p1mr2741916ybd.57.1314035298531; Mon, 22 Aug 2011 10:48:18 -0700 (PDT) Received: by 10.150.142.1 with SMTP id p1mr2741890ybd.57.1314035297298; Mon, 22 Aug 2011 10:48:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Mon, 22 Aug 2011 10:47:57 -0700 (PDT) In-Reply-To: <4E5290A7.4010109@gmail.com> References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5C9C6@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CA0A@EXVMBX020-12.exch020.serverdata.net> <4E52577A.9080905@gmail.com> <4E5290A7.4010109@gmail.com> From: Takeshi Yoshino Date: Tue, 23 Aug 2011 02:47:57 +0900 Message-ID: To: Philipp Serafin Content-Type: multipart/alternative; boundary=000e0cdf16c61e2b3104ab1baf35 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 17:47:16 -0000 --000e0cdf16c61e2b3104ab1baf35 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 02:23, Philipp Serafin wrote: > Am 22.08.2011 15:28, schrieb I=F1aki Baz Castillo: > > I know that Tobias says it's not an error, but honestly I don't find > > such assertion in the WS draft. > > > > PLEASE: Change the spec to say: "the *whole* message (after joining > > all the frames payload) MUST be UTF-8 in case the first frame has > > opcode=3D1." > Also discussed here. http://www.ietf.org/mail-archive/web/hybi/current/msg07811.html I agree that this should be clarified in the spec. As I said in the thread, I prefer allowing fragmentation in the middle of UTF-8 sequence. --000e0cdf16c61e2b3104ab1baf35 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 02:23, Philipp Serafin <= span dir=3D"ltr"><phil127@gmail.com= > wrote:
Am 22.08.2011 15:28, schrieb I=F1aki Baz Castillo:
> I know that Tobias says it's not an error, but honestly I don'= t find
> such assertion in the WS draft.
>
> PLEASE: Change the spec to say: "the *whole* message (after joini= ng
> all the frames payload) MUST be UTF-8 in case the first frame has
> opcode=3D1."

Also discu= ssed here.

I agree that this should be clarified in the spec. As I= said in the thread, I prefer allowing fragmentation in the middle of UTF-8= sequence.

--000e0cdf16c61e2b3104ab1baf35-- From ibc@aliax.net Mon Aug 22 10:53:32 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 4629021F8C15 for ; Mon, 22 Aug 2011 10:53:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R58rQXTTKpAe for ; Mon, 22 Aug 2011 10:53:31 -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 32C7A21F8C12 for ; Mon, 22 Aug 2011 10:53:31 -0700 (PDT) Received: by qyk35 with SMTP id 35so2349095qyk.10 for ; Mon, 22 Aug 2011 10:54:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr1531698qch.299.1314035676029; Mon, 22 Aug 2011 10:54:36 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 10:54:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 19:54:35 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 17:53:32 -0000 2011/8/22 John Tamplin : > The client can require it -- when it gets the response back from the serv= er, > if it doesn't include any extensions that it requires, it closes the > connection. The problem is that the server does not know if the client has closed the connection due to the lack of an extension in the 101 response. Difficult to debug then. Or at least, there could be a new WS close status code (i.e 1008 "Extension Required") which is sent by the client to inform the server that it closes the connection because the server does not include an extensions asked by the client. It would change nothing in the current spect, and could be useful. --=20 I=C3=B1aki Baz Castillo From jat@google.com Mon Aug 22 10:57: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 06D3321F8B18 for ; Mon, 22 Aug 2011 10:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.737 X-Spam-Level: X-Spam-Status: No, score=-105.737 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCibIPqy-K2m for ; Mon, 22 Aug 2011 10:57:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 193B621F8A6C for ; Mon, 22 Aug 2011 10:57:46 -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 p7MHwp8V011354 for ; Mon, 22 Aug 2011 10:58:52 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314035932; bh=9bfJBYBFMcgauZ8MPpxKeo2wqQs=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ZoQaxPcycbNRyI2+B3QUurRxBcxNe0cPLVy0cHXM0HJZ/YDo7FvJU0RjIZWcg9d/G J7oqq3vVG4L43d9GDOXFQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=UrEv4kCyRrmzqXEDCScI1GhhkGsrDZV7NgOzZvtZ6urHYWDvNR1L4vZyRbn9n7Zjv yF14mKJUzF5Tut3RwMTzA== Received: from gyc15 (gyc15.prod.google.com [10.243.49.143]) by hpaq12.eem.corp.google.com with ESMTP id p7MHwZD5018474 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 10:58:50 -0700 Received: by gyc15 with SMTP id 15so4905960gyc.39 for ; Mon, 22 Aug 2011 10:58:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3Y6koVb4q41GAtM8zL7XvLOlV3EJFqkaNPZkK9gLZwE=; b=TY+euCdD0m1//BbklpxX4ovnSjKp0zh5iUo9tFE4Uvp4IU8NynuoecVVLxa7EWpEOX j3GNEKLAU6bcbdpx4qTg== Received: by 10.151.59.14 with SMTP id m14mr2839055ybk.401.1314035930356; Mon, 22 Aug 2011 10:58:50 -0700 (PDT) Received: by 10.151.59.14 with SMTP id m14mr2839048ybk.401.1314035930142; Mon, 22 Aug 2011 10:58:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 10:58:30 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Mon, 22 Aug 2011 13:58:30 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00151750ebe4d696b904ab1bd4aa X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 17:57:48 -0000 --00151750ebe4d696b904ab1bd4aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 1:54 PM, I=C3=B1aki Baz Castillo wr= ote: > The problem is that the server does not know if the client has closed > the connection due to the lack of an extension in the 101 response. > Difficult to debug then. > > Or at least, there could be a new WS close status code (i.e 1008 > "Extension Required") which is sent by the client to inform the server > that it closes the connection because the server does not include an > extensions asked by the client. It would change nothing in the current > spect, and could be useful. I would be fine defining a new error code. However, I think for it to actually be useful you need to include the required extensions, which means making the close frame more complicated. --=20 John A. Tamplin Software Engineer (GWT), Google --00151750ebe4d696b904ab1bd4aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 1:54 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
The problem is that the server does not know if the client has closed
the connection due to the lack of an extension in the 101 response.
Difficult to debug then.

Or at least, there could be a new WS close status code (i.e 1008
"Extension Required") which is sent by the client to inform the s= erver
that it closes the connection because the server does not include an
extensions asked by the client. It would change nothing in the current
spect, and could be useful.

I would be fine= defining a new error code. =C2=A0However, I think for it to actually be us= eful you need to include the required extensions, which means making the cl= ose frame more complicated.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--00151750ebe4d696b904ab1bd4aa-- From sdw@lig.net Mon Aug 22 11:00: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 04DA821F8A51 for ; Mon, 22 Aug 2011 11:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.04 X-Spam-Level: X-Spam-Status: No, score=-2.04 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GdBkPOSrJwL for ; Mon, 22 Aug 2011 11:00:51 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id E00D721F852C for ; Mon, 22 Aug 2011 11:00:51 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id D05FFAB5DB0; Mon, 22 Aug 2011 11:12:38 -0700 (PDT) Message-ID: <4E52998C.9020803@lig.net> Date: Mon, 22 Aug 2011 11:01:48 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> In-Reply-To: <20110822040148.ef1fc80126c74c6c202a919c41c7bb0b.66fc2174f0.wbe@email03.secureserver.net> Content-Type: multipart/alternative; boundary="------------070505030108000503080507" Cc: Bjoern Hoehrmann , hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 18:00:53 -0000 This is a multi-part message in MIME format. --------------070505030108000503080507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/22/11 4:01 AM, Bob Gezelter wrote: > @Steve: > > UTF-8 text != UTF-8 binary (actually, "UTF-8" binary is a misnomer). UTF-8 text, encoded as UTF-8 needs no further encoding. Assuming you don't use BOM and leave no other options, like UTF-16 etc., then UTF-8 sent as "text" is indistinguishable from UTF-8 sent with "binary" "encoding". So, UTF-8 text == UTF-8 binary. Or did you mean something else? Obviously UTF-8 text/binary != binary. UTF-8 with "binary" "encoding" (i.e. simply sending UTF-8 as bytes) is not UTF-8 plus any random byte. I wasn't suggesting that and I didn't see anyone else saying that either. In the past, pre-UTF-8, a "text" mode (especially with IETF protocols) implied 7-bit, CRLF (with conversion to other line endings when necessary), line length limits often, etc. "Clean" UTF-8, web style, has none of these limitations or conversions. Therefore, when transmitted, it is treated as a simple sequence of bytes. Of course, when created or consumed, it is often converted to 2 byte (Java especially, some C++ and most others) or 4 byte (some C++) characters internally. But this is hidden from the protocol, and mostly hidden through language libraries. API idioms are now common to allow this transformation without making application code handle details most of the time. > > This is likely redundant for many, but UTF-8 is identical to text, so > long as the text is composed of the 128 characters in the USASCII 7-bit > code. For 8-bit characters with a decimal value exceeding 127, the > result is a multiple byte encoding as defined by RFC 3629. Wikipedia has > a good quick reference to UTF-8 (with chart or illegal characters) at > http://en.wikipedia.org/wiki/Utf-8. > > The strength of UTF-8 is that it permits backwards compatibility with > USASCII-7 while providing encoding of non-ASCII characters. This is why Except line endings are more liberal for UTF-8 than USASCII-7, at least in the sense that all UTF-8 receivers generally handle any combination of line endings, where it was common for ASCII processors to assume one of the 3 dominant styles. While I understand, and mostly agree with IETF's affection with ASCII and CRLF, the inefficiency was always a little annoying. > it is becoming a IETF standard. However, it is not good for representing > binary data that has not been first encoded into a printable subset > (e.g., Base 64, MIME). > > As one who has often been involved in transferring large volumes of > data, requiring MIME'ification represents a significant loss of > effective bandwidth. I agree. > > (Everyone) > > I have long ago stated, and my preference remains for the WebSocket > protocol to be defined as "UTF-8 for control messages (per IETF > convention) and "8-bit binary transparent" for the actual data channel. > The case of an application that wants to send some messages in UTF-8 and > some in binary is to me, not a compelling case for support within the > WebSocket protocol. It is an appropriate provision in an applications > level protocol that uses the WebSocket protocol as its underlying > transport. This was my point. > > The argument that "JavaScript does not support binary" is, IMHO, without > significant merit. Typed arrays are used in other HTML5 features (e.g., > WebGL) and are supported by current versions of browsers (see > https://developer.mozilla.org/en/JavaScript_typed_arrays under > subheading "Specification"). > > It has been mentioned that "most applications will not need to exchange > anything but text messages". This is an unproven (and unprovable) > assertion. It is also true that what is true in the aggregate will most > likely not apply to individual application implementers. > > A small mezzanine protocol (layered on top of the WebSockets API, using > the WebSocket protocol for transport) can easily serve those > implementers that wish to have a text-only connection. It is thus > unnecessary to place that support within the WebSocket protocol. > > That I am suggesting a change in the WebSockets API is unclear. There is > already a need to distinguish Text from Binary at the level of the API, > I merely suggest that the distinction be handled somewhat differently > than is currently envisioned. > > - Bob Gezelter, http://www.rlgsc.com > sdw -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com --------------070505030108000503080507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/22/11 4:01 AM, Bob Gezelter wrote: 
@Steve:

UTF-8 text != UTF-8 binary (actually, "UTF-8" binary is a misnomer).

UTF-8 text, encoded as UTF-8 needs no further encoding.  Assuming you don't use BOM and leave no other options, like UTF-16 etc., then UTF-8 sent as "text" is indistinguishable from UTF-8 sent with "binary" "encoding".

So, UTF-8 text == UTF-8 binary.  Or did you mean something else?  Obviously UTF-8 text/binary != binary.

UTF-8 with "binary" "encoding" (i.e. simply sending UTF-8 as bytes) is not UTF-8 plus any random byte.  I wasn't suggesting that and I didn't see anyone else saying that either.

In the past, pre-UTF-8, a "text" mode (especially with IETF protocols) implied 7-bit, CRLF (with conversion to other line endings when necessary), line length limits often, etc.  "Clean" UTF-8, web style, has none of these limitations or conversions.  Therefore, when transmitted, it is treated as a simple sequence of bytes.

Of course, when created or consumed, it is often converted to 2 byte (Java especially, some C++ and most others) or 4 byte (some C++) characters internally.  But this is hidden from the protocol, and mostly hidden through language libraries.  API idioms are now common to allow this transformation without making application code handle details most of the time.


This is likely redundant for many, but UTF-8 is identical to text, so
long as the text is composed of the 128 characters in the USASCII 7-bit
code. For 8-bit characters with a decimal value exceeding 127, the
result is a multiple byte encoding as defined by RFC 3629. Wikipedia has
a good quick reference to UTF-8 (with chart or illegal characters) at
http://en.wikipedia.org/wiki/Utf-8.

The strength of UTF-8 is that it permits backwards compatibility with
USASCII-7 while providing encoding of non-ASCII characters. This is why

Except line endings are more liberal for UTF-8 than USASCII-7, at least in the sense that all UTF-8 receivers generally handle any combination of line endings, where it was common for ASCII processors to assume one of the 3 dominant styles.

While I understand, and mostly agree with IETF's affection with ASCII and CRLF, the inefficiency was always a little annoying.

it is becoming a IETF standard. However, it is not good for representing
binary data that has not been first encoded into a printable subset
(e.g., Base 64, MIME).

As one who has often been involved in transferring large volumes of
data, requiring MIME'ification represents a significant loss of
effective bandwidth.

I agree.


(Everyone)

I have long ago stated, and my preference remains for the WebSocket
protocol to be defined as "UTF-8 for control messages (per IETF
convention) and "8-bit binary transparent" for the actual data channel.
The case of an application that wants to send some messages in UTF-8 and
some in binary is to me, not a compelling case for support within the
WebSocket protocol. It is an appropriate provision in an applications
level protocol that uses the WebSocket protocol as its underlying
transport.

This was my point.


The argument that "JavaScript does not support binary" is, IMHO, without
significant merit. Typed arrays are used in other HTML5 features (e.g.,
WebGL) and are supported by current versions of browsers (see
https://developer.mozilla.org/en/JavaScript_typed_arrays under
subheading "Specification"). 

It has been mentioned that "most applications will not need to exchange
anything but text messages". This is an unproven (and unprovable)
assertion. It is also true that what is true in the aggregate will most
likely not apply to individual application implementers. 

A small mezzanine protocol (layered on top of the WebSockets API, using
the WebSocket protocol for transport) can easily serve those
implementers that wish to have a text-only connection. It is thus
unnecessary to place that support within the WebSocket protocol.

That I am suggesting a change in the WebSockets API is unclear. There is
already a need to distinguish Text from Binary at the level of the API,
I merely suggest that the distinction be handled somewhat differently
than is currently envisioned.

- Bob Gezelter, http://www.rlgsc.com

sdw
--
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com

--------------070505030108000503080507-- From ibc@aliax.net Mon Aug 22 11:01: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 B493721F8B01 for ; Mon, 22 Aug 2011 11:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOrSC2UZcg78 for ; Mon, 22 Aug 2011 11:01:07 -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 383EE21F852C for ; Mon, 22 Aug 2011 11:01:07 -0700 (PDT) Received: by qyk35 with SMTP id 35so2353303qyk.10 for ; Mon, 22 Aug 2011 11:02:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr1554208qce.185.1314036132501; Mon, 22 Aug 2011 11:02:12 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 11:02:12 -0700 (PDT) Date: Mon, 22 Aug 2011 20:02:12 +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] Suggested new WS status code: 1008 "Extension Required" 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, 22 Aug 2011 18:01:07 -0000 Following the rationale in other thread, I suggest the following new WS status code: 1008 1008 is just sent from client to server when the client decides to disconnect due to lack of some extension in the server's Sec-WebSocket-Extensions header during 101 response. It MAY contain the name of the extension (or extensions separated by comma) in the frame payload data after the status code. This would be useful to inform the server (so it can log it) the reason of the client's disconnect after WS handshake. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 11:02: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 B225B21F8B21 for ; Mon, 22 Aug 2011 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-K3HtH5eMDU for ; Mon, 22 Aug 2011 11:02:20 -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 3254C21F8B10 for ; Mon, 22 Aug 2011 11:02:20 -0700 (PDT) Received: by qwc23 with SMTP id 23so3931899qwc.31 for ; Mon, 22 Aug 2011 11:03:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr1507214qcq.261.1314036205453; Mon, 22 Aug 2011 11:03:25 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 11:03:25 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 20:03:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 18:02:20 -0000 2011/8/22 John Tamplin : > I would be fine defining a new error code. =C2=A0However, I think for it = to > actually be useful you need to include the required extensions, which mea= ns > making the close frame more complicated. I've suggested exactly that in a new mail :) I've suggested to include the name of the affected extensions within the descriptive reason/text after the status code. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Mon Aug 22 11:03: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 AECEC21F8B5B for ; Mon, 22 Aug 2011 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNMAM+NWlA3M for ; Mon, 22 Aug 2011 11:03:45 -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 30AD821F8B21 for ; Mon, 22 Aug 2011 11:03:45 -0700 (PDT) Received: by qwc23 with SMTP id 23so3932697qwc.31 for ; Mon, 22 Aug 2011 11:04:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr1508318qcq.261.1314036290444; Mon, 22 Aug 2011 11:04:50 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 11:04:50 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 20:04:50 +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: Re: [hybi] Suggested new WS status code: 1008 "Extension Required" 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, 22 Aug 2011 18:03:45 -0000 2011/8/22 I=C3=B1aki Baz Castillo : > =C2=A01008 > > =C2=A0 =C2=A0 1008 is just sent from client to server when the client dec= ides to > =C2=A0 =C2=A0 disconnect due to lack of some extension in the server's > =C2=A0 =C2=A0 Sec-WebSocket-Extensions header during 101 response. > =C2=A0 =C2=A0 It MAY contain the name of the extension (or extensions sep= arated > =C2=A0 =C2=A0 by comma) in the frame payload data after the status code. To clarify, I meant that the name of the affected extensions could be carried within the reason/description text after the status code (instead of writting an "human" text). Anyhow the server can do nothing with it as the connection has been already closed. --=20 I=C3=B1aki Baz Castillo From jat@google.com Mon Aug 22 11:09: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 094F121F8B6E for ; Mon, 22 Aug 2011 11:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.776 X-Spam-Level: X-Spam-Status: No, score=-105.776 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZG-HVsrafAd for ; Mon, 22 Aug 2011 11:09:31 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 798AF21F8B6D for ; Mon, 22 Aug 2011 11:09:30 -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 p7MIAYxE019041 for ; Mon, 22 Aug 2011 11:10:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314036634; bh=BeO9R1Dy1ccEaVN4QbqlUvxK7gQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=u5z+r6qZ8g18bkVi5EK4BZnUHs8E2TIS8mp+oH8NPaFTKGhoYD0giD/BgygWzsC1P jWToeudvKm+q0RKS8CUBg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=FCQewSoC3vwAIRCmcfyEvaVbPAAWKgQ3yeEzvey/g8PkONtwheZAkbfzq4mUwmjHI OdvO5lgy3+cFSBbWBy8cg== Received: from yib2 (yib2.prod.google.com [10.243.65.66]) by hpaq6.eem.corp.google.com with ESMTP id p7MI8D7V009707 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 11:10:33 -0700 Received: by yib2 with SMTP id 2so3639515yib.28 for ; Mon, 22 Aug 2011 11:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bSpFHzon5g/WBtrQSNfG4lwMVAPcDL24NbF9hv9RXkg=; b=UtCHmQPBcbfYhV6je2lKbMKEM2Rr/Yb0fV6n5eaJ/tiGz53gckAZ0kzhKlkRbuZHUx EbRczV2FH8Q2YCotDmjw== Received: by 10.151.25.12 with SMTP id c12mr2564818ybj.116.1314036633365; Mon, 22 Aug 2011 11:10:33 -0700 (PDT) Received: by 10.151.25.12 with SMTP id c12mr2564810ybj.116.1314036633164; Mon, 22 Aug 2011 11:10:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Mon, 22 Aug 2011 11:10:13 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Mon, 22 Aug 2011 14:10:13 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd293c2bddb4c04ab1bfe0e X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 18:09:46 -0000 --000e0cd293c2bddb4c04ab1bfe0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 2:03 PM, I=C3=B1aki Baz Castillo wr= ote: > I've suggested to include the name of the affected extensions within > the descriptive reason/text after the status code. > Then I think it is not useful for anything besides logging -- you couldn't use it for the client to then offer the extension that the server required (though in the current spec, a client should be advertising everything it supports anyway). That isn't to say it isn't useful, but the descriptive text is just for human consumption and not machine-parseable. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd293c2bddb4c04ab1bfe0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 2:03 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
I've suggested to include the name of the affected ex= tensions within
the descriptive reason/text after the status code.

Then I think it is not useful for anything besides logging -- you couldn&#= 39;t use it for the client to then offer the extension that the server requ= ired (though in the current spec, a client should be advertising everything= it supports anyway). =C2=A0That isn't to say it isn't useful, but = the descriptive text is just for human consumption and not machine-parseabl= e.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd293c2bddb4c04ab1bfe0e-- From ibc@aliax.net Mon Aug 22 11:12: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 8620621F8B6D for ; Mon, 22 Aug 2011 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwQjQk9qZ-R0 for ; Mon, 22 Aug 2011 11:12:39 -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 F133821F8B21 for ; Mon, 22 Aug 2011 11:12:38 -0700 (PDT) Received: by qwc23 with SMTP id 23so3937944qwc.31 for ; Mon, 22 Aug 2011 11:13:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.197.66 with SMTP id ej2mr1688945qab.398.1314036824237; Mon, 22 Aug 2011 11:13:44 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 11:13:44 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 20:13:44 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 18:12:39 -0000 2011/8/22 John Tamplin : > Then I think it is not useful for anything besides logging -- you couldn'= t > use it for the client to then offer the extension that the server require= d > (though in the current spec, a client should be advertising everything it > supports anyway). =C2=A0That isn't to say it isn't useful, but the descri= ptive > text is just for human consumption and not machine-parseable. I've explained and justified exactly that in my new thread speaking just about this new status code :) --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Mon Aug 22 11:21: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 38E6521F85B1 for ; Mon, 22 Aug 2011 11:21:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exuXpeLpkQx2 for ; Mon, 22 Aug 2011 11:21:05 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id AE58221F8B4B for ; Mon, 22 Aug 2011 11:21:05 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.12]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QvZ8U-0007ta-CK; Mon, 22 Aug 2011 11:22:10 -0700 Message-ID: <4E529E48.7070507@callenish.com> Date: Mon, 22 Aug 2011 11:22:00 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> In-Reply-To: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; 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] Binary/Text Distinction 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, 22 Aug 2011 18:21:06 -0000 On 22/08/2011 6:41 AM, Bob Gezelter wrote: > However, the WebSocket protocol is not, IMHO, the correct place for that > distinction. It is a higher-level distinction, that should be a > "protocol" between the respective WebSockets APIs. There is no need for > this distinction within the WebSocket protocol itself. But the Websocket protocol does specify the application-level protocol through the Sec-Websocket-Protocol field. The question is what the application protocol should look like when the field is not provided. The Javascript layer in a browser is itself an application layer above Websockets, just one that is scriptable. It needs an application protocol to work with. Since working within a browser is the most common usecase, it makes sense that this application protocol should be the default one that is used when no Sec-Websocket-Protocol field is sent. Imagine if the spec made it explicit that any browser that wanted to use a mix of binary and text messages as its application protocol had to send a "Sec-Websocket-Protocol" header with the value "mixed-message". The default when no header is present just accomplishes the same thing. This is exactly like the way that HTTP works. HTTP can be used to transfer any type of content, but you can specify the type within the HTTP protocol by using a Content-Type header. For historical reasons, when the Content-Type is not specified the default behaviour is typically to use heuristics to determine the actual type, but the details of this behaviour are not specified in the HTTP protocol. Websockets, on the other hand, is specifying the default behaviour up-front. I think, though, that there may be value in clearly separating the default subprotocol from the rest of Websockets in the specification to make this clearer. That way another subprotocol could reuse the opcodes differentiating binary from text with no fear of incompatibility issues. The control opcodes, of course, are specific to the Websocket layer and remain the same across all subprotocols, and so cannot be reused. So once we understand the mixed-message application protocol as one imposed by the Javascript appplication layer, the only question is whether that is a good design for the application. I think it is desirable for all the reasons that have been listed in these threads. From tyoshino@google.com Mon Aug 22 11:23: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 F418621F8B94 for ; Mon, 22 Aug 2011 11:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.753 X-Spam-Level: X-Spam-Status: No, score=-105.753 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sr3WBbjUg5Wd for ; Mon, 22 Aug 2011 11:23:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 58A9321F8B92 for ; Mon, 22 Aug 2011 11:23:16 -0700 (PDT) Received: from wpaz21.hot.corp.google.com (wpaz21.hot.corp.google.com [172.24.198.85]) by smtp-out.google.com with ESMTP id p7MIOJBK025483 for ; Mon, 22 Aug 2011 11:24:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314037459; bh=Gcspv55ZS9esPzgtdE2OTEXZEpA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=P7wiSKfi2mWz0R5YA3PcuRBgseR6z1TEzdkd4zO/xhBsCYvdRAXlHzQIJzy+CwgNj A/50FpT6Opi3tkAqyiQow== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=lZoorAJ/pAat+71wOYLMbc94+44pV/vM+durzzjyXuCL3lgUrmVKS9conhLYvN+sW acVGAB//y5rxs1tuhlHIQ== Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by wpaz21.hot.corp.google.com with ESMTP id p7MINXlt030606 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 11:24:18 -0700 Received: by gxk2 with SMTP id 2so3886170gxk.8 for ; Mon, 22 Aug 2011 11:24:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=kl3hP4lhapbdxPCsrVcGuH7fg8mqZW0FSclLvewTiMY=; b=k4DjBGLxTgg/4J/CO0MIZkHarRbMMaQjQp4RkuZ9ur2TXqO8xDd4yZVroj5sJEf398 evWxE2L/E7Horms4JHvw== Received: by 10.150.170.10 with SMTP id s10mr2669023ybe.171.1314037458348; Mon, 22 Aug 2011 11:24:18 -0700 (PDT) Received: by 10.150.170.10 with SMTP id s10mr2669017ybe.171.1314037458147; Mon, 22 Aug 2011 11:24:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Mon, 22 Aug 2011 11:23:58 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 23 Aug 2011 03:23:58 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd58c6eea1b1204ab1c2f43 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Close frame from webbrowser after close frame from server 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, 22 Aug 2011 18:23:17 -0000 --000e0cd58c6eea1b1204ab1c2f43 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi, On Mon, Aug 22, 2011 at 21:26, I=F1aki Baz Castillo wrote: > As per WS specification both seem valid behaviors but, shouldn't the > spec mandate (or make more recommended) a more specific behaviour? 5th paragraph of this section tells us to do so. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-= 4.5.1 Chrome 15.0.854.0 does so. We've implemented it as specified there. Firefox 8.0a2 (2011-08-22) also responds server initiated close frame befor= e closing TCP here against pywebsocket. ... 03:18:14.756457 IP pywebsocket > Fx8: Flags [P.], seq 130:134, ack 498, win 54, length 4 (snip) 0x0030: 0036 e2cb 0000 8802 03e8 .6........ 03:18:14.756835 IP Fx8 > pywebsocket: Flags [P.], seq 498:506, ack 134, win 16391, length 8 (snip) 0x0030: 4007 818a 0000 8882 d59e a784 d676 @............v ... Here, 0xd59e XOR 0xd676 is 1000 in decimal. Thanks, Takeshi --000e0cd58c6eea1b1204ab1c2f43 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

On Mon, Aug 22, 2011 at 21:26, I=F1aki Baz Castill= o <ibc@aliax.net&= gt; wrote:
As per WS specification both seem valid beh= aviors but, shouldn't the
spec mandate (or make more recommended) a more specific behaviour?

5th paragraph of this section tells us to do so.

Chrome 15.0.854.0 does so. We've implemented it as = specified there.

Firefox 8.0a2 (2011-08-22) also r= esponds server initiated close frame before closing TCP here against pywebs= ocket.

...
03:18:14.756457 IP pywebsocket > = Fx8: Flags [P.], seq 130:134, ack 498, win 54, length 4
(snip)
=A0 =A0 =A0 =A0 0x0030: =A00036 e2cb 0000 8802 03e8 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 .6........
03:18:14.756835 IP Fx8 > pywebsocket: Flags [P.], seq 498:506, ack = 134, win 16391, length 8
(snip)
=A0 =A0 =A0 =A0 0x0030:= =A04007 818a 0000 8882 d59e a784 d676 =A0 =A0 =A0 @............v
...

Here,=A00xd59e XOR 0xd676 is=A01000 in decimal.

Thanks,
Takeshi
--000e0cd58c6eea1b1204ab1c2f43-- From gezelter@rlgsc.com Mon Aug 22 11:23:27 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 6100721F8B9D for ; Mon, 22 Aug 2011 11:23:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrP5bjkSTPtn for ; Mon, 22 Aug 2011 11:23:26 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id A765D21F8B92 for ; Mon, 22 Aug 2011 11:23:26 -0700 (PDT) Received: (qmail 28613 invoked from network); 22 Aug 2011 18:24:31 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 18:24:31 -0000 Received: (qmail 29600 invoked by uid 99); 22 Aug 2011 18:24:31 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822112430.ef1fc80126c74c6c202a919c41c7bb0b.7eef12ffb2.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Stephen Williams" Date: Mon, 22 Aug 2011 11:24:30 -0700 Mime-Version: 1.0 Cc: Bjoern Hoehrmann , hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 18:23:27 -0000 Stephen,=0A=0AI was responding to an earlier message.=0A=0AMy point was tha= t while all UTF-8 can be sent as binary, not all binary=0Acan be sent as UT= F-8 without appropriate wrapping/encoding.=0A=0AAs I have said in other pos= tings, my strong preference is:=0A=0A- a single message type=0A- the protoc= ol be defined as 8-bit transparent octets=0A- a trivial WSAPI-WSAPI protoco= l be defined that is either pure UTF-8 or=0Amessage-by-message UTF-8/binary= .=0A=0AThis little impact on performance, and has significant advantages in= =0Aclarity. While I do not have a sample WSAPI implementation handy, I do= =0Anot see how moving the "data" meaning layer up a notch has any=0Asignifi= cant negative impact. In most cases, I would expect the impact to=0Abe a ha= ndful of lines in WSAPI.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A=0A=0A From ibc@aliax.net Mon Aug 22 11:37: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 B845621F8BB3 for ; Mon, 22 Aug 2011 11:37:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wECTvozmEwDI for ; Mon, 22 Aug 2011 11:37:54 -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 358AA21F8BB8 for ; Mon, 22 Aug 2011 11:37:54 -0700 (PDT) Received: by qyk35 with SMTP id 35so2372316qyk.10 for ; Mon, 22 Aug 2011 11:38:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr1567762qch.299.1314038338649; Mon, 22 Aug 2011 11:38:58 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Mon, 22 Aug 2011 11:38:58 -0700 (PDT) In-Reply-To: References: Date: Mon, 22 Aug 2011 20:38:58 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Close frame from webbrowser after close frame from server 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, 22 Aug 2011 18:37:54 -0000 2011/8/22 Takeshi Yoshino : > Firefox 8.0a2 (2011-08-22) also responds server initiated close frame bef= ore > closing TCP here against pywebsocket. I have Firefox 9.0a1 (2011-08-19) and does not send the close frame when it receives a close frame. Google 15.X does it. I will recheck however. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Mon Aug 22 11:48: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 80C6921F8C09 for ; Mon, 22 Aug 2011 11:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pz1Tr9Coog5M for ; Mon, 22 Aug 2011 11:48:52 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 9042721F8BE8 for ; Mon, 22 Aug 2011 11:48:52 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Mon, 22 Aug 2011 11:49:57 -0700 From: Tobias Oberstein To: Takeshi Yoshino , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Mon, 22 Aug 2011 11:49:09 -0700 Thread-Topic: [hybi] Close frame from webbrowser after close frame from server Thread-Index: Acxg+LwvKgcWVd5sS7awqziijO4UqAAAgi+Q Message-ID: <634914A010D0B943A035D226786325D422C0D5CCB2@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D422C0D5CCB2EXVMBX02012ex_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Close frame from webbrowser after close frame from server 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, 22 Aug 2011 18:48:53 -0000 --_000_634914A010D0B943A035D226786325D422C0D5CCB2EXVMBX02012ex_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As far as I understand you describe the behavior of Chrome/FF in response t= o a server initiated close frame as part of a graceful closing handshake. However, there is a 2nd scenario where both user agents currently don't app= ear to send close frames, namely upon failing the connection, i.e. because of receiving a frame with reserved opcode in the absence of extensions negotia= ted. The spec says SHOULD though. Chrome at least reports the error (i.e. reserved opcode) in JS, but - as FF= - won't send a close. Is that by design? 7.1.7. Fail the WebSocket Connection Certain algorithms and specifications require an endpoint to _Fail the WebSocket Connection_. To do so, the client MUST _Close the WebSocket Connection_, and MAY report the problem to the user (which would be especially useful for developers) in an appropriate manner. If _The WebSocket Connection is Established_ prior to the point where the endpoint is required to _Fail the WebSocket Connection_, the endpoint SHOULD send a Close frame with an appropriate status code Section 7.4 before proceeding to _Close the WebSocket Connection_. An endpoint MAY omit sending a Close frame if it believes the other side is unlikely to be able to receive and process the close frame, due to the nature of the error that led to the WebSocket connection being failed in the first place. An endpoint MUST NOT continue to attempt to process data (including a responding Close frame) from the remote endpoint after being instruted to _Fail the WebSocket Connection_. Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von Ta= keshi Yoshino Gesendet: Montag, 22. August 2011 20:24 An: I=F1aki Baz Castillo Cc: hybi@ietf.org Betreff: Re: [hybi] Close frame from webbrowser after close frame from serv= er Hi, On Mon, Aug 22, 2011 at 21:26, I=F1aki Baz Castillo > wrote: As per WS specification both seem valid behaviors but, shouldn't the spec mandate (or make more recommended) a more specific behaviour? 5th paragraph of this section tells us to do so. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-10#section-= 4.5.1 Chrome 15.0.854.0 does so. We've implemented it as specified there. Firefox 8.0a2 (2011-08-22) also responds server initiated close frame befor= e closing TCP here against pywebsocket. ... 03:18:14.756457 IP pywebsocket > Fx8: Flags [P.], seq 130:134, ack 498, win= 54, length 4 (snip) 0x0030: 0036 e2cb 0000 8802 03e8 .6........ 03:18:14.756835 IP Fx8 > pywebsocket: Flags [P.], seq 498:506, ack 134, win= 16391, length 8 (snip) 0x0030: 4007 818a 0000 8882 d59e a784 d676 @............v ... Here, 0xd59e XOR 0xd676 is 1000 in decimal. Thanks, Takeshi --_000_634914A010D0B943A035D226786325D422C0D5CCB2EXVMBX02012ex_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

As far as I= understand you describe the behavior of Chrome/FF in response to

a server initiated close frame as p= art of a graceful closing handshake.

 

However,= there is a 2nd scenario where both user agents currently don't appear=

to send close frames, namely u= pon failing the connection, i.e. because of

receiving a frame with reserved opcode in the absence o= f extensions negotiated.

<= o:p> 

The spec says SHOULD= though.

 =

Chrome at least reports the error (i= .e. reserved opcode) in JS, but - as FF - won't send

<= p class=3DMsoNormal>a close. Is that by design?

 

 

7.1.7.=A0 Fai= l the WebSocket Connection

 

=A0=A0 Certain algorithms and specifications require an endpoint= to _Fail

=A0=A0 the WebSocket Connection_.=A0 To= do so, the client MUST _Close the

=A0=A0 WebSock= et Connection_, and MAY report the problem to the user (which

=A0=A0 would be especially useful for developers) in an approp= riate manner.

 

= =A0=A0 If _The WebSocket Connection is Established_ prior to the point wher= e

=A0=A0 the endpoint is required to _Fail the We= bSocket Connection_, the

=A0=A0 endpoint SHOULD s= end a Close frame with an appropriate status code

=A0=A0 Section 7.4 before proceeding to _Close the Web= Socket Connection_.

=A0=A0 An endpoint MAY omit= sending a Close frame if it believes the other

= =A0=A0 side is unlikely to be able to receive and process the close frame,<= o:p>

=A0=A0 due to the nature of the error that led to= the WebSocket connection

=A0=A0 being failed in = the first place.=A0 An endpoint MUST NOT continue to

<= p class=3DMsoNormal>=A0=A0 attempt to process data (including a responding Close frame) fro= m the

=A0=A0 remote endpoint after being instrute= d to _Fail the WebSocket

=A0=A0 Connection_.=

 

 

=  

Von= : hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von= Takeshi Yoshino
Gesendet: Montag, 22. August 2011 20:24
<= b>An: I=F1aki Baz Castillo
Cc: hybi@ietf.org
Betreff: Re: [hybi] Close frame from webbrowser after close frame from server

 

Hi,

 

On Mon, Aug 22, 2011 at = 21:26, I=F1aki Baz Castillo <ibc@aliax.= net> wrote:

As per WS specificati= on both seem valid behaviors but, shouldn't the
spec mandate (or make mo= re recommended) a more specific behaviour?

 

5th paragraph = of this section tells us to do so.

 

Chrome 15.0.854.0= does so. We've implemented it as specified there.

 

= Firefox 8.0a2 (2011-08-22) also responds server initiated close frame befor= e closing TCP here against pywebsocket.

 

...<= /o:p>

03:18:14.756457 IP pywebsocke= t > Fx8: Flags [P.], seq 130:134, ack 498, win 54, length 4

(snip)

        0x0030:  0036 e2cb 0000 8802 = 03e8                 .6........

03:18:14.756835 IP Fx8 > pywe= bsocket: Flags [P.], seq 498:506, ack 134, win 16391, length 8

(snip)

        0x0030:  4007 818a 0000 8882 = d59e a784 d676       @............v

...

 

Here, 0xd59e X= OR 0xd676 is 1000 in decimal.

 

Thanks,

Takeshi

= --_000_634914A010D0B943A035D226786325D422C0D5CCB2EXVMBX02012ex_-- From jamie@shareable.org Mon Aug 22 12:25: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 01B8121F8B48 for ; Mon, 22 Aug 2011 12:25:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5wlobNpE2Io for ; Mon, 22 Aug 2011 12:25:21 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 3728921F8888 for ; Mon, 22 Aug 2011 12:25:21 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Qva8M-0004DR-5Q; Mon, 22 Aug 2011 20:26:06 +0100 Date: Mon, 22 Aug 2011 20:26:06 +0100 From: Jamie Lokier To: John Tamplin Message-ID: <20110822192606.GJ14899@jl-vm1.vm.bytemark.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 19:25:22 -0000 John Tamplin wrote: > On Mon, Aug 22, 2011 at 12:24 PM, Iñaki Baz Castillo > <[1]ibc@aliax.net> wrote: > > The current way of negotiating extensions during WS handshake states > that the client offers some capabilities it implements and the > server > decides which ones tu use within the WS connection. > I don't like it too much as the client cannot *require* the usage of > a > specific extension but just "ask for it". > > The client can require it -- when it gets the response back from the > server, if it doesn't include any extensions that it requires, it > closes the connection. If the HTTP negotiation were rejected with an HTTP error, then the client could reuse the connection with a new request, either trying a different combination of capabilities, or adding it back to the HTTP connection pool to immediately reuse for the over-HTTP method that it probably falls back to. If WS close-frames allowed the HTTP connection to be reused -- or to enter a WS renegotiation, that would accomplish the same but seems far more fragile, potentially insecure, and very unlikely to be approved. -- Jamie From tyoshino@google.com Mon Aug 22 12:38: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 DBBAA21F8C75 for ; Mon, 22 Aug 2011 12:38:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.843 X-Spam-Level: X-Spam-Status: No, score=-105.843 tagged_above=-999 required=5 tests=[AWL=0.133, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iySih7U3d1mR for ; Mon, 22 Aug 2011 12:38:45 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0008621F8C74 for ; Mon, 22 Aug 2011 12:38:44 -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 p7MJdo2K023544 for ; Mon, 22 Aug 2011 12:39:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314041990; bh=FtT0xvDTBj1g9BNUvIwSrJ+9+G4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=FWBMlbgLhq2EqA7vILwbd3aIZUPx8klyVlWP2LbXli+heHqgyXGHm3SofhYL3eEfc +vnKG6WHsSjwelYdpGtrA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Vo0CRoSPvTSD0feFlXNE+VqvQ0mT8e0U0vLqazf5PBU/SYztDkWKoP0YuF7zHQyuC 90yY4rDjJm2Z9Wz7jJW7A== Received: from yia28 (yia28.prod.google.com [10.243.65.28]) by hpaq6.eem.corp.google.com with ESMTP id p7MJdlkq015729 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 12:39:48 -0700 Received: by yia28 with SMTP id 28so3572813yia.6 for ; Mon, 22 Aug 2011 12:39:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ojyJuKufgRCl1a/83m7XsXcwzmIDCXcs13DU//9+0Vk=; b=xXImrbf2PXoLonn3c68O4cTd8ywyEMYIY3QFZFDZ00xSJ3Io+7nIATXN4hEPwkHgqr S9zWb2xfnBOJ+Gnf5qww== Received: by 10.90.16.10 with SMTP id 10mr2062033agp.190.1314041987473; Mon, 22 Aug 2011 12:39:47 -0700 (PDT) Received: by 10.90.16.10 with SMTP id 10mr2062025agp.190.1314041987256; Mon, 22 Aug 2011 12:39:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.32.2 with HTTP; Mon, 22 Aug 2011 12:39:27 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5CCB2@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5CCB2@EXVMBX020-12.exch020.serverdata.net> From: Takeshi Yoshino Date: Tue, 23 Aug 2011 04:39:27 +0900 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=0016361e7d62ded0d704ab1d3d8c X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Close frame from webbrowser after close frame from server 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, 22 Aug 2011 19:38:46 -0000 --0016361e7d62ded0d704ab1d3d8c Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 23, 2011 at 03:49, Tobias Oberstein wrote: > As far as I understand you describe the behavior of Chrome/FF in response > to**** > > a server initiated close frame as part of a graceful closing handshake. > Yes. > ** > > However, there is a 2nd scenario where both user agents currently don't > appear**** > > to send close frames, namely upon failing the connection, i.e. because of* > *** > > receiving a frame with reserved opcode in the absence of extensions > negotiated.**** > > ** ** > > The spec says SHOULD though. > Yes, it's SHOULD. Since after seeing broken frame from the other peer, it doesn't make much sense to wait for close in response to perform graceful shutdown, the close initiator doesn't have to wait for close in response (in the spec, "have to wait" is "MUST NOT process"). Then, as we give up graceful shutdown, even the first close frame is not really necessary, but SHOULD be sent since close code/reason might be informative for the other peer. So, though it's required in the spec, endpoints don't need to reply close frames resulted from _Fail the... algorithm. But now graceful closing handshake may carry any code/reason. Endpoints cannot determine if a certain close frame is for _Fail the.. or for _Start the WebSocket Closing.... We may group codes into ones require response and ones not, but I don't see much gain from that effort. I think it's fine to just require endpoints to respond to a close frame assuming it's one for _Start WebSocket Closing Handshake_. Thanks, Takeshi --0016361e7d62ded0d704ab1d3d8c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 03:49, Tobias Oberstein = <tobias= .oberstein@tavendo.de> wrote:

As far as I understand you = describe the behavior of Chrome/FF in response to

<= p class=3D"MsoNormal"> a server initiated close fra= me as part of a graceful closing handshake.

=A0
Yes.
=A0

However, ther= e is a 2nd scenario where both user agents currently don't appear

to se= nd close frames, namely upon failing the connection, i.e. because of=

receiving a frame with reserved opcode in the absence of exten= sions negotiated.

=A0

The spec says SHOULD though.


Yes, it's SHOULD. Since after seeing broken frame f= rom the other peer, it doesn't make much sense to wait for close in res= ponse to perform graceful shutdown, the close initiator doesn't have to= wait for close in response (in the spec, "have to wait" is "= ;MUST NOT process"). Then, as we give up graceful shutdown, even the f= irst close frame is not really necessary, but SHOULD be sent since close co= de/reason might be informative for the other peer.

So, though it's required in the spec, endpoints don= 't need to reply close frames resulted from _Fail the... algorithm. But= now graceful closing handshake may carry any code/reason. Endpoints cannot= determine if a certain close frame is for _Fail the.. or for _Start the We= bSocket Closing....

We may group codes into ones require response and ones = not, but I don't see much gain from that effort.

I think it's fine to just require endpoints to respond to a close fr= ame assuming it's one for _Start WebSocket Closing Handshake_.

Thanks,
Takeshi
--0016361e7d62ded0d704ab1d3d8c-- From jmason@rim.com Mon Aug 22 13:25:27 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 9CC5721F8B8C for ; Mon, 22 Aug 2011 13:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saRLS4Bux9hR for ; Mon, 22 Aug 2011 13:25:27 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id C7F5B21F8B8A for ; Mon, 22 Aug 2011 13:25:26 -0700 (PDT) X-AuditID: 0a41282f-b7cb9ae000005384-78-4e52bb644d1f Received: from XHT104CNC.rim.net (xht104cnc.rim.net [10.65.22.52]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 09.05.21380.46BB25E4; Mon, 22 Aug 2011 20:26:13 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT104CNC.rim.net ([fe80::9520:36d8:1c40:a506%11]) with mapi; Mon, 22 Aug 2011 16:26:31 -0400 From: Joe Mason To: John Tamplin , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Mon, 22 Aug 2011 16:26:29 -0400 Thread-Topic: [hybi] About WebSocket extensions negotiation Thread-Index: Acxg7Pw/vY9iuwAqRTmfrvpOdSl2cwAHE2Tw Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB31C4AB95A70042A256109D461991260ACDAAE4XCH117CNCrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOKsWRmVeSWpSXmKPExsXC5Shmopu6O8jPYO0xVov3L7cxWUzfZ2Px dNIBdgdmj3MN79k9Fmwq9Viy5CdTAHNUA6NNYl5efkliSapCSmpxsq2ST2p6Yo5CQFFmWWJy pYJLZnFyTmJmbmqRkkJmiq2SiZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jNS85P ycxLt1XyDPbXtbAwtdQ1VLLTRQIJ/7gzDuxfxVpwyq6i4dQCtgbGFzZdjJwcEgImEj2Xd7JB 2GISF+6tB7K5OIQEepgkup9OZYVwFjNKnJ++nRWkik1AQeLz4QdMILaIQKzEvEn7GUFsZgFl iavHVrCA2CwCqhJ75z8CqxcWsJK4tWcyI0S9tcSiKXNYIGwjifUXpzKD2LwCHhIXWrZALZvO KLFx1S2wkzgFAiUeXL4LtowR6Lzvp9YwQSwTl7j1ZD4TxNkCEkv2nGeGsEUlXj7+xwpRLypx p3091HH5EnMW/WGFWCYocXLmE5YJjKKzkIyahaRsFpKyWYwcQHFNifW79CFKFCWmdD9kh7A1 JFrnzGVHFl/AyL6KUTA3o9jAzCA5L1mvKDNXLy+1ZBMjONFo6O9g7NurdYhRgINRiYf3+9Yg PyHWxLLiytxDjBIczEoivPd7gEK8KYmVValF+fFFpTmpxYcYXYEhOpFZijs5H5gE80rijQ0M cHOUxHmDpQ38hATSgcktOzW1ILUIZg4TB6dUA2NbhpLYBK+AiMUsC/Z6Lp/8dKXqz6InDeIX He3MU47M0eQ4c2lfhcWTM2Eik1z2qcscbDzWx2pwOFj42b65wYtVerjrdOW1Ys5vLrDeGtSS MfmSVe3pFEt2vQKnKfeXsQVpH/TyiXdvP6aycsfLwJrEjngjm1udE3YpLwzSlp7E9O779pCV 0UosxRmJhlrMRcWJABii6l1aAwAA Cc: "hybi@ietf.org" Subject: Re: [hybi] About WebSocket extensions negotiation 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, 22 Aug 2011 20:25:27 -0000 --_000_BB31C4AB95A70042A256109D461991260ACDAAE4XCH117CNCrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 VGhlIHNlcnZlciBtYXkgbm90IGRlY2lkZSB0byBlbmFibGUgYWxsIGV4dGVuc2lvbnMgaXQg c3VwcG9ydHMgZm9yIGEgY29ubmVjdGlvbiAoZm9yIGV4YW1wbGUsIHVuZGVyIGxvYWQgaXQg bWF5IHN0b3AgYWNjZXB0aW5nIHJlcXVlc3RzIGZvciBleHRlbnNpb25zIHRoYXQgdXNlIGEg bG90IG9mIHJlc291cmNlcykuICBJbiB0aGlzIGNhc2UgaXQgbWF5IHdhbnQgdG8gdXNlIHRo ZSDigJxyZXF1aXJlZOKAnSBzdGF0dXMgdG8gbWFrZSBpdHMgZGVjaXNpb24gd2hldGhlciB0 byBzdXBwb3J0IGFuIGV4dGVuc2lvbiBvciBub3QuICjigJxUaGlzIGV4dGVuc2lvbiBpcyBw cmV0dHkgaGVhdnl3ZWlnaHQsIEnigJlsbCBvbmx5IGVuYWJsZSBpdCBpZiB5b3UgUkVBTExZ IG5lZWQgaXQu4oCdKQ0KDQpJIGRvbuKAmXQgdGhpbmsgdGhhdOKAmXMgaW1wb3J0YW50IGVu b3VnaCB0byBiZSB3b3J0aCBtYWtpbmcgYSBjaGFuZ2Ugbm93IOKAkyBqdXN0IHBvaW50aW5n IG91dCB0aGF0IHRoZSDigJxyZXF1aXJlZOKAnSBoZWFkZXIgaXNu4oCZdCB0b3RhbGx5IHdp dGhvdXQgdXRpbGl0eS4NCg0KRnJvbTogaHliaS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 aHliaS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSm9obiBUYW1wbGluDQpTZW50 OiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSAxOjAwIFBNDQpUbzogScOxYWtpIEJheiBDYXN0 aWxsbw0KQ2M6IGh5YmlAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbaHliaV0gQWJvdXQgV2Vi U29ja2V0IGV4dGVuc2lvbnMgbmVnb3RpYXRpb24NCg0KT24gTW9uLCBBdWcgMjIsIDIwMTEg YXQgMTI6MjQgUE0sIEnDsWFraSBCYXogQ2FzdGlsbG8gPGliY0BhbGlheC5uZXQ8bWFpbHRv OmliY0BhbGlheC5uZXQ+PiB3cm90ZToNClRoZSBjdXJyZW50IHdheSBvZiBuZWdvdGlhdGlu ZyBleHRlbnNpb25zIGR1cmluZyBXUyBoYW5kc2hha2Ugc3RhdGVzDQp0aGF0IHRoZSBjbGll bnQgb2ZmZXJzIHNvbWUgY2FwYWJpbGl0aWVzIGl0IGltcGxlbWVudHMgYW5kIHRoZSBzZXJ2 ZXINCmRlY2lkZXMgd2hpY2ggb25lcyB0dSB1c2Ugd2l0aGluIHRoZSBXUyBjb25uZWN0aW9u Lg0KSSBkb24ndCBsaWtlIGl0IHRvbyBtdWNoIGFzIHRoZSBjbGllbnQgY2Fubm90ICpyZXF1 aXJlKiB0aGUgdXNhZ2Ugb2YgYQ0Kc3BlY2lmaWMgZXh0ZW5zaW9uIGJ1dCBqdXN0ICJhc2sg Zm9yIGl0Ii4NCg0KVGhlIGNsaWVudCBjYW4gcmVxdWlyZSBpdCAtLSB3aGVuIGl0IGdldHMg dGhlIHJlc3BvbnNlIGJhY2sgZnJvbSB0aGUgc2VydmVyLCBpZiBpdCBkb2Vzbid0IGluY2x1 ZGUgYW55IGV4dGVuc2lvbnMgdGhhdCBpdCByZXF1aXJlcywgaXQgY2xvc2VzIHRoZSBjb25u ZWN0aW9uLg0KDQotLQ0KSm9obiBBLiBUYW1wbGluDQpTb2Z0d2FyZSBFbmdpbmVlciAoR1dU KSwgR29vZ2xlDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1 ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1h dGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3Rl ZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVn ZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2Yg dGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVj aXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNt aXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBk aXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRy YW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQg YW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== --_000_BB31C4AB95A70042A256109D461991260ACDAAE4XCH117CNCrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1l PUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVt KSI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4t VVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGUgc2VydmVyIG1h eSBub3QgZGVjaWRlIHRvIGVuYWJsZSBhbGwgZXh0ZW5zaW9ucyBpdCBzdXBwb3J0cyBmb3Ig YSBjb25uZWN0aW9uIChmb3IgZXhhbXBsZSwgdW5kZXIgbG9hZCBpdCBtYXkgc3RvcCBhY2Nl cHRpbmcgcmVxdWVzdHMgZm9yIGV4dGVuc2lvbnMgdGhhdCB1c2UgYSBsb3Qgb2YgcmVzb3Vy Y2VzKS7CoCBJbiB0aGlzIGNhc2UgaXQgbWF5IHdhbnQgdG8gdXNlIHRoZSDigJxyZXF1aXJl ZOKAnSBzdGF0dXMgdG8gbWFrZSBpdHMgZGVjaXNpb24gd2hldGhlciB0byBzdXBwb3J0IGFu IGV4dGVuc2lvbiBvciBub3QuICjigJxUaGlzIGV4dGVuc2lvbiBpcyBwcmV0dHkgaGVhdnl3 ZWlnaHQsIEnigJlsbCBvbmx5IGVuYWJsZSBpdCBpZiB5b3UgUkVBTExZIG5lZWQgaXQu4oCd KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBkb27igJl0IHRoaW5rIHRoYXTi gJlzIGltcG9ydGFudCBlbm91Z2ggdG8gYmUgd29ydGggbWFraW5nIGEgY2hhbmdlIG5vdyDi gJMganVzdCBwb2ludGluZyBvdXQgdGhhdCB0aGUg4oCccmVxdWlyZWTigJ0gaGVhZGVyIGlz buKAmXQgdG90YWxseSB3aXRob3V0IHV0aWxpdHkuPG86cD48L286cD48L3NwYW4+PC9wPjxw IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPjxkaXY+PGRpdiBz dHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4nPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiIn PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiInPiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21h aWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBU YW1wbGluPGJyPjxiPlNlbnQ6PC9iPiBNb25kYXksIEF1Z3VzdCAyMiwgMjAxMSAxOjAwIFBN PGJyPjxiPlRvOjwvYj4gScOxYWtpIEJheiBDYXN0aWxsbzxicj48Yj5DYzo8L2I+IGh5YmlA aWV0Zi5vcmc8YnI+PGI+U3ViamVjdDo8L2I+IFJlOiBbaHliaV0gQWJvdXQgV2ViU29ja2V0 IGV4dGVuc2lvbnMgbmVnb3RpYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9k aXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xh c3M9TXNvTm9ybWFsPk9uIE1vbiwgQXVnIDIyLCAyMDExIGF0IDEyOjI0IFBNLCBJw7Fha2kg QmF6IENhc3RpbGxvICZsdDs8YSBocmVmPSJtYWlsdG86aWJjQGFsaWF4Lm5ldCI+aWJjQGFs aWF4Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5UaGUgY3VycmVudCB3YXkgb2YgbmVnb3RpYXRpbmcgZXh0ZW5zaW9ucyBkdXJpbmcgV1Mg aGFuZHNoYWtlIHN0YXRlczxicj50aGF0IHRoZSBjbGllbnQgb2ZmZXJzIHNvbWUgY2FwYWJp bGl0aWVzIGl0IGltcGxlbWVudHMgYW5kIHRoZSBzZXJ2ZXI8YnI+ZGVjaWRlcyB3aGljaCBv bmVzIHR1IHVzZSB3aXRoaW4gdGhlIFdTIGNvbm5lY3Rpb24uPGJyPkkgZG9uJ3QgbGlrZSBp dCB0b28gbXVjaCBhcyB0aGUgY2xpZW50IGNhbm5vdCAqcmVxdWlyZSogdGhlIHVzYWdlIG9m IGE8YnI+c3BlY2lmaWMgZXh0ZW5zaW9uIGJ1dCBqdXN0ICZxdW90O2FzayBmb3IgaXQmcXVv dDsuPG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGNsaWVudCBjYW4g cmVxdWlyZSBpdCAtLSB3aGVuIGl0IGdldHMgdGhlIHJlc3BvbnNlIGJhY2sgZnJvbSB0aGUg c2VydmVyLCBpZiBpdCBkb2Vzbid0IGluY2x1ZGUgYW55IGV4dGVuc2lvbnMgdGhhdCBpdCBy ZXF1aXJlcywgaXQgY2xvc2VzIHRoZSBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwv ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD4tLSA8YnI+Sm9obiBBLiBUYW1wbGluPGJyPlNvZnR3 YXJlIEVuZ2luZWVyIChHV1QpLCBHb29nbGU8bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rpdj4t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkg YXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJp dmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUg c29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBj b25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZv cm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlz IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGlu IGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVs ZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0 aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lv biBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBi ZSB1bmxhd2Z1bC4NCjwvYm9keT48L2h0bWw+ --_000_BB31C4AB95A70042A256109D461991260ACDAAE4XCH117CNCrimnet_-- From sdw@lig.net Mon Aug 22 13:35: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 0DEFB21F8C66 for ; Mon, 22 Aug 2011 13:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 807he9Tg5eu8 for ; Mon, 22 Aug 2011 13:35:06 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBE521F8C46 for ; Mon, 22 Aug 2011 13:35:06 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 78E38AB5DB0 for ; Mon, 22 Aug 2011 13:46:58 -0700 (PDT) Message-ID: <4E52BDBB.8040402@lig.net> Date: Mon, 22 Aug 2011 13:36:11 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> <4E529E48.7070507@callenish.com> In-Reply-To: <4E529E48.7070507@callenish.com> Content-Type: multipart/alternative; boundary="------------050506040102060502080905" Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 20:35:07 -0000 This is a multi-part message in MIME format. --------------050506040102060502080905 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/22/11 11:22 AM, Bruce Atherton wrote: > On 22/08/2011 6:41 AM, Bob Gezelter wrote: >> However, the WebSocket protocol is not, IMHO, the correct place for that >> distinction. It is a higher-level distinction, that should be a >> "protocol" between the respective WebSockets APIs. There is no need for >> this distinction within the WebSocket protocol itself. > > But the Websocket protocol does specify the application-level protocol through the Sec-Websocket-Protocol field. The question is > what the application protocol should look like when the field is not provided. > > The Javascript layer in a browser is itself an application layer above Websockets, just one that is scriptable. It needs an > application protocol to work with. Since working within a browser is the most common usecase, it makes sense that this application > protocol should be the default one that is used when no Sec-Websocket-Protocol field is sent. Imagine if the spec made it explicit > that any browser that wanted to use a mix of binary and text messages as its application protocol had to send a > "Sec-Websocket-Protocol" header with the value "mixed-message". The default when no header is present just accomplishes the same > thing. > > This is exactly like the way that HTTP works. HTTP can be used to transfer any type of content, but you can specify the type > within the HTTP protocol by using a Content-Type header. For historical reasons, when the Content-Type is not specified the > default behaviour is typically to use heuristics to determine the actual type, but the details of this behaviour are not specified > in the HTTP protocol. Websockets, on the other hand, is specifying the default behaviour up-front. > > I think, though, that there may be value in clearly separating the default subprotocol from the rest of Websockets in the > specification to make this clearer. That way another subprotocol could reuse the opcodes differentiating binary from text with no > fear of incompatibility issues. The control opcodes, of course, are specific to the Websocket layer and remain the same across all > subprotocols, and so cannot be reused. > > So once we understand the mixed-message application protocol as one imposed by the Javascript appplication layer, the only > question is whether that is a good design for the application. I think it is desirable for all the reasons that have been listed > in these threads. I hope that we don't slip into a situation where that Javascript default subprotocol is the only one easily usable. Based on recent comments, it seems that current thinking is that Javascript+Browser automatically forces you into the "default subprotocol". There should be an option to layer application semantics on top of that, and also for a Javascript+browser application to select a different subprotocol and manage things directly. I don't see rationale for why the latter seems to not be expected to be allowed. If there are specific security concerns, I'd like to see them reiterated. sdw --------------050506040102060502080905 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/22/11 11:22 AM, Bruce Atherton wrote:
On 22/08/2011 6:41 AM, Bob Gezelter wrote:
However, the WebSocket protocol is not, IMHO, the correct place for that
distinction. It is a higher-level distinction, that should be a
"protocol" between the respective WebSockets APIs. There is no need for
this distinction within the WebSocket protocol itself.

But the Websocket protocol does specify the application-level protocol through the Sec-Websocket-Protocol field. The question is what the application protocol should look like when the field is not provided.

The Javascript layer in a browser is itself an application layer above Websockets, just one that is scriptable. It needs an application protocol to work with. Since working within a browser is the most common usecase, it makes sense that this application protocol should be the default one that is used when no Sec-Websocket-Protocol field is sent. Imagine if the spec made it explicit that any browser that wanted to use a mix of binary and text messages as its application protocol had to send a "Sec-Websocket-Protocol" header with the value "mixed-message". The default when no header is present just accomplishes the same thing.

This is exactly like the way that HTTP works. HTTP can be used to transfer any type of content, but you can specify the type within the HTTP protocol by using a Content-Type header. For historical reasons, when the Content-Type is not specified the default behaviour is typically to use heuristics to determine the actual type, but the details of this behaviour are not specified in the HTTP protocol. Websockets, on the other hand, is specifying the default behaviour up-front.

I think, though, that there may be value in clearly separating the default subprotocol from the rest of Websockets in the specification to make this clearer. That way another subprotocol could reuse the opcodes differentiating binary from text with no fear of incompatibility issues. The control opcodes, of course, are specific to the Websocket layer and remain the same across all subprotocols, and so cannot be reused.

So once we understand the mixed-message application protocol as one imposed by the Javascript appplication layer, the only question is whether that is a good design for the application. I think it is desirable for all the reasons that have been listed in these threads.

I hope that we don't slip into a situation where that Javascript default subprotocol is the only one easily usable.  Based on recent comments, it seems that current thinking is that Javascript+Browser automatically forces you into the "default subprotocol".  There should be an option to layer application semantics on top of that, and also for a Javascript+browser application to select a different subprotocol and manage things directly.  I don't see rationale for why the latter seems to not be expected to be allowed.  If there are specific security concerns, I'd like to see them reiterated.

sdw

--------------050506040102060502080905-- From sdw@lig.net Mon Aug 22 13:41: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 9A2BF21F8B31 for ; Mon, 22 Aug 2011 13:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.199 X-Spam-Level: X-Spam-Status: No, score=-2.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8co2MVPS70Q0 for ; Mon, 22 Aug 2011 13:41:07 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id EA1B521F8B8A for ; Mon, 22 Aug 2011 13:41:07 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 4D674AB5DB0; Mon, 22 Aug 2011 13:52:57 -0700 (PDT) Message-ID: <4E52BF23.9060303@lig.net> Date: Mon, 22 Aug 2011 13:42:11 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110822112430.ef1fc80126c74c6c202a919c41c7bb0b.7eef12ffb2.wbe@email03.secureserver.net> In-Reply-To: <20110822112430.ef1fc80126c74c6c202a919c41c7bb0b.7eef12ffb2.wbe@email03.secureserver.net> Content-Type: multipart/alternative; boundary="------------010204090108080001000902" Cc: Bjoern Hoehrmann , hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 20:41:08 -0000 This is a multi-part message in MIME format. --------------010204090108080001000902 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/22/11 11:24 AM, Bob Gezelter wrote: > Stephen, > > I was responding to an earlier message. > > My point was that while all UTF-8 can be sent as binary, not all binary > can be sent as UTF-8 without appropriate wrapping/encoding. > > As I have said in other postings, my strong preference is: > > - a single message type > - the protocol be defined as 8-bit transparent octets > - a trivial WSAPI-WSAPI protocol be defined that is either pure UTF-8 or > message-by-message UTF-8/binary. We should acknowledge that we're just finally reimplementing BEEP (BXXP originally) in the web world. While we're wiser now, and the current level of agreement is nicely concise, BEEP was a direct precursor to WS in some sense and might suggest some ideas or features. I would want to suggest that, regardless of the binary/text message tagging, that we strongly suggest the use of UTF-8 for text as a default. > > This little impact on performance, and has significant advantages in > clarity. While I do not have a sample WSAPI implementation handy, I do > not see how moving the "data" meaning layer up a notch has any > significant negative impact. In most cases, I would expect the impact to > be a handful of lines in WSAPI. > > - Bob Gezelter, http://www.rlgsc.com sdw --------------010204090108080001000902 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/22/11 11:24 AM, Bob Gezelter wrote: 
Stephen,

I was responding to an earlier message.

My point was that while all UTF-8 can be sent as binary, not all binary
can be sent as UTF-8 without appropriate wrapping/encoding.

As I have said in other postings, my strong preference is:

- a single message type
- the protocol be defined as 8-bit transparent octets
- a trivial WSAPI-WSAPI protocol be defined that is either pure UTF-8 or
message-by-message UTF-8/binary.

We should acknowledge that we're just finally reimplementing BEEP (BXXP originally) in the web world.  While we're wiser now, and the current level of agreement is nicely concise, BEEP was a direct precursor to WS in some sense and might suggest some ideas or features.

I would want to suggest that, regardless of the binary/text message tagging, that we strongly suggest the use of UTF-8 for text as a default.


This little impact on performance, and has significant advantages in
clarity. While I do not have a sample WSAPI implementation handy, I do
not see how moving the "data" meaning layer up a notch has any
significant negative impact. In most cases, I would expect the impact to
be a handful of lines in WSAPI.

- Bob Gezelter, http://www.rlgsc.com

sdw

--------------010204090108080001000902-- From bruce@callenish.com Mon Aug 22 14:00: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 DE56921F854D for ; Mon, 22 Aug 2011 14:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FcvswkX7ynj for ; Mon, 22 Aug 2011 14:00:34 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 64CE121F8549 for ; Mon, 22 Aug 2011 14:00:34 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.12]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qvbcp-0006hv-7w; Mon, 22 Aug 2011 14:01:39 -0700 Message-ID: <4E52C3A9.5020000@callenish.com> Date: Mon, 22 Aug 2011 14:01:29 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Stephen Williams References: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> <4E529E48.7070507@callenish.com> <4E52BDBB.8040402@lig.net> In-Reply-To: <4E52BDBB.8040402@lig.net> Content-Type: multipart/alternative; boundary="------------020906060106060704040602" 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] Binary/Text Distinction 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, 22 Aug 2011 21:00:35 -0000 This is a multi-part message in MIME format. --------------020906060106060704040602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/08/2011 1:36 PM, Stephen Williams wrote: > > I hope that we don't slip into a situation where that Javascript > default subprotocol is the only one easily usable. Based on recent > comments, it seems that current thinking is that Javascript+Browser > automatically forces you into the "default subprotocol". There should > be an option to layer application semantics on top of that, and also > for a Javascript+browser application to select a different subprotocol > and manage things directly. I don't see rationale for why the latter > seems to not be expected to be allowed. If there are specific > security concerns, I'd like to see them reiterated. Note that the Websocket API defined for browsers[1] allows specifying a list of subprotocols. It is just that there are no other subprotocols defined within the Javascript layer, so these subprotocols would be ones layered on top of the Javascript-specific subprotocol. Perhaps someday browsers will have standard plugin APIs for defining Websocket extensions and subprotocols, or ones will become so common that the vendors will incorporate them directly. Time will tell. [1] http://dev.w3.org/html5/websockets/ --------------020906060106060704040602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/08/2011 1:36 PM, Stephen Williams wrote:

I hope that we don't slip into a situation where that Javascript default subprotocol is the only one easily usable.  Based on recent comments, it seems that current thinking is that Javascript+Browser automatically forces you into the "default subprotocol".  There should be an option to layer application semantics on top of that, and also for a Javascript+browser application to select a different subprotocol and manage things directly.  I don't see rationale for why the latter seems to not be expected to be allowed.  If there are specific security concerns, I'd like to see them reiterated.

Note that the Websocket API defined for browsers[1] allows specifying a list of subprotocols. It is just that there are no other subprotocols defined within the Javascript layer, so these subprotocols would be ones layered on top of the Javascript-specific subprotocol.

Perhaps someday browsers will have standard plugin APIs for defining Websocket extensions and subprotocols, or ones will become so common that the vendors will incorporate them directly. Time will tell.

[1] http://dev.w3.org/html5/websockets/
--------------020906060106060704040602-- From gezelter@rlgsc.com Mon Aug 22 14:02: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 6B2D721F85B8 for ; Mon, 22 Aug 2011 14:02:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6jAFVi98a-8 for ; Mon, 22 Aug 2011 14:02:57 -0700 (PDT) Received: from smtpoutwbe05.prod.mesa1.secureserver.net (smtpoutwbe05.prod.mesa1.secureserver.net [208.109.78.207]) by ietfa.amsl.com (Postfix) with SMTP id AB67021F8591 for ; Mon, 22 Aug 2011 14:02:57 -0700 (PDT) Received: (qmail 9039 invoked from network); 22 Aug 2011 21:04:02 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe05.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 21:04:02 -0000 Received: (qmail 5110 invoked by uid 99); 22 Aug 2011 21:04:02 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822140401.ef1fc80126c74c6c202a919c41c7bb0b.23bf00817e.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Stephen Williams" Date: Mon, 22 Aug 2011 14:04:01 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 21:02:58 -0000 Stephen,=0A=0A=0A=0A> -------- Original Message --------=0A> Subject: Re: B= inary/Text Distinction (Hybi Volume 30, Number 63, et al)=0A> From: Stephen= Williams =0A> Date: Mon, August 22, 2011 1:42 pm=0A> To: Bob = Gezelter =0A> Cc: hybi@ietf.org, bruce@callenish.com, J= ohn Tamplin , =0A> tyoshino@google.com, Bjoern Hoehrmann =0A> =0A> =0A> On 8/22/11 11:24 AM, Bob Gezelter wrote:=0A= > > Stephen,=0A> >=0A> > I was responding to an earlier message.=0A> >=0A> = > My point was that while all UTF-8 can be sent as binary, not all binary= =0A> > can be sent as UTF-8 without appropriate wrapping/encoding.=0A> >=0A= > > As I have said in other postings, my strong preference is:=0A> >=0A> > = - a single message type=0A> > - the protocol be defined as 8-bit transparen= t octets=0A> > - a trivial WSAPI-WSAPI protocol be defined that is either p= ure UTF-8 or=0A> > message-by-message UTF-8/binary.=0A> =0A> We should ackn= owledge that we're just finally reimplementing BEEP (BXXP originally) in th= e web world. While we're wiser now, and =0A> the current level of agreemen= t is nicely concise, BEEP was a direct precursor to WS in some sense and mi= ght suggest some ideas or =0A> features.=0A> =0A> I would want to suggest t= hat, regardless of the binary/text message tagging, that we strongly sugges= t the use of UTF-8 for text as a =0A> default.=0A> =0A=0AStephen,=0A=0AI fi= nd the use of UTF-8 for text strings appropriate. It is the=0Adistinction b= etween text/binary within message payloads at the WebSocket=0Aprotocol leve= l suboptimal.=0A=0AThe past days of arbitrating character and format transf= ormations at one=0A(or both) ends of a connection are certainly not fond me= mories.=0A=0AThat said, the need for that syntactic limit is one level high= er than=0Athe WebSocket protocol. The WebSocket protocol is implementing tw= o=0Alevels in the protocol stack, and we all too well know from Internet=0A= history that such mixing of functions often leads us into a deep swamp. =0A= =0AThe WebSocket protocol is best described as a transport protocol, albeit= =0Aone layered on top of another transport protocol (at the moment TCP, but= =0Athe linkage to TCP is tenuous, to say the least -- any sequential,=0Aess= entially error-free pipe/message protocol would serve). =0A=0AThe actual WS= API/WSAPI negotiation of character/binary should be left at=0Athat level. F= or that matter, providing intermixed binary/text messages=0Ahas hazards in = and of itself. =0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From sdw@lig.net Mon Aug 22 14: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 0E55F21F8C4F for ; Mon, 22 Aug 2011 14:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.349, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEHrA9TrIDuq for ; Mon, 22 Aug 2011 14:29:25 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id 6CEEF21F8C4D for ; Mon, 22 Aug 2011 14:29:24 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id 95A33AB5DB0; Mon, 22 Aug 2011 14:41:16 -0700 (PDT) Message-ID: <4E52CA77.3010305@lig.net> Date: Mon, 22 Aug 2011 14:30:31 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Bruce Atherton References: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> <4E529E48.7070507@callenish.com> <4E52BDBB.8040402@lig.net> <4E52C3A9.5020000@callenish.com> In-Reply-To: <4E52C3A9.5020000@callenish.com> Content-Type: multipart/alternative; boundary="------------030603050707070702010800" Cc: hybi@ietf.org Subject: Re: [hybi] Binary/Text Distinction 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, 22 Aug 2011 21:29:26 -0000 This is a multi-part message in MIME format. --------------030603050707070702010800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 8/22/11 2:01 PM, Bruce Atherton wrote: > On 22/08/2011 1:36 PM, Stephen Williams wrote: >> >> I hope that we don't slip into a situation where that Javascript default subprotocol is the only one easily usable. Based on >> recent comments, it seems that current thinking is that Javascript+Browser automatically forces you into the "default >> subprotocol". There should be an option to layer application semantics on top of that, and also for a Javascript+browser >> application to select a different subprotocol and manage things directly. I don't see rationale for why the latter seems to not >> be expected to be allowed. If there are specific security concerns, I'd like to see them reiterated. > > Note that the Websocket API defined for browsers[1] allows specifying a list of subprotocols. It is just that there are no other > subprotocols defined within the Javascript layer, so these subprotocols would be ones layered on top of the Javascript-specific > subprotocol. Why on top of the "Javascript-specific subprotocol"? While it is easy to see why it should be friendly to Javascript, it doesn't seem right to aim for "Javascript-specific". I can see that "WS default subprotocol" being equivalent to HTTP/HTTPS in a browser. (BTW, I'd argue for TLS-only operation at this point. You can always get plain text for debugging via a man in the middle debugging proxy.) However, outside of the lowest level of the protocol, and maintain security basics (only connecting back to origin server / path), it seems possible to support different base subprotocols. At the API level, simply have Javascript callbacks or similar as needed. The setup/teardown and basic control messages can be fixed while allowing freedom in the rest of the details. While this can be layered, the current stance is likely to result in everything useful being layered over a single default subprotocol simply to allow servers to have the same view of all clients, Javascript web browsers or not. > > Perhaps someday browsers will have standard plugin APIs for defining Websocket extensions and subprotocols, or ones will become so > common that the vendors will incorporate them directly. Time will tell. > > [1] http://dev.w3.org/html5/websockets/ sdw --------------030603050707070702010800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 8/22/11 2:01 PM, Bruce Atherton wrote:
On 22/08/2011 1:36 PM, Stephen Williams wrote:

I hope that we don't slip into a situation where that Javascript default subprotocol is the only one easily usable.  Based on recent comments, it seems that current thinking is that Javascript+Browser automatically forces you into the "default subprotocol".  There should be an option to layer application semantics on top of that, and also for a Javascript+browser application to select a different subprotocol and manage things directly.  I don't see rationale for why the latter seems to not be expected to be allowed.  If there are specific security concerns, I'd like to see them reiterated.

Note that the Websocket API defined for browsers[1] allows specifying a list of subprotocols. It is just that there are no other subprotocols defined within the Javascript layer, so these subprotocols would be ones layered on top of the Javascript-specific subprotocol.

Why on top of the "Javascript-specific subprotocol"?  While it is easy to see why it should be friendly to Javascript, it doesn't seem right to aim for "Javascript-specific".

I can see that "WS default subprotocol" being equivalent to HTTP/HTTPS in a browser.  (BTW, I'd argue for TLS-only operation at this point.  You can always get plain text for debugging via a man in the middle debugging proxy.)  However, outside of the lowest level of the protocol, and maintain security basics (only connecting back to origin server / path), it seems possible to support different base subprotocols.  At the API level, simply have Javascript callbacks or similar as needed.  The setup/teardown and basic control messages can be fixed while allowing freedom in the rest of the details.

While this can be layered, the current stance is likely to result in everything useful being layered over a single default subprotocol simply to allow servers to have the same view of all clients, Javascript web browsers or not.


Perhaps someday browsers will have standard plugin APIs for defining Websocket extensions and subprotocols, or ones will become so common that the vendors will incorporate them directly. Time will tell.

[1] http://dev.w3.org/html5/websockets/


sdw

--------------030603050707070702010800-- From sdw@lig.net Mon Aug 22 14:34: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 2214721F8C5D for ; Mon, 22 Aug 2011 14:34:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzqydbTT+e2A for ; Mon, 22 Aug 2011 14:34:50 -0700 (PDT) Received: from mail.lig.net (lig.net [64.69.38.223]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF1B21F8C5C for ; Mon, 22 Aug 2011 14:34:50 -0700 (PDT) Received: from sdwmbp-043135148081.am.sony.com (unknown [157.238.217.59]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: sdw) by mail.lig.net (Postfix) with ESMTP id A95F4AB5DB0; Mon, 22 Aug 2011 14:46:41 -0700 (PDT) Message-ID: <4E52CBBD.2010809@lig.net> Date: Mon, 22 Aug 2011 14:35:57 -0700 From: Stephen Williams Organization: OptimaLogic, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110822140401.ef1fc80126c74c6c202a919c41c7bb0b.23bf00817e.wbe@email03.secureserver.net> In-Reply-To: <20110822140401.ef1fc80126c74c6c202a919c41c7bb0b.23bf00817e.wbe@email03.secureserver.net> Content-Type: multipart/alternative; boundary="------------020605070305060708060104" Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 21:34:51 -0000 This is a multi-part message in MIME format. --------------020605070305060708060104 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 8/22/11 2:04 PM, Bob Gezelter wrote: > Stephen, > > > >> -------- Original Message -------- >> Subject: Re: Binary/Text Distinction (Hybi Volume 30, Number 63, et al) >> From: Stephen Williams >> ... >> We should acknowledge that we're just finally reimplementing BEEP (BXXP originally) in the web world. While we're wiser now, and >> the current level of agreement is nicely concise, BEEP was a direct precursor to WS in some sense and might suggest some ideas or >> features. >> >> I would want to suggest that, regardless of the binary/text message tagging, that we strongly suggest the use of UTF-8 for text as a >> default. >> > Stephen, > > I find the use of UTF-8 for text strings appropriate. It is the > distinction between text/binary within message payloads at the WebSocket > protocol level suboptimal. > > The past days of arbitrating character and format transformations at one > (or both) ends of a connection are certainly not fond memories. > > That said, the need for that syntactic limit is one level higher than > the WebSocket protocol. The WebSocket protocol is implementing two > levels in the protocol stack, and we all too well know from Internet > history that such mixing of functions often leads us into a deep swamp. Well.... TCP/IP and the IETF Internet stack in general mix and merge and bridge levels as far as the ISO OSI stack are concerned. And that is a very good thing. While OSI was elegant, although redudant in some ways, to describe, it was suboptimal in many ways. So, I would take the lesson from Internet history that careful analysis and optimization hacking cyccles often leads to a more nuanced and effective design. OSI is more of a guideline. ;-) > > The WebSocket protocol is best described as a transport protocol, albeit > one layered on top of another transport protocol (at the moment TCP, but > the linkage to TCP is tenuous, to say the least -- any sequential, > essentially error-free pipe/message protocol would serve). > > The actual WSAPI/WSAPI negotiation of character/binary should be left at > that level. For that matter, providing intermixed binary/text messages > has hazards in and of itself. > > - Bob Gezelter, http://www.rlgsc.com > sdw -- Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com --------------020605070305060708060104 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 8/22/11 2:04 PM, Bob Gezelter wrote: 
Stephen,




-------- Original Message --------
Subject: Re: Binary/Text Distinction (Hybi Volume 30, Number 63, et al)
From: Stephen Williams <sdw@lig.net>
...
We should acknowledge that we're just finally reimplementing BEEP (BXXP originally) in the web world.  While we're wiser now, and 
the current level of agreement is nicely concise, BEEP was a direct precursor to WS in some sense and might suggest some ideas or 
features.

I would want to suggest that, regardless of the binary/text message tagging, that we strongly suggest the use of UTF-8 for text as a 
default.


Stephen,

I find the use of UTF-8 for text strings appropriate. It is the
distinction between text/binary within message payloads at the WebSocket
protocol level suboptimal.

The past days of arbitrating character and format transformations at one
(or both) ends of a connection are certainly not fond memories.

That said, the need for that syntactic limit is one level higher than
the WebSocket protocol. The WebSocket protocol is implementing two
levels in the protocol stack, and we all too well know from Internet
history that such mixing of functions often leads us into a deep swamp.

Well....  TCP/IP and the IETF Internet stack in general mix and merge and bridge levels as far as the ISO OSI stack are concerned.  And that is a very good thing.  While OSI was elegant, although redudant in some ways, to describe, it was suboptimal in many ways.  So, I would take the lesson from Internet history that careful analysis and optimization hacking cyccles often leads to a more nuanced and effective design.  OSI is more of a guideline.  ;-)


The WebSocket protocol is best described as a transport protocol, albeit
one layered on top of another transport protocol (at the moment TCP, but
the linkage to TCP is tenuous, to say the least -- any sequential,
essentially error-free pipe/message protocol would serve). 

The actual WSAPI/WSAPI negotiation of character/binary should be left at
that level. For that matter, providing intermixed binary/text messages
has hazards in and of itself. 

- Bob Gezelter, http://www.rlgsc.com

sdw
--
Stephen D. Williams sdw@lig.net stephendwilliams@gmail.com

--------------020605070305060708060104-- From gezelter@rlgsc.com Mon Aug 22 14:56: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 1B14F21F8CA7 for ; Mon, 22 Aug 2011 14:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRzMmSh4v-rS for ; Mon, 22 Aug 2011 14:56:14 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 687D921F8C9F for ; Mon, 22 Aug 2011 14:56:14 -0700 (PDT) Received: (qmail 9784 invoked from network); 22 Aug 2011 21:57:19 -0000 Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 21:57:19 -0000 Received: (qmail 11926 invoked by uid 99); 22 Aug 2011 21:57:19 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822145718.ef1fc80126c74c6c202a919c41c7bb0b.fcbd3eb88b.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Stephen Williams" Date: Mon, 22 Aug 2011 14:57:18 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 21:56:15 -0000 Stephen,=0A=0AI would agree with you in regards to the OSI model. It was a = VERY=0A(emphasis: VERY) bloated specification, and was not a good example t= o=0Aemulate. =0A=0AHowever, I was not referring to the OSI stack in terms o= f the OSI=0Aprotocol specifications. I was referring to the Open Systems=0A= Interconnect Model (which long predates the standards).=0A=0AThere are many= cases where TCP/IP took good choices, and there are more=0Athan a few plac= es where the choices have proven suboptimal (e.g.,=0Asecurity). The consequ= ences of these choices remain with us today. =0A=0ARemoving the character e= ncoding issue from the WebSocket protocol to a=0Aseparate small application= s protocol for use between two WSAPI=0Ainstantiations over a WebSocket mess= aging connection would clarify the=0Aprotocol without costing efficiency.= =0A=0AIt also allows the inter-WSAPI interchange to evolve without a need t= o=0Achange the WebSocket protocol implementation or RFC, which is another= =0Ahighly desirable result.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A From bruce@callenish.com Mon Aug 22 15:06: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 8CE2421F854F for ; Mon, 22 Aug 2011 15:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOTew4s7WRGf for ; Mon, 22 Aug 2011 15:06:29 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id A059A21F899F for ; Mon, 22 Aug 2011 15:06:29 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.12]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qvcec-000777-Ht; Mon, 22 Aug 2011 15:07:34 -0700 Message-ID: <4E52D31D.1070105@callenish.com> Date: Mon, 22 Aug 2011 15:07:25 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Stephen Williams References: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> <4E529E48.7070507@callenish.com> <4E52BDBB.8040402@lig.net> <4E52C3A9.5020000@callenish.com> <4E52CA77.3010305@lig.net> In-Reply-To: <4E52CA77.3010305@lig.net> Content-Type: multipart/alternative; boundary="------------030207020001060704060605" 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] Binary/Text Distinction 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, 22 Aug 2011 22:06:31 -0000 This is a multi-part message in MIME format. --------------030207020001060704060605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 22/08/2011 2:30 PM, Stephen Williams wrote: > On 8/22/11 2:01 PM, Bruce Atherton wrote: >> >> Note that the Websocket API defined for browsers[1] allows specifying >> a list of subprotocols. It is just that there are no other >> subprotocols defined within the Javascript layer, so these >> subprotocols would be ones layered on top of the Javascript-specific >> subprotocol. > > Why on top of the "Javascript-specific subprotocol"? While it is easy > to see why it should be friendly to Javascript, it doesn't seem right > to aim for "Javascript-specific". Because we are talking about clients in the browser that have to be written in Javascript. That means that the protocol must first pass through the forms required by the Javascript layer. That means DOMString, Blob, or ArrayBuffer. So the UTF8/binary distinction in the Javascript layer of the subprotocol makes a lot of sense, at least until there is a Plugin subprotocol in the browser that allows the Javascript layer to be bypassed for something more specific. For clients not in the browser, then there is no need to have the subprotocol deal with a divide between binary and text, it can be completely controlled by the application. > > ... it seems possible to support different base subprotocols. At the > API level, simply have Javascript callbacks or similar as needed. The > setup/teardown and basic control messages can be fixed while allowing > freedom in the rest of the details. I'm not sure how this would work, but it seems like something to bring up on the W3 HTML5 list, not here. --------------030207020001060704060605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 22/08/2011 2:30 PM, Stephen Williams wrote:
On 8/22/11 2:01 PM, Bruce Atherton wrote:

Note that the Websocket API defined for browsers[1] allows specifying a list of subprotocols. It is just that there are no other subprotocols defined within the Javascript layer, so these subprotocols would be ones layered on top of the Javascript-specific subprotocol.

Why on top of the "Javascript-specific subprotocol"?  While it is easy to see why it should be friendly to Javascript, it doesn't seem right to aim for "Javascript-specific".

Because we are talking about clients in the browser that have to be written in Javascript. That means that the protocol must first pass through the forms required by the Javascript layer. That means DOMString, Blob, or ArrayBuffer. So the UTF8/binary distinction in the Javascript layer of the subprotocol makes a lot of sense, at least until there is a Plugin subprotocol in the browser that allows the Javascript layer to be bypassed for something more specific.

For clients not in the browser, then there is no need to have the subprotocol deal with a divide between binary and text, it can be completely controlled by the application.


... it seems possible to support different base subprotocols.  At the API level, simply have Javascript callbacks or similar as needed.  The setup/teardown and basic control messages can be fixed while allowing freedom in the rest of the details.

I'm not sure how this would work, but it seems like something to bring up on the W3 HTML5 list, not here.

--------------030207020001060704060605-- From jat@google.com Mon Aug 22 15:42: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 D3D4121F886D for ; Mon, 22 Aug 2011 15:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.922 X-Spam-Level: X-Spam-Status: No, score=-105.922 tagged_above=-999 required=5 tests=[AWL=0.054, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq5FuUWj8K5P for ; Mon, 22 Aug 2011 15:42: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 A8D3221F87FC for ; Mon, 22 Aug 2011 15:42:23 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p7MMhJrw016683 for ; Mon, 22 Aug 2011 15:43:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314053004; bh=WxlQekzvTmusN6oYANNh0NZ/Wh0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=hgePHlXTm/6iBP0UM4JBjZ0ig5SoHPmTAD532HKn6UwXeGDOfAJ8jF12vumUrwQxa 2eBwKstZyZGA56O5IRfEA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=tbgMkyDkKxAmv9+Y0WmXe7q8gJX6D3MUWt8vnO7WhjX65SrWmcLVrEhxFVzd0BVfb ulQBeHlPK8btDsMzbkquw== Received: from qwb8 (qwb8.prod.google.com [10.241.193.72]) by hpaq2.eem.corp.google.com with ESMTP id p7MMfQUx021205 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 22 Aug 2011 15:43:18 -0700 Received: by qwb8 with SMTP id 8so5649088qwb.39 for ; Mon, 22 Aug 2011 15:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7Up2QRGF8ZGh6wGMcQlgN8WAqczGgUEkHCZABGIklBM=; b=yMYRs0MMNTSrT/6TOEhKXWvM/8glEaghSrAyrYg1lisveFthj+ZSv1V1D5u5iBrxQo 1LX9Bv2EJ0NQjP05upnA== Received: by 10.229.188.9 with SMTP id cy9mr1764719qcb.37.1314052998312; Mon, 22 Aug 2011 15:43:18 -0700 (PDT) Received: by 10.229.188.9 with SMTP id cy9mr1764707qcb.37.1314052998128; Mon, 22 Aug 2011 15:43:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.137 with HTTP; Mon, 22 Aug 2011 15:42:58 -0700 (PDT) In-Reply-To: <20110822145718.ef1fc80126c74c6c202a919c41c7bb0b.fcbd3eb88b.wbe@email03.secureserver.net> References: <20110822145718.ef1fc80126c74c6c202a919c41c7bb0b.fcbd3eb88b.wbe@email03.secureserver.net> From: John Tamplin Date: Mon, 22 Aug 2011 18:42:58 -0400 Message-ID: To: Bob Gezelter Content-Type: multipart/alternative; boundary=0016361e7e002b642d04ab1fce6c X-System-Of-Record: true Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 22:42:24 -0000 --0016361e7e002b642d04ab1fce6c Content-Type: text/plain; charset=UTF-8 On Mon, Aug 22, 2011 at 5:57 PM, Bob Gezelter wrote: > Removing the character encoding issue from the WebSocket protocol to a > separate small applications protocol for use between two WSAPI > instantiations over a WebSocket messaging connection would clarify the > protocol without costing efficiency. > All I see it would do is mean the protocol isn't actually useful for its intended purpose until an additional standard were agreed upon and implemented. As this one has taken years, let's not double the time until we can use it. -- John A. Tamplin Software Engineer (GWT), Google --0016361e7e002b642d04ab1fce6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 5:57 PM, Bob Gezelter <gezelter@rlgsc.co= m> wrote:
Removing the character encoding issue from the WebSocket protocol to a
separate small applications protocol for use between two WSAPI
instantiations over a WebSocket messaging connection would clarify the
protocol without costing efficiency.

A= ll I see it would do is mean the protocol isn't actually useful for its= intended purpose until an additional standard were agreed upon and impleme= nted. =C2=A0As this one has taken years, let's not double the time unti= l we can use it.

--
John A. Tamplin
Software Engineer (GWT), Google --0016361e7e002b642d04ab1fce6c-- From gezelter@rlgsc.com Mon Aug 22 16:06: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 853DE21F8BD5 for ; Mon, 22 Aug 2011 16:06:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5eqFLSV6Fiu for ; Mon, 22 Aug 2011 16:06:23 -0700 (PDT) Received: from smtpoutwbe01.prod.mesa1.secureserver.net (smtpoutwbe01.prod.mesa1.secureserver.net [208.109.78.112]) by ietfa.amsl.com (Postfix) with SMTP id 9FB8321F8BBE for ; Mon, 22 Aug 2011 16:06:19 -0700 (PDT) Received: (qmail 29318 invoked from network); 22 Aug 2011 23:07:25 -0000 Received: from unknown (HELO localhost) (72.167.218.131) by smtpoutwbe01.prod.mesa1.secureserver.net with SMTP; 22 Aug 2011 23:07:25 -0000 Received: (qmail 9262 invoked by uid 99); 22 Aug 2011 23:07:25 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110822160723.ef1fc80126c74c6c202a919c41c7bb0b.a48039c30a.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "John Tamplin" Date: Mon, 22 Aug 2011 16:07:23 -0700 Mime-Version: 1.0 Cc: hybi@ietf.org, Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 23:06:24 -0000 John,=0A=0AWhile it has been a long time to get to this point, I seriously = doubt=0Athat splitting the binary/text portion into a separate document wil= l=0Atake "years".=0A=0ASince you enunciated the case for interspersed text/= binary messages,=0Apresumably the present WSAPI-WSAPI capabilities are, in = your view,=0Acompletely adequate.=0A=0AWhat is needed is for the relevant m= aterial to be excised from the=0AWebSocket protocol specification proper an= d formatted as a separate=0Adocument. The underlying WebSocket protocol spe= cification will, of=0Acourse, be cited as the underlying framework.=0A=0AAt= that point the separate message codes (binary/text) and various=0Acomments= about text messages limited to UTF-8 can be exised from the=0AWebSocket pr= otocol specification.=0A=0AVirtually all of the required material is alread= y extant, it is mostly a=0Aquestion of segregating the separate pieces.=0A= =0A- Bob Gezelter, http://www.rlgsc.com=0A=0A=0A> -------- Original Message= --------=0A> Subject: Re: Binary/Text Distinction (Hybi Volume 30, Number = 63, et al)=0A> From: John Tamplin =0A> Date: Mon, August 22= , 2011 3:42 pm=0A> To: Bob Gezelter =0A> Cc: Stephen Wi= lliams , hybi@ietf.org, bruce@callenish.com,=0A> tyoshi= no@google.com, Bjoern Hoehrmann , =0A> I=C3=B1aki_= Baz_Castillo =0A> =0A> =0A> On Mon, Aug 22, 2011 at 5:57 PM,= Bob Gezelter wrote:=0A> =0A> > Removing the character= encoding issue from the WebSocket protocol to a=0A> > separate small appli= cations protocol for use between two WSAPI=0A> > instantiations over a WebS= ocket messaging connection would clarify the=0A> > protocol without costing= efficiency.=0A> >=0A> =0A> All I see it would do is mean the protocol isn'= t actually useful for its=0A> intended purpose until an additional standard= were agreed upon and=0A> implemented. As this one has taken years, let's = not double the time until=0A> we can use it.=0A> =0A> -- =0A> John A. Tampl= in=0A> Software Engineer (GWT), Google=0A From tobias.oberstein@tavendo.de Mon Aug 22 16:46: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 9485B21F8B92 for ; Mon, 22 Aug 2011 16:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CE1gex3Mvmyj for ; Mon, 22 Aug 2011 16:46:28 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id F17C021F8BD7 for ; Mon, 22 Aug 2011 16:46:27 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Mon, 22 Aug 2011 16:47:33 -0700 From: Tobias Oberstein To: John Tamplin , Bob Gezelter Date: Mon, 22 Aug 2011 16:47:32 -0700 Thread-Topic: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) Thread-Index: AcxhHO94EiqsuBGNSX+5/vG+FJ6tmgACOyM6 Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 22 Aug 2011 23:46:28 -0000 On 23.08.11 00:42, "John Tamplin" wrote: > On Mon, Aug 22, 2011 at 5:57 PM, Bob Gezelter wrote: >> Removing the character encoding issue from the WebSocket protocol to a >> separate small applications protocol for use between two WSAPI >> instantiations over a WebSocket messaging connection would clarify the >> protocol without costing efficiency. Bob, There is no "issue". An issue is a problem, and there is none. The term "character" is ill-defined. In the context of Unicode there are code points and encodings thereof. UTF-8 is well-defined, so here is no issue. So I assume that what you wanted to say is like in your earlier remarks, namely that the "issue" that you are trying to evoke is about having 2 opcodes which differentiate payload types into text/binary. However, the reasoning: WS is a transport protocol, and thus should not include payload types is not pointing to a practical problem with WS. Where is the practical problem? What does not work with WS today, because it has opcodes designating payloads into text or binary? >=20 > All I see it would do is mean the protocol isn't actually useful for its > intended purpose until an additional standard were agreed upon and > implemented. =A0As this one has taken years, let's not double the time un= til we > can use it. ++1 John Please don't open the pandora's box. Over the weekend I started playing with FF8 on Android talking to our servers and PC all via WS + HTML5. It's awesome, it works - today! Bob, now, you tell me you want to take that away/break again for months-years to come, because you find it "unclean" to have that payload type stuff in WS. Well. That's a tough call ... From theturtle32@gmail.com Mon Aug 22 21:56: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 86B4721F8B17 for ; Mon, 22 Aug 2011 21:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.479 X-Spam-Level: X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.119, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygtV-ZflxT6F for ; Mon, 22 Aug 2011 21:56:17 -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 BC6D821F8B08 for ; Mon, 22 Aug 2011 21:56:16 -0700 (PDT) Received: by bkar4 with SMTP id r4so5047917bka.31 for ; Mon, 22 Aug 2011 21:57:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RLFEs6TVkJr5mR3HRWnwgHQuYdAriIKmlPSllvTgpZU=; b=tnBanjsREq6SAVrx0FQ86Y0e+ouzT4MytCK42Wnsuf0SXUfN3xuznjzXcPkK3HUbNF lpQ6iuw3vuuG+TnxXkCpFW4OdayxeL3PzCOb6MaCnK3jXqO96BpeiZIY50wb9jeCSKjq 5MpQ0yCDT9hg1BcjpmH0k1SqlPrRLPLGNu2kQ= MIME-Version: 1.0 Received: by 10.204.157.144 with SMTP id b16mr1378399bkx.396.1314075442563; Mon, 22 Aug 2011 21:57:22 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Mon, 22 Aug 2011 21:57:22 -0700 (PDT) In-Reply-To: <4E529E48.7070507@callenish.com> References: <20110822064154.ef1fc80126c74c6c202a919c41c7bb0b.4130feb3cc.wbe@email03.secureserver.net> <4E529E48.7070507@callenish.com> Date: Mon, 22 Aug 2011 21:57:22 -0700 Message-ID: From: Brian To: Bruce Atherton Content-Type: multipart/alternative; boundary=0015175cd0daf64b1204ab2507ca Cc: hybi@ietf.org, Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 04:56:17 -0000 --0015175cd0daf64b1204ab2507ca Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 22, 2011 at 11:22 AM, Bruce Atherton wrote: > I think, though, that there may be value in clearly separating the default > subprotocol from the rest of Websockets in the specification to make this > clearer. That way another subprotocol could reuse the opcodes > differentiating binary from text with no fear of incompatibility issues. The > control opcodes, of course, are specific to the Websocket layer and remain > the same across all subprotocols, and so cannot be reused. > To be clear.. a "subprotocol" as defined in the spec has absolutely nothing whatsoever to do with frame types, opcodes, message types, binary vs text, or any of that. It represents an agreement between the client and server regarding what *content* to send in the binary or text messages (or combination) that is provided by the base protocol, and how to interpret that content. Examples of "subprotocols" are things like "SuperChat", "MyRealTimeGameProtocol", "SharedWhiteboard" etc. It's layered on top of the messaging semantics. Lets stop using the word "subprotocol" to mean something else -- it's confusing. There is no "default subprotocol," and a subprotocol cannot define new types of messages. It can use the existing text and binary message types only. Brian --0015175cd0daf64b1204ab2507ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Aug 22, 2011 at 11:22 AM, Bruce Atherton= <bruce@calleni= sh.com> wrote:
I think, though, that there may be value in clearly separ= ating the default subprotocol from the rest of Websockets in the specificat= ion to make this clearer. That way another subprotocol could reuse the opco= des differentiating binary from text with no fear of incompatibility issues= . The control opcodes, of course, are specific to the Websocket layer and r= emain the same across all subprotocols, and so cannot be reused.

To be clear.. a "subprotocol" as defi= ned in the spec has absolutely nothing whatsoever to do with frame types, o= pcodes, message types, binary vs text, or any of that. =A0It represents an = agreement between the client and server regarding what *content* to send in= the binary or text messages (or combination) that is provided by the base = protocol, and how to interpret that content. =A0Examples of "subprotoc= ols" are things like "SuperChat", "MyRealTimeGameProtoc= ol", "SharedWhiteboard" etc. =A0It's layered on top of t= he messaging semantics. =A0Lets stop using the word "subprotocol"= to mean something else -- it's confusing. =A0There is no "default= subprotocol," and a subprotocol cannot define new types of messages. = =A0It can use the existing text and binary message types only.

Brian

--0015175cd0daf64b1204ab2507ca-- From theturtle32@gmail.com Mon Aug 22 22:18: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 A614B21F8B3D for ; Mon, 22 Aug 2011 22:18:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.494 X-Spam-Level: X-Spam-Status: No, score=-3.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKPqkxFxA4EC for ; Mon, 22 Aug 2011 22:18:53 -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 36AFA21F8B3A for ; Mon, 22 Aug 2011 22:18:53 -0700 (PDT) Received: by bkar4 with SMTP id r4so5059244bka.31 for ; Mon, 22 Aug 2011 22:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MVt7py51WrdmZ7oW8i93Gf50UEcSIDeUTdqmhv7yT7o=; b=I2m/Nn6Lz9oGBopI0F8uB6rRy5yTnUjW+eRDq0DWOD1WxFCRAARN8ohe5O48tyZfFd lIJ+Q3gIfMkh29nrrk4gEQOhsD+ZRMmtTDkO0T4PEfh99PUafz9csoEaBxw7u0RMwxUV WQRj89KqTuBHKDavkGjy8C6mYP8y/KuoHujKc= MIME-Version: 1.0 Received: by 10.204.7.75 with SMTP id c11mr61940bkc.32.1314076799303; Mon, 22 Aug 2011 22:19:59 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Mon, 22 Aug 2011 22:19:59 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 22 Aug 2011 22:19:59 -0700 Message-ID: From: Brian To: Tobias Oberstein Content-Type: multipart/alternative; boundary=001517588ca8d480ab04ab2558a2 Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 05:18:54 -0000 --001517588ca8d480ab04ab2558a2 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 22, 2011 at 7:16 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Honestly, I see WS as a _pragmatic_ effort to bring the web to the next > level. > > If it helps with that goal to have text/binary payload type distinction in > the WS protocol, I am fine with that, > even if that is somehow unclean from an idealistic protocol design view (to > which I agree). Yes. This is *exactly* the purpose of WebSockets. And having the type distinction will be of *extremely* high value to JavaScript developers. Existing non-browser applications have TCP at their disposal directly and can use it how they see fit. The entire purpose for the WebSockets protocol from the beginning was explicitly to allow *browsers* to use a real-time bidirectional socket connection in a JavaScript environment. That was and is the *whole point* of this protocol. Period. End of story. Other non-browser applications can and will find good uses for this protocol, but that's all gravy. This WG has gone out of its way to make the protocol flexible enough to allow for such uses, and for future enhancements in browser capabilities, to the benefit of everyone. Adding binary support in the first place is a good example of this -- recall that draft-00 is a text-only protocol! But I tell you that removing text frames will not be to the benefit of anyone. It would be way beyond absurd to put utf-8 parsing into the application layer of a JavaScript app. It would only be barely tolerable if the browsers started providing a native function that could internally convert UTF-8 out of a slice of binary data - such a function does not yet exist - but would cause JavaScript developers to have to think about how to work with binary data. The original goal of the WebSocket protocol was to be dead simple for inexperienced implementers to trivially build WebSocket servers. We've (I think rightly) deviated some from that goal, but it is still crucial to make it brain-dead simple for an inexperienced client-side developer to use the JavaScript API. Forcing these developers to think about parsing binary data structures is setting the bar too high. Working with binary formats is old hat to many of us here, but remember that there are a lot of programmers out there who have effectively no knowledge of binary data representations and may never need to throughout their entire career. Especially programmers doing front-end web development. Given its intended purpose, I think the WebSocket protocol rightly straddles the line between a transport protocol and an application protocol. In some ways, it's an application protocol which is intended to have yet another application protocol (the subprotocol) layered on top of it, but its primary function is to transport data. I don't think it can or should commit to being on only one of those conceptual layers. For someone already implementing the WebSocket protocol and its binary frames, it also certainly isn't any more difficult to add support for the text frame data type. I really am actually rather flabbergasted that anyone is even entertaining the idea of removing the text frames. Brian McKelvey https://github.com/Worlize/WebSocket-Node --001517588ca8d480ab04ab2558a2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Aug 22, 2011 at 7:16 AM, Tobias Oberstein <tobias.oberstein@tavendo.de= > wrote:
Honestly, I see WS as a _pragmatic_ effort to bring the web to the next lev= el.

If it helps with that goal to have text/binary payload type distinction in = the WS protocol, I am fine with that,
even if that is somehow unclean from an idealistic protocol design view (to= which I agree).

Yes. =A0This is *exactly* = the purpose of WebSockets. =A0And having the type distinction will be of *e= xtremely* high value to JavaScript developers. =A0Existing non-browser appl= ications have TCP at their disposal directly and can use it how they see fi= t. =A0The entire purpose for the WebSockets protocol from the beginning was= explicitly to allow *browsers* to use a real-time bidirectional socket con= nection in a JavaScript environment. =A0That was and is the *whole point* o= f this protocol. =A0Period. =A0End of story. =A0Other non-browser applicati= ons can and will find good uses for this protocol, but that's all gravy= . =A0This WG has gone out of its way to make the protocol flexible enough t= o allow for such uses, and for future enhancements in browser capabilities,= to the benefit of everyone. =A0Adding binary support in the first place is= a good example of this -- recall that draft-00 is a text-only protocol! = =A0But I tell you that removing text frames will not be to the benefit of a= nyone.

It would be way beyond absurd to put utf-8 parsing into= the application layer of a JavaScript app. =A0It would only be barely tole= rable if the browsers started providing a native function that could intern= ally convert UTF-8 out of a slice of binary data - such a function does not= yet exist - but would cause JavaScript developers to have to think about h= ow to work with binary data.

The original goal of the WebSocket protocol was to be d= ead simple for inexperienced implementers to trivially build WebSocket serv= ers. =A0We've (I think rightly) deviated some from that goal, but it is= still crucial to make it brain-dead simple for an inexperienced client-sid= e developer to use the JavaScript API. =A0Forcing these developers to think= about parsing binary data structures is setting the bar too high. =A0Worki= ng with binary formats is old hat to many of us here, but remember that the= re are a lot of programmers out there who have effectively no knowledge of = binary data representations and may never need to throughout their entire c= areer. =A0Especially programmers doing front-end web development.

Given its intended purpose, I think the WebSocket proto= col rightly straddles the line between a transport protocol and an applicat= ion protocol. =A0In some ways, it's an application protocol which is in= tended to have yet another application protocol (the subprotocol) layered o= n top of it, but its primary function is to transport data. =A0I don't = think it can or should commit to being on only one of those conceptual laye= rs.

For someone already implementing the WebSocket protocol= and its binary frames, it also certainly isn't any more difficult to a= dd support for the text frame data type. =A0I really am actually rather fla= bbergasted that anyone is even entertaining the idea of removing the text f= rames.

Brian McKelvey
=

--001517588ca8d480ab04ab2558a2-- From gezelter@rlgsc.com Tue Aug 23 02:32: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 242AF21F8880 for ; Tue, 23 Aug 2011 02:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NuT9UzcuR-UY for ; Tue, 23 Aug 2011 02:32:29 -0700 (PDT) Received: from smtpoutwbe03.prod.mesa1.secureserver.net (smtpoutwbe03.prod.mesa1.secureserver.net [208.109.78.114]) by ietfa.amsl.com (Postfix) with SMTP id 6305621F883A for ; Tue, 23 Aug 2011 02:32:29 -0700 (PDT) Received: (qmail 1043 invoked from network); 23 Aug 2011 09:33:36 -0000 Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe03.prod.mesa1.secureserver.net with SMTP; 23 Aug 2011 09:33:36 -0000 Received: (qmail 945 invoked by uid 99); 23 Aug 2011 09:33:36 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110823023334.ef1fc80126c74c6c202a919c41c7bb0b.44bdc0a3db.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Tobias Oberstein" Date: Tue, 23 Aug 2011 02:33:34 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63, et al) 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, 23 Aug 2011 09:32:30 -0000 Tobias,=0A=0AThe primary point that I must raise is that the change I am pr= oposing=0Aproduces ZERO IMPACT to users at the level of the WHATWG WSAPI. S= imply=0Aput, the change is mostly editorial, with a very small at the sourc= e=0Acode level (e.g., quite likely a single data structure definition and a= =0Asingle or handful of function call parameter lists). =0A=0AThere is also= the improved clarity for implementers. There have been=0Anumerous, extende= d dialogues on this list about issues, that in the end,=0Aare the results o= f the commingling of different protocol levels within=0Athe WebSocket proto= col draft. This creates a false appearance of=0Asemantic relevance where th= ere is none.=0A=0AI have designed, built, and maintained many systems over = the years, and=0AI do not make suggestions of massive changes lightly. On t= he other hand,=0Astarting with the well-acknowledged conceptual problems wi= th OS/360, am=0Aall too familiar with the long-term consequences of lesser = choices (I do=0Anot have my copy of Brooks' "Mythical Man Month" at hand, b= ut my=0Arecollection is that there are similar comments in both the Forward= and=0Aa later section recounting a scheduling meeting are relevant).=0A=0A= The semantics of whether to refer to a character, a code point, or an=0Aenc= oding is besides the point. We know (or should know from a long=0Ahistory o= f published and unpublished misadventures) that clean=0Aseparation has sign= ificant advantages. In the case of the WebSocket API=0A(which gave birth to= this group), we have evolved a protocol with an=0Aunneeded and also insuff= icient (more later) coupling between the task of=0Atransporting bits (betwe= en browser API to server API) and the semantics=0Aof those bits.=0A=0A- Bob= Gezelter, http://www.rlgsc.com=0A=0A> -------- Original Message --------= =0A> Subject: Re: [hybi] Binary/Text Distinction (Hybi Volume 30, Number 63= ,=0A> et al)=0A> From: Tobias Oberstein =0A> D= ate: Mon, August 22, 2011 4:47 pm=0A> To: John Tamplin , Bo= b Gezelter =0A> Cc: "hybi@ietf.org" , Bj= oern Hoehrmann=0A> =0A> =0A> =0A> On 23.08.11 00:42, "Jo= hn Tamplin" wrote:=0A> > On Mon, Aug 22, 2011 at 5:57 PM, = Bob Gezelter wrote:=0A> >> Removing the character enco= ding issue from the WebSocket protocol to a=0A> >> separate small applicati= ons protocol for use between two WSAPI=0A> >> instantiations over a WebSock= et messaging connection would clarify the=0A> >> protocol without costing e= fficiency.=0A> =0A> Bob,=0A> =0A> There is no "issue". An issue is a proble= m, and there is none.=0A> =0A> The term "character" is ill-defined. In the = context of Unicode=0A> there are code points and encodings thereof. UTF-8 i= s well-defined,=0A> so here is no issue. So I assume that what you wanted t= o say is like=0A> in your earlier remarks, namely that the "issue" that you= are trying=0A> to evoke is about having 2 opcodes which differentiate payl= oad types=0A> into text/binary.=0A> =0A> However, the reasoning: WS is a tr= ansport protocol, and thus should=0A> not include payload types is not poin= ting to a practical problem=0A> with WS. Where is the practical problem? Wh= at does not work with=0A> WS today, because it has opcodes designating payl= oads into text=0A> or binary?=0A> =0A> > =0A> > All I see it would do is me= an the protocol isn't actually useful for its=0A> > intended purpose until = an additional standard were agreed upon and=0A> > implemented. =C2=A0As thi= s one has taken years, let's not double the time until we=0A> > can use it.= =0A> =0A> ++1 John=0A> =0A> Please don't open the pandora's box.=0A> =0A> O= ver the weekend I started playing with FF8 on Android talking to=0A> our se= rvers and PC all via WS + HTML5. It's awesome, it works - today!=0A> =0A> B= ob, now, you tell me you want to take that away/break again for=0A> months-= years to come, because you find it "unclean" to have=0A> that payload type = stuff in WS. Well. That's a tough call ...=0A From ibc@aliax.net Tue Aug 23 03:08: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 584AD21F8A91 for ; Tue, 23 Aug 2011 03:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i90lrGOkuaOf for ; Tue, 23 Aug 2011 03:07:59 -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 919D421F8A55 for ; Tue, 23 Aug 2011 03:07:59 -0700 (PDT) Received: by qyk34 with SMTP id 34so1873436qyk.10 for ; Tue, 23 Aug 2011 03:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr2085195qce.185.1314094146609; Tue, 23 Aug 2011 03:09:06 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 03:09:06 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 23 Aug 2011 12:09:06 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Brian Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 10:08:00 -0000 2011/8/23 Brian : > Yes. =C2=A0This is *exactly* the purpose of WebSockets. =C2=A0And having = the type > distinction will be of *extremely* high value to JavaScript developers. Is JavaScript the only scripting technology for a web page? Will it be the only one? > =C2=A0Existing non-browser applications have TCP at their disposal direct= ly and > can use it how they see fit. That's wrong IMHO. TCP is not a friendly protocol for high-level developers since TCP is not message boundary. There are lot of buggy programs implementing a protocol on top of TCP because the author expected that a received TCP package must contain an entire application level message (and no more). HTTP is a good example. Even if HTTP/1.1 allows connection reuse and the hyper-ugly-and-bad-designed pipeline feature, nobody uses it (but just experimented and optimized web browsers). Nobody making an HTTP library for language XXXX implements HTTP connection reuse or pipeline. Lazy developers assume that each application request uses single TCP connection which must be closed after getting the response. Do you imagine a smartphone application using an HTTP library and opening a new TCP connection for each "message"? WebSocket could help here. If there appear (and there are) WebSocket libraries for any language, a developer could use them to build an application running out of a webbrowser (i.e. an smartphone). The developer gets, by free, a message boundary protocol (simple API) and a standarized protocol which, probably, will be implemented by many services offering content not just via a web browser. Using raw TCP is not the solution, as currently people prefers to build an ugly HTTP-polling solution rather than dealing with TCP. So, assuming that WebSocket must be designed just considering JavaScript is a very very wrong asumption IMHO. > The entire purpose for the WebSockets protocol > from the beginning was explicitly to allow *browsers* to use a real-time > bidirectional socket connection in a JavaScript environment. =C2=A0That w= as and > is the *whole point* of this protocol. =C2=A0Period. =C2=A0End of story. There are a lot of smartphone applications which "imitate" the web browser interface (but they are not html browsers, but phone native applications). Examples: Facebook chat, Twitter messenger, and so on. Am I really the only one assuming that WebSocket is the perfect protocol for those NON-web-browsers applications (think in smartphones please) which currently use HTTP for communicating with the server? > It would be way beyond absurd to put utf-8 parsing into the application > layer of a JavaScript app. =C2=A0It would only be barely tolerable if the > browsers started providing a native function that could internally conver= t > UTF-8 out of a slice of binary data - such a function does not yet exist = - > but would cause JavaScript developers to have to think about how to work > with binary data. That's a good argument. --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Tue Aug 23 03:16: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 E81B021F8AB8 for ; Tue, 23 Aug 2011 03:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_28=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OYm1ffBoOa4 for ; Tue, 23 Aug 2011 03:16:28 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id 3E57721F86EE for ; Tue, 23 Aug 2011 03:16:28 -0700 (PDT) Received: (qmail 14266 invoked from network); 23 Aug 2011 10:17:35 -0000 Received: from unknown (HELO localhost) (72.167.218.135) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 23 Aug 2011 10:17:35 -0000 Received: (qmail 28015 invoked by uid 99); 23 Aug 2011 10:17:35 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Brian" Date: Tue, 23 Aug 2011 03:17:33 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 10:16:29 -0000 Brian,=0A=0AFor clarity, I am combining my response to your messages from 0= 457Z and=0A0520Z today into a single message. I have correspondingly merged= the=0ACC'courtesy lists.=0A=0AYour posting crystallized an issue that has = long disturbed me about the=0AWebSocket protocol specification, the co-char= acterization of what are=0Adeemed protocol extensions (e.g., John's multipl= exing draft) with user=0Aapplications protocols. In architectural terms, on= e (multiplexing) is a=0Ahorizontal technology, applicable to all protocol u= sers; the other is a=0Avertical, useful to to a discrete, far smaller audie= nce.=0A=0ABy this token, I also respectfully disagree with Bruce's comment = about=0Areassigning op codes.=0A=0AThis commingling produces the appearance= of cross-connections where=0Athere are truly none. It is also not necessar= y.=0A=0AThe binary/text dichotomy is an artifact of the original conception= . I=0Aagree (emphasis: AGREE) that the programmer's ability to send text=0A= messages FROM THE WEBSOCKET API (WSAPI) SHOULD REMAIN UNCHANGED=0A[apologie= s for the capitalization, but there is no other way to show=0Aemphasis in U= S ASCII-7]. =0A=0ARecently, it was observed that the desired state was to b= e able to=0Ainterleave, on a message-to-message basis, text and binary mess= ages on a=0Asingle channel. The precise reference was to text control messa= ges, and=0Aa binary version of a JSON object. This example is reasonable, b= ut it=0Aalso illuminates my point: There must be far more agreement between= the=0Arespective communicating entities than the text/binary dichotomy.=0A= =0AI forget the message, but it was also raised that imposing the=0AUTF-8/b= inary transformation on the programmer is unreasonable. Once=0Aagain, I agr= ee with the statement, but NOT WITH THE END RESULT. =0A=0AThe present Struc= ture is:=0A=0AClient WSAPI=0A |=0AClient WebSocket Protocol (text/binary r= ecords)=0A |=0AServer WebSocket Protocol (text/binary records)=0A |=0ASer= ver WSAPI =0A=0AWhat I am proposing is:=0A=0AClient WSAPI=0A |=0AClient WS= API App (text/binary records)=0A |=0A Client WebSocket Protocol (bina= ry records)=0A |=0A Server WebSocket Protocol (binary records)=0A = |=0AServer WSAPI App (text/binary records)=0A |=0AServer WSAPI =0A=0ADesp= ite the change in the structure diagram, I must emphasize that this=0Achang= e is almost completely an editorial change in documentation. There=0Aare no= needs for additional layers of code. All code already exists in=0AWSAPI. T= he one change is the elimination of the text/binary dichotomy at=0Athe leve= l of the WebSocket protocol and the corresponding change in a=0Ahandful of = parameter lists and data structures. User code that runs=0Atoday before the= change runs tomorrow after the change.=0A=0AYou put it well, that the purp= ose of WebSockets (the API) is to enable=0AJavaScript programmers to easily= develop browser-based communications.=0ANone of the changes that I am prop= osing will have any effect on those=0AJavaScript programmers.=0A=0AIt will = have a positive effect however, on the wide-range of developers=0Awho need = to develop tools and devices where a thorough understanding of=0Athe protoc= ol is essential to ensure correct operation.=0A=0A- Bob Gezelter, http://ww= w.rlgsc.com=0A From tobias.oberstein@tavendo.de Tue Aug 23 03:20: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 ABB7B21F84DF for ; Tue, 23 Aug 2011 03:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ueF004G8-OEt for ; Tue, 23 Aug 2011 03:20:31 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id D800621F8A7E for ; Tue, 23 Aug 2011 03:20:30 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 23 Aug 2011 03:21:37 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Brian Date: Tue, 23 Aug 2011 03:20:48 -0700 Thread-Topic: [hybi] Binary/Text Distinction Thread-Index: AcxhfLOhEeXu47D4SNCApeLl80PldwAAA+xg Message-ID: <634914A010D0B943A035D226786325D422C0D5CE5A@EXVMBX020-12.exch020.serverdata.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 10:20:31 -0000 PiA+IMKgRXhpc3Rpbmcgbm9uLWJyb3dzZXIgYXBwbGljYXRpb25zIGhhdmUgVENQIGF0IHRoZWly IGRpc3Bvc2FsIGRpcmVjdGx5DQo+ID4gYW5kIGNhbiB1c2UgaXQgaG93IHRoZXkgc2VlIGZpdC4N Cj4gDQo+IFRoYXQncyB3cm9uZyBJTUhPLiBUQ1AgaXMgbm90IGEgZnJpZW5kbHkgcHJvdG9jb2wg Zm9yIGhpZ2gtbGV2ZWwgZGV2ZWxvcGVycw0KPiBzaW5jZSBUQ1AgaXMgbm90IG1lc3NhZ2UgYm91 bmRhcnkuIFRoZXJlIGFyZSBsb3Qgb2YgYnVnZ3kgcHJvZ3JhbXMNCg0KdXNlIFNDVFAgLi4gaXQg aGFzIG1lc3NhZ2VzIGFuZCBtdWx0aXBsZXhpbmcNCg0KPiBpbXBsZW1lbnRpbmcgYSBwcm90b2Nv bCBvbiB0b3Agb2YgVENQIGJlY2F1c2UgdGhlIGF1dGhvciBleHBlY3RlZCB0aGF0IGENCj4gcmVj ZWl2ZWQgVENQIHBhY2thZ2UgbXVzdCBjb250YWluIGFuIGVudGlyZSBhcHBsaWNhdGlvbiBsZXZl bCBtZXNzYWdlIChhbmQNCj4gbm8gbW9yZSkuDQoNCkkgYXNzdW1lIHlvdSBtZWFuICJUQ1AgcGFj a2V0IiAuLiBidXQgZXZlbiB0aGVuLCB0aGVyZSBhcmUgb25seSBUQ1Agc2VnbWVudHMNCmFuZCBJ UCBwYWNrZXRzLg0KDQpJZiB5b3Ugd2FudCBmcmFtaW5nIG9uIFRDUCwgdXNlIHNvbWV0aGluZyB0 aGF0IGV2ZW4gd2FzIHRyaWdnZXJlZCBieSB5b3VyDQoic2VjdXJpdHkgY29uY2VybnMiDQogDQpo dHRwOi8vY3IueXAudG8vcHJvdG8vbmV0c3RyaW5ncy50eHQNCg0KaXQncyB0cml2aWFsLCBzdWZm aWNpZW50IGZvciBmcmFtaW5nIChvbmx5KSBhbmQgYXZhaWxhYmxlIHNpbmNlIDE5OTcuDQoNCj4g U28sIGFzc3VtaW5nIHRoYXQgV2ViU29ja2V0IG11c3QgYmUgZGVzaWduZWQganVzdCBjb25zaWRl cmluZyBKYXZhU2NyaXB0IGlzDQo+IGEgdmVyeSB2ZXJ5IHdyb25nIGFzdW1wdGlvbiBJTUhPLg0K DQpXaG8gc2FpZCAib25seSI/DQoNCj4gPiBUaGUgZW50aXJlIHB1cnBvc2UgZm9yIHRoZSBXZWJT b2NrZXRzIHByb3RvY29sIGZyb20gdGhlIGJlZ2lubmluZyB3YXMNCj4gPiBleHBsaWNpdGx5IHRv IGFsbG93ICpicm93c2VycyogdG8gdXNlIGEgcmVhbC10aW1lIGJpZGlyZWN0aW9uYWwgc29ja2V0 DQo+ID4gY29ubmVjdGlvbiBpbiBhIEphdmFTY3JpcHQgZW52aXJvbm1lbnQuIMKgVGhhdCB3YXMg YW5kIGlzIHRoZSAqd2hvbGUNCj4gPiBwb2ludCogb2YgdGhpcyBwcm90b2NvbC4gwqBQZXJpb2Qu IMKgRW5kIG9mIHN0b3J5Lg0KPiANCj4gVGhlcmUgYXJlIGEgbG90IG9mIHNtYXJ0cGhvbmUgYXBw bGljYXRpb25zIHdoaWNoICJpbWl0YXRlIiB0aGUgd2ViIGJyb3dzZXINCj4gaW50ZXJmYWNlIChi dXQgdGhleSBhcmUgbm90IGh0bWwgYnJvd3NlcnMsIGJ1dCBwaG9uZSBuYXRpdmUgYXBwbGljYXRp b25zKS4NCj4gRXhhbXBsZXM6IEZhY2Vib29rIGNoYXQsIFR3aXR0ZXIgbWVzc2VuZ2VyLCBhbmQg c28gb24uDQo+IA0KPiBBbSBJIHJlYWxseSB0aGUgb25seSBvbmUgYXNzdW1pbmcgdGhhdCBXZWJT b2NrZXQgaXMgdGhlIHBlcmZlY3QgcHJvdG9jb2wgZm9yDQo+IHRob3NlIE5PTi13ZWItYnJvd3Nl cnMgYXBwbGljYXRpb25zICh0aGluayBpbiBzbWFydHBob25lcw0KPiBwbGVhc2UpIHdoaWNoIGN1 cnJlbnRseSB1c2UgSFRUUCBmb3IgY29tbXVuaWNhdGluZyB3aXRoIHRoZSBzZXJ2ZXI/DQoNCldo YXQgc2VyaWFsaXphdGlvbiBmb3JtYXQgd2lsbCBwcm9iYWJseSBiZSB0aGUgbW9zdCB3aWRlbHkg dXNlZCBmb3IgSlMgX2FuZF8NCiJuYXRpdmUiIGNsaWVudHMgYWxpa2U/IElmIEkgaGFkIHRvIG1h a2UgYSBiZXQsIGl0IHdvdWxkIGJlIEpTT04uIFlvdSBjYW4NCmhhdmUgeW91ciBIVE1MNSBmcm9u dGVuZCBfYW5kXyB5b3VyIG5hdGl2ZSBmcm9udGVuZCB0YWxrIHRvIHlvdXINCnNlcnZlcnMgb3Zl ciB0aGUgc2FtZSB0cmFuc3BvcnQvc2VyaWFsaXphdGlvbi4NCg0KQWdhaW46IF9ub18gcmVxdWly ZW1lbnQgdG8gdXNlIEpTT04gdGhvdWdoLiBVc2luZyBUaHJpZnQgb24gUHJvdG9CdWZmZXJzDQp3 aXRoIFdTIGlzIGp1c3QgYXMgZmluZSAuLg0KDQo= From internet-drafts@ietf.org Tue Aug 23 03:27: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 47A7021F8AFE; Tue, 23 Aug 2011 03:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDzAvNdLq4+z; Tue, 23 Aug 2011 03:27:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A349921F8AE9; Tue, 23 Aug 2011 03:27:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> Date: Tue, 23 Aug 2011 03:27:13 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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, 23 Aug 2011 10:27:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTT= P Working Group of the IETF. Title : The WebSocket protocol Author(s) : Ian Fette Alexey Melnikov Filename : draft-ietf-hybi-thewebsocketprotocol-11.txt Pages : 68 Date : 2011-08-23 The WebSocket protocol enables two-way communication between a client running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling). Please send feedback to the hybi@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-11= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-11.= txt From alexey.melnikov@isode.com Tue Aug 23 03:32: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 28B1021F87C5 for ; Tue, 23 Aug 2011 03:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.537 X-Spam-Level: X-Spam-Status: No, score=-102.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35L0lw8utNM7 for ; Tue, 23 Aug 2011 03:32:51 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 650DC21F87C2 for ; Tue, 23 Aug 2011 03:32:51 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Aug 2011 11:33:58 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E538213.7020207@isode.com> Date: Tue, 23 Aug 2011 11:33:55 +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: hybi@ietf.org References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> In-Reply-To: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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, 23 Aug 2011 10:32:52 -0000 internet-drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. > > Title : The WebSocket protocol > Author(s) : Ian Fette > Alexey Melnikov > Filename : draft-ietf-hybi-thewebsocketprotocol-11.txt > Pages : 68 > Date : 2011-08-23 > > This version addresses most of the Gen-Art/SecDir/IETF LC issues presented in Quebec City, with the exception of: 1). Updated Security Considerations 2). Better explanation of the purpose of masking 3). x- namespace 4). Frame too big and extensibility clarification issues. 5). addition of text about exponential back-off Note that the Acknowledgments section was updated, but it is not yet complete yet. I still have some emails on the subject to process/reply to. I might post -12 today or later this week. The only type of change that would be present in -12 is moving sections around to improve readability of the document. From ibc@aliax.net Tue Aug 23 03:39: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 BD42F21F8B06 for ; Tue, 23 Aug 2011 03:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rc81mfhrqyOi for ; Tue, 23 Aug 2011 03:39:24 -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 0216321F87D9 for ; Tue, 23 Aug 2011 03:39:23 -0700 (PDT) Received: by qwc23 with SMTP id 23so4349115qwc.31 for ; Tue, 23 Aug 2011 03:40:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.211.136 with SMTP id go8mr2042438qab.348.1314096031115; Tue, 23 Aug 2011 03:40:31 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 03:40:30 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5CE5A@EXVMBX020-12.exch020.serverdata.net> References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CE5A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 23 Aug 2011 12:40:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 10:39:24 -0000 2011/8/23 Tobias Oberstein : >> > =C2=A0Existing non-browser applications have TCP at their disposal dir= ectly >> > and can use it how they see fit. >> >> That's wrong IMHO. TCP is not a friendly protocol for high-level develop= ers >> since TCP is not message boundary. There are lot of buggy programs > > use SCTP .. it has messages and multiplexing Yes, I know SCTP, and I also know that it's a transport protocol just present in big telephony providers networks for carrying ISUP or SIP protocols and intercommunicate with other providers. So I don't think we should suggest "use SCTP" in this thread. >> implementing a protocol on top of TCP because the author expected that a >> received TCP package must contain an entire application level message (a= nd >> no more). > > I assume you mean "TCP packet" .. but even then, there are only TCP segme= nts > and IP packets. My fault. > If you want framing on TCP, use something that even was triggered by your > "security concerns" > > http://cr.yp.to/proto/netstrings.txt I was asking for nothing, neither SCTP neither a framing solution for TCP. I was describing existing issues when a lazy developer tries to implement a *already* given protocol (so forget netstings stuff) on top of TCP. For example, there are some XMPP clients assuming that a TCP packet must contain an entire XMPP message (and just one). >> So, assuming that WebSocket must be designed just considering JavaScript= is >> a very very wrong asumption IMHO. > > Who said "only"? Extracted from the last mail of Brian in this thread: > The entire purpose for the WebSockets protocol from the beginning was exp= licitly to allow *browsers* to use a real-time bidirectional socket connect= ion in a JavaScript environment. >> Am I really the only one assuming that WebSocket is the perfect protocol= for >> those NON-web-browsers applications (think in smartphones >> please) which currently use HTTP for communicating with the server? > > What serialization format will probably be the most widely used for JS _a= nd_ > "native" clients alike? If I had to make a bet, it would be JSON. You can > have your HTML5 frontend _and_ your native frontend talk to your > servers over the same transport/serialization. I don't care which serialization format "native" clients would choose for use within WebSocket protocol. Why is that important? I just meant that, IMHO, WS is a perfect choice for a "generic" application (out of a web page) communicating with a server which usually servers web pages. Regards. --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Tue Aug 23 03:50: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 5E74221F8A69 for ; Tue, 23 Aug 2011 03:50:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.417 X-Spam-Level: X-Spam-Status: No, score=-2.417 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuDn3Jh6Ni5j for ; Tue, 23 Aug 2011 03:50:17 -0700 (PDT) Received: from smtpoutwbe06.prod.mesa1.secureserver.net (smtpoutwbe06.prod.mesa1.secureserver.net [208.109.78.208]) by ietfa.amsl.com (Postfix) with SMTP id E31AC21F8A55 for ; Tue, 23 Aug 2011 03:50:16 -0700 (PDT) Received: (qmail 30377 invoked from network); 23 Aug 2011 10:51:18 -0000 Received: from unknown (HELO localhost) (72.167.218.133) by smtpoutwbe06.prod.mesa1.secureserver.net with SMTP; 23 Aug 2011 10:51:18 -0000 Received: (qmail 4960 invoked by uid 99); 23 Aug 2011 10:51:18 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110823035117.ef1fc80126c74c6c202a919c41c7bb0b.bb005cd5de.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "=?UTF-8?Q?I=C3=B1aki=5FBaz=5FCastillo?=" Date: Tue, 23 Aug 2011 03:51:17 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 10:50:18 -0000 Inaki,=0A=0AWith regards to SCTP, I have long ago noted that absent the=0AH= TTP-specific handshaking and the discrete places where ports 80/443 and=0At= heir corresponding schemes are specified, there is no technical=0Aconnectio= n or dependency on TCP (my article this past March noted that=0Aone could e= asily and [emphasis] virtually transparently to the end user=0A[end emphasi= s] implement the WebSocket protocol over an SCTP transport=0Ausing a differ= ent scheme (e.g., "wsc:/wssc:" instead of "ws:/wss:"). In=0Athat way, appli= cations code would only need a small change in URLs=0A(which could be handl= ed by DNS records or redirects), the meat of the=0Awork would be in the WSA= PI-level code.=0A=0AWith regards to XMPP, if there are assumptions about TC= P delivery of=0Adata other than a stream, the implementation is certainly s= everely=0Abroken. One of the first things I learned about TCP connections i= s that=0Aany resemblance between packets and the chunks that data is receiv= ed=0Ainstantaneously is purely coincidence and cannot be relied upon.=0A=0A= - Bob Gezelter, http://www.rlgsc.com=0A=0A=0A=0A> -------- Original Message= --------=0A> Subject: Re: [hybi] Binary/Text Distinction=0A> From: I=C3=B1= aki_Baz_Castillo =0A> Date: Tue, August 23, 2011 3:40 am=0A>= To: Tobias Oberstein =0A> Cc: Brian , "hybi@ietf.org" , =0A> Bjoern Hoehrmann , Bob Gezelter =0A> =0A> =0A> 2011/8/23 = Tobias Oberstein :=0A> >> > =C2=A0Existing non= -browser applications have TCP at their disposal directly=0A> >> > and can = use it how they see fit.=0A> >>=0A> >> That's wrong IMHO. TCP is not a frie= ndly protocol for high-level developers=0A> >> since TCP is not message bou= ndary. There are lot of buggy programs=0A> >=0A> > use SCTP .. it has messa= ges and multiplexing=0A> =0A> Yes, I know SCTP, and I also know that it's a= transport protocol just=0A> present in big telephony providers networks fo= r carrying ISUP or SIP=0A> protocols and intercommunicate with other provid= ers. So I don't think=0A> we should suggest "use SCTP" in this thread.=0A> = =0A> =0A> >> implementing a protocol on top of TCP because the author expec= ted that a=0A> >> received TCP package must contain an entire application l= evel message (and=0A> >> no more).=0A> >=0A> > I assume you mean "TCP packe= t" .. but even then, there are only TCP segments=0A> > and IP packets.=0A> = =0A> My fault.=0A> =0A> =0A> > If you want framing on TCP, use something th= at even was triggered by your=0A> > "security concerns"=0A> >=0A> > http://= cr.yp.to/proto/netstrings.txt=0A> =0A> I was asking for nothing, neither SC= TP neither a framing solution for=0A> TCP. I was describing existing issues= when a lazy developer tries to=0A> implement a *already* given protocol (s= o forget netstings stuff) on=0A> top of TCP. For example, there are some XM= PP clients assuming that a=0A> TCP packet must contain an entire XMPP messa= ge (and just one).=0A> =0A> =0A> =0A> =0A> >> So, assuming that WebSocket m= ust be designed just considering JavaScript is=0A> >> a very very wrong asu= mption IMHO.=0A> >=0A> > Who said "only"?=0A> =0A> Extracted from the last = mail of Brian in this thread:=0A> =0A> > The entire purpose for the WebSock= ets protocol from the beginning was explicitly to allow *browsers* to use a= real-time bidirectional socket connection in a JavaScript environment.=0A>= =0A> =0A> =0A> =0A> >> Am I really the only one assuming that WebSocket is= the perfect protocol for=0A> >> those NON-web-browsers applications (think= in smartphones=0A> >> please) which currently use HTTP for communicating w= ith the server?=0A> >=0A> > What serialization format will probably be the = most widely used for JS _and_=0A> > "native" clients alike? If I had to mak= e a bet, it would be JSON. You can=0A> > have your HTML5 frontend _and_ you= r native frontend talk to your=0A> > servers over the same transport/serial= ization.=0A> =0A> I don't care which serialization format "native" clients = would choose=0A> for use within WebSocket protocol. Why is that important? = I just meant=0A> that, IMHO, WS is a perfect choice for a "generic" applica= tion (out of=0A> a web page) communicating with a server which usually serv= ers web=0A> pages.=0A> =0A> =0A> Regards.=0A> =0A> =0A> -- =0A> I=C3=B1aki = Baz Castillo=0A> =0A From ibc@aliax.net Tue Aug 23 04:00: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 7407B21F84EF for ; Tue, 23 Aug 2011 04:00:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RFW-yxA2xuY for ; Tue, 23 Aug 2011 04:00:39 -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 E8C2C21F84EC for ; Tue, 23 Aug 2011 04:00:38 -0700 (PDT) Received: by qyk35 with SMTP id 35so2732103qyk.10 for ; Tue, 23 Aug 2011 04:01:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr2089062qch.299.1314097306221; Tue, 23 Aug 2011 04:01:46 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 04:01:46 -0700 (PDT) Date: Tue, 23 Aug 2011 13:01:46 +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] Are RSV1-3 bits really useful? 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, 23 Aug 2011 11:00:39 -0000 >From the spec: RSV1, RSV2, RSV3: 1 bit each MUST be 0 unless an extension is negotiated which defines meanings for non-zero values. If a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint MUST _Fail the WebSocket Connection_. So what about if a WS handshake requires two extensions ext1 and ext2, and both extensions want to make usage of the same RSV1 bit? This is: - For ext1 bit RSV1 means: 1 (do something) / 0 (do other thing) - For ext2 bit RSV1 means: 1 (do something) / 0 (do other thing) Who decides the value of RSV1? the last extension requested? there would be an obvious conflict. Is the usage of these RSV bits really well designed? or is it more like "let's think about it in a future"? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Aug 23 04:12: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 4143021F8797 for ; Tue, 23 Aug 2011 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alYeIHOIBrZp for ; Tue, 23 Aug 2011 04:12:01 -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 A4E2321F8772 for ; Tue, 23 Aug 2011 04:12:01 -0700 (PDT) Received: by qwc23 with SMTP id 23so4364593qwc.31 for ; Tue, 23 Aug 2011 04:13:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr2128370qce.185.1314097988854; Tue, 23 Aug 2011 04:13:08 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 04:13:08 -0700 (PDT) In-Reply-To: <20110823035117.ef1fc80126c74c6c202a919c41c7bb0b.bb005cd5de.wbe@email03.secureserver.net> References: <20110823035117.ef1fc80126c74c6c202a919c41c7bb0b.bb005cd5de.wbe@email03.secureserver.net> Date: Tue, 23 Aug 2011 13:13:08 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 11:12:02 -0000 2011/8/23 Bob Gezelter : > With regards to SCTP, I have long ago noted that absent the > HTTP-specific handshaking and the discrete places where ports 80/443 and > their corresponding schemes are specified, there is no technical > connection or dependency on TCP (my article this past March noted that > one could easily and [emphasis] virtually transparently to the end user > [end emphasis] implement the WebSocket protocol over an SCTP transport > using a different scheme (e.g., "wsc:/wssc:" instead of "ws:/wss:"). In > that way, applications code would only need a small change in URLs > (which could be handled by DNS records or redirects), the meat of the > work would be in the WSAPI-level code. I don't think the URI schema should represent the transport to use. When it ends in "s" (wss, sips, https) it means "use security" which is not a transport itself, but an extra layer (i.e. TLS) on top of a real transport protocol (i.e. TCP, SCTP). In case of SIP, the transport is given in a URI parameter: 1) Use TCP to contact the destination: sip:alice@example.org;transport=3Dtcp 2) Use TLS over TCP to contact the destination: sips:alice@example.org;transport=3Dtcp > With regards to XMPP, if there are assumptions about TCP delivery of > data other than a stream, the implementation is certainly severely > broken. One of the first things I learned about TCP connections is that > any resemblance between packets and the chunks that data is received > instantaneously is purely coincidence and cannot be relied upon. Sure. Regards. --=20 I=C3=B1aki Baz Castillo From theturtle32@gmail.com Tue Aug 23 04:20: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 E1AF721F8512 for ; Tue, 23 Aug 2011 04:20:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.355 X-Spam-Level: X-Spam-Status: No, score=-3.355 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doJ4rK6paZSU for ; Tue, 23 Aug 2011 04:20:35 -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 2658021F8508 for ; Tue, 23 Aug 2011 04:20:34 -0700 (PDT) Received: by bkar4 with SMTP id r4so5308438bka.31 for ; Tue, 23 Aug 2011 04:21:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w1wGzWXjl+JFnYrvNqjo8Vp1sfd6BvvoKECOvtPLayU=; b=uqEMR0y5rI1Sj9Cxb5j1J4lWApdPO3iGPTnDjhHOr1O1DiExhLgzJadZ2aToXFh9+0 TIJ9Om7qYYLqHjx/NUUAhJ/I757F5b0k1eCkz5TmSpQiVlvG5PFthCjCegQztV4Vs1QF Xm/R2HIOOOBPioQE1IUtugymBJoorvkumC8w0= MIME-Version: 1.0 Received: by 10.204.137.77 with SMTP id v13mr1477816bkt.344.1314098499293; Tue, 23 Aug 2011 04:21:39 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Tue, 23 Aug 2011 04:21:39 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CE5A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 23 Aug 2011 04:21:39 -0700 Message-ID: From: Brian To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00151744897440134d04ab2a662a Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 11:20:40 -0000 --00151744897440134d04ab2a662a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 3:40 AM, I=F1aki Baz Castillo wrote= : > > Extracted from the last mail of Brian in this thread: > > > The entire purpose for the WebSockets protocol from the beginning was > explicitly to allow *browsers* to use a real-time bidirectional socket > connection in a JavaScript environment. > My point is not that non-browsers shouldn't use WebSocket. Nor is it that we shouldn't consider such use cases in the design of the protocol. My point was that since the browser use case was the impetus for creating this protocol in the first place, we shouldn't accept changes that would be in any way detrimental to the browser or JavaScript developers for the sake of a secondary use case, or even for a clean separation of application vs transport protocol concepts. This WG has frequently considered and accepte= d changes and improvements motivated by forward-thinking people who envision = a broader use for WebSockets than the browser, and we all benefit from that, but only when it causes no harm to the JS/HTML5 use case. Brian --00151744897440134d04ab2a662a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 3:40 AM, I=F1aki Baz Cas= tillo <ibc@aliax.net<= /a>> wrote:
Extracted from the last mail of Brian in this thread:

> The entire purpose for the WebSockets protocol from the beginning was = explicitly to allow *browsers* to use a real-time bidirectional socket conn= ection in a JavaScript environment.

My point is not that non-browsers shouldn't use WebSocket. =A0Nor = is it that we shouldn't consider such use cases in the design of the pr= otocol. =A0My point was that since the browser use case was the impetus for= creating this protocol in the first place, we shouldn't accept changes= that would be in any way detrimental to the browser or JavaScript develope= rs for the sake of a secondary use case, or even for a clean separation of = application vs transport protocol concepts. =A0This WG has frequently consi= dered and accepted changes and improvements motivated by forward-thinking p= eople who envision a broader use for WebSockets than the browser, and we al= l benefit from that, but only when it causes no harm to the JS/HTML5 use ca= se.

Brian

--00151744897440134d04ab2a662a-- From tyoshino@google.com Tue Aug 23 04:34: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 EFD5021F8AF0 for ; Tue, 23 Aug 2011 04:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.747 X-Spam-Level: X-Spam-Status: No, score=-105.747 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wzlxb+qhIecl for ; Tue, 23 Aug 2011 04:34:03 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8FD21F8AF5 for ; Tue, 23 Aug 2011 04:34:03 -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 p7NBZAGO026139 for ; Tue, 23 Aug 2011 04:35:10 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314099310; bh=zt/P2OtcXQQsmegMeJ2VnrkwUu0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LaPPLYyeUkEGYG38PU7tVnoVNesDxuj5FuNQA/Xurc1iSNB4STFzJYMpVTP4tYwir SZwDhJr4kC4N1MTQnHzRA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=KUbdRz2PijYoD8ZIFkh5HKXEzl6SE3QY6IH0mbTo4gWy3VX7CFUyz1PZfc6kX3fJ9 hEbTip8QU26yumVp879Gg== Received: from gwj16 (gwj16.prod.google.com [10.200.10.16]) by wpaz5.hot.corp.google.com with ESMTP id p7NBZ96F015178 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 04:35:09 -0700 Received: by gwj16 with SMTP id 16so3316gwj.37 for ; Tue, 23 Aug 2011 04:35:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=rlLE9XwcB0iwO3htvpAWM274peIDVK7GOSXPnQmdfOA=; b=drUCtud4yu8vHZWjSvGwcV94968fdS+nMFxurkScmkEXdwN4lEaGAaRqM1aJ6L8uJE Ij53FiU/8PlezvvYKPtQ== Received: by 10.91.67.20 with SMTP id u20mr3634228agk.163.1314099309350; Tue, 23 Aug 2011 04:35:09 -0700 (PDT) Received: by 10.91.67.20 with SMTP id u20mr3634222agk.163.1314099309105; Tue, 23 Aug 2011 04:35:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.32.2 with HTTP; Tue, 23 Aug 2011 04:34:49 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Tue, 23 Aug 2011 20:34:49 +0900 Message-ID: To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001485f7c13284d30004ab2a9638 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 23 Aug 2011 11:34:04 -0000 --001485f7c13284d30004ab2a9638 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable In June, bit allocation method was actively discussed. Here's chairs' conclusion then. http://www.ietf.org/mail-archive/web/hybi/current/msg07455.html The spec is requesting registry for RSV* bits. http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-11#section-= 11.9 On Tue, Aug 23, 2011 at 20:01, I=F1aki Baz Castillo wrote: > So what about if a WS handshake requires two extensions ext1 and ext2, > and both extensions want to make usage of the same RSV1 bit? > > This is: > > - For ext1 bit RSV1 means: 1 (do something) / 0 (do other thing) > - For ext2 bit RSV1 means: 1 (do something) / 0 (do other thing) > > Who decides the value of RSV1? the last extension requested? there > would be an obvious conflict. > > Is the usage of these RSV bits really well designed? or is it more > like "let's think about it in a future"? Kind of. --001485f7c13284d30004ab2a9638 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In June, bit allocation method was actively disc= ussed.
Here's chairs' conclusion th= en.
http://www.ietf.org/mail-archive/web/h= ybi/current/msg07455.html

The spec is= requesting registry for RSV* bits.
http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-1= 1#section-11.9

On Tue, Aug= 23, 2011 at 20:01, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
So what about if a WS handshake requires two extensions ext1 and ext2,
and both extensions want to make usage of the same RSV1 bit?

This is:

- For ext1 bit RSV1 means: 1 (do something) / 0 (do other thing)
- For ext2 bit RSV1 means: 1 (do something) / 0 (do other thing)

Who decides the value of RSV1? the last extension requested? there
would be an obvious conflict.

Is the usage of these RSV bits really well designed? or is it more
like "let's think about it in a future"?
Kind of.
=A0
--001485f7c13284d30004ab2a9638-- From sh@defuze.org Tue Aug 23 04:36: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 C3E3321F886D for ; Tue, 23 Aug 2011 04:36:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6u4jcr7R-7ry for ; Tue, 23 Aug 2011 04:36:12 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC3C921F87FA for ; Tue, 23 Aug 2011 04:36:12 -0700 (PDT) Received: by mail-pz0-f45.google.com with SMTP id 33so30372pzk.18 for ; Tue, 23 Aug 2011 04:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.151.2 with SMTP id y2mr1965796wfd.176.1314099440593; Tue, 23 Aug 2011 04:37:20 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Tue, 23 Aug 2011 04:37:20 -0700 (PDT) X-Originating-IP: [195.101.247.164] In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 23 Aug 2011 13:37:20 +0200 Message-ID: From: Sylvain Hellegouarch To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd157d45b2a4904ab2a9ead Cc: "hybi@ietf.org" Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 11:36:13 -0000 --000e0cd157d45b2a4904ab2a9ead Content-Type: text/plain; charset=ISO-8859-1 > > > Nobody making an HTTP library for language XXXX implements HTTP connection > reuse or pipeline. No idea where you get that from. There's a difference between implementing a feature and using it. Pipelining has proven to be complex too use but most servers and clients do implement it. Keep-alive is actually quite used. > Lazy developers assume that each application request uses > single TCP connection which must be closed after getting the response. > Do you imagine a smartphone application using an HTTP library and > opening a new TCP connection for each "message"? > Is it the role of specification to handle lazy developers? > > WebSocket could help here. If there appear (and there are) WebSocket > libraries for any language, a developer could use them to build an > application running out of a webbrowser (i.e. an smartphone). The > developer gets, by free, a message boundary protocol (simple API) and > a standarized protocol which, probably, will be implemented by many > services offering content not just via a web browser. Using raw TCP is > not the solution, as currently people prefers to build an ugly > HTTP-polling solution rather than dealing with TCP. > People use HTTP-polling from a browser because you don't have any other alternative due to the nature of HTTP. Raw sockets aren't available from JavaScript hence a middle ground which is WS. > > So, assuming that WebSocket must be designed just considering > JavaScript is a very very wrong asumption IMHO. > I don't believe this is assumed but that's the historical background of the protocol. > > > > The entire purpose for the WebSockets protocol > > from the beginning was explicitly to allow *browsers* to use a real-time > > bidirectional socket connection in a JavaScript environment. That was > and > > is the *whole point* of this protocol. Period. End of story. > > There are a lot of smartphone applications which "imitate" the web > browser interface (but they are not html browsers, but phone native > applications). Examples: Facebook chat, Twitter messenger, and so on. > > Am I really the only one assuming that WebSocket is the perfect > protocol for those NON-web-browsers applications (think in smartphones > please) which currently use HTTP for communicating with the server? > WebSocket is probably an interesting protocol on mobile devices indeed and I, for one, already play with it in that context. -- - Sylvain http://www.defuze.org http://twitter.com/lawouach --000e0cd157d45b2a4904ab2a9ead Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Nobody making an HTTP=A0library for language XXXX implements HTTP connectio= n reuse or=A0pipeline.


No i= dea where you get that from. There's a difference between implementing = a feature and using it. Pipelining has proven to be complex too use but mos= t servers and clients do implement it.
Keep-alive is actually quite used.

=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">Lazy developers assume that each application= request uses
single TCP connection which must be closed after getting the response.
Do you imagine a smartphone application using an HTTP library and
opening a new TCP connection for each "message"?
=
=A0

Is it the role of specification to handle= lazy developers?=A0

=A0

WebSocket could help here. If there appear (and there are) WebSocket
libraries for any language, a developer could use them to build an
application running out of a webbrowser (i.e. an smartphone). The
developer gets, by free, a message boundary protocol (simple API) and
a standarized protocol which, probably, will be implemented by many
services offering content not just via a web browser. Using raw TCP is
not the solution, as currently people prefers to build an ugly
HTTP-polling solution rather than dealing with TCP.

People use HTTP-polling from a browser because = you don't have any other alternative due to the nature of HTTP. Raw soc= kets aren't available from JavaScript hence a middle ground which is WS= .

=A0

So, assuming that WebSocket must be designed just considering
JavaScript is a very very wrong asumption IMHO.


I don't believe this is assumed but that's = the historical background of the protocol.

=A0


> The entire purpose for the WebSockets protocol
> from the beginning was explicitly to allow *browsers* to use a real-ti= me
> bidirectional socket connection in a JavaScript environment. =A0That w= as and
> is the *whole point* of this protocol. =A0Period. =A0End of story.

There are a lot of smartphone applications which "imitate" = the web
browser interface (but they are not html browsers, but phone native
applications). Examples: Facebook chat, Twitter messenger, and so on.

Am I really the only one assuming that WebSocket is the perfect
protocol for those NON-web-browsers applications (think in smartphones
please) which currently use HTTP for communicating with the server?


WebSocket is probably an intere= sting protocol on mobile devices indeed and I, for one, already play with i= t in that context.

--
- Sylvain
= http://www.defuze.org
http:/= /twitter.com/lawouach
--000e0cd157d45b2a4904ab2a9ead-- From gezelter@rlgsc.com Tue Aug 23 04:46: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 D3F0121F8B13 for ; Tue, 23 Aug 2011 04:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.409 X-Spam-Level: X-Spam-Status: No, score=-2.409 tagged_above=-999 required=5 tests=[AWL=-0.110, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6BnqDk7aWUNE for ; Tue, 23 Aug 2011 04:46:45 -0700 (PDT) Received: from smtpoutwbe11.prod.mesa1.secureserver.net (smtpoutwbe11.prod.mesa1.secureserver.net [208.109.78.27]) by ietfa.amsl.com (Postfix) with SMTP id 24C2921F8782 for ; Tue, 23 Aug 2011 04:46:45 -0700 (PDT) Received: (qmail 30862 invoked from network); 23 Aug 2011 11:47:47 -0000 Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe11.prod.mesa1.secureserver.net with SMTP; 23 Aug 2011 11:47:47 -0000 Received: (qmail 4541 invoked by uid 99); 23 Aug 2011 11:47:47 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110823044746.ef1fc80126c74c6c202a919c41c7bb0b.c46bfbdbee.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "=?UTF-8?Q?I=C3=B1aki=5FBaz=5FCastillo?=" Date: Tue, 23 Aug 2011 04:47:46 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: [hybi] Retitled: Use of Schemes (was: RE: Binary/Text Distinction) 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, 23 Aug 2011 11:46:45 -0000 Inaki,=0A=0AWith all due respect, I disagree. =0A=0AThe URI RFC (RFC 2396) = defines "scheme". There are several relevant=0Apassages, but one in particu= lar is in section 1.2, to wit:=0A=0A " ... Although many URL schemes are n= amed after protocols, this does=0Anot=0A imply that the only way to acces= s the URL's resource is via the named=0A protocol. Gateways, proxies, ca= ches, and name resolution services=0A might be used to access some resour= ces, independent of the protocol=0A of their origin, and the resolution o= f some URL may require the use=0A of more than one protocol (e.g., both D= NS and HTTP are typically used=0A to access an "http" URL's resource when= it can't be found in a local=0A cache). ..."=0A=0AIndeed, for many TCP-l= ayered applications level protocols, the scheme=0Aeffectively implies (if n= ot identifies) the protocol (e.g., telnet, ftp,=0Amail-to). The use of a tr= ailing "s" to indicate "secure" is an=0Ahistorical accident. HTTP/SSL (with= the scheme designator https:) got=0Atraction. There was a proposal for Sec= ure HTTP (which, if I recall=0Acorrectly, was using the scheme designator "= shttp:)=0A=0AMy point was that using the URI scheme to indicate the underly= ing=0Atransport used by a WebSocket protocol connection is very low impact.= =0AThe actual choice of scheme name is, frankly an irrelevancy. If the=0Atr= ailing "s" has esthetic benefits, one can easily use "wcs:/wcss:" or=0A"wss= ctp:/wssctps:"; there is no downside to an even longer scheme name=0A(e.g.,= "websocket-sctp:/websocket-sctp-s:"; note, I do not recall if RFC=0A2396 p= ermits hyphens, but the point is made regardless).=0A=0AA change in the sch= eme also permits the least impact on the code that=0Aparses inbound URIs at= the application level. In my experience, the=0Ascheme portion of the URI i= s almost universally ignored, having been=0Aalready processed by the client= and having come through the designated=0Anetwork pathway, it has served it= s purpose.=0A=0A- Bob Gezelter, http://www.rlgsc.com =0A> -------- Original= Message --------=0A> Subject: Re: [hybi] Binary/Text Distinction=0A> From:= I=C3=B1aki_Baz_Castillo =0A> Date: Tue, August 23, 2011 4:1= 3 am=0A> To: Bob Gezelter =0A> Cc: Brian , "hybi@ietf.org" , =0A> Bjoern Hoehrmann , Tobias Oberstein=0A> =0A> =0A> =0A= > 2011/8/23 Bob Gezelter :=0A> > With regards to SCTP, = I have long ago noted that absent the=0A> > HTTP-specific handshaking and t= he discrete places where ports 80/443 and=0A> > their corresponding schemes= are specified, there is no technical=0A> > connection or dependency on TCP= (my article this past March noted that=0A> > one could easily and [emphasi= s] virtually transparently to the end user=0A> > [end emphasis] implement t= he WebSocket protocol over an SCTP transport=0A> > using a different scheme= (e.g., "wsc:/wssc:" instead of "ws:/wss:"). In=0A> > that way, application= s code would only need a small change in URLs=0A> > (which could be handled= by DNS records or redirects), the meat of the=0A> > work would be in the W= SAPI-level code.=0A> =0A> I don't think the URI schema should represent the= transport to use.=0A> When it ends in "s" (wss, sips, https) it means "use= security" which=0A> is not a transport itself, but an extra layer (i.e. TL= S) on top of a=0A> real transport protocol (i.e. TCP, SCTP).=0A> =0A> In ca= se of SIP, the transport is given in a URI parameter:=0A> =0A> =0A> 1) Use = TCP to contact the destination:=0A> =0A> sip:alice@example.org;transport= =3Dtcp=0A> =0A> =0A> 2) Use TLS over TCP to contact the destination:=0A> = =0A> sips:alice@example.org;transport=3Dtcp=0A> =0A> =0A> =0A> > With reg= ards to XMPP, if there are assumptions about TCP delivery of=0A> > data oth= er than a stream, the implementation is certainly severely=0A> > broken. On= e of the first things I learned about TCP connections is that=0A> > any res= emblance between packets and the chunks that data is received=0A> > instant= aneously is purely coincidence and cannot be relied upon.=0A> =0A> Sure.=0A= > =0A> Regards.=0A> =0A> =0A> -- =0A> I=C3=B1aki Baz Castillo=0A> =0A From ibc@aliax.net Tue Aug 23 04:48: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 E6BA521F8B1E for ; Tue, 23 Aug 2011 04:48:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSRNRcVCMBOr for ; Tue, 23 Aug 2011 04:48:45 -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 6208D21F8B18 for ; Tue, 23 Aug 2011 04:48:45 -0700 (PDT) Received: by qyk35 with SMTP id 35so10306qyk.10 for ; Tue, 23 Aug 2011 04:49:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr2137948qci.223.1314100192766; Tue, 23 Aug 2011 04:49:52 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 04:49:51 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CE5A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 23 Aug 2011 13:49:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Brian Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Bjoern Hoehrmann , "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 11:48:46 -0000 2011/8/23 Brian : > On Tue, Aug 23, 2011 at 3:40 AM, I=C3=B1aki Baz Castillo = wrote: >> >> Extracted from the last mail of Brian in this thread: >> >> > The entire purpose for the WebSockets protocol from the beginning was >> > explicitly to allow *browsers* to use a real-time bidirectional socket >> > connection in a JavaScript environment. > > My point is not that non-browsers shouldn't use WebSocket. =C2=A0Nor is i= t that > we shouldn't consider such use cases in the design of the protocol. =C2= =A0My > point was that since the browser use case was the impetus for creating th= is > protocol in the first place, we shouldn't accept changes that would be in > any way detrimental to the browser or JavaScript developers for the sake = of > a secondary use case, or even for a clean separation of application vs > transport protocol concepts. =C2=A0This WG has frequently considered and = accepted > changes and improvements motivated by forward-thinking people who envisio= n a > broader use for WebSockets than the browser, and we all benefit from that= , > but only when it causes no harm to the JS/HTML5 use case. I don't want to suggest *nothing* that would make more complex to use WS within a common JS application. But that's not mean that current spec cannot be improved in order to be more "ellegant" and correct. --=20 I=C3=B1aki Baz Castillo From theturtle32@gmail.com Tue Aug 23 04:51: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 2DE7121F858D for ; Tue, 23 Aug 2011 04:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.2 X-Spam-Level: X-Spam-Status: No, score=-3.2 tagged_above=-999 required=5 tests=[AWL=-0.202, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evd5tpDGoUVB for ; Tue, 23 Aug 2011 04:51:30 -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 D262C21F86FF for ; Tue, 23 Aug 2011 04:51:28 -0700 (PDT) Received: by bkar4 with SMTP id r4so18355bka.31 for ; Tue, 23 Aug 2011 04:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3HzDB4kC3NBgzosM/YA2KYkvjve2H/leLimeRDKZVFk=; b=F9a/Q0DeNMQ55nasC+lF08rcSGSehEAs64cnFP5NkMLvNIsKj1PIzDbMZKO/YULS6G MjBXjJRw73lMzYV/E8uEg6R7OZLU7d3QWMnEED99T8K0uZvOtwVJMyYiLrBBWj/Nlai6 001dokaOi1hXjcOYaaY440mCFqShZ9HSHk478= MIME-Version: 1.0 Received: by 10.204.138.202 with SMTP id b10mr1457811bku.188.1314100355575; Tue, 23 Aug 2011 04:52:35 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Tue, 23 Aug 2011 04:52:35 -0700 (PDT) In-Reply-To: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> Date: Tue, 23 Aug 2011 04:52:35 -0700 Message-ID: From: Brian To: Bob Gezelter Content-Type: multipart/alternative; boundary=001517477fa0e4af7c04ab2ad41b Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 11:51:35 -0000 --001517477fa0e4af7c04ab2ad41b Content-Type: text/plain; charset=ISO-8859-1 I get what you're saying here, but how can today's code (separate text vs. binary opcodes) interoperate with "tomorrow's" spec (only a binary opcode)? JavaScript code using the WebSocket API could remain unchanged, yes, but in order to perform the separation you're suggesting, there would have to be some kind of preamble in the application data section of the binary frame to indicate whether to interpret the data as UTF-8, and according to your suggestion as I understand it, that preamble would be under the purview of a separate specification. And to what end really? This is all so simple and straightforward already I really don't see the point of the extra bureaucratic nonsense required to perform such an extraction. I would be opposed to based on the extra red-tape, delays (no matter how short you feel they might be), and the formation of yet another working group to build yet another specification. I can't imagine that could all get done in any less 6 months, optimistically speaking. The concept of separating out the tagging of "content-type" is a fine idea on its own, but given that we're all getting really antsy for this protocol to be released, it's incredibly depressing to think about doing something like that for such a simple two-case scenario, especially when we're so close to the finish line. It's not like we support arbitrary content types or text encodings. The understanding of how to interpret the contents of text or binary messages, whether to expect text messages, binary messages, or both, is all up to the end-user of the WebSocket API when he defines the subprotocol for his individual specific application. Most such developers will simply use JSON in "text" messages because it's easy, and users that want to use a binary format will define which serialization format to use for their newly-minted "SuperUltraChat" subprotocol as they please. We really don't need any kind of content-type encoding or tagging in this protocol (or the meta-application-protocol you're suggesting) at all except for the one convenience case. I don't think I'd even want it to get any more complex than utf-8 vs. raw binary. The simplicity of that limitation is what makes it so convenient for so many things. The thing is.. there really are only two types of messages. It's not that hard. And since utf-8 is "The One True Encoding," there is no need for misdirection in talking about antiquated problems like character set conversions or line-ending mangling or anything else of that sort. The text frame is a simple additional case that's really not that hard to comprehend in the specification's current format. I got through building my Websocket client & server implementation with shockingly few questions, and had none about the distinction between text or binary messages, or when to use or not to use utf-8. The formality of separating all that into its own specification, like many other things discussed on this working group, could absolutely be done in a later revision of the protocol, where the "text" message would be deprecated in favor of using only the "binary" message type in conjunction with the new meta-application-level protocol that you're suggesting. I feel exceptionally strongly against holding up the release of WebSockets for this issue. Cheers, Brian On Tue, Aug 23, 2011 at 3:17 AM, Bob Gezelter wrote: > Brian, > > For clarity, I am combining my response to your messages from 0457Z and > 0520Z today into a single message. I have correspondingly merged the > CC'courtesy lists. > > Your posting crystallized an issue that has long disturbed me about the > WebSocket protocol specification, the co-characterization of what are > deemed protocol extensions (e.g., John's multiplexing draft) with user > applications protocols. In architectural terms, one (multiplexing) is a > horizontal technology, applicable to all protocol users; the other is a > vertical, useful to to a discrete, far smaller audience. > > By this token, I also respectfully disagree with Bruce's comment about > reassigning op codes. > > This commingling produces the appearance of cross-connections where > there are truly none. It is also not necessary. > > The binary/text dichotomy is an artifact of the original conception. I > agree (emphasis: AGREE) that the programmer's ability to send text > messages FROM THE WEBSOCKET API (WSAPI) SHOULD REMAIN UNCHANGED > [apologies for the capitalization, but there is no other way to show > emphasis in US ASCII-7]. > > Recently, it was observed that the desired state was to be able to > interleave, on a message-to-message basis, text and binary messages on a > single channel. The precise reference was to text control messages, and > a binary version of a JSON object. This example is reasonable, but it > also illuminates my point: There must be far more agreement between the > respective communicating entities than the text/binary dichotomy. > > I forget the message, but it was also raised that imposing the > UTF-8/binary transformation on the programmer is unreasonable. Once > again, I agree with the statement, but NOT WITH THE END RESULT. > > The present Structure is: > > Client WSAPI > | > Client WebSocket Protocol (text/binary records) > | > Server WebSocket Protocol (text/binary records) > | > Server WSAPI > > What I am proposing is: > > Client WSAPI > | > Client WSAPI App (text/binary records) > | > Client WebSocket Protocol (binary records) > | > Server WebSocket Protocol (binary records) > | > Server WSAPI App (text/binary records) > | > Server WSAPI > > Despite the change in the structure diagram, I must emphasize that this > change is almost completely an editorial change in documentation. There > are no needs for additional layers of code. All code already exists in > WSAPI. The one change is the elimination of the text/binary dichotomy at > the level of the WebSocket protocol and the corresponding change in a > handful of parameter lists and data structures. User code that runs > today before the change runs tomorrow after the change. > > You put it well, that the purpose of WebSockets (the API) is to enable > JavaScript programmers to easily develop browser-based communications. > None of the changes that I am proposing will have any effect on those > JavaScript programmers. > > It will have a positive effect however, on the wide-range of developers > who need to develop tools and devices where a thorough understanding of > the protocol is essential to ensure correct operation. > > - Bob Gezelter, http://www.rlgsc.com > > --001517477fa0e4af7c04ab2ad41b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I get what you're saying here, but how can today's code (separate t= ext vs. binary opcodes) interoperate with "tomorrow's" spec (= only a binary opcode)? =A0JavaScript code using the WebSocket API could rem= ain unchanged, yes, but in order to perform the separation you're sugge= sting, there would have to be some kind of preamble in the application data= section of the binary frame to indicate whether to interpret the data as U= TF-8, and according to your suggestion as I understand it, that preamble wo= uld be under the purview of a separate specification. =A0And to what end re= ally?

This is all so simple and straightforward already I really d= on't see the point of the extra bureaucratic nonsense required to perfo= rm such an extraction. =A0I would be opposed to based on the extra red-tape= , delays (no matter how short you feel they might be), and the formation of= yet another working group to build yet another specification. =A0I can'= ;t imagine that could all get done in any less 6 months, optimistically spe= aking. =A0The concept of separating out the tagging of "content-type&q= uot; is a fine idea on its own, but given that we're all getting really= antsy for this protocol to be released, it's incredibly depressing to = think about doing something like that for such a simple two-case scenario, = especially when we're so close to the finish line.

It's not like we support arbitrary content types or= text encodings. =A0The understanding of how to interpret the contents of t= ext or binary messages, whether to expect text messages, binary messages, o= r both, is all up to the end-user of the WebSocket API when he defines the = subprotocol for his individual specific application. =A0Most such developer= s will simply use JSON in "text" messages because it's easy, = and users that want to use a binary format will define which serialization = format to use for their newly-minted "SuperUltraChat" subprotocol= as they please. =A0We really don't need any kind of content-type encod= ing or tagging in this protocol (or the meta-application-protocol you'r= e suggesting) at all except for the one convenience case. =A0I don't th= ink I'd even want it to get any more complex than utf-8 vs. raw binary.= =A0The simplicity of that limitation is what makes it so convenient for so= many things.

The thing is.. there really are only two types of messages. = =A0It's not that hard. =A0And since utf-8 is "The One True Encodin= g," there is no need for misdirection in talking about antiquated prob= lems like character set conversions or line-ending mangling or anything els= e of that sort. =A0The text frame is a simple additional case that's re= ally not that hard to comprehend in the specification's current format.= =A0I got through building my Websocket client & server implementation = with shockingly few questions, and had none about the distinction between t= ext or binary messages, or when to use or not to use utf-8.

The formality of separating all that into its own speci= fication, like many other things discussed on this working group, could abs= olutely be done in a later revision of the protocol, where the "text&q= uot; message would be deprecated in favor of using only the "binary&qu= ot; message type in conjunction with the new meta-application-level protoco= l that you're suggesting. =A0I feel exceptionally strongly against hold= ing up the release of WebSockets for this issue.

Cheers,
Brian

On Tue, Aug 23, 2011 at 3:17 AM, Bob Gezelter <gezelter@rlgsc.com> wrote:<= br>
Brian,

For clarity, I am combining my response to your messages from 0457Z and
0520Z today into a single message. I have correspondingly merged the
CC'courtesy lists.

Your posting crystallized an issue that has long disturbed me about the
WebSocket protocol specification, the co-characterization of what are
deemed protocol extensions (e.g., John's multiplexing draft) with user<= br> applications protocols. In architectural terms, one (multiplexing) is a
horizontal technology, applicable to all protocol users; the other is a
vertical, useful to to a discrete, far smaller audience.

By this token, I also respectfully disagree with Bruce's comment about<= br> reassigning op codes.

This commingling produces the appearance of cross-connections where
there are truly none. It is also not necessary.

The binary/text dichotomy is an artifact of the original conception. I
agree (emphasis: AGREE) that the programmer's ability to send text
messages FROM THE WEBSOCKET API (WSAPI) SHOULD REMAIN UNCHANGED
[apologies for the capitalization, but there is no other way to show
emphasis in US ASCII-7].

Recently, it was observed that the desired state was to be able to
interleave, on a message-to-message basis, text and binary messages on a single channel. The precise reference was to text control messages, and
a binary version of a JSON object. This example is reasonable, but it
also illuminates my point: There must be far more agreement between the
respective communicating entities than the text/binary dichotomy.

I forget the message, but it was also raised that imposing the
UTF-8/binary transformation on the programmer is unreasonable. Once
again, I agree with the statement, but NOT WITH THE END RESULT.

The present Structure is:

Client WSAPI
=A0|
Client WebSocket Protocol (text/binary records)
=A0|
Server WebSocket Protocol (text/binary records)
=A0|
Server WSAPI

What I am proposing is:

Client WSAPI
=A0|
Client WSAPI App (text/binary records)
=A0 =A0 |
=A0 Client WebSocket Protocol (binary records)
=A0 =A0 |
=A0 Server WebSocket Protocol (binary records)
=A0 =A0 |
Server WSAPI App (text/binary records)
=A0|
Server WSAPI

Despite the change in the structure diagram, I must emphasize that this
change is almost completely an editorial change in documentation. There
are no needs for additional layers of code. All code already exists in
WSAPI. The one change is the elimination of the text/binary dichotomy at the level of the WebSocket protocol and the corresponding change in a
handful of parameter lists and data structures. User code that runs
today before the change runs tomorrow after the change.

You put it well, that the purpose of WebSockets (the API) is to enable
JavaScript programmers to easily develop browser-based communications.
None of the changes that I am proposing will have any effect on those
JavaScript programmers.

It will have a positive effect however, on the wide-range of developers
who need to develop tools and devices where a thorough understanding of
the protocol is essential to ensure correct operation.

- Bob Gezelter, http://w= ww.rlgsc.com


--001517477fa0e4af7c04ab2ad41b-- From ibc@aliax.net Tue Aug 23 04:54: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 E8A7E21F8AE9 for ; Tue, 23 Aug 2011 04:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pASbAo5fWfsQ for ; Tue, 23 Aug 2011 04:54: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 53C3021F886D for ; Tue, 23 Aug 2011 04:54:58 -0700 (PDT) Received: by qyk34 with SMTP id 34so1918661qyk.10 for ; Tue, 23 Aug 2011 04:56:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.114.139 with SMTP id e11mr2084658qcq.261.1314100565736; Tue, 23 Aug 2011 04:56:05 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 04:56:04 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 23 Aug 2011 13:56:04 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Sylvain Hellegouarch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 11:54:59 -0000 2011/8/23 Sylvain Hellegouarch : >> Nobody making an HTTP=C2=A0library for language XXXX implements HTTP con= nection >> reuse or=C2=A0pipeline. > > No idea where you get that from. There's a difference between implementin= g a > feature and using it. Pipelining has proven to be complex too use but mos= t > servers and clients do implement it. > Keep-alive is actually quite used. Sorry, let me refactor my statement: "Nobody using an HTTP library implementing HTTP connection reuse or pipeline makes usage if such features". >> Lazy developers assume that each application request uses >> single TCP connection which must be closed after getting the response. >> Do you imagine a smartphone application using an HTTP library and >> opening a new TCP connection for each "message"? > > > Is it the role of specification to handle lazy developers? In other mails I've clearly read that WS is intented for "just-frontend-web-developers" (along with more experienced developers, of course). So yes, one of the WS specification targets is to make WS usage easy for web developers (just 5-6 JavaScript functions, no more). >> WebSocket could help here. If there appear (and there are) WebSocket >> libraries for any language, a developer could use them to build an >> application running out of a webbrowser (i.e. an smartphone). The >> developer gets, by free, a message boundary protocol (simple API) and >> a standarized protocol which, probably, will be implemented by many >> services offering content not just via a web browser. Using raw TCP is >> not the solution, as currently people prefers to build an ugly >> HTTP-polling solution rather than dealing with TCP. > > > People use HTTP-polling from a browser because you don't have any other > alternative due to the nature of HTTP. Raw sockets aren't available from > JavaScript hence a middle ground which is WS. I was speaking about non-web-browsers apps which use HTTP rather than a bidirectional protocol on top of TCP. >> There are a lot of smartphone applications which "imitate" the web >> browser interface (but they are not html browsers, but phone native >> applications). Examples: Facebook chat, Twitter messenger, and so on. >> >> Am I really the only one assuming that WebSocket is the perfect >> protocol for those NON-web-browsers applications (think in smartphones >> please) which currently use HTTP for communicating with the server? > > > WebSocket is probably an interesting protocol on mobile devices indeed an= d > I, for one, already play with it in that context. :) --=20 I=C3=B1aki Baz Castillo From daniel@haxx.se Tue Aug 23 05:00: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 0291821F8511 for ; Tue, 23 Aug 2011 05:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.915 X-Spam-Level: X-Spam-Status: No, score=-3.915 tagged_above=-999 required=5 tests=[AWL=-1.966, BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QildDfGapQFK for ; Tue, 23 Aug 2011 05:00:05 -0700 (PDT) Received: from giant.haxx.se (www.haxx.se [IPv6:2a00:1a28:1200:9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE4D21F84AC for ; Tue, 23 Aug 2011 05:00:04 -0700 (PDT) Received: from giant.haxx.se (giant.haxx.se [80.67.6.50]) by giant.haxx.se (8.14.4/8.14.4/Debian-2) with ESMTP id p7NC11m3024402; Tue, 23 Aug 2011 14:01:01 +0200 Date: Tue, 23 Aug 2011 14:01:01 +0200 (CEST) From: Daniel Stenberg X-X-Sender: dast@giant.haxx.se To: =?ISO-8859-15?Q?I=F1aki_Baz_Castillo?= In-Reply-To: Message-ID: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) X-fromdanielhimself: yes MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1129329158-1503030962-1314100861=:22257" X-Greylist: Default is to whitelist mail, not delayed by milter-greylist-4.3.8 (giant.haxx.se [80.67.6.50]); Tue, 23 Aug 2011 14:01:01 +0200 (CEST) Cc: "hybi@ietf.org" Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 12:00:06 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1129329158-1503030962-1314100861=:22257 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 23 Aug 2011, Iñaki Baz Castillo wrote: > "Nobody using an HTTP library implementing HTTP connection reuse or pipeline > makes usage if such features". Having implemented and worked with HTTP libraries for many years, I strongly disagree with this statement. I believe you're just guessing here without having any facts at hand. [and now I'll go back and lurk again] -- / daniel.haxx.se --1129329158-1503030962-1314100861=:22257-- From theturtle32@gmail.com Tue Aug 23 05:13: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 C168721F8AD2 for ; Tue, 23 Aug 2011 05:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.181 X-Spam-Level: X-Spam-Status: No, score=-3.181 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_28=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ft+-k5Oq+qOn for ; Tue, 23 Aug 2011 05:13:36 -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 C09F721F8A56 for ; Tue, 23 Aug 2011 05:13:35 -0700 (PDT) Received: by bkar4 with SMTP id r4so36795bka.31 for ; Tue, 23 Aug 2011 05:14:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RSInu3Za0SwCf9qm989pJxVQNob6IUBE6p/U+XXhNVU=; b=OOGzg+62z6q7onb5DVzb/Y8rfAaojx7Z9dTi3u7typ8+kcO0fYySF0pVORu2cK6JmG ofyv0oB65BbkbV5XVN2E3G9YGWXBa4Cys06dgnjtyB/2nn6AKuvMRb4M1wj9NtJ4b6+f kQ9hWeWdNxe4tKvMYD46Nr4wHbTE36/hh0lsU= MIME-Version: 1.0 Received: by 10.204.133.10 with SMTP id d10mr1471737bkt.292.1314101682607; Tue, 23 Aug 2011 05:14:42 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Tue, 23 Aug 2011 05:14:42 -0700 (PDT) In-Reply-To: References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> Date: Tue, 23 Aug 2011 05:14:42 -0700 Message-ID: From: Brian To: Bob Gezelter Content-Type: multipart/alternative; boundary=0015174791b2fd96c904ab2b2365 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 12:13:37 -0000 --0015174791b2fd96c904ab2b2365 Content-Type: text/plain; charset=ISO-8859-1 One more comment.. All this over-engineering business about separating out the existing super-simple text vs. binary distinction reminds me frighteningly of the famous hammer factory factories in this classic rant on the Joel on Software forums here: http://discuss.joelonsoftware.com/default.asp?joel.3.219431 On Tue, Aug 23, 2011 at 4:52 AM, Brian wrote: > I get what you're saying here, but how can today's code (separate text vs. > binary opcodes) interoperate with "tomorrow's" spec (only a binary opcode)? > JavaScript code using the WebSocket API could remain unchanged, yes, but in > order to perform the separation you're suggesting, there would have to be > some kind of preamble in the application data section of the binary frame to > indicate whether to interpret the data as UTF-8, and according to your > suggestion as I understand it, that preamble would be under the purview of a > separate specification. And to what end really? > > This is all so simple and straightforward already I really don't see the > point of the extra bureaucratic nonsense required to perform such an > extraction. I would be opposed to based on the extra red-tape, delays (no > matter how short you feel they might be), and the formation of yet another > working group to build yet another specification. I can't imagine that > could all get done in any less 6 months, optimistically speaking. The > concept of separating out the tagging of "content-type" is a fine idea on > its own, but given that we're all getting really antsy for this protocol to > be released, it's incredibly depressing to think about doing something like > that for such a simple two-case scenario, especially when we're so close to > the finish line. > > It's not like we support arbitrary content types or text encodings. The > understanding of how to interpret the contents of text or binary messages, > whether to expect text messages, binary messages, or both, is all up to the > end-user of the WebSocket API when he defines the subprotocol for his > individual specific application. Most such developers will simply use JSON > in "text" messages because it's easy, and users that want to use a binary > format will define which serialization format to use for their newly-minted > "SuperUltraChat" subprotocol as they please. We really don't need any kind > of content-type encoding or tagging in this protocol (or the > meta-application-protocol you're suggesting) at all except for the one > convenience case. I don't think I'd even want it to get any more complex > than utf-8 vs. raw binary. The simplicity of that limitation is what makes > it so convenient for so many things. > > The thing is.. there really are only two types of messages. It's not that > hard. And since utf-8 is "The One True Encoding," there is no need for > misdirection in talking about antiquated problems like character set > conversions or line-ending mangling or anything else of that sort. The text > frame is a simple additional case that's really not that hard to comprehend > in the specification's current format. I got through building my Websocket > client & server implementation with shockingly few questions, and had none > about the distinction between text or binary messages, or when to use or not > to use utf-8. > > The formality of separating all that into its own specification, like many > other things discussed on this working group, could absolutely be done in a > later revision of the protocol, where the "text" message would be deprecated > in favor of using only the "binary" message type in conjunction with the new > meta-application-level protocol that you're suggesting. I feel > exceptionally strongly against holding up the release of WebSockets for this > issue. > > Cheers, > Brian > > > On Tue, Aug 23, 2011 at 3:17 AM, Bob Gezelter wrote: > >> Brian, >> >> For clarity, I am combining my response to your messages from 0457Z and >> 0520Z today into a single message. I have correspondingly merged the >> CC'courtesy lists. >> >> Your posting crystallized an issue that has long disturbed me about the >> WebSocket protocol specification, the co-characterization of what are >> deemed protocol extensions (e.g., John's multiplexing draft) with user >> applications protocols. In architectural terms, one (multiplexing) is a >> horizontal technology, applicable to all protocol users; the other is a >> vertical, useful to to a discrete, far smaller audience. >> >> By this token, I also respectfully disagree with Bruce's comment about >> reassigning op codes. >> >> This commingling produces the appearance of cross-connections where >> there are truly none. It is also not necessary. >> >> The binary/text dichotomy is an artifact of the original conception. I >> agree (emphasis: AGREE) that the programmer's ability to send text >> messages FROM THE WEBSOCKET API (WSAPI) SHOULD REMAIN UNCHANGED >> [apologies for the capitalization, but there is no other way to show >> emphasis in US ASCII-7]. >> >> Recently, it was observed that the desired state was to be able to >> interleave, on a message-to-message basis, text and binary messages on a >> single channel. The precise reference was to text control messages, and >> a binary version of a JSON object. This example is reasonable, but it >> also illuminates my point: There must be far more agreement between the >> respective communicating entities than the text/binary dichotomy. >> >> I forget the message, but it was also raised that imposing the >> UTF-8/binary transformation on the programmer is unreasonable. Once >> again, I agree with the statement, but NOT WITH THE END RESULT. >> >> The present Structure is: >> >> Client WSAPI >> | >> Client WebSocket Protocol (text/binary records) >> | >> Server WebSocket Protocol (text/binary records) >> | >> Server WSAPI >> >> What I am proposing is: >> >> Client WSAPI >> | >> Client WSAPI App (text/binary records) >> | >> Client WebSocket Protocol (binary records) >> | >> Server WebSocket Protocol (binary records) >> | >> Server WSAPI App (text/binary records) >> | >> Server WSAPI >> >> Despite the change in the structure diagram, I must emphasize that this >> change is almost completely an editorial change in documentation. There >> are no needs for additional layers of code. All code already exists in >> WSAPI. The one change is the elimination of the text/binary dichotomy at >> the level of the WebSocket protocol and the corresponding change in a >> handful of parameter lists and data structures. User code that runs >> today before the change runs tomorrow after the change. >> >> You put it well, that the purpose of WebSockets (the API) is to enable >> JavaScript programmers to easily develop browser-based communications. >> None of the changes that I am proposing will have any effect on those >> JavaScript programmers. >> >> It will have a positive effect however, on the wide-range of developers >> who need to develop tools and devices where a thorough understanding of >> the protocol is essential to ensure correct operation. >> >> - Bob Gezelter, http://www.rlgsc.com >> >> > --0015174791b2fd96c904ab2b2365 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One more comment.. All this over-engineering business about separating out = the existing super-simple text vs. binary distinction reminds me frightenin= gly of the famous hammer factory factories in this classic rant on the Joel= on Software forums here:=A0http://discuss.joelonsoftware.com/default.asp?joel= .3.219431

On Tue, Aug 23, 2011 at 4:52 AM, Brian <theturtle32@gmail= .com> wrote:
I get what you're saying here, but how can today's code (separate t= ext vs. binary opcodes) interoperate with "tomorrow's" spec (= only a binary opcode)? =A0JavaScript code using the WebSocket API could rem= ain unchanged, yes, but in order to perform the separation you're sugge= sting, there would have to be some kind of preamble in the application data= section of the binary frame to indicate whether to interpret the data as U= TF-8, and according to your suggestion as I understand it, that preamble wo= uld be under the purview of a separate specification. =A0And to what end re= ally?

This is all so simple and straightforward already I really d= on't see the point of the extra bureaucratic nonsense required to perfo= rm such an extraction. =A0I would be opposed to based on the extra red-tape= , delays (no matter how short you feel they might be), and the formation of= yet another working group to build yet another specification. =A0I can'= ;t imagine that could all get done in any less 6 months, optimistically spe= aking. =A0The concept of separating out the tagging of "content-type&q= uot; is a fine idea on its own, but given that we're all getting really= antsy for this protocol to be released, it's incredibly depressing to = think about doing something like that for such a simple two-case scenario, = especially when we're so close to the finish line.

It's not like we support arbitrary content types or= text encodings. =A0The understanding of how to interpret the contents of t= ext or binary messages, whether to expect text messages, binary messages, o= r both, is all up to the end-user of the WebSocket API when he defines the = subprotocol for his individual specific application. =A0Most such developer= s will simply use JSON in "text" messages because it's easy, = and users that want to use a binary format will define which serialization = format to use for their newly-minted "SuperUltraChat" subprotocol= as they please. =A0We really don't need any kind of content-type encod= ing or tagging in this protocol (or the meta-application-protocol you'r= e suggesting) at all except for the one convenience case. =A0I don't th= ink I'd even want it to get any more complex than utf-8 vs. raw binary.= =A0The simplicity of that limitation is what makes it so convenient for so= many things.

The thing is.. there really are only two types of messages. = =A0It's not that hard. =A0And since utf-8 is "The One True Encodin= g," there is no need for misdirection in talking about antiquated prob= lems like character set conversions or line-ending mangling or anything els= e of that sort. =A0The text frame is a simple additional case that's re= ally not that hard to comprehend in the specification's current format.= =A0I got through building my Websocket client & server implementation = with shockingly few questions, and had none about the distinction between t= ext or binary messages, or when to use or not to use utf-8.

The formality of separating all that into its own speci= fication, like many other things discussed on this working group, could abs= olutely be done in a later revision of the protocol, where the "text&q= uot; message would be deprecated in favor of using only the "binary&qu= ot; message type in conjunction with the new meta-application-level protoco= l that you're suggesting. =A0I feel exceptionally strongly against hold= ing up the release of WebSockets for this issue.

Cheers,
Brian


On Tue, Aug 23, 2011 at 3:17 AM, Bob G= ezelter <gezelter@rlgsc.com> wrote:
Brian,

For clarity, I am combining my response to your messages from 0457Z and
0520Z today into a single message. I have correspondingly merged the
CC'courtesy lists.

Your posting crystallized an issue that has long disturbed me about the
WebSocket protocol specification, the co-characterization of what are
deemed protocol extensions (e.g., John's multiplexing draft) with user<= br> applications protocols. In architectural terms, one (multiplexing) is a
horizontal technology, applicable to all protocol users; the other is a
vertical, useful to to a discrete, far smaller audience.

By this token, I also respectfully disagree with Bruce's comment about<= br> reassigning op codes.

This commingling produces the appearance of cross-connections where
there are truly none. It is also not necessary.

The binary/text dichotomy is an artifact of the original conception. I
agree (emphasis: AGREE) that the programmer's ability to send text
messages FROM THE WEBSOCKET API (WSAPI) SHOULD REMAIN UNCHANGED
[apologies for the capitalization, but there is no other way to show
emphasis in US ASCII-7].

Recently, it was observed that the desired state was to be able to
interleave, on a message-to-message basis, text and binary messages on a single channel. The precise reference was to text control messages, and
a binary version of a JSON object. This example is reasonable, but it
also illuminates my point: There must be far more agreement between the
respective communicating entities than the text/binary dichotomy.

I forget the message, but it was also raised that imposing the
UTF-8/binary transformation on the programmer is unreasonable. Once
again, I agree with the statement, but NOT WITH THE END RESULT.

The present Structure is:

Client WSAPI
=A0|
Client WebSocket Protocol (text/binary records)
=A0|
Server WebSocket Protocol (text/binary records)
=A0|
Server WSAPI

What I am proposing is:

Client WSAPI
=A0|
Client WSAPI App (text/binary records)
=A0 =A0 |
=A0 Client WebSocket Protocol (binary records)
=A0 =A0 |
=A0 Server WebSocket Protocol (binary records)
=A0 =A0 |
Server WSAPI App (text/binary records)
=A0|
Server WSAPI

Despite the change in the structure diagram, I must emphasize that this
change is almost completely an editorial change in documentation. There
are no needs for additional layers of code. All code already exists in
WSAPI. The one change is the elimination of the text/binary dichotomy at the level of the WebSocket protocol and the corresponding change in a
handful of parameter lists and data structures. User code that runs
today before the change runs tomorrow after the change.

You put it well, that the purpose of WebSockets (the API) is to enable
JavaScript programmers to easily develop browser-based communications.
None of the changes that I am proposing will have any effect on those
JavaScript programmers.

It will have a positive effect however, on the wide-range of developers
who need to develop tools and devices where a thorough understanding of
the protocol is essential to ensure correct operation.

- Bob Gezelter, http://w= ww.rlgsc.com



--0015174791b2fd96c904ab2b2365-- From ibc@aliax.net Tue Aug 23 06:27: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 81C7E21F8B0A for ; Tue, 23 Aug 2011 06:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kkmchUITL3Mv for ; Tue, 23 Aug 2011 06:27:25 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id B79BC21F8AEC for ; Tue, 23 Aug 2011 06:27:25 -0700 (PDT) Received: by gxk19 with SMTP id 19so96660gxk.31 for ; Tue, 23 Aug 2011 06:28:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.253.16 with SMTP id a16mr3622325ybi.147.1314106112428; Tue, 23 Aug 2011 06:28:32 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Tue, 23 Aug 2011 06:28:32 -0700 (PDT) In-Reply-To: <20110823044746.ef1fc80126c74c6c202a919c41c7bb0b.c46bfbdbee.wbe@email03.secureserver.net> References: <20110823044746.ef1fc80126c74c6c202a919c41c7bb0b.c46bfbdbee.wbe@email03.secureserver.net> Date: Tue, 23 Aug 2011 15:28:32 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bob Gezelter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Retitled: Use of Schemes (was: RE: Binary/Text Distinction) 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, 23 Aug 2011 13:27:26 -0000 2011/8/23 Bob Gezelter : > Inaki, > > With all due respect, I disagree. > > The URI RFC (RFC 2396) defines "scheme". There are several relevant > passages, but one in particular is in section 1.2, to wit: > > =C2=A0" ... Although many URL schemes are named after protocols, this doe= s > not > =C2=A0 imply that the only way to access the URL's resource is via the na= med > =C2=A0 protocol. =C2=A0Gateways, proxies, caches, and name resolution ser= vices > =C2=A0 might be used to access some resources, independent of the protoco= l > =C2=A0 of their origin, and the resolution of some URL may require the us= e > =C2=A0 of more than one protocol (e.g., both DNS and HTTP are typically u= sed > =C2=A0 to access an "http" URL's resource when it can't be found in a loc= al > =C2=A0 cache). ..." It changes nothing (IMHO). Imagine the case in which you send, via SMTP/SIP/XMPP/whatever-protocol, a WS request with RURI wsc://domain.org, or a WS request with RURI ws://domain.org?transport=3Dsctp (assuming both are valid). In both cases the server (acting as a really exotic gateway) should route the request using WebSocket under SCTP. What I mean is that the usage of the URI schema or an URI transport is not the key as the result would be the very same. Anyhow, I've realized that in HTTP / WS URI's there are not "URI params", but just "URI headers", and such headers seem to belong to the application level so it would be a bad place for setting such a transport indicator. > My point was that using the URI scheme to indicate the underlying > transport used by a WebSocket protocol connection is very low impact. > The actual choice of scheme name is, frankly an irrelevancy. If the > trailing "s" has esthetic benefits, one can easily use "wcs:/wcss:" or > "wssctp:/wssctps:"; there is no downside to an even longer scheme name > (e.g., "websocket-sctp:/websocket-sctp-s:"; note, I do not recall if RFC > 2396 permits hyphens, but the point is made regardless). > A change in the scheme also permits the least impact on the code that > parses inbound URIs at the application level. Sure. Even more in HTTP URI's where URI headers ( ?lalala=3Dfoo&lololo=3Dbaz ) are "application" data rather than URI's properties. Anyhow, given the fact that WS is purely oriented to TCP and JavaScript, I strongly expect that nobody will care about another layer 4 transport for WebSocket within next 20 years. Regards. --=20 I=C3=B1aki Baz Castillo From gezelter@rlgsc.com Tue Aug 23 06:53: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 0CE4421F8B2F for ; Tue, 23 Aug 2011 06:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7gD6HU4SOjO for ; Tue, 23 Aug 2011 06:53:18 -0700 (PDT) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id 4252D21F8563 for ; Tue, 23 Aug 2011 06:53:17 -0700 (PDT) Received: (qmail 25848 invoked from network); 23 Aug 2011 13:54:22 -0000 Received: from unknown (HELO localhost) (72.167.218.130) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 23 Aug 2011 13:54:22 -0000 Received: (qmail 10489 invoked by uid 99); 23 Aug 2011 13:54:22 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110823065421.ef1fc80126c74c6c202a919c41c7bb0b.6881ff4e09.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "Brian" Date: Tue, 23 Aug 2011 06:54:21 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: [hybi] (partial) RE: Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 13:53:19 -0000 Brian,=0A=0A"We can do this later" is in effect a "straw man". The Internet= =0Acommunity has had no shortage of such episodes. A few years ago, I was= =0Aasked to do a book chapter on the evolution of electronic mail. When I= =0Adug into the historical record, I found that there was a reason that our= =0Astandard mail transport is "SMTP" (the "S" stands for "Simple").=0A=0AMa= ny problems were to be solved when the true mail transport was=0Afinished, = but SMTP usage hit critical mass, and the issue of backwards=0Acompatibilit= y raised its head. We are still dealing with the mayhem=0Acaused by using a= "demonstration" technology in production.=0A=0AWe are having a similar pro= blem with IPv6. It has been many years, but=0Athe huge mass of installed pr= oduction infrastructure is VERY slowly=0A(emphasis on the SLOWLY) being rep= laced. The main stimulus being address=0Aavailability. =0A=0AWhatever final= ly comes out of the process is what we will be stuck with=0Afor a good, lon= g time, for better or worse.=0A=0AThere is no need for another committee, t= his committee can easily=0Abifurcate the present draft specification into t= wo different documents. =0A=0AThe last time I checked, most of the implemen= tations of the WebSocket=0Aprotocol were not up to the latest version of th= e specification. =0A=0AIn terms of applications protocols, there are two di= stinct classes:=0Aclosed and documented. Closed connections are within a pa= ir of=0Aapplications written as a unitary entity, often between one or two= =0Aprogrammers working as a team. Often, the descriptions of such=0Ainterfa= ces are ad hoc, frequently defined, if at all, by comments in one=0Aor both= code bases. Such protocols can be widely deployed, but do not=0Aactively i= nvolve other parties. For these, bare text or bare JSON, is=0Aoften viable.= =0A=0ADocumented protocols involve many-to-one or many-to-many interactions= =0Abetween client-based applications and server-based information providers= =0Aof various forms. These applications protocols must be strictly=0Adocume= nted in their own right, to ensure that software developed by=0Adifferent t= eams can interoperate. =0A=0AI do not deny anyone the freedom to use "just = plain UTF-8/binary" as=0Athey wish. What I propose is simply a removal of t= he UTF-8/binary bit=0A(currently implicit in the OpCode) to part of the pay= load. and the=0Acorresponding small change to the current libraries. =0A=0A= My background in 35 years of systems internals and network-stack=0Aprogramm= ing informs this belief, I have spent far too much of my time=0Aand client'= s money correcting this type of semantic mixing. The=0Atransport component = has no need for the type differentiation (even less=0Athan previously, Java= Script now supports typed arrays).=0A=0AUser programs have to define the co= ntents to the extent that they find=0Aappropriate. A distinction between bi= nary and UTF-8 records in WSAPI is=0Areasonable, but it does not need to go= lower in the stack than that.=0A=0A- Bob Gezelter, http://www.rlgsc.com=0A= =0A[origial message removed to conserve bandwidth]=0A=0A From gezelter@rlgsc.com Tue Aug 23 07:02: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 E4E8521F8B5F for ; Tue, 23 Aug 2011 07:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.405 X-Spam-Level: X-Spam-Status: No, score=-2.405 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7Ct0XyUwBM6 for ; Tue, 23 Aug 2011 07:02:08 -0700 (PDT) Received: from smtpoutwbe07.prod.mesa1.secureserver.net (smtpoutwbe07.prod.mesa1.secureserver.net [208.109.78.209]) by ietfa.amsl.com (Postfix) with SMTP id 166B021F8B3E for ; Tue, 23 Aug 2011 07:02:00 -0700 (PDT) Received: (qmail 4720 invoked from network); 23 Aug 2011 14:03:08 -0000 Received: from unknown (HELO localhost) (72.167.218.134) by smtpoutwbe07.prod.mesa1.secureserver.net with SMTP; 23 Aug 2011 14:03:08 -0000 Received: (qmail 27885 invoked by uid 99); 23 Aug 2011 14:03:08 -0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-IP: 141.157.213.69 User-Agent: Web-Based Email 5.5.16 Message-Id: <20110823070306.ef1fc80126c74c6c202a919c41c7bb0b.38bec8f39e.wbe@email03.secureserver.net> From: "Bob Gezelter" To: "=?UTF-8?Q?I=C3=B1aki=5FBaz=5FCastillo?=" Date: Tue, 23 Aug 2011 07:03:06 -0700 Mime-Version: 1.0 Cc: "hybi@ietf.org" , Bjoern Hoehrmann Subject: Re: [hybi] Retitled: Use of Schemes (was: RE: Binary/Text Distinction) 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, 23 Aug 2011 14:02:09 -0000 Inaki,=0A=0AWith regards to be supremacy of TCP, that may or may not be so.= =0A=0AOne of the factors buttressing TCP is the inertia factor and the=0Adi= fficulty of migration. If there are significant advantages to a=0Adifferent= underlying protocol, and adoption of the other protocol is a=0Asimple matt= er of providing an additional DNS record, but no (or minimal)=0Aapplication= s-level changes, it is a different story.=0A=0AIt is often the risk of adop= tion versus the payoff, as well as the risk=0Aif one is wrong. The attracti= veness of what I propose is the=0Aminimization of the costs and the risks. = Defining the scheme as a=0Aparameter (or a DNS query) has little real cost,= and immense potential=0Apayoffs.=0A=0A- Bob Gezelter, http://www.rlgsc.com= =0A=0A=0A> -------- Original Message --------=0A> Subject: Re: Retitled: Us= e of Schemes (was: RE: [hybi] Binary/Text=0A> Distinction)=0A> From: I=C3= =B1aki_Baz_Castillo =0A> Date: Tue, August 23, 2011 6:28 am= =0A> To: Bob Gezelter =0A> Cc: Brian , "hybi@ietf.org" , =0A> Bjoern Hoehrmann , Tobias Oberstein=0A> =0A> =0A> =0A> 20= 11/8/23 Bob Gezelter :=0A> > Inaki,=0A> >=0A> > With al= l due respect, I disagree.=0A> >=0A> > The URI RFC (RFC 2396) defines "sche= me". There are several relevant=0A> > passages, but one in particular is in= section 1.2, to wit:=0A> >=0A> > =C2=A0" ... Although many URL schemes are= named after protocols, this does=0A> > not=0A> > =C2=A0 imply that the onl= y way to access the URL's resource is via the named=0A> > =C2=A0 protocol. = =C2=A0Gateways, proxies, caches, and name resolution services=0A> > =C2=A0 = might be used to access some resources, independent of the protocol=0A> > = =C2=A0 of their origin, and the resolution of some URL may require the use= =0A> > =C2=A0 of more than one protocol (e.g., both DNS and HTTP are typica= lly used=0A> > =C2=A0 to access an "http" URL's resource when it can't be f= ound in a local=0A> > =C2=A0 cache). ..."=0A> =0A> It changes nothing (IMHO= ). Imagine the case in which you send, via=0A> SMTP/SIP/XMPP/whatever-proto= col, a WS request with RURI=0A> wsc://domain.org, or a WS request with RURI= =0A> ws://domain.org?transport=3Dsctp (assuming both are valid).=0A> =0A> I= n both cases the server (acting as a really exotic gateway) should=0A> rout= e the request using WebSocket under SCTP. What I mean is that the=0A> usage= of the URI schema or an URI transport is not the key as the=0A> result wou= ld be the very same.=0A> =0A> Anyhow, I've realized that in HTTP / WS URI's= there are not "URI=0A> params", but just "URI headers", and such headers s= eem to belong to=0A> the application level so it would be a bad place for s= etting such a=0A> transport indicator.=0A> =0A> =0A> > My point was that us= ing the URI scheme to indicate the underlying=0A> > transport used by a Web= Socket protocol connection is very low impact.=0A> > The actual choice of s= cheme name is, frankly an irrelevancy. If the=0A> > trailing "s" has esthet= ic benefits, one can easily use "wcs:/wcss:" or=0A> > "wssctp:/wssctps:"; t= here is no downside to an even longer scheme name=0A> > (e.g., "websocket-s= ctp:/websocket-sctp-s:"; note, I do not recall if RFC=0A> > 2396 permits hy= phens, but the point is made regardless).=0A> =0A> > A change in the scheme= also permits the least impact on the code that=0A> > parses inbound URIs a= t the application level.=0A> =0A> Sure. Even more in HTTP URI's where URI h= eaders (=0A> ?lalala=3Dfoo&lololo=3Dbaz ) are "application" data rather tha= n URI's=0A> properties.=0A> =0A> =0A> Anyhow, given the fact that WS is pur= ely oriented to TCP and=0A> JavaScript, I strongly expect that nobody will = care about another=0A> layer 4 transport for WebSocket within next 20 years= .=0A> =0A> =0A> Regards.=0A> =0A> =0A> -- =0A> I=C3=B1aki Baz Castillo=0A> = =0A From jat@google.com Tue Aug 23 07:23: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 A1D6E21F8B56 for ; Tue, 23 Aug 2011 07:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.735 X-Spam-Level: X-Spam-Status: No, score=-105.735 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FlFMjHfrYBl7 for ; Tue, 23 Aug 2011 07:23:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF7F21F8B54 for ; Tue, 23 Aug 2011 07:23:00 -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 p7NEO4ra002521 for ; Tue, 23 Aug 2011 07:24:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314109444; bh=lVd0YWkcIYHimvZNKrtjrDlP0cY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=TY75D5I8490kvVRKLINT8isw/RiJ/gyZomOiu34DteF4pUwnD1p7lj92r65zpNLqY OS/utw4Hcy3dmNiEUEbdA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=dvQriCyqqAXWu9UICln2zOdnqEjw4U9GidZF9uaIJq4xaD0qEczJzD7/Moh0y3loJ k4ghjAKCNBugPmwzSoJeQ== Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by wpaz33.hot.corp.google.com with ESMTP id p7NEKG2o010893 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 07:24:03 -0700 Received: by qyk27 with SMTP id 27so2486886qyk.14 for ; Tue, 23 Aug 2011 07:24:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=M3bTFEEifhVmu34cdm2PoaCYaYtl0O70GUJkbP73RHI=; b=ogdCqZM2RTDgdA7eeJtu3yqP11HF+pl8IOsjU+yeE6h5JWcZESMw+OYWLqS8OLvlMg SjRceMvQ52ocnYQjbLxw== Received: by 10.229.246.2 with SMTP id lw2mr2267479qcb.228.1314109443228; Tue, 23 Aug 2011 07:24:03 -0700 (PDT) Received: by 10.229.246.2 with SMTP id lw2mr2267474qcb.228.1314109443093; Tue, 23 Aug 2011 07:24:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.137 with HTTP; Tue, 23 Aug 2011 07:23:43 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Tue, 23 Aug 2011 10:23:43 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=001485f92bf28d356704ab2cf22e X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 23 Aug 2011 14:23:01 -0000 --001485f92bf28d356704ab2cf22e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 23, 2011 at 7:01 AM, I=C3=B1aki Baz Castillo wr= ote: > So what about if a WS handshake requires two extensions ext1 and ext2, > and both extensions want to make usage of the same RSV1 bit? > Clearly if two extensions require use of the same fixed reserved bit, then they cannot both be used at the same time. If a client were to request both, the server would have to accept no more than one of them. At the point we need to allocate them, we can always define a standard for dynamically allocating them (which has been discussed here multiple times) if desired, and have an extension say that it uses that method. Given how hard it is to get agreement on anything here (witness the current debate of rolling the clock back a year and a half to remove text frames), it seems prudent to defer standardizing what we don't know we even need until we actually need it. --=20 John A. Tamplin Software Engineer (GWT), Google --001485f92bf28d356704ab2cf22e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 7:01 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
So what about if a WS handshake requires two extensions ext1 and ext2,
and both extensions want to make usage of the same RSV1 bit?

Clearly if two extensions require use of the same fi= xed reserved bit, then they cannot both be used at the same time. =C2=A0If = a client were to request both, the server would have to accept no more than= one of them.

At the point we need to allocate them, we can always define = a standard for dynamically allocating them (which has been discussed here m= ultiple times) if desired, and have an extension say that it uses that meth= od. =C2=A0Given how hard it is to get agreement on anything here (witness t= he current debate of rolling the clock back a year and a half to remove tex= t frames), it seems prudent to defer standardizing what we don't know w= e even need until we actually need it.

--
John A. Tamplin
Software Engineer (GWT), Google
--001485f92bf28d356704ab2cf22e-- From ibc@aliax.net Tue Aug 23 07:58: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 DCF6221F8AE4 for ; Tue, 23 Aug 2011 07:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0eomFi9iNCgz for ; Tue, 23 Aug 2011 07:58:25 -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 60B6321F8AE1 for ; Tue, 23 Aug 2011 07:58:25 -0700 (PDT) Received: by yie12 with SMTP id 12so179957yie.31 for ; Tue, 23 Aug 2011 07:59:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.253.16 with SMTP id a16mr3725333ybi.147.1314111573133; Tue, 23 Aug 2011 07:59:33 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Tue, 23 Aug 2011 07:59:33 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Aug 2011 16:59:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Takeshi Yoshino Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Close frame from webbrowser after close frame from server 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, 23 Aug 2011 14:58:26 -0000 2011/8/22 I=C3=B1aki Baz Castillo : > 2011/8/22 Takeshi Yoshino : >> Firefox 8.0a2 (2011-08-22) also responds server initiated close frame be= fore >> closing TCP here against pywebsocket. > > I have Firefox 9.0a1 (2011-08-19) and does not send the close frame > when it receives a close frame. Google 15.X does it. > I will recheck however. It was a bug in my WS server which was sending incorrectly the close frame. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Tue Aug 23 09:37: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 B67D321F8ACC for ; Tue, 23 Aug 2011 09:37:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uo5eS99mJTM for ; Tue, 23 Aug 2011 09:37:40 -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 EA67921F8906 for ; Tue, 23 Aug 2011 09:37:39 -0700 (PDT) Received: by qwc23 with SMTP id 23so242265qwc.31 for ; Tue, 23 Aug 2011 09:38:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr2439676qce.185.1314117527813; Tue, 23 Aug 2011 09:38:47 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 09:38:47 -0700 (PDT) Date: Tue, 23 Aug 2011 18:38:47 +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] Max frame size for a PING frame 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, 23 Aug 2011 16:37:40 -0000 Hi, is there any limit in the payload size of a ping control frame? I don't want to receive a 4GB big ping... Should a WS server allow a big text frame (i.e. 10MB) but disallow it in a control frame (as ping)? IMHO a ping frame should contain no more than... 16 bytes of data payload? note that ping control frame just works at "transport/framing" layer, it does not arrive to "WS application layer" (I hope). So, what would be the purpose of a big payload in such a control frame? --=20 I=C3=B1aki Baz Castillo From godjonez@codepad.info Tue Aug 23 09:39: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 4208A21F8AE4 for ; Tue, 23 Aug 2011 09:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wh5bd8zRWC3n for ; Tue, 23 Aug 2011 09:39:42 -0700 (PDT) Received: from smtpout.kotinet.com (smtpout.kotinet.com [212.50.215.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9E61921F8AD2 for ; Tue, 23 Aug 2011 09:39:42 -0700 (PDT) Received: from codepad.info (codepad.info [62.240.71.135]) by smtpout.kotinet.com (Postfix) with ESMTP id C9916E3024; Tue, 23 Aug 2011 19:40:47 +0300 (EEST) Received: from overwatchnexus.combinet (overwatchnexus.combinet [192.168.2.7]) by codepad.info (Postfix) with ESMTPSA id 78387F44001; Tue, 23 Aug 2011 19:40:49 +0300 (EEST) Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: hybi@ietf.org, =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= References: Date: Tue, 23 Aug 2011 19:40:50 +0300 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Joonas Lehtolahti" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.00 (Win32) Subject: Re: [hybi] Max frame size for a PING frame 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, 23 Aug 2011 16:39:43 -0000 On Tue, 23 Aug 2011 19:38:47 +0300, I=C3=B1aki Baz Castillo = wrote: > Hi, is there any limit in the payload size of a ping control frame? I > don't want to receive a 4GB big ping... > > Should a WS server allow a big text frame (i.e. 10MB) but disallow it > in a control frame (as ping)? > > IMHO a ping frame should contain no more than... 16 bytes of data > payload? note that ping control frame just works at > "transport/framing" layer, it does not arrive to "WS application > layer" (I hope). So, what would be the purpose of a big payload in > such a control frame? > Section 4.5: All control frames MUST have a payload length of 125 bytes or less and = MUST NOT be fragmented. So the maximum payload size is 125 bytes. From ibc@aliax.net Tue Aug 23 09:45: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 4C98721F8B1D for ; Tue, 23 Aug 2011 09:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ko7bZGHSB0l2 for ; Tue, 23 Aug 2011 09:45:01 -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 B690921F8B1F for ; Tue, 23 Aug 2011 09:45:01 -0700 (PDT) Received: by qwc23 with SMTP id 23so248091qwc.31 for ; Tue, 23 Aug 2011 09:46:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr2447502qce.185.1314117969683; Tue, 23 Aug 2011 09:46:09 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Tue, 23 Aug 2011 09:46:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Aug 2011 18:46:09 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Joonas Lehtolahti Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Max frame size for a PING frame 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, 23 Aug 2011 16:45:02 -0000 2011/8/23 Joonas Lehtolahti : > Section 4.5: > > All control frames MUST have a payload length of 125 bytes or less and MU= ST > NOT be fragmented. > > So the maximum payload size is 125 bytes. Opps, thanks a lot. I missed that. --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Tue Aug 23 09:45: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 5AF1921F8B25 for ; Tue, 23 Aug 2011 09:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.53 X-Spam-Level: X-Spam-Status: No, score=-2.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1BL1aL4sF+l for ; Tue, 23 Aug 2011 09:45:14 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id DD25621F8B1D for ; Tue, 23 Aug 2011 09:45:14 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qvu7J-00089G-4I; Tue, 23 Aug 2011 09:46:21 -0700 Message-ID: <4E53D952.1000202@callenish.com> Date: Tue, 23 Aug 2011 09:46:10 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Bob Gezelter References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> In-Reply-To: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> Content-Type: text/plain; charset=UTF-8; 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] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 16:45:15 -0000 On 23/08/2011 3:17 AM, Bob Gezelter wrote: > Your posting crystallized an issue that has long disturbed me about the > WebSocket protocol specification, the co-characterization of what are > deemed protocol extensions (e.g., John's multiplexing draft) with user > applications protocols. In architectural terms, one (multiplexing) is a > horizontal technology, applicable to all protocol users; the other is a > vertical, useful to to a discrete, far smaller audience. I agree that these are different things, but if by "co-characterization" you mean the spec mixes these two concepts, I disagree. There is a reason that there are two separate headers, one for extensions and one for the application protocol. On this list in the past there have been people who wondered at the difference between the two and asked why they could not be merged together, so I would agree that the two concepts could be more clearly defined and separated in the spec as it currently exists. I disagree a separate document is required. > By this token, I also respectfully disagree with Bruce's comment about > reassigning op codes. Fair enough, but perhaps you could explain why. I use application protocols in my native client that do not benefit from a binary/text split. If one recognizes the Javascript layer in a browser as an application layer (which becomes obvious when using native clients with a defined protocol header) then it becomes clear that the binary/text definition is a feature of the base application protocol required in a browser. There are enough opcodes for my needs so I don't actually need to reuse the binary and text opcodes, but I don't see why it shouldn't be allowed for other situations. Once you allow that the binary and text opcodes are part of an application protocol, it naturally falls out that they can be reused. > This commingling produces the appearance of cross-connections where > there are truly none. It is also not necessary. Perhaps you could expand on the commingling and the cross-connections. Where do you see that happening? From jat@google.com Tue Aug 23 09:49: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 ABBB221F8B1D for ; Tue, 23 Aug 2011 09:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.924 X-Spam-Level: X-Spam-Status: No, score=-105.924 tagged_above=-999 required=5 tests=[AWL=0.052, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nui11xVEvFRM for ; Tue, 23 Aug 2011 09:49:15 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id DA29E21F8AEA for ; Tue, 23 Aug 2011 09:49:14 -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 p7NGoLII023464 for ; Tue, 23 Aug 2011 09:50:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314118222; bh=gUp9BhE489P9TjCf1RmLUt+WrkA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=fJg0x0dG42xzB4Y6RFabccMY6CCPeaIL7hAiyVO9RowHe5xwqUHRzo2Gs+r/U2JFd 19v112OiYezvxKHHALitA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=SlrByrkb+TpLP0w5mNDmTLuTckOYpw+yr5NnfrYUQfP4InGphDgwxxZ0Izc7lX3VK JHZN5CZSXCsxPo7BA1Eew== Received: from qyk27 (qyk27.prod.google.com [10.241.83.155]) by wpaz33.hot.corp.google.com with ESMTP id p7NGmiuO032102 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 09:50:20 -0700 Received: by qyk27 with SMTP id 27so2038927qyk.7 for ; Tue, 23 Aug 2011 09:50:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NO4tT30jV3nV4TLsG2LhLg5226OX5owQdgPehOMz2Iw=; b=Y70TMc3y99T64wVzZPmYNTKe/EwmAoSXG6avQdAbqseIe3CrOkji7RdJK42jK3PPaT IQ+vitDYenosS0YXzagw== Received: by 10.229.246.2 with SMTP id lw2mr2421832qcb.228.1314118220271; Tue, 23 Aug 2011 09:50:20 -0700 (PDT) Received: by 10.229.246.2 with SMTP id lw2mr2421824qcb.228.1314118220085; Tue, 23 Aug 2011 09:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.137 with HTTP; Tue, 23 Aug 2011 09:50:00 -0700 (PDT) In-Reply-To: <4E53D952.1000202@callenish.com> References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> From: John Tamplin Date: Tue, 23 Aug 2011 12:50:00 -0400 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=001485f92bf2b37b2704ab2efd44 X-System-Of-Record: true Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 16:49:15 -0000 --001485f92bf2b37b2704ab2efd44 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2011 at 12:46 PM, Bruce Atherton wrote: > Fair enough, but perhaps you could explain why. I use application protocols > in my native client that do not benefit from a binary/text split. If one > recognizes the Javascript layer in a browser as an application layer (which > becomes obvious when using native clients with a defined protocol header) > then it becomes clear that the binary/text definition is a feature of the > base application protocol required in a browser. > If you allow subprotocols to change the meaning of the framing, then you essentially have an extension not a subprotocol, as it means no intermediary can do anything with your frame if it doesn't understand it, a MUX extension can't aggregate frames in a different subprotocol, etc. What exactly does the subprotocol benefit from being on WebSocket if it change the base framing? -- John A. Tamplin Software Engineer (GWT), Google --001485f92bf2b37b2704ab2efd44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 12:46 PM, Bruce Atherton= <bruce@calleni= sh.com> wrote:
Fair enough, but perhaps you could explain why. I use app= lication protocols in my native client that do not benefit from a binary/te= xt split. If one recognizes the Javascript layer in a browser as an applica= tion layer (which becomes obvious when using native clients with a defined = protocol header) then it becomes clear that the binary/text definition is a= feature of the base application protocol required in a browser.

If you allow subprotocols to change the me= aning of the framing, then you essentially have an extension not a subproto= col, as it means no intermediary can do anything with your frame if it does= n't understand it, a MUX extension can't aggregate frames in a diff= erent subprotocol, etc. =C2=A0What exactly does the subprotocol benefit fro= m being on WebSocket if it change the base framing?

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--001485f92bf2b37b2704ab2efd44-- From bruce@callenish.com Tue Aug 23 10:47:11 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 7715421F8B95 for ; Tue, 23 Aug 2011 10:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VNzdbw6Wijr1 for ; Tue, 23 Aug 2011 10:47:11 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id F16CE21F8B94 for ; Tue, 23 Aug 2011 10:47:10 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1Qvv5F-0007OC-Kl; Tue, 23 Aug 2011 10:48:17 -0700 Message-ID: <4E53E7D6.8040601@callenish.com> Date: Tue, 23 Aug 2011 10:48:06 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: John Tamplin References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 17:47:11 -0000 On 23/08/2011 9:50 AM, John Tamplin wrote: > If you allow subprotocols to change the meaning of the framing, then > you essentially have an extension not a subprotocol, as it means no > intermediary can do anything with your frame if it doesn't understand > it, a MUX extension can't aggregate frames in a different subprotocol, > etc. What exactly does the subprotocol benefit from being on > WebSocket if it change the base framing? I'm not talking about changing the framing. I am talking about using the opcode field that is already there, but allowing different subprotocols to define how to interpret it. I guess changing the definition of the binary and text opcodes could be seen as changing the framing given how the spec is currently written, but that could be changed editorially with no impact to anyone. Just identify those opcodes as being defined that way when no subprotocol is specified or when subprotocols are defined but need to differentiate binary and text messages (ie. all subprotocols used in the browser). That would solve the issue that Bob and Iñaki have with application protocol issues getting into the base spec, and it wouldn't require a separate document. Or leave it alone as a bit of leakage of application level concerns into the base spec, but let subprotocols define the other reserved opcodes. Looking through the spec, though, I see that there is no reference to allowing a subprotocol to use reserved opcodes. I thought they were available for use by both extensions and subprotocols. My mistake for making that assumption. I guess my question now is, why not? The opcode is a useful way to determine how to handle different message types, as the example for handling binary and text in Javascript shows. I can tell you from experience that it comes in handy for other application protocols as well. I don't understand your claim that a subprotocol defining opcodes disallows the aggregation of frames. The opcode is only used on the first frame of a message in any case. Are you thinking that an intermediary or MUX extension will merge frames from different messages somehow? If not, then why would it matter if the intermediary or MUX extension understands the opcode for a particular subprotocol? That would be an application-only concern. From jat@google.com Tue Aug 23 11:01: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 CFA6F21F8ADC for ; Tue, 23 Aug 2011 11:01:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.926 X-Spam-Level: X-Spam-Status: No, score=-105.926 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojr3RhRb7VTO for ; Tue, 23 Aug 2011 11:01:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D33A821F8A97 for ; Tue, 23 Aug 2011 11:01:51 -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 p7NI2sZp006100 for ; Tue, 23 Aug 2011 11:02:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314122575; bh=5wXK1FkDRheU2+OAjxMshlCuwLU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=VgN52TzPxmtgsTbsrJSuTnsnxyG+hwQLacbsHapeVHfSv8Hs5wPiskHmv1FEifP/X +qFmo/VUbK08glKaL5MSQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=f2YEgHHmzZ985yqHlZgvqsRVMzLxj63unRZ2n2aiFX4/LLvjeqJ8gAGD2NT+9kPvV 5LrU5bYjl5T7WhOKKIk/g== Received: from qyk9 (qyk9.prod.google.com [10.241.83.137]) by wpaz13.hot.corp.google.com with ESMTP id p7NI2r6N023259 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 11:02:53 -0700 Received: by qyk9 with SMTP id 9so347044qyk.13 for ; Tue, 23 Aug 2011 11:02:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=fr8P2ZjiJZ4Gp05gUWoROhcll9Z3Kmo1mA7tjIMJrSs=; b=h2PD5Y+2vGeDSqAvBBhmyCB+YTtHI7AndLVy/ccoFb4p79IdkNcHsROzBOFtPBLRAX U1damWQQ0oT93RzSz1cw== Received: by 10.229.213.12 with SMTP id gu12mr1496060qcb.189.1314122573282; Tue, 23 Aug 2011 11:02:53 -0700 (PDT) Received: by 10.229.213.12 with SMTP id gu12mr1496054qcb.189.1314122573142; Tue, 23 Aug 2011 11:02:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.137 with HTTP; Tue, 23 Aug 2011 11:02:33 -0700 (PDT) In-Reply-To: <4E53E7D6.8040601@callenish.com> References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> <4E53E7D6.8040601@callenish.com> From: John Tamplin Date: Tue, 23 Aug 2011 14:02:33 -0400 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=00163630e8cb29d9c204ab300118 X-System-Of-Record: true Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 18:01:52 -0000 --00163630e8cb29d9c204ab300118 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2011 at 1:48 PM, Bruce Atherton wrote: > I'm not talking about changing the framing. I am talking about using the > opcode field that is already there, but allowing different subprotocols to > define how to interpret it. I guess changing the definition of the binary > and text opcodes could be seen as changing the framing given how the spec is > currently written, but that could be changed editorially with no impact to > anyone. > I think that is changing the framing -- imagine an intermediary that scans text frames for company secrets leaving the building or looking for dirty words etc. You decide that instead of TEXT you want to send some arbitrary binary data. The intermediary will likely choke. I do not believe you should be allowed to do that with a subprotocol. Others on the list (hi Greg) believe that even extensions should not be able to change the framing, only define things that were previously reserved. > Looking through the spec, though, I see that there is no reference to > allowing a subprotocol to use reserved opcodes. I thought they were > available for use by both extensions and subprotocols. My mistake for making > that assumption. I guess my question now is, why not? The opcode is a useful > way to determine how to handle different message types, as the example for > handling binary and text in Javascript shows. I can tell you from experience > that it comes in handy for other application protocols as well. > My understanding is the subprotocol is intended to be a "next layer up" protocol. Of course, it is free to use binary frames and define whatever it likes for the content, including having the first byte of the binary frame payload identify a subprotocol frame. Likewise, it could define that all text frames are JSON encoded, with a fixed tag to identify the message type. > I don't understand your claim that a subprotocol defining opcodes disallows > the aggregation of frames. The opcode is only used on the first frame of a > message in any case. Are you thinking that an intermediary or MUX extension > will merge frames from different messages somehow? If not, then why would it > matter if the intermediary or MUX extension understands the opcode for a > particular subprotocol? That would be an application-only concern. > As long as your reuse of opcodes still follows the same rules as what is currently spec'd, in particular the opcode of the first frame defines that of the message, messages can be arbitrarily fragmented, and continuation fragments have a continuation opcde -- then yes, it could still do it. But if you aren't changing any of those things, what exactly do you get by redefining the opcodes? -- John A. Tamplin Software Engineer (GWT), Google --00163630e8cb29d9c204ab300118 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 1:48 PM, Bruce Atherton = <bruce@callenis= h.com> wrote:
I'm not talking about changing the framing. I am talk= ing about using the opcode field that is already there, but allowing differ= ent subprotocols to define how to interpret it. I guess changing the defini= tion of the binary and text opcodes could be seen as changing the framing g= iven how the spec is currently written, but that could be changed editorial= ly with no impact to anyone.

I think that is changing the framing -- im= agine an intermediary that scans text frames for company secrets leaving th= e building or looking for dirty words etc. =C2=A0You decide that instead of= TEXT you want to send some arbitrary binary data. =C2=A0The intermediary w= ill likely choke.

I do not believe you should be allowed to do that with = a subprotocol. =C2=A0Others on the list (hi Greg) believe that even extensi= ons should not be able to change the framing, only define things that were = previously reserved.
=C2=A0
Looking = through the spec, though, I see that there is no reference to allowing a su= bprotocol to use reserved opcodes. I thought they were available for use by= both extensions and subprotocols. My mistake for making that assumption. I= guess my question now is, why not? The opcode is a useful way to determine= how to handle different message types, as the example for handling binary = and text in Javascript shows. I can tell you from experience that it comes = in handy for other application protocols as well.

My understanding is the subprotocol is int= ended to be a "next layer up" protocol. =C2=A0Of course, it is fr= ee to use binary frames and define whatever it likes for the content, inclu= ding having the first byte of the binary frame payload identify a subprotoc= ol frame. =C2=A0Likewise, it could define that all text frames are JSON enc= oded, with a fixed tag to identify the message type.
=C2=A0
I don't understand your claim that a subprotocol defining opcodes disal= lows the aggregation of frames. The opcode is only used on the first frame = of a message in any case. Are you thinking that an intermediary or MUX exte= nsion will merge frames from different messages somehow? If not, then why w= ould it matter if the intermediary or MUX extension understands the opcode = for a particular subprotocol? That would be an application-only concern.

As long as your reuse of opcodes still follows the s= ame rules as what is currently spec'd, in particular the opcode of the = first frame defines that of the message, messages can be arbitrarily fragme= nted, and continuation fragments have a continuation opcde -- then yes, it = could still do it. =C2=A0But if you aren't changing any of those things= , what exactly do you get by redefining the opcodes?

--
John A. Tamplin
Software Engineer (GWT), Google --00163630e8cb29d9c204ab300118-- From bruce@callenish.com Tue Aug 23 11:32: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 5345121F8BD8 for ; Tue, 23 Aug 2011 11:32:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.532 X-Spam-Level: X-Spam-Status: No, score=-2.532 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hs8pASuOjlFr for ; Tue, 23 Aug 2011 11:32:51 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 64CD321F8BDE for ; Tue, 23 Aug 2011 11:32:51 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QvvnS-0004SH-0e; Tue, 23 Aug 2011 11:33:58 -0700 Message-ID: <4E53F28B.6030300@callenish.com> Date: Tue, 23 Aug 2011 11:33:47 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: John Tamplin References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> <4E53E7D6.8040601@callenish.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080100000303010505020509" 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" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 18:32:52 -0000 This is a multi-part message in MIME format. --------------080100000303010505020509 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 23/08/2011 11:02 AM, John Tamplin wrote: > > I think that is changing the framing -- imagine an intermediary that > scans text frames for company secrets leaving the building or looking > for dirty words etc. You decide that instead of TEXT you want to send > some arbitrary binary data. The intermediary will likely choke. Hmm. Ok, I guess that could be a usecase for maintaining the text opcode in all application protocols. I don't find it terribly compelling, but I can see why might want that. The only reason I have for reusing the binary and text opcodes is to make it clear that they are defined strictly for application purposes. If you think it is worth breaking that boundary so that intermediaries can have visibility into application data, then that is fine with me. I was just trying to resolve the issues that Bob and Iñaki have with minimal impact. Note that any move to an all binary format as suggested by Bob would also remove the ability for intermediaries to depend on their ability to interpret the application data. > > Looking through the spec, though, I see that there is no reference > to allowing a subprotocol to use reserved opcodes. I thought they > were available for use by both extensions and subprotocols. My > mistake for making that assumption. I guess my question now is, > why not? The opcode is a useful way to determine how to handle > different message types, as the example for handling binary and > text in Javascript shows. I can tell you from experience that it > comes in handy for other application protocols as well. > > > My understanding is the subprotocol is intended to be a "next layer > up" protocol. Of course, it is free to use binary frames and define > whatever it likes for the content, including having the first byte of > the binary frame payload identify a subprotocol frame. Likewise, it > could define that all text frames are JSON encoded, with a fixed tag > to identify the message type. I am not being clear enough. Let me give a concrete, although made-up, example with a protocol that everyone here understands. Suppose you wanted to implement the HTTP protocol in Websockets, and you are only going to use native clients. To make this more Websockety, let us say that both endpoints can send and receive both requests and responses. You are going to want to present two types of messages to your application: requests and responses. You may even go a bit more fine-grained and split the request message into different types for the different HTTP methods. Whether a message is text or binary is not an issue at the Websockets layer. The application protocol defines it with a Content-Type header. What is useful is to have different opcodes for requests and responses, so that the data can be fed into the appropriate message type for parsing and for presenting an interface to the rest of the application. This way you can determine message types without having to artificially add a prefix or envelope to the data. To me, identifying the message type is exactly what the opcode field is for. > > As long as your reuse of opcodes still follows the same rules as what > is currently spec'd, in particular the opcode of the first frame > defines that of the message, messages can be arbitrarily fragmented, > and continuation fragments have a continuation opcde -- then yes, it > could still do it. But if you aren't changing any of those things, > what exactly do you get by redefining the opcodes? The ability to define different message types that are relevant for the application protocol. But as I say, if the binary and text opcodes stay static that is just a bit of wastage that doesn't bother me too much. To be fair to Bob and Iñaki though, it _is_ leaking application concerns into the base protocol. --------------080100000303010505020509 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit On 23/08/2011 11:02 AM, John Tamplin wrote:

I think that is changing the framing -- imagine an intermediary that scans text frames for company secrets leaving the building or looking for dirty words etc.  You decide that instead of TEXT you want to send some arbitrary binary data.  The intermediary will likely choke.

Hmm. Ok, I guess that could be a usecase for maintaining the text opcode in all application protocols. I don't find it terribly compelling, but I can see why might want that.

The only reason I have for reusing the binary and text opcodes is to make it clear that they are defined strictly for application purposes. If you think it is worth breaking that boundary so that intermediaries can have visibility into application data, then that is fine with me. I was just trying to resolve the issues that Bob and Iñaki have with minimal impact. Note that any move to an all binary format as suggested by Bob would also remove the ability for intermediaries to depend on their ability to interpret the application data.


Looking through the spec, though, I see that there is no reference to allowing a subprotocol to use reserved opcodes. I thought they were available for use by both extensions and subprotocols. My mistake for making that assumption. I guess my question now is, why not? The opcode is a useful way to determine how to handle different message types, as the example for handling binary and text in Javascript shows. I can tell you from experience that it comes in handy for other application protocols as well.

My understanding is the subprotocol is intended to be a "next layer up" protocol.  Of course, it is free to use binary frames and define whatever it likes for the content, including having the first byte of the binary frame payload identify a subprotocol frame.  Likewise, it could define that all text frames are JSON encoded, with a fixed tag to identify the message type.

I am not being clear enough. Let me give a concrete, although made-up, example with a protocol that everyone here understands.

Suppose you wanted to implement the HTTP protocol in Websockets, and you are only going to use native clients. To make this more Websockety, let us say that both endpoints can send and receive both requests and responses.

You are going to want to present two types of messages to your application: requests and responses. You may even go a bit more fine-grained and split the request message into different types for the different HTTP methods.

Whether a message is text or binary is not an issue at the Websockets layer. The application protocol defines it with a Content-Type header. What is useful is to have different opcodes for requests and responses, so that the data can be fed into the appropriate message type for parsing and for presenting an interface to the rest of the application. This way you can determine message types without having to artificially add a prefix or envelope to the data.

To me, identifying the message type is exactly what the opcode field is for.


As long as your reuse of opcodes still follows the same rules as what is currently spec'd, in particular the opcode of the first frame defines that of the message, messages can be arbitrarily fragmented, and continuation fragments have a continuation opcde -- then yes, it could still do it.  But if you aren't changing any of those things, what exactly do you get by redefining the opcodes?

The ability to define different message types that are relevant for the application protocol. But as I say, if the binary and text opcodes stay static that is just a bit of wastage that doesn't bother me too much. To be fair to Bob and Iñaki though, it _is_ leaking application concerns into the base protocol.

--------------080100000303010505020509-- From tyoshino@google.com Tue Aug 23 12:41: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 33DD321F8C4C for ; Tue, 23 Aug 2011 12:41:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.856 X-Spam-Level: X-Spam-Status: No, score=-105.856 tagged_above=-999 required=5 tests=[AWL=0.120, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asy66WU5jHnD for ; Tue, 23 Aug 2011 12:41:08 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 4D87521F8C4B for ; Tue, 23 Aug 2011 12:41:08 -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 p7NJgFVJ015843 for ; Tue, 23 Aug 2011 12:42:16 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314128536; bh=MDk0XBeHzZq9SZyGeHnAsiMG1kQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=L/YUM6PLLH3xeqGKI/U7mBPyOZaGMUI0W5DiRZkr2d05xmH/sQITDfgRvD47FI+cb Lkvf1CSybCdq4Lm+VTqPw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=F3BA1vDProVvlNwXGYG0+f8jxNaR/vavsYxrUQf2S2XNIfNx6Eq5/w+6Me8uziQGX Rh1dpuOyU0xm4wLbals2A== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by hpaq1.eem.corp.google.com with ESMTP id p7NJgDia006373 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 12:42:14 -0700 Received: by ywo7 with SMTP id 7so643376ywo.25 for ; Tue, 23 Aug 2011 12:42:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=qualZseZjg8BDSnAh3+7U/X5gIjkiUX59wnXS1Yj1BQ=; b=U06amODdybbXjKNrkM2ggllcJOCSshIQ9w9Rm8I6nf0sXPK1s82kQPSJOzvOaYFeEK zo1ZqX8VTnJRX7IjI0XQ== Received: by 10.91.158.16 with SMTP id k16mr4135109ago.82.1314128533359; Tue, 23 Aug 2011 12:42:13 -0700 (PDT) Received: by 10.91.158.16 with SMTP id k16mr4135102ago.82.1314128533141; Tue, 23 Aug 2011 12:42:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.91.32.2 with HTTP; Tue, 23 Aug 2011 12:41:53 -0700 (PDT) In-Reply-To: <4E538213.7020207@isode.com> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> From: Takeshi Yoshino Date: Wed, 24 Aug 2011 04:41:53 +0900 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=001485f94c626836e404ab316416 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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, 23 Aug 2011 19:41:09 -0000 --001485f94c626836e404ab316416 Content-Type: text/plain; charset=ISO-8859-1 Hi Alexey, I have some questions about section 5.2.2. and 5.3. ---- implied WSP rule -> implied LWS rule ? ---- Are Sec-WebSocket-Protocol-Client, Sec-WebSocket-Version-Client, Sec-WebSocket-Protocol-Server, Sec-WebSocket-Version-Server just names of ABNF rules? i.e. Sec-WebSocket-Protocol-Client is the grammar for the right hand side of the Sec-WebSocket-Protocol header in client handshake? ---- It seems header name and colon are missing from rules. e.g. Sec-WebSocket-Accept = base64-value The left hand side was accept-value in -10 and the line seemed to be defining the grammar of the right hand side of the Sec-WebSocket-Accept data. So, just base64-value was fine. But now, maybe you've tried to give grammar for full header line as RFC 2616 does and follow its style like Accept = "Accept" ":" #( media-range [ accept-params ] ) so, this should be Sec-WebSocket-Accept = "Sec-WebSocket-Accept" ":" base64-value ---- This ABNF doesn't cover 1, 2, ... 99 version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) ; 0-255 ---- Maybe "1#" here is typo. Sec-WebSocket-Version-Server = 1#version ---- Thanks, --001485f94c626836e404ab316416 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Alexey,

I have some questions about sectio= n 5.2.2. and 5.3.

----

im= plied WSP rule ->=A0implied LWS rule ?

----

Are Sec-WebSocket-Protocol-Client,=A0Sec-WebSocket-Vers= ion-Client,=A0Sec-WebSocket-Protocol-Server,=A0Sec-WebSocket-Version-Server= just names of ABNF rules?

i.e.=A0Sec-WebSocket-Pr= otocol-Client is the grammar for the right hand side of the Sec-WebSocket-P= rotocol header in client handshake?

----

It seems header name and = colon are missing from rules. e.g.

Sec-WebSocket-A= ccept =A0 =A0 =3D base64-value

The left hand side = was accept-value=A0in -10=A0and the line seemed to be defining the grammar = of the right hand side of the Sec-WebSocket-Accept data. So, just base64-va= lue was fine. But now, maybe you've tried to give grammar for full head= er line as RFC 2616 does and follow its style like
=A0 =A0 =A0 =A0Accept =A0 =A0 =A0 =A0 =3D "Accept"= ; ":"
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 #( media-range [ accept-params ] )
so, this should= be

Sec-WebSocket-Accept =A0 =A0 =3D "Sec-Web= Socket-Accept" ":" base64-value

----

This ABNF doesn'= ;t cover 1, 2, ... 99
=A0 =A0 =A0 =A0 =A0 =A0version =3D "0&qu= ot; | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT)
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0; 0-255

---= -

Maybe "1#"=A0here is typo.
Sec-WebSocket-Version-Server =3D 1#version

--= --

Thanks,
--001485f94c626836e404ab316416-- From sh@defuze.org Tue Aug 23 13:13: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 B907121F8D22 for ; Tue, 23 Aug 2011 13:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.526 X-Spam-Level: X-Spam-Status: No, score=-2.526 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RhZUv8F5DlJ0 for ; Tue, 23 Aug 2011 13:13:52 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id ADB4421F8CFA for ; Tue, 23 Aug 2011 13:13:52 -0700 (PDT) Received: by pzk33 with SMTP id 33so105413pzk.18 for ; Tue, 23 Aug 2011 13:15:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.234.5 with SMTP id g5mr2258868wfh.347.1314130500887; Tue, 23 Aug 2011 13:15:00 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Tue, 23 Aug 2011 13:15:00 -0700 (PDT) X-Originating-IP: [82.229.61.197] Date: Tue, 23 Aug 2011 22:15:00 +0200 Message-ID: From: Sylvain Hellegouarch To: Server-Initiated HTTP Content-Type: multipart/alternative; boundary=000e0cd244b2b1a3b304ab31d9c3 Subject: [hybi] Android sensors to control your webapp through WebSocket X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Aug 2011 20:13:53 -0000 --000e0cd244b2b1a3b304ab31d9c3 Content-Type: text/plain; charset=ISO-8859-1 Hi all, I wrote a simple demo that I thought would be fun. Using WebSocket, I'm sending Android sensor values to a server which broadcasts those to any connected clients, like a browser running WebSocket. Then I'm using JavaScript and a HTML5 Canvas to render received values in real time. http://www.defuze.org/oss/ws4py/screenshots/droidsensors.png Ultimately this is to show one could use a mobile device to control a webapp a bit like a Wii control does on your TV. The communication between the device and the server needn't to be WebSocket but I thought it'd be interesting to show ws4py can run on Android as well.This has been tested with Android 2.2 on my HTC Desire and Chrome 15.0.854.0 dev on Debian 6. The code is probably rather prone to break so do not use in production ;-) If you want to give it a try, use the last git revision. https://github.com/Lawouach/WebSocket-for-Python Some info on how to setup the Android client: https://github.com/Lawouach/WebSocket-for-Python/blob/master/example/droid_sensor.py Enjoy, -- - Sylvain http://www.defuze.org http://twitter.com/lawouach --000e0cd244b2b1a3b304ab31d9c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I wrote a simple demo that I thought would be fu= n. Using WebSocket, I'm sending Android sensor values to a server which= broadcasts those to any connected clients, like a browser running WebSocke= t. Then I'm using JavaScript and a HTML5 Canvas to render received valu= es in real time.


Ultimately this is to show one could use a= mobile device to control a webapp a bit like a Wii control does on your TV= . The communication between the device and the server needn't to be Web= Socket but I thought it'd be interesting to show ws4py can run on Andro= id as well.This has been tested with Android 2.2 on my HTC Desire and Chrom= e=A015.0.854.0 dev on Debian 6.

The code is probably rather prone to break so do n= ot use in production ;-)

If you want to give it a = try, use the last git revision.

Some info on how to setup the Android client:
https://github.com/Lawouach/WebSocket-for-Python/blo= b/master/example/droid_sensor.py

Enjoy,
--
- Sylvain
http://www.defuze.org
http://twitter.com/lawouach
--000e0cd244b2b1a3b304ab31d9c3-- From alexey.melnikov@isode.com Tue Aug 23 14:55: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 8011C21F8D09 for ; Tue, 23 Aug 2011 14:55:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.744 X-Spam-Level: X-Spam-Status: No, score=-102.744 tagged_above=-999 required=5 tests=[AWL=-0.145, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GspFdE-RFA2u for ; Tue, 23 Aug 2011 14:55:17 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id BB4F421F8CEF for ; Tue, 23 Aug 2011 14:55:16 -0700 (PDT) Received: from [188.29.229.65] (188.29.229.65.threembb.co.uk [188.29.229.65]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 23 Aug 2011 22:56:23 +0100 Message-ID: <4E5421FF.90101@isode.com> Date: Tue, 23 Aug 2011 22:56:15 +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: Takeshi Yoshino References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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, 23 Aug 2011 21:55:17 -0000 Takeshi Yoshino wrote: > Hi Alexey, Hi Takeshi, > I have some questions about section 5.2.2. and 5.3. > > ---- > > implied WSP rule -> implied LWS rule ? Yes. It might have been called different things in different IETF RFCs, but I will double check and use the right term. > ---- > > Are > Sec-WebSocket-Protocol-Client, Sec-WebSocket-Version-Client, Sec-WebSocket-Protocol-Server, Sec-WebSocket-Version-Server > just names of ABNF rules? Yes. The suffix "-Client" means that the syntax is used in HTTP requests (C->S), the suffix "-Server" means that the syntax is used in HTTP responses. > i.e. Sec-WebSocket-Protocol-Client is the grammar for the right hand > side of the Sec-WebSocket-Protocol header in client handshake? Yes. > ---- > > It seems header name and colon are missing from rules. e.g. > > Sec-WebSocket-Accept = base64-value > > The left hand side was accept-value in -10 and the line seemed to be > defining the grammar of the right hand side of the > Sec-WebSocket-Accept data. So, just base64-value was fine. But now, > maybe you've tried to give grammar for full header line as RFC 2616 > does and follow its style like > Accept = "Accept" ":" > #( media-range [ accept-params ] ) > so, this should be > > Sec-WebSocket-Accept = "Sec-WebSocket-Accept" ":" base64-value I suggest we do whatever RFC 2616 is doing. I will double check. > ---- > > This ABNF doesn't cover 1, 2, ... 99 > version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) > ; 0-255 Sigh, you are right, this needs to be fixed to match the comment. > ---- > > Maybe "1#" here is typo. > Sec-WebSocket-Version-Server = 1#version No typo here, this matches the text elsewhere in the document: the server advertises all versions it supports. From buskanaka@gmail.com Tue Aug 23 15:33: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 193EA21F8B3D for ; Tue, 23 Aug 2011 15:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ae+L76zVdZ2E for ; Tue, 23 Aug 2011 15:33:40 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 34CF721F8C21 for ; Tue, 23 Aug 2011 15:33:40 -0700 (PDT) Received: by fxe6 with SMTP id 6so647842fxe.31 for ; Tue, 23 Aug 2011 15:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=hPgkNB/24Muow3KnydJsXCUd/pcx/uby21slMctCIIQ=; b=iOQeGHBPObT4KW7QxIajfs8lVIvmE78EQ8mtZK+okl6BEk7JIm5exzqXhGfat2Em3c naOuzEb8/Sg/hMjWq0s9CYrkLEmCyNXYizTL2nNDElpyXcpX+TSXWJDfI9b70mGfvJh8 KYkIINNQcEmEB9qwlc+ggkwwfLqiEsqTXhZ1k= Received: by 10.223.29.9 with SMTP id o9mr6108138fac.131.1314138888419; Tue, 23 Aug 2011 15:34:48 -0700 (PDT) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.223.102.79 with HTTP; Tue, 23 Aug 2011 15:34:28 -0700 (PDT) In-Reply-To: References: <20110822061930.ef1fc80126c74c6c202a919c41c7bb0b.a6f648ae02.wbe@email03.secureserver.net> <634914A010D0B943A035D226786325D422C0D5CA9A@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5CE5A@EXVMBX020-12.exch020.serverdata.net> From: Joel Martin Date: Tue, 23 Aug 2011 17:34:28 -0500 X-Google-Sender-Auth: QlOZ14oMsMBYt5XFDoWcjYTVHx0 Message-ID: To: Brian Content-Type: multipart/alternative; boundary=0015174767fca13b2f04ab33cd09 Cc: "hybi@ietf.org" Subject: Re: [hybi] Binary/Text Distinction 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, 23 Aug 2011 22:33:41 -0000 --0015174767fca13b2f04ab33cd09 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 23, 2011 at 6:21 AM, Brian wrote: > My point was that since the browser use case was the impetus for creating > this protocol in the first place, we shouldn't accept changes that would be > in any way detrimental to the browser or JavaScript developers for the sake > of a secondary use case, or even for a clean separation of application vs > transport protocol concepts. > +1. Secondary use cases can just use binary set to true for all frames and be done with it. Unless they are pretending to be a browser, in which case ... well, they should pretend to be a browser (and support text too if needed). Earlier someone asked if there would be many use cases of sending/receiving binary data over WebSockets from Javascript. Absolutely! But most of them haven't even been thought of yet. That's the real potential of WebSocket (opening new applications domains rather than making the existing ones incrementally better). My own noVNC project send/receives binary data over the existing Hixie Websocket implementations and I'm very much looking forward to being able to send binary data directly without base64 encoding/decoding first (which adds non-trivial latency). I think the arguments in favor of retaining the binary/text distinction in the spec are much more compelling than the "history teaches us to keep layers distinct" line of arguments. Even more compelling to me is not delaying the protocol over a purity vs practical argument. Regards, Joel Martin (kanaka) --0015174767fca13b2f04ab33cd09 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 6:21 AM, Brian <theturtle32@gmail.com= > wrote:
My point was that since the br= owser use case was the impetus for creating this protocol in the first plac= e, we shouldn't accept changes that would be in any way detrimental to = the browser or JavaScript developers for the sake of a secondary use case, = or even for a clean separation of application vs transport protocol concept= s.

+1. Secondary use cases can just use= binary set to true for all frames and be done with it. Unless they are pre= tending to be a browser, in which case ... well, they should pretend to be = a browser (and support text too if needed).

Earlier someone asked if there would be many use cases = of sending/receiving binary data over WebSockets from Javascript. Absolutel= y! But most of them haven't even been thought of yet. That's the re= al potential of WebSocket (opening new applications domains rather than mak= ing the existing ones incrementally better).=A0My own noVNC project send/re= ceives binary data over the existing Hixie Websocket implementations and I&= #39;m very much looking forward to being able to send binary data directly = without base64 encoding/decoding first (which adds non-trivial latency).

I think the arguments in favor of retaining the binary/= text distinction in the spec are much more compelling than the "histor= y teaches us to keep layers distinct" line of arguments. Even more com= pelling to me is not delaying the protocol over a purity vs practical argum= ent.

Regards,

Joel Martin (kanaka)<= /div>
--0015174767fca13b2f04ab33cd09-- From gregw@intalio.com Tue Aug 23 16:40: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 E439321F8BE4 for ; Tue, 23 Aug 2011 16:40:07 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-z4eJGAeBXV for ; Tue, 23 Aug 2011 16:40:07 -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 5AE2A21F8B98 for ; Tue, 23 Aug 2011 16:40:07 -0700 (PDT) Received: by vws12 with SMTP id 12so664061vws.31 for ; Tue, 23 Aug 2011 16:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.5 with SMTP id z5mr4221662vde.112.1314142875963; Tue, 23 Aug 2011 16:41:15 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 23 Aug 2011 16:41:15 -0700 (PDT) In-Reply-To: <4E53E7D6.8040601@callenish.com> References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> <4E53E7D6.8040601@callenish.com> Date: Wed, 24 Aug 2011 09:41:15 +1000 Message-ID: From: Greg Wilkins To: Bruce Atherton Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 23 Aug 2011 23:40:08 -0000 On 24 August 2011 03:48, Bruce Atherton wrote: > > Looking through the spec, though, I see that there is no reference to > allowing a subprotocol to use reserved opcodes. I thought they were > available for use by both extensions and subprotocols. My mistake for making > that assumption. I guess my question now is, why not? This WG appears to have a phobia about negotiating anything in the protocol layer. With only a handful of reserved opcode and bits, the allocation of them to extensions and sub protocols needs to be dynamically negotiated if we are to avoid de facto assignment (eg google-mux takes 0x7 opcode, making it pretty tough for anybody else to use that opcode in the face of googles market share). Yet every attempt to suggest even the simplest mechanism to negotiate usage of these resources has been met with rejection due to the apparent complexities of it. So without a mechanism to allocate them, we are left holding them in reserve for future versions of the protocol or to be assigned by request to IANA. regards From gregw@intalio.com Tue Aug 23 16:50: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 6848E21F8A56 for ; Tue, 23 Aug 2011 16:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ5Gt+Q2pBBM for ; Tue, 23 Aug 2011 16:50:37 -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 84D2521F86AA for ; Tue, 23 Aug 2011 16:50:36 -0700 (PDT) Received: by vxi29 with SMTP id 29so686834vxi.31 for ; Tue, 23 Aug 2011 16:51:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.171 with SMTP id a11mr1891258vdj.313.1314143505196; Tue, 23 Aug 2011 16:51:45 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 23 Aug 2011 16:51:45 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 09:51:45 +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] Are RSV1-3 bits really useful? 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, 23 Aug 2011 23:50:38 -0000 Inaki, the ability to negotiate dynamic allocation of opcodes and reserve bits to extensions was deemed to be beyond the capabilities of the developers implementing websockets. So we are instead left with either an implied free for all (if you read 4.8) or a process of static allocation by request (11.8 /11.9). As static allocation will be untenable for all but a few hi profile extensions, most ad-hoc extensions/protocols will need to put their own opcodes/reserved bits into the payload. cheers On 23 August 2011 21:01, I=F1aki Baz Castillo wrote: > From the spec: > > =A0 RSV1, RSV2, RSV3: =A01 bit each > > =A0 =A0 =A0MUST be 0 unless an extension is negotiated which defines mean= ings > =A0 =A0 =A0for non-zero values. =A0If a nonzero value is received and non= e of > =A0 =A0 =A0the negotiated extensions defines the meaning of such a nonzer= o > =A0 =A0 =A0value, the receiving endpoint MUST _Fail the WebSocket > =A0 =A0 =A0Connection_. > > > So what about if a WS handshake requires two extensions ext1 and ext2, > and both extensions want to make usage of the same RSV1 bit? > > This is: > > - For ext1 bit RSV1 means: 1 (do something) / 0 (do other thing) > - For ext2 bit RSV1 means: 1 (do something) / 0 (do other thing) > > Who decides the value of RSV1? the last extension requested? there > would be an obvious conflict. > > Is the usage of these RSV bits really well designed? or is it more > like "let's think about it in a future"? > > -- > I=F1aki Baz Castillo > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From jat@google.com Tue Aug 23 17: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 52F5421F8C07 for ; Tue, 23 Aug 2011 17:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7YtTMIQf68M for ; Tue, 23 Aug 2011 17:00:57 -0700 (PDT) Received: from mail-gy0-f198.google.com (mail-gy0-f198.google.com [209.85.160.198]) by ietfa.amsl.com (Postfix) with ESMTP id AEB2521F8BFB for ; Tue, 23 Aug 2011 17:00:57 -0700 (PDT) Received: by gyd8 with SMTP id 8so813937gyd.1 for ; Tue, 23 Aug 2011 17:02:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZZEEGOl2hQhnaDiuyxqd5OQoER0BX9eEmhY2zljVt2Q=; b=k7PSmMJU21hfMx+PxWZ8mX85DthZ7/mNyGzypxlMUwJLzzumIM5ej3LCKjQYaZzpxH VPPqoDcQBd0nJDV8Jg5A== Received: by 10.150.253.9 with SMTP id a9mr4252094ybi.230.1314144125775; Tue, 23 Aug 2011 17:02:05 -0700 (PDT) Received: by 10.150.253.9 with SMTP id a9mr4252084ybi.230.1314144125092; Tue, 23 Aug 2011 17:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 23 Aug 2011 17:01:45 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Tue, 23 Aug 2011 20:01:45 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=001517475c92c2830804ab350528 Cc: hybi@ietf.org Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 00:00:58 -0000 --001517475c92c2830804ab350528 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2011 at 7:51 PM, Greg Wilkins wrote: > the ability to negotiate dynamic allocation of opcodes and reserve > bits to extensions was deemed to be beyond the capabilities of the > developers implementing websockets. > What was deemed was that there was no need to define a method for allocating the bits/opcodes before there was an extension that needed them. The first extension that needs to allocate a bit/opcode can define such a mechanism if it is justified. Until then, delaying the base protocol to achieve consensus on something that isn't even needed yet seems foolhardy. > As static allocation will be untenable for all but a few hi profile extensions, most ad-hoc extensions/protocols will need to put their > own opcodes/reserved bits into the payload. > You objected at the time, and there was wording put into the spec at your request that says only registered extensions can use them, so I don't know why you keep beating the same horse that hi profile companies can force use of them but others can't. -- John A. Tamplin Software Engineer (GWT), Google --001517475c92c2830804ab350528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 7:51 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
the ability to negotiate dynamic allocation of opcodes and reserve
bits to extensions was deemed to be beyond the capabilities of the
developers implementing websockets.

Wha= t was deemed was that there was no need to define a method for allocating t= he bits/opcodes before there was an extension that needed them. =C2=A0The f= irst extension that needs to allocate a bit/opcode can define such a mechan= ism if it is justified.

Until then, delaying the base protocol to achieve conse= nsus on something that isn't even needed yet seems foolhardy.
=C2=A0
As static allocation will be untenable for all but a few hi profile
extensions, =C2=A0most ad-hoc extensions/protocols will need to put their own opcodes/reserved bits into the payload.
You objected at the time, and there was wording put into the spec at = your request that says only registered extensions can use them, so I don= 9;t know why you keep beating the same horse that hi profile companies can = force use of them but others can't.

--
John A. Tamplin
Software Engineer (GWT), Google --001517475c92c2830804ab350528-- From gregw@intalio.com Tue Aug 23 17:19: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 3B14021F8C9C for ; Tue, 23 Aug 2011 17:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmyMv6RjVQXH for ; Tue, 23 Aug 2011 17:19: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 99B8321F8C8D for ; Tue, 23 Aug 2011 17:19:22 -0700 (PDT) Received: by vws12 with SMTP id 12so686947vws.31 for ; Tue, 23 Aug 2011 17:20:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.21.109 with SMTP id u13mr4134707vde.447.1314145231315; Tue, 23 Aug 2011 17:20:31 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 23 Aug 2011 17:20:31 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 10:20:31 +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 Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 00:19:23 -0000 On 24 August 2011 10:01, John Tamplin wrote: > On Tue, Aug 23, 2011 at 7:51 PM, Greg Wilkins wrote: >> >> the ability to negotiate dynamic allocation of opcodes and reserve >> bits to extensions was deemed to be beyond the capabilities of the >> developers implementing websockets. > > What was deemed was that there was no need to define a method for allocat= ing > the bits/opcodes before there was an extension that needed them. =A0The f= irst > extension that needs to allocate a bit/opcode can define such a mechanism= if > it is justified. sorry for my sarcasm about the reason - not helpful. > Until then, delaying the base protocol to achieve consensus on something > that isn't even needed yet seems foolhardy. I agree we should not further delay the protocol. But I still believe lack of negotiated use of opcodes and reserved bits is a significant deficiency that would have been very simple to have solved without delay - had we addressed it at the time. I only bring it up now because others are asking about this obvious deficiency. >> >> As static allocation will be untenable for all but a few hi profile >> >> extensions, =A0most ad-hoc extensions/protocols will need to put their >> own opcodes/reserved bits into the payload. > > You objected at the time, and there was wording put into the spec at your > request that says only registered extensions can use them, so I don't kno= w > why you keep beating the same horse that hi profile companies can force u= se > of them but others can't. I'm not beating that horse anymore. In the absence of dynamic allocation, IANA request is the only sane thing to do. By high profile extension, I am NOT meaning high profile company using market share - I'm meaning an extension that has sufficient wide appeal that it will be standardised through the IETF and be able to make a good case to IANA for allocation of these scarce resources. This is fine and fair and the best we can do for now. But it does mean that reserve bits and opcodes are out of bounds for proprietary extensions (eg what we might see between an intermediary and an app server). I did mention google-mux's use of 0x7 in the other thread - but such usage would now have to be approved by IANA - so my apologies for alluding to that dead horse. regards From jat@google.com Tue Aug 23 17:58: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 605EC21F8564 for ; Tue, 23 Aug 2011 17:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qclSk+nlSIO for ; Tue, 23 Aug 2011 17:58:17 -0700 (PDT) Received: from mail-vx0-f198.google.com (mail-vx0-f198.google.com [209.85.220.198]) by ietfa.amsl.com (Postfix) with ESMTP id 957F821F8556 for ; Tue, 23 Aug 2011 17:58:17 -0700 (PDT) Received: by vxh13 with SMTP id 13so873466vxh.1 for ; Tue, 23 Aug 2011 17:59:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=9AXXw92uOsWlmRdgGj9EYX2IaYEYpyGWNgiVgIorBJo=; b=UjEEF1lOMEVNCWyHWKQ5FImuFcHUg6Q8B+LCZkzJo8ab27v9gIjImUV/pREe9MO6MW V/wPTF6CbR3+n/uUAg6A== Received: by 10.151.59.14 with SMTP id m14mr4726502ybk.401.1314147565409; Tue, 23 Aug 2011 17:59:25 -0700 (PDT) Received: by 10.151.59.14 with SMTP id m14mr4726493ybk.401.1314147565140; Tue, 23 Aug 2011 17:59:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 23 Aug 2011 17:59:04 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Tue, 23 Aug 2011 20:59:04 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=00151750ebe4cd7aa604ab35d23f Cc: hybi@ietf.org Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 00:58:18 -0000 --00151750ebe4cd7aa604ab35d23f Content-Type: text/plain; charset=UTF-8 On Tue, Aug 23, 2011 at 8:20 PM, Greg Wilkins wrote: > I agree we should not further delay the protocol. But I still > believe lack of negotiated use of opcodes and reserved bits is a > significant deficiency that would have been very simple to have solved > without delay - had we addressed it at the time. I only bring it > up now because others are asking about this obvious deficiency. I still don't believe it would be added without delay -- currently we are re-debating the framing that was decided over a year ago, and there were significant objections to your proposal. So, I think it would take a while to achieve something that people can agree on. > I'm not beating that horse anymore. In the absence of dynamic > allocation, IANA request is the only sane thing to do. By high > profile extension, I am NOT meaning high profile company using market > share - I'm meaning an extension that has sufficient wide appeal that > it will be standardised through the IETF and be able to make a good > case to IANA for allocation of these scarce resources. This is > fine and fair and the best we can do for now. But it does mean that > reserve bits and opcodes are out of bounds for proprietary extensions > (eg what we might see between an intermediary and an app server). > I did mention google-mux's use of 0x7 in the other thread - but such > usage would now have to be approved by IANA - so my apologies for > alluding to that dead horse. > If you own the network the connection runs over, you can allocate reserved bits to your heart's content -- you just can't use them on the public network with endpoints you don't control. In reality, the endpoints that you don't control are going to be browsers, and it seems a high enough bar to get them to implement some extension that the extra friction of having to get a bit/opcode allocated seems to be in the noise. -- John A. Tamplin Software Engineer (GWT), Google --00151750ebe4cd7aa604ab35d23f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 23, 2011 at 8:20 PM, Greg Wilkins <gregw@intalio.com<= /a>> wrote:
I agree we should not further delay the protocol. =C2=A0 = But I still
believe lack of negotiated use of opcodes and reserved bits is a
significant deficiency that would have been very simple to have solved
without delay - had we addressed it at the time. =C2=A0 =C2=A0 I only bring= it
up now because others are asking about this obvious deficiency.

I still don't believe it would be added without de= lay -- currently we are re-debating the framing that was decided over a yea= r ago, and there were significant objections to your proposal. =C2=A0So, I = think it would take a while to achieve something that people can agree on.<= /div>
=C2=A0
I'm = not beating that horse anymore. =C2=A0 =C2=A0In the absence of dynamic allocation, IANA request is the only sane thing to do. =C2=A0 =C2=A0By high=
profile extension, I am NOT meaning high profile company using market
share - I'm meaning an extension that has sufficient wide appeal that it will be standardised through the IETF and be able to make a good
case to IANA for allocation of these scarce resources. =C2=A0 =C2=A0 =C2=A0= This is
fine and fair and the best we can do for now. =C2=A0 =C2=A0But it does mean= that
reserve bits and opcodes are out of bounds for proprietary extensions
(eg what we might see between an intermediary and an app server).
I did mention google-mux's use of 0x7 in the other thread - but such usage would now have to be approved by IANA - so my apologies for
alluding to that dead horse.

If you ow= n the network the connection runs over, you can allocate reserved bits to y= our heart's content -- you just can't use them on the public networ= k with endpoints you don't control.

In reality, the endpoints that you don't control are goi= ng to be browsers, and it seems a high enough bar to get them to implement = some extension that the extra friction of having to get a bit/opcode alloca= ted seems to be in the noise.

--
John A. Tamplin
Software Engineer (GWT), Google
--00151750ebe4cd7aa604ab35d23f-- From tyoshino@google.com Tue Aug 23 19:13:47 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 24A3F21F8B7D for ; Tue, 23 Aug 2011 19:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.867 X-Spam-Level: X-Spam-Status: No, score=-105.867 tagged_above=-999 required=5 tests=[AWL=0.109, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5bEK1y3gRN3P for ; Tue, 23 Aug 2011 19:13:46 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 050D621F8B7B for ; Tue, 23 Aug 2011 19:13:45 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p7O2EjRj028042 for ; Tue, 23 Aug 2011 19:14:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314152090; bh=J6u7wK33s1oR+obYpMfqcu/ALqI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=dwcGiocYy6HBqyTMIbvSx24m7WHCNAcjxiNWHZ8snWzzXTmyMwfCCJiLLUClDcXOp fJIqkZiE1yPHc0gc5OGzA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=nt8bzAuIKUsAhHjQAGRtkJmo/rnnvE0Z4rlJRFdq8YtATIZW8Da6xCCh3loldM+6X qXYiJjhCf4CBvplG56Z4g== Received: from ywf9 (ywf9.prod.google.com [10.192.6.9]) by wpaz9.hot.corp.google.com with ESMTP id p7O2EiNj014443 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 23 Aug 2011 19:14:44 -0700 Received: by ywf9 with SMTP id 9so642470ywf.4 for ; Tue, 23 Aug 2011 19:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nfTHcP5LP0GssPN/oIaKDBeClViI9jXtwHmr9QC43dM=; b=Y1Ci7ze2EnOV5HC8eFneu3S0EQIiV2MeUWSm884zkMcb75FvHxgl2QC/PfXJ2pC7QT f6MVQPpognOFQ6wLf4Iw== Received: by 10.150.170.10 with SMTP id s10mr4423997ybe.171.1314152084324; Tue, 23 Aug 2011 19:14:44 -0700 (PDT) Received: by 10.150.170.10 with SMTP id s10mr4423987ybe.171.1314152084147; Tue, 23 Aug 2011 19:14:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Tue, 23 Aug 2011 19:14:24 -0700 (PDT) In-Reply-To: <4E5421FF.90101@isode.com> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> From: Takeshi Yoshino Date: Wed, 24 Aug 2011 11:14:24 +0900 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=000e0cd58c6e280fad04ab36e096 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 02:13:47 -0000 --000e0cd58c6e280fad04ab36e096 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 24, 2011 at 06:56, Alexey Melnikov wrote: > Maybe "1#" here is typo. >> Sec-WebSocket-Version-Server = 1#version >> > > No typo here, this matches the text elsewhere in the document: the server > advertises all versions it supports. > I overlooked the change. Thanks. --000e0cd58c6e280fad04ab36e096 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 24, 2011 at 06:56, Alexey Melnikov <= span dir=3D"ltr"><alexey.me= lnikov@isode.com> wrote:
Maybe "1#" here = is typo.
Sec-WebSocket-Version-Server =3D 1#version

No typo here, this matches the text elsewhere in the document: the server a= dvertises all versions it supports.

I overlooked the change. Thanks.
--000e0cd58c6e280fad04ab36e096-- From gregw@intalio.com Tue Aug 23 21:37: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 062C221F8AFE for ; Tue, 23 Aug 2011 21:37:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmBUxGxPQh5S for ; Tue, 23 Aug 2011 21:37:53 -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 5671C21F8AFC for ; Tue, 23 Aug 2011 21:37:53 -0700 (PDT) Received: by vxi29 with SMTP id 29so861341vxi.31 for ; Tue, 23 Aug 2011 21:39:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.5 with SMTP id z5mr4594670vde.112.1314160742588; Tue, 23 Aug 2011 21:39:02 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 23 Aug 2011 21:39:02 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 14:39:02 +1000 Message-ID: From: Greg Wilkins To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 04:37:54 -0000 On 24 August 2011 10:59, John Tamplin wrote: > On Tue, Aug 23, 2011 at 8:20 PM, Greg Wilkins wrote: > > I still don't believe it would be added without delay -- currently we are > re-debating the framing that was decided over a year ago, and there were > significant objections to your proposal. =A0So, I think it would take a w= hile > to achieve something that people can agree on. What proposal? I'm not proposing we change framing and I'm not proposing that we delay now to add negotiation for reserve bits and/or opcodes. I think we are good to go. I was just explaining to Inaki why we don't have a mechanism to negotiate reserve bit/codes and that we must statically allocate them via IANA. I think this is probably sufficient for the immediate future, but in the mid/long term is going to stifle innovation. OK I mixed in some sour grapes with that explanation because I do think it was a failing of this WG not to address what is essentially a pretty simple issue. > If you own the network the connection runs over, you can allocate reserve= d > bits to your heart's content Not really, as you still need to deal with future allocation by end to end extensions. Say for example if I allocated RSV bit 3 to talk to/from my proprietary WS load balancer, but then IANA allocates that bit to a compression extension, my load balancer would then not be able to pass standard compressed frames. Currently it will be very difficult for intermediaries to do any in-band signalling that will be future proof, since any indication you pick to mark out a signal may subsequently be allocated to a standard extension. > In reality, the endpoints that you don't control are going to be browsers= , > and it seems a high enough bar to get them to implement some extension th= at > the extra friction of having to get a bit/opcode allocated seems to be in > the noise. True that is going to present significant inertia, and for good reasons I don't think browsers are going to be in a rush to add a huge number of extensions any time soon. So I think we are good to go and don't need to delay the process for this issue. But it remains an issue that I believe will need to be addressed eventually. regards From andy@warmcat.com Tue Aug 23 22:12: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 5F8B721F8BAB for ; Tue, 23 Aug 2011 22:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sqs2dZnRrzB6 for ; Tue, 23 Aug 2011 22:12:23 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id BDDE021F8BA7 for ; Tue, 23 Aug 2011 22:12:22 -0700 (PDT) Message-ID: <4E548875.80804@warmcat.com> Date: Wed, 24 Aug 2011 06:13:25 +0100 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Greg Wilkins References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 05:12:23 -0000 On 08/24/2011 05:39 AM, Somebody in the thread at some point said: >> If you own the network the connection runs over, you can allocate reserved >> bits to your heart's content > > Not really, as you still need to deal with future allocation by end to > end extensions. Say for example if I allocated RSV bit 3 to talk > to/from my proprietary WS load balancer, but then IANA allocates that > bit to a compression extension, my load balancer would then not be > able to pass standard compressed frames. Currently it will be very This is correct... as it is to be sure you have to add framing bytes or a pre-opcode or similar for your "load balancer", wrapping the existing framing and be unable to leverage the reserved bits. It's not deadly just a tiny bit less optimal than it could be. In return though, dynamic reserved bit management can be left out of the base spec, which is its own different kind of win; and your load balancer is proof against whatever is done with the reserved bits eventually, if anything. -Andy From jat@google.com Tue Aug 23 22:12: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 D1B9321F8B86 for ; Tue, 23 Aug 2011 22:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eBojniclpJJ for ; Tue, 23 Aug 2011 22:12:27 -0700 (PDT) Received: from mail-yw0-f70.google.com (mail-yw0-f70.google.com [209.85.213.70]) by ietfa.amsl.com (Postfix) with ESMTP id 0482C21F8BB9 for ; Tue, 23 Aug 2011 22:12:26 -0700 (PDT) Received: by ywb3 with SMTP id 3so1090360ywb.1 for ; Tue, 23 Aug 2011 22:13:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=NM3DzK7oqj5GjzKqmi+L8FsPp4wVDsmqKrpcC8XvlNk=; b=ggmN82J1yotV5Aknu+rMJAGw/qccyo6sZ43mJl+evOSf+DarJfOidVfoFbir15/s24 MumTR69enyNr8Pn+cuew== Received: by 10.150.253.9 with SMTP id a9mr4622589ybi.230.1314162816454; Tue, 23 Aug 2011 22:13:36 -0700 (PDT) Received: by 10.150.253.9 with SMTP id a9mr4622583ybi.230.1314162816261; Tue, 23 Aug 2011 22:13:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 23 Aug 2011 22:13:16 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Wed, 24 Aug 2011 01:13:16 -0400 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=001517475c92d71f7104ab395fe7 Cc: hybi@ietf.org Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 05:12:38 -0000 --001517475c92d71f7104ab395fe7 Content-Type: text/plain; charset=UTF-8 On Wed, Aug 24, 2011 at 12:39 AM, Greg Wilkins wrote: > What proposal? > The one you made a while back - I'm not saying you were making one now, though you were complaining that your proposal was not included in the base spec. Not really, as you still need to deal with future allocation by end to > end extensions. Say for example if I allocated RSV bit 3 to talk > to/from my proprietary WS load balancer, but then IANA allocates that > bit to a compression extension, my load balancer would then not be > able to pass standard compressed frames. Currently it will be very > difficult for intermediaries to do any in-band signalling that will be > future proof, since any indication you pick to mark out a signal may > subsequently be allocated to a standard extension. The gateway between the part you control and the outside world is free to refuse to accept the requested extension that conflicts with the internal private extension. -- John A. Tamplin Software Engineer (GWT), Google --001517475c92d71f7104ab395fe7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 24, 2011 at 12:39 AM, Greg Wilkins <= span dir=3D"ltr"><gregw@intalio.com= > wrote:
What proposal?

The = one you made a while back - I'm not saying you were making one now, tho= ugh you were complaining that your proposal was not included in the base sp= ec.

Not really, as you still nee= d to deal with future allocation by end to
end extensions. =C2=A0 Say for example if I allocated RSV bit 3 to talk
to/from my proprietary WS load balancer, but then IANA allocates that
bit to a compression extension, my load balancer would then not be
able to pass standard compressed frames. =C2=A0Currently it will be very difficult for intermediaries to do any in-band signalling that will be
future proof, since any indication you pick to mark out a signal may
subsequently be allocated to a standard extension.

The gateway between the part you control and the outside world is f= ree to refuse to accept the requested extension that conflicts with the int= ernal private extension.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--001517475c92d71f7104ab395fe7-- From jamie@shareable.org Wed Aug 24 02: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 3C33F21F8AD3 for ; Wed, 24 Aug 2011 02:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QTnN5XmqPIOf for ; Wed, 24 Aug 2011 02:37:24 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 9195C21F8A96 for ; Wed, 24 Aug 2011 02:37:24 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Qw9uo-0002PC-SM; Wed, 24 Aug 2011 10:38:30 +0100 Date: Wed, 24 Aug 2011 10:38:30 +0100 From: Jamie Lokier To: John Tamplin Message-ID: <20110824093830.GT14899@jl-vm1.vm.bytemark.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 09:37:25 -0000 John Tamplin wrote: > On Wed, Aug 24, 2011 at 12:39 AM, Greg Wilkins <[1]gregw@intalio.com> > wrote: > > What proposal? > > The one you made a while back - I'm not saying you were making one now, > though you were complaining that your proposal was not included in the > base spec. > > Not really, as you still need to deal with future allocation by end > to > end extensions.  Say for example if I allocated RSV bit 3 to talk > to/from my proprietary WS load balancer, but then IANA allocates > that > bit to a compression extension, my load balancer would then not be > able to pass standard compressed frames.  Currently it will be very > difficult for intermediaries to do any in-band signalling that will > be > future proof, since any indication you pick to mark out a signal may > subsequently be allocated to a standard extension. > > The gateway between the part you control and the outside world is free > to refuse to accept the requested extension that conflicts with the > internal private extension. If it blocks the outside world's end-to-end extension, something the load balancer should not care about (because it's end-to-end), the load balancer will be quite right regarded as broken. It is not even a case of refusing during negotiation, but rather dropping connections spuriously as far as other components see it. Since *end-to-end* negotiation is not something a load balancer should be participating in, it would not know what to reject at negotiation time, and would have to abort the connection when it sees extra bits that it knows it cannot forward. Luckily, there is a solution: As private extensions require both sides to agree before using them, they can also agree to encode conflicting, unrecognised bits from the outside world on entry to that hop, and decode them on exit. I.e. tunnel what they don't understand. (The same applies to mux encodings, which is why I have argued before that any frame bits and semantics that are present just to make room for future mux encodings, are unnecessary.) Unluckily, use of standardised bits *when automatically negotiated* for private purposes likely to be badly mangled by filtering ("censoring") intermediaries at some point, where components think they have hop-to-hop agreement but something in between thinks it is interfering with a standard WebSocket stream. But that's just something we'll have to deal with in the same ad-hoc way as with HTTP. Almost all of this comes down to whether negotiation is robust and reliable, and respected by every component in the path. -- Jamie From ibc@aliax.net Wed Aug 24 03:17: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 3ECFC21F86AA for ; Wed, 24 Aug 2011 03:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIvY48PJ47vm for ; Wed, 24 Aug 2011 03:17:24 -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 A522A21F8620 for ; Wed, 24 Aug 2011 03:17:24 -0700 (PDT) Received: by qyk35 with SMTP id 35so653026qyk.10 for ; Wed, 24 Aug 2011 03:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr3384508qce.185.1314181114628; Wed, 24 Aug 2011 03:18:34 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 03:18:34 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 12:18:34 +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] Are RSV1-3 bits really useful? 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, 24 Aug 2011 10:17:25 -0000 2011/8/24 Greg Wilkins : > Say for example if I allocated RSV bit 3 to talk > to/from my proprietary WS load balancer, but then IANA allocates that > bit to a compression extension, my load balancer would then not be > able to pass standard compressed frames. Wow, WebSocket is not yet a standard and people here is already thinking about using WS frame features for a propietary load balancing system. This must be the famous HTTP world... --=20 I=C3=B1aki Baz Castillo From phil127@gmail.com Wed Aug 24 03:20: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 3011A21F8620 for ; Wed, 24 Aug 2011 03:20:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.411 X-Spam-Level: X-Spam-Status: No, score=-3.411 tagged_above=-999 required=5 tests=[AWL=-0.112, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUu2YTb6OqWe for ; Wed, 24 Aug 2011 03:20:01 -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 C25C621F86CA for ; Wed, 24 Aug 2011 03:19:58 -0700 (PDT) Received: by bkar4 with SMTP id r4so914921bka.31 for ; Wed, 24 Aug 2011 03:21:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=dTNtt3F67flh1k2Z2MWesRn0ol8VVXK91OTqvWFXpuc=; b=IkmsXtJFajcjRUWwq+xHhGENmJIuoL6ikvM7Sa3Utc2pw6v+UY2t3SS05nAB01vcex S4cv2PDTi3VErjjsTYsMQDuH+XDEZzOqm609lylqAoYr/hITNXPwqiSczK0+F8E6krP5 Ir1Y20wmIjsf0qoXJn3U7vpb3+/F0NQiB1BFI= Received: by 10.204.8.82 with SMTP id g18mr2158850bkg.141.1314181268241; Wed, 24 Aug 2011 03:21:08 -0700 (PDT) Received: from [212.201.78.150] (pptp-212-201-78-150.pptp.stw-bonn.de [212.201.78.150]) by mx.google.com with ESMTPS id h26sm237793bkt.19.2011.08.24.03.21.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 03:21:07 -0700 (PDT) Message-ID: <4E54D087.4080001@gmail.com> Date: Wed, 24 Aug 2011 12:20:55 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Hybi References: In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 10:20:02 -0000 Am 24.08.2011 12:18, schrieb Iñaki Baz Castillo: > 2011/8/24 Greg Wilkins : >> Say for example if I allocated RSV bit 3 to talk >> to/from my proprietary WS load balancer, but then IANA allocates that >> bit to a compression extension, my load balancer would then not be >> able to pass standard compressed frames. > Wow, WebSocket is not yet a standard and people here is already > thinking about using WS frame features for a propietary load balancing > system. > This must be the famous HTTP world... > Hey, if people use HTTP as an internal database API (see couchdb), they'll use WS for load balancing, too. From julian.reschke@gmx.de Wed Aug 24 03:20: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 E927621F8B3F for ; Wed, 24 Aug 2011 03:20:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.428 X-Spam-Level: X-Spam-Status: No, score=-104.428 tagged_above=-999 required=5 tests=[AWL=-1.829, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSPeozyrONWY for ; Wed, 24 Aug 2011 03:20:24 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C6C1E21F8B42 for ; Wed, 24 Aug 2011 03:20:23 -0700 (PDT) Received: (qmail invoked by alias); 24 Aug 2011 10:21:32 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 24 Aug 2011 12:21:32 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX182FpwrewE2NnsKlxqF92mIhFkhjgBD8ZTWcJTOVw 21edu6d4tIJYBL Message-ID: <4E54D0AD.3050201@gmx.de> Date: Wed, 24 Aug 2011 12:21:33 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Alexey Melnikov References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> In-Reply-To: <4E5421FF.90101@isode.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 10:20:25 -0000 On 2011-08-23 23:56, Alexey Melnikov wrote: > ... >> Sec-WebSocket-Accept = "Sec-WebSocket-Accept" ":" base64-value > > I suggest we do whatever RFC 2616 is doing. I will double check. > ... I strongly suggest to do what HTTPbis is doing; just specify the ABNF for the field *value*. > ... Best regards, Julian From ibc@aliax.net Wed Aug 24 03:54: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 06BE421F8B1C for ; Wed, 24 Aug 2011 03:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6fBJ+WV+CNX for ; Wed, 24 Aug 2011 03:54:54 -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 6ADE521F8B03 for ; Wed, 24 Aug 2011 03:54:54 -0700 (PDT) Received: by qyk34 with SMTP id 34so2575106qyk.10 for ; Wed, 24 Aug 2011 03:56:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr3408352qce.185.1314183362510; Wed, 24 Aug 2011 03:56:02 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 03:56:02 -0700 (PDT) In-Reply-To: <4E54D087.4080001@gmail.com> References: <4E54D087.4080001@gmail.com> Date: Wed, 24 Aug 2011 12:56:02 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Philipp Serafin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 10:54:55 -0000 2011/8/24 Philipp Serafin : >> Wow, WebSocket is not yet a standard and people here is already >> thinking about using WS frame features for a propietary load balancing >> system. >> This must be the famous HTTP world... > Hey, if people use HTTP as an internal database API (see couchdb), > they'll use WS for load balancing, too. Yes, the new OSI model: 4 - Any kind of stuf Layer 3 - HTTP / WebSocket Layer 2.5 - DNS just type A Layer 2 - Data Link Layer 1 - Physical Layer - There is no need for a Transport Layer because applications just use TCP port 80 or 443 (TLS). - Network layer is neither needed as WebSocket Layer already replaces it. - No need for DNS queries other than A (AAAA is too modern and MX is not needed with current webmails). - There is no Application Layer (as any application must be built within a web page). HTML5 already provides audio/video (waiting for web-rtc) so SIP and XMPP are dropped. - JavaScript is the only language in the world for client applications, and any new specification must be designed to fit well with JavaScript. Also PHP is allowed in server side (the best and the only server side language). - Finally desktop operating systems (Windows, Linux/Ubuntu, MacOSX) must be replaced with single web browsers. Personal data must be stored in the cloud. --=20 I=C3=B1aki Baz Castillo From alexey.melnikov@isode.com Wed Aug 24 04:22: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 3032021F8AE6 for ; Wed, 24 Aug 2011 04:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id laqAaNTU7M-v for ; Wed, 24 Aug 2011 04:22:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7A521F8A23 for ; Wed, 24 Aug 2011 04:22:44 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 24 Aug 2011 12:23:53 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E54DF3E.6050207@isode.com> Date: Wed, 24 Aug 2011 12:23:42 +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: Julian Reschke References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> In-Reply-To: <4E54D0AD.3050201@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 11:22:45 -0000 Julian Reschke wrote: > On 2011-08-23 23:56, Alexey Melnikov wrote: > >> ... >> >>> Sec-WebSocket-Accept = "Sec-WebSocket-Accept" ":" base64-value >> >> I suggest we do whatever RFC 2616 is doing. I will double check. >> ... > > I strongly suggest to do what HTTPbis is doing; just specify the ABNF > for the field *value*. I am happy with that, because this means I don't need to change anything ;-). ' From ibc@aliax.net Wed Aug 24 04:49: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 8D94521F8B24 for ; Wed, 24 Aug 2011 04:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EPGwS28iZLY for ; Wed, 24 Aug 2011 04:49:10 -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 CE91321F8B1F for ; Wed, 24 Aug 2011 04:49:09 -0700 (PDT) Received: by qwc23 with SMTP id 23so785000qwc.31 for ; Wed, 24 Aug 2011 04:50:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr3411717qch.299.1314186619849; Wed, 24 Aug 2011 04:50:19 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 04:50:19 -0700 (PDT) In-Reply-To: <4E53E7D6.8040601@callenish.com> References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> <4E53E7D6.8040601@callenish.com> Date: Wed, 24 Aug 2011 13:50:19 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 24 Aug 2011 11:49:10 -0000 2011/8/23 Bruce Atherton : > I'm not talking about changing the framing. I am talking about using the > opcode field that is already there, but allowing different subprotocols t= o > define how to interpret it. I guess changing the definition of the binary > and text opcodes could be seen as changing the framing given how the spec= is > currently written, but that could be changed editorially with no impact t= o > anyone. Just identify those opcodes as being defined that way when no > subprotocol is specified or when subprotocols are defined but need to > differentiate binary and text messages (ie. all subprotocols used in the > browser). That would solve the issue that Bob and I=C3=B1aki have with > application protocol issues getting into the base spec, and it wouldn't > require a separate document. Or leave it alone as a bit of leakage of > application level concerns into the base spec, but let subprotocols defin= e > the other reserved opcodes. > > Looking through the spec, though, I see that there is no reference to > allowing a subprotocol to use reserved opcodes. I thought they were > available for use by both extensions and subprotocols. My mistake for mak= ing > that assumption. I guess my question now is, why not? The opcode is a use= ful > way to determine how to handle different message types, as the example fo= r > handling binary and text in Javascript shows. I can tell you from experie= nce > that it comes in handy for other application protocols as well. Hi. I don't like the layer mixing you are suggesting. opcode is a frame field, not a message field. WS Application layer is supposed to work with WS messages and use a simple API to close connection, send frame ping for keepalive and not much more. So I imagine a WS Framming layer (this is how I name it in my server) which receives frames and passes WS messages (full message or via streaming) to the WS Application which just receives the WS message and *nothing* else. An analogy of what you suggest would be an HTTP server inspecting TCP packet bits. That's wrong. But of course, I have no doubt that all these discussions exist due to the not very "standard" WS protocol design. No doubt at all. When a protocol is well designed and provides logical layers, the whole picture is easier to understand and implement. In WS draft lot of stuf is unclear, for example: - If my WS server receives a ping frame, should my "primary" WS Framming layer reply pong? or should it pass to my WS Application layer? - Some question in case my WS server receives a close frame. - If my WS Application must send a very long WS message, should the WS Application layer itself split it and pass it to the WS Framming layer (which would require informing about FIN bit and so, ugly for an API)? or should the WS Framming layer receive the full (or via straming) message and decide whether to fragment it or not in N frames? - Should the WS Application layer read RSV bits or extensions data from the frame?, which frame in case a message has been splitted in N frames???, or should the WS Framming be the only concerned layer about that? So from my point of view, the spec should clearly talk about a framming layer and application layer, setting limits and interaction between them. But it does not so all gets mixed and people then suggests things like the WS message receiver reading frame bits (which means no layers at all). Indicating layers in a protocol specification does NOT make it over engineered. Instead it would avoid 70% of daily discussions in this maillist. Just to give a personal example, recently I've coded a SIP proxy/server. SIP protocol (RFC 3261) is 100000 times more complex than WebSocket, but layers are very well specified within the RFC. So I spent more of the time coding specific parsing, timers and message passing mechanism, but the rsulting code is very clear as it implements the layers as stated in the RFC. In contrast, I've started a WS server recently. Parsing/framing stuf is already done but now I've terrible doubts about WS logic (i.e. the above given list of questions) and I don't like too much the resulting code as it's unclear where the responsibility is. Regards. --=20 I=C3=B1aki Baz Castillo From jamie@shareable.org Wed Aug 24 06:57: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 3847B21F8A70 for ; Wed, 24 Aug 2011 06:57:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.406 X-Spam-Level: X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6TNuh-28wcDu for ; Wed, 24 Aug 2011 06:57:55 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id AB86221F8A6F for ; Wed, 24 Aug 2011 06:57:55 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QwDyw-0004QX-WA; Wed, 24 Aug 2011 14:59:02 +0100 Date: Wed, 24 Aug 2011 14:59:02 +0100 From: Jamie Lokier To: =?iso-8859-1?Q?I=F1aki?= Baz Castillo Message-ID: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 13:57:56 -0000 Iñaki Baz Castillo wrote: > 2011/8/24 Greg Wilkins : > > Say for example if I allocated RSV bit 3 to talk > > to/from my proprietary WS load balancer, but then IANA allocates that > > bit to a compression extension, my load balancer would then not be > > able to pass standard compressed frames. > > Wow, WebSocket is not yet a standard and people here is already > thinking about using WS frame features for a propietary load balancing > system. I think you misunderstood. That WS load balancer is distributing *WS* connections among a backend of *normal WS* server applications. It's completely reasonably to at least consider WS, or modified WS, for the backends in that case, instead of inventing a different protocol which just carries WS traffic anyway. Imagine if you have 100,000,000 users connected by WS to your server. Obviously you cannot do it without a WS-aware load balancer. (I think 1,000,000 is roughly the maximum order of magnitude for a single, very well tuned server at the moment.) I expect even 10,000 connections will stress many WS applications, so WS-aware load balancers will be popular, I expect. > This must be the famous HTTP world... If you mean it needs to scale, yes of course... -- Jamie From ibc@aliax.net Wed Aug 24 07:00: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 E84C921F8556 for ; Wed, 24 Aug 2011 07:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nCPowBTo68Ql for ; Wed, 24 Aug 2011 07:00: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 65CE421F8540 for ; Wed, 24 Aug 2011 07:00:38 -0700 (PDT) Received: by qyk34 with SMTP id 34so2676315qyk.10 for ; Wed, 24 Aug 2011 07:01:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.43.3 with SMTP id u3mr120491qce.261.1314194508735; Wed, 24 Aug 2011 07:01:48 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 07:01:48 -0700 (PDT) Date: Wed, 24 Aug 2011 16:01:48 +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] Bug in draft-11 (Connection header) 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, 24 Aug 2011 14:00:39 -0000 Page 31: 3. If the response lacks a "Connection" header field or the "Connection" header field contains a value that is not an ASCII case-insensitive match for the value "Upgrade", the client MUST _Fail the WebSocket Connection_. "Connection" header allows a list of tokens separated by comma. So the following is valid (in fact Firefox 8 uses it): Connection: keep-alive, upgrade However the text above invalidates sich header value since: the "Connection" header field contains a value that is not an ASCII case-insensitive match for the value "Upgrade" Please replace it with: 3. If the response lacks a "Connection" header field or the "Connection" header field does not contain a value that is an ASCII case-insensitive match for the value "Upgrade", the client MUST _Fail the WebSocket Connection_. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 24 07:04: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 8582F21F8AB9 for ; Wed, 24 Aug 2011 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esNMqVKtwLZM for ; Wed, 24 Aug 2011 07:04:09 -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 E227821F8AAF for ; Wed, 24 Aug 2011 07:04:08 -0700 (PDT) Received: by qwc23 with SMTP id 23so877763qwc.31 for ; Wed, 24 Aug 2011 07:05:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.197.66 with SMTP id ej2mr3341765qab.398.1314194717890; Wed, 24 Aug 2011 07:05:17 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 07:05:17 -0700 (PDT) In-Reply-To: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> Date: Wed, 24 Aug 2011 16:05:17 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Jamie Lokier Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org, Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 14:04:09 -0000 2011/8/24 Jamie Lokier : > Imagine if you have 100,000,000 users connected by WS to your server. I would never do that. Instead I would try to implement DNS SRV mechanism within the protocol so I would never require a single server/point receiving all the clients connection, but a distributed cluster and each client connecting to a random server (using DNS SRV procedures). But better not to restart such discussion again :) --=20 I=C3=B1aki Baz Castillo From tyoshino@google.com Wed Aug 24 07:21: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 483CD21F8B1E for ; Wed, 24 Aug 2011 07:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.876 X-Spam-Level: X-Spam-Status: No, score=-105.876 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx+GVpRMqbkG for ; Wed, 24 Aug 2011 07:21:16 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0FDE321F8B16 for ; Wed, 24 Aug 2011 07:21:13 -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 p7OEM9Nd010875 for ; Wed, 24 Aug 2011 07:22:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314195732; bh=Sz860ixbY1aKhwc7xNHzu7Pa8GY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=LkuVQlxcWNjDb/2lXyN1xImIf/9ihdkg7NNglfd04UojBCM/It+eN2m8+DEETyBFX LK+TBt4zXS6dJeVCPtt8A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=FitqUMtoVUegU3pXlFKDIjoDjeKjVYq1WJ51Lq39buLhsRxGxrA1CXKff8zabf3JD kJbzHNqiODVPsxy8lUIWg== Received: from gyg8 (gyg8.prod.google.com [10.243.50.136]) by wpaz37.hot.corp.google.com with ESMTP id p7OEM8LT014634 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 07:22:08 -0700 Received: by gyg8 with SMTP id 8so1164800gyg.40 for ; Wed, 24 Aug 2011 07:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=k1vRxjXIt7DQ7gVZJGNwdIV9hvyE44YC83hH2xZ7rXY=; b=ceQBlbW71ihDF2bHZw6X/yYDtO1+zW/7A+HFwCIUIEl1kfbUTJROgJplN7PdKQ8JC1 dEFKMdQ631SMhdUm1tqw== Received: by 10.90.136.17 with SMTP id j17mr4857929agd.55.1314195728380; Wed, 24 Aug 2011 07:22:08 -0700 (PDT) Received: by 10.90.136.17 with SMTP id j17mr4857925agd.55.1314195728153; Wed, 24 Aug 2011 07:22:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.192.17 with HTTP; Wed, 24 Aug 2011 07:21:48 -0700 (PDT) In-Reply-To: <4E54DF3E.6050207@isode.com> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> <4E54DF3E.6050207@isode.com> From: Takeshi Yoshino Date: Wed, 24 Aug 2011 23:21:48 +0900 Message-ID: To: Alexey Melnikov Content-Type: multipart/alternative; boundary=00163630ecb38abd2404ab41097f X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 14:21:18 -0000 --00163630ecb38abd2404ab41097f Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 24, 2011 at 20:23, Alexey Melnikov wrote: > Julian Reschke wrote: > > On 2011-08-23 23:56, Alexey Melnikov wrote: >> >> ... >>> >>> Sec-WebSocket-Accept = "Sec-WebSocket-Accept" ":" base64-value >>>> >>> >>> I suggest we do whatever RFC 2616 is doing. I will double check. >>> ... >>> >> >> I strongly suggest to do what HTTPbis is doing; just specify the ABNF for >> the field *value*. > > Thanks Julian. I just took a look at HTTPbis docs. So, the WebSocket spec points RFC 2616 but uses ones in HTTPbis? I think it's not friendly for readers. What's the plan for final publish? Will the reference be replaced with HTTPbis? e.g. I'm fine with keeping "WSP" instead of "LWS" as HTTPbis defines, but one cannot find "WSP" in RFC 2616 referred from the sentence. > I am happy with that, because this means I don't need to change anything > ;-).' > OK. But if you do so, I'd suggest that we clarify what *-Client and *-Server means or remove those suffixes since the context (talking about S->C or C->S) is clear (separated into two paragraphs). It's clear if they were embedded in main text like Sec-WebSocket-Accept ABNF in the section 5.2.2.-3.-4. But they're not referred from any sentence but just appears suddenly in the section 5.3. It's confusing. Sounds like header names are Foo-Client and Bar-Server. Thanks, Takeshi --00163630ecb38abd2404ab41097f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 24, 2011 at 20:23, Alexey Melni= kov <alex= ey.melnikov@isode.com> wrote:
Julian Reschke wrote:
On 2011-08-23 23:56, Alexey Melnikov wrote:

...

Sec-WebSocket-Accept =3D "Sec-WebSocket-Accept" ":" bas= e64-value

I suggest we do whatever RFC 2616 is doing. I will double check.
...

I strongly suggest to do what HTTPbis is doing; just specify the ABNF for t= he field *value*.

= Thanks Julian. I just took a look at HTTPbis docs.

So, the WebSocket spec points RFC 2616 but uses ones in HTTPbis? I thi= nk it's not friendly for readers. What's the plan for final publish= ? Will the reference be replaced with HTTPbis?

e.g. I'm fine with keeping "WSP" instead of "LWS" a= s HTTPbis defines, but one cannot find "WSP" in RFC 2616 referred= from the sentence.
=A0
I am happy with that, because this means I don't need to change anythin= g ;-).'

OK. But if you do so, I'd suggest tha= t we clarify what *-Client and *-Server means or remove those suffixes sinc= e the context=A0(talking about S->C or C->S)=A0is clear (separated in= to two paragraphs).=A0It's clear if they were embedded in main text lik= e Sec-WebSocket-Accept ABNF in the section 5.2.2.-3.-4. But they're not= referred from any sentence but just appears suddenly in the section 5.3. I= t's confusing. Sounds like header names are Foo-Client and Bar-Server.<= /div>

Thanks,
Takeshi
--00163630ecb38abd2404ab41097f-- From tobias.oberstein@tavendo.de Wed Aug 24 07:23: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 93B4E21F8AD9 for ; Wed, 24 Aug 2011 07:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.045, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoOJqbwjUoRY for ; Wed, 24 Aug 2011 07:23:38 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id A4C7E21F876F for ; Wed, 24 Aug 2011 07:23:38 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Wed, 24 Aug 2011 07:24:49 -0700 From: Tobias Oberstein To: Jamie Lokier , =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= Date: Wed, 24 Aug 2011 07:23:52 -0700 Thread-Topic: [hybi] Are RSV1-3 bits really useful? Thread-Index: AcxiZgLceVO8PqCkRciV455MYpjmlQAAuw7A Message-ID: <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 14:23:39 -0000 > I think you misunderstood. >=20 > That WS load balancer is distributing *WS* connections among a backend of > *normal WS* server applications. >=20 > It's completely reasonably to at least consider WS, or modified WS, for t= he > backends in that case, instead of inventing a different protocol which ju= st > carries WS traffic anyway. >=20 > Imagine if you have 100,000,000 users connected by WS to your server. >=20 > Obviously you cannot do it without a WS-aware load balancer. I have zero experience with a scale like this, but why do you need the load-balancer have any knowledge of WS? There is stuff like OpenBSD relayd which can do stateful Layer-3 (not 7) lo= ad balancing. An incoming TCP connection is routed to a backend node, that rule is then d= ynamically inserted into the OpenBSD pf firewall (which is stateful). Subsequent traff= ic on layer 3 (IP) is then routed to that backend node. It can hearbeat/monitor backend c= luster, and pf can do failover/scale itself using CARP. http://www.openbsd.org/cgi-bin/man.cgi?query=3Drelayd&sektion=3D8&format=3D= html So, why does one need the load-balancer be WS aware? Just interested ..=20 From julian.reschke@gmx.de Wed Aug 24 07:42: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 F399721F8B5D for ; Wed, 24 Aug 2011 07:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.358 X-Spam-Level: X-Spam-Status: No, score=-104.358 tagged_above=-999 required=5 tests=[AWL=-1.759, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqqMwcFHhwjm for ; Wed, 24 Aug 2011 07:42:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9F09C21F8B4E for ; Wed, 24 Aug 2011 07:42:18 -0700 (PDT) Received: (qmail invoked by alias); 24 Aug 2011 14:43:28 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp024) with SMTP; 24 Aug 2011 16:43:28 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19KUQVOL9lKXbV6Bv1s3AygL1vXviQF5y7lhrjLnC LUlUV7SCiYVluE Message-ID: <4E550E0D.6050107@gmx.de> Date: Wed, 24 Aug 2011 16:43:25 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Takeshi Yoshino References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> <4E54DF3E.6050207@isode.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 14:42:20 -0000 On 2011-08-24 16:21, Takeshi Yoshino wrote: > On Wed, Aug 24, 2011 at 20:23, Alexey Melnikov > > wrote: > > Julian Reschke wrote: > > On 2011-08-23 23:56, Alexey Melnikov wrote: > > ... > > Sec-WebSocket-Accept = "Sec-WebSocket-Accept" ":" > base64-value > > > I suggest we do whatever RFC 2616 is doing. I will double check. > ... > > > I strongly suggest to do what HTTPbis is doing; just specify the > ABNF for the field *value*. > > > Thanks Julian. I just took a look at HTTPbis docs. > > So, the WebSocket spec points RFC 2616 but uses ones in HTTPbis? I think > it's not friendly for readers. What's the plan for final publish? Will > the reference be replaced with HTTPbis? ...that would imply waiting for HTTPbis; I doubt the WG wants to do this. My recommendation is to use RFC2616 grammar constructs, but follow the HTTPbis style of only defining the ABNF for the header value. > ... Best regards, Julian From jamie@shareable.org Wed Aug 24 08:02:32 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 5B0E121F8B9B for ; Wed, 24 Aug 2011 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6xD3x50CPr9 for ; Wed, 24 Aug 2011 08:02:31 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id C6F7421F8AAA for ; Wed, 24 Aug 2011 08:02:31 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QwEzU-0004lS-3M; Wed, 24 Aug 2011 16:03:40 +0100 Date: Wed, 24 Aug 2011 16:03:40 +0100 From: Jamie Lokier To: Tobias Oberstein Message-ID: <20110824150340.GZ14899@jl-vm1.vm.bytemark.co.uk> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 15:02:32 -0000 Tobias Oberstein wrote: > So, why does one need the load-balancer be WS aware? Just interested .. The simplest is probably using mux of some kind, even if it's only to the backend servers. Also, connection transfers. As WS depends on a continuous connection, unlike HTTP, if you have servers going up and down, or their availability varying with individual load, rerouting connections without the client seeing a drop may be desirable in some applications. (All the more if some nice programming model hides it.) It goes deeper when you route individual requests in the WS stream based on request type, object or whatever (like HTTP relays do based on the URL or Cookie), or aggregate pub-sub subscriptions or multicast updates. Since WS conversations are likely to be used, in some applications, for continuous real-time state which may well depend on real-time activity of any of the other users, there's potentially more internode traffic than HTTP where the coordination tends to be isolated in the database and memcached. So the message topology matters more. I will readily agree at that point you're using another protocol, though you may well want it to be an WS application protocol or WS extension, so the backend servers are not much different than serving a smaller version of the same site. That's what's attractive about "horizontal scaling" after all - no need to rewrite everything as you scale up. All the best, -- Jamie From phil127@gmail.com Wed Aug 24 08:29: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 D4BCE21F8C3E for ; Wed, 24 Aug 2011 08:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKrxvwfHstND for ; Wed, 24 Aug 2011 08:29:59 -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 1C72821F8C39 for ; Wed, 24 Aug 2011 08:29:58 -0700 (PDT) Received: by bkar4 with SMTP id r4so1173781bka.31 for ; Wed, 24 Aug 2011 08:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=8z+zrzULi9epCJ2459r1/ifiG9e8+LiGXIGUc5AtOyg=; b=gyYmbW/jg/iGlBH3cI+N8W5GvE4lYocHymUxz/ghdV6cKcp1lz/n71zixqylf0Sw88 F+UQkpGKvhXNaTCiljfujM+2CL2q/0wZK8yBOCtlFC5FGxryFfKH+Gov9WFDHegkp/kw 8kpnITjlLdSsresc8SF5qjHiY4t8A/xGHmKcM= Received: by 10.204.142.65 with SMTP id p1mr2514455bku.183.1314199866812; Wed, 24 Aug 2011 08:31:06 -0700 (PDT) Received: from [212.201.78.150] (pptp-212-201-78-150.pptp.stw-bonn.de [212.201.78.150]) by mx.google.com with ESMTPS id a3sm325524bkd.35.2011.08.24.08.31.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 08:31:06 -0700 (PDT) Message-ID: <4E55192D.3020606@gmail.com> Date: Wed, 24 Aug 2011 17:30:53 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E54D087.4080001@gmail.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Hybi Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 15:29:59 -0000 Am 24.08.2011 12:56, schrieb Iñaki Baz Castillo: > > > Yes, the new OSI model: > > 4 - Any kind of stuf Layer > 3 - HTTP / WebSocket Layer > 2.5 - DNS just type A Layer > 2 - Data Link Layer > 1 - Physical Layer > > > - There is no need for a Transport Layer because applications just use > TCP port 80 or 443 (TLS). > > - Network layer is neither needed as WebSocket Layer already replaces it. > > - No need for DNS queries other than A (AAAA is too modern and MX is > not needed with current webmails). > > - There is no Application Layer (as any application must be built > within a web page). HTML5 already provides audio/video (waiting for > web-rtc) so SIP and XMPP are dropped. > > - JavaScript is the only language in the world for client > applications, and any new specification must be designed to fit well > with JavaScript. Also PHP is allowed in server side (the best and the > only server side language). > > - Finally desktop operating systems (Windows, Linux/Ubuntu, MacOSX) > must be replaced with single web browsers. Personal data must be > stored in the cloud. I'd like to pass this on to randall munroe, please. From tobias.oberstein@tavendo.de Wed Aug 24 08:30: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 3D7A021F8C3D for ; Wed, 24 Aug 2011 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvjbec08ujI6 for ; Wed, 24 Aug 2011 08:30:24 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA0D21F8C35 for ; Wed, 24 Aug 2011 08:30:24 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Wed, 24 Aug 2011 08:31:34 -0700 From: Tobias Oberstein To: Jamie Lokier Date: Wed, 24 Aug 2011 08:30:37 -0700 Thread-Topic: [hybi] Are RSV1-3 bits really useful? Thread-Index: AcxibwW/QI9l1oPkSz2fnCwl2uN+ZQAAjMDg Message-ID: <634914A010D0B943A035D226786325D422C0D5D39F@EXVMBX020-12.exch020.serverdata.net> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> <20110824150340.GZ14899@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20110824150340.GZ14899@jl-vm1.vm.bytemark.co.uk> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 15:30:25 -0000 > > So, why does one need the load-balancer be WS aware? Just interested .. >=20 > The simplest is probably using mux of some kind, even if it's only to the > backend servers. Ok, I see, when muxed complete WS connections (like with x-google-mux) or individual message channels (like with a yet to be defined flat-mux) should be targeted at different backend nodes, then yes, that can't be done with stateful layer-3 or layer-7 (TCP) load-balancing. > Also, connection transfers. As WS depends on a continuous connection, > unlike HTTP, if you have servers going up and down, or their availability > varying with individual load, rerouting connections without the client se= eing a > drop may be desirable in some applications. (All the more if some nice > programming model hides it.) That will get quite tricky. I.e. the WS connection that was previously authenticated on backend node 1 during WS handshake now needs to be handed over to node 2, while telling node 2 that the WS is already established/authenticated. But yes, as far as I know, relayd can transparently failover itself (by pf/= carp), but not mediated, established TCP connections when the target node fails. I might be wrong here. > It goes deeper when you route individual requests in the WS stream based > on request type, object or whatever (like HTTP relays do based on the URL= or > Cookie), or aggregate pub-sub subscriptions or multicast updates. >=20 > Since WS conversations are likely to be used, in some applications, for > continuous real-time state which may well depend on real-time activity of > any of the other users, there's potentially more internode traffic than H= TTP > where the coordination tends to be isolated in the database and > memcached. So the message topology matters more. >=20 > I will readily agree at that point you're using another protocol, though = you > may well want it to be an WS application protocol or WS extension, so the > backend servers are not much different than serving a smaller version of = the > same site. That's what's attractive about "horizontal scaling" after all= - no > need to rewrite everything as you scale up. What you then do with above is put deep application logic into the load-balancing layer. Whether thats good is open for debate. I for at least= , would be afraid of doing that. I'd prefer having the LB layer only know who's up and maybe what's the load on each backend node. Also, with all of above I'd guess we are talking about really large deploym= ents. I mean, probably 10 world-wide. A couple of OBSD boxes with sane NICs and low end CPUs can saturate multiple Gb/s links. pf can maintain statefully really large numbers of connections. That should take one quite far, withou= t the complexity of WS aware balancing .. just my 2cts. Anyway, thanks for your insights! >=20 > All the best, > -- Jamie From ibc@aliax.net Wed Aug 24 08:53: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 1146221F8C4E for ; Wed, 24 Aug 2011 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nEVJFLU8Lo6u for ; Wed, 24 Aug 2011 08:53:20 -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 B307521F8C55 for ; Wed, 24 Aug 2011 08:53:20 -0700 (PDT) Received: by qwc23 with SMTP id 23so989268qwc.31 for ; Wed, 24 Aug 2011 08:54:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr3654313qch.299.1314201268656; Wed, 24 Aug 2011 08:54:28 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 08:54:28 -0700 (PDT) In-Reply-To: <4E55192D.3020606@gmail.com> References: <4E54D087.4080001@gmail.com> <4E55192D.3020606@gmail.com> Date: Wed, 24 Aug 2011 17:54:28 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Philipp Serafin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 15:53:22 -0000 2011/8/24 Philipp Serafin : > Am 24.08.2011 12:56, schrieb I=C3=B1aki Baz Castillo: >> >> >> Yes, the new OSI model: >> >> =C2=A0 4 =C2=A0 =C2=A0 =C2=A0- Any kind of stuf Layer >> =C2=A0 3 =C2=A0 =C2=A0 =C2=A0- HTTP / WebSocket Layer >> =C2=A0 2.5 =C2=A0 - DNS just type A Layer >> =C2=A0 2 =C2=A0 =C2=A0 =C2=A0- Data Link Layer >> =C2=A0 1 =C2=A0 =C2=A0 =C2=A0- Physical Layer >> >> >> - There is no need for a Transport Layer because applications just use >> TCP port 80 or 443 (TLS). >> >> - Network layer is neither needed as WebSocket Layer already replaces it= . >> >> - No need for DNS queries other than A (AAAA is too modern and MX is >> not needed with current webmails). >> >> - There is no Application Layer (as any application must be built >> within a web page). HTML5 already provides audio/video (waiting for >> web-rtc) so SIP and XMPP are dropped. >> >> - JavaScript is the only language in the world for client >> applications, and any new specification must be designed to fit well >> with JavaScript. Also PHP is allowed in server side (the best and the >> only server side language). >> >> - Finally desktop operating systems (Windows, Linux/Ubuntu, MacOSX) >> must be replaced with single web browsers. Personal data must be >> stored in the cloud. > I'd like to pass this on to randall munroe, please. Oh, it could fit well: http://xkcd.com/934/ XD --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Wed Aug 24 09:05: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 9F39B21F86CA for ; Wed, 24 Aug 2011 09:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L4l2WaMErc3A for ; Wed, 24 Aug 2011 09:05:57 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 41E3821F86BE for ; Wed, 24 Aug 2011 09:05:57 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.10]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QwFyr-0003G9-Gy; Wed, 24 Aug 2011 09:07:05 -0700 Message-ID: <4E5521A1.6010702@callenish.com> Date: Wed, 24 Aug 2011 09:06:57 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> <4E53E7D6.8040601@callenish.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 24 Aug 2011 16:05:57 -0000 On 24/08/2011 4:50 AM, Iñaki Baz Castillo wrote: > Hi. I don't like the layer mixing you are suggesting. opcode is a > frame field, not a message field. WS Application layer is supposed to > work with WS messages and use a simple API to close connection, send > frame ping for keepalive and not much more. Opcode is a message field. It is set only on the first frame of a message. All other frames have a continuation opcode. It is only a frame field in the sense that it is stored in the header of the first frame of the message. From Gabriel.Montenegro@microsoft.com Wed Aug 24 09:11: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 1394E21F8A1A for ; Wed, 24 Aug 2011 09:11:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU5LUP3TK2wZ for ; Wed, 24 Aug 2011 09:11:16 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id 8856021F8997 for ; Wed, 24 Aug 2011 09:11:16 -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; Wed, 24 Aug 2011 09:12:27 -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.323.7; Wed, 24 Aug 2011 09:12:26 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.133]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Wed, 24 Aug 2011 09:12:26 -0700 From: Gabriel Montenegro To: Julian Reschke , Takeshi Yoshino Thread-Topic: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.txt Thread-Index: AQHMYmlFF82DkUaV402RzULTk8gdR5UsiOGA//+jbXA= Date: Wed, 24 Aug 2011 16:12:26 +0000 Message-ID: References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> <4E54DF3E.6050207@isode.com> <4E550E0D.6050107@gmx.de> In-Reply-To: <4E550E0D.6050107@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 16:11:17 -0000 Agree with Julian. We cannot have a normative reference to HTTPbis. > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Julian Reschke > Sent: Wednesday, August 24, 2011 07:43 > To: Takeshi Yoshino > Cc: hybi@ietf.org > Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi- > thewebsocketprotocol-11.txt >=20 > On 2011-08-24 16:21, Takeshi Yoshino wrote: > > On Wed, Aug 24, 2011 at 20:23, Alexey Melnikov > > > wrote: > > > > Julian Reschke wrote: > > > > On 2011-08-23 23:56, Alexey Melnikov wrote: > > > > ... > > > > Sec-WebSocket-Accept =3D "Sec-WebSocket-Accept" ":" > > base64-value > > > > > > I suggest we do whatever RFC 2616 is doing. I will double c= heck. > > ... > > > > > > I strongly suggest to do what HTTPbis is doing; just specify th= e > > ABNF for the field *value*. > > > > > > Thanks Julian. I just took a look at HTTPbis docs. > > > > So, the WebSocket spec points RFC 2616 but uses ones in HTTPbis? I > > think it's not friendly for readers. What's the plan for final > > publish? Will the reference be replaced with HTTPbis? >=20 > ...that would imply waiting for HTTPbis; I doubt the WG wants to do this. >=20 > My recommendation is to use RFC2616 grammar constructs, but follow the > HTTPbis style of only defining the ABNF for the header value. >=20 > > ... >=20 > Best regards, Julian > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ibc@aliax.net Wed Aug 24 09:11: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 5E94F21F8661 for ; Wed, 24 Aug 2011 09:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYzM8ejH3LWP for ; Wed, 24 Aug 2011 09:11:53 -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 AACF121F8997 for ; Wed, 24 Aug 2011 09:11:53 -0700 (PDT) Received: by qyk35 with SMTP id 35so887935qyk.10 for ; Wed, 24 Aug 2011 09:13:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.204.5 with SMTP id fk5mr3552045qab.298.1314202384173; Wed, 24 Aug 2011 09:13:04 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 09:13:04 -0700 (PDT) In-Reply-To: <4E5521A1.6010702@callenish.com> References: <20110823031733.ef1fc80126c74c6c202a919c41c7bb0b.2dc166514a.wbe@email03.secureserver.net> <4E53D952.1000202@callenish.com> <4E53E7D6.8040601@callenish.com> <4E5521A1.6010702@callenish.com> Date: Wed, 24 Aug 2011 18:13:04 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Bob Gezelter Subject: Re: [hybi] Retitled: Poor Use of subprotocol; Probably should be supraprotocol (or client 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, 24 Aug 2011 16:11:54 -0000 2011/8/24 Bruce Atherton : > On 24/08/2011 4:50 AM, I=C3=B1aki Baz Castillo wrote: >> >> Hi. I don't like the layer mixing you are suggesting. opcode is a >> frame field, not a message field. WS Application layer is supposed to >> work with WS messages and use a simple API to close connection, send >> frame ping for keepalive and not much more. > > Opcode is a message field. It is set only on the first frame of a message= . > All other frames have a continuation opcode. It is only a frame field in = the > sense that it is stored in the header of the first frame of the message. Yes, sorry, my mistake. In fact, my WS Framming layer pass also the opcode (just text or binary) to the WS Application layer along with the message itself. --=20 I=C3=B1aki Baz Castillo From jamie@shareable.org Wed Aug 24 09:18: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 9EFFE21F8C6F for ; Wed, 24 Aug 2011 09:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiL0A9qtjgPy for ; Wed, 24 Aug 2011 09:18:49 -0700 (PDT) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 0827C21F8C69 for ; Wed, 24 Aug 2011 09:18:49 -0700 (PDT) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1QwGBJ-00053K-8r; Wed, 24 Aug 2011 17:19:57 +0100 Date: Wed, 24 Aug 2011 17:19:57 +0100 From: Jamie Lokier To: Tobias Oberstein Message-ID: <20110824161957.GA14899@jl-vm1.vm.bytemark.co.uk> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> <20110824150340.GZ14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D39F@EXVMBX020-12.exch020.serverdata.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <634914A010D0B943A035D226786325D422C0D5D39F@EXVMBX020-12.exch020.serverdata.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? 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, 24 Aug 2011 16:18:49 -0000 Tobias Oberstein wrote: > > Also, connection transfers. As WS depends on a continuous connection, > > unlike HTTP, if you have servers going up and down, or their availability > > varying with individual load, rerouting connections without the client seeing a > > drop may be desirable in some applications. (All the more if some nice > > programming model hides it.) > > That will get quite tricky. I.e. the WS connection that was previously > authenticated on backend node 1 during WS handshake now needs to > be handed over to node 2, while telling node 2 that the WS is already > established/authenticated. With WS there's application state, but there's no reason it can't be a generic blob as far as failover components are concerned. You still want the client to be able to resync (networks cut off TCP randomly), but state transfer reduces the incidence of delays due to that, and frees up the engineers who can bring up and take down servers more freely. > What you then do with above is put deep application logic into the > load-balancing layer. Whether thats good is open for debate. I for at least, > would be afraid of doing that. I'd prefer having the LB layer only know > who's up and maybe what's the load on each backend node. I agree, avoid deep application logic in the LB if you can. Keep the equipment / software generic at each layer. However certain useful structures like publish-subcribe and pseudo-multicasting are generic and useful enough to build into LBs. That the same structures also simplify many applications on a single server, and then scale well, is another motivation. We're talking here about LBs and backends, but the same applies elsewhere, though it's realistically a lot harder to deploy elsewhere. > Also, with all of above I'd guess we are talking about really large > deployments. I mean, probably 10 world-wide. A couple of OBSD boxes > with sane NICs and low end CPUs can saturate multiple Gb/s links. Everything depends on the amount of CPU and memory you need to work out *what* to send, and the size of individual messages if you are talking about saturating links. > pf can maintain statefully really large numbers of connections. That > should take one quite far, without the complexity of WS aware > balancing .. just my 2cts. Oh I agree. It remains to be seen what will really work & there's not much point optimising what isn't needed. We shouldn't design much *in* to WS, just avoid over-constraining it. -- Jamie From ibc@aliax.net Wed Aug 24 09:31: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 0952421F8C64 for ; Wed, 24 Aug 2011 09:31:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kclkuFrlmWT7 for ; Wed, 24 Aug 2011 09:31:58 -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 42FD821F8C5E for ; Wed, 24 Aug 2011 09:31:58 -0700 (PDT) Received: by qwc23 with SMTP id 23so1026955qwc.31 for ; Wed, 24 Aug 2011 09:33:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr3732394qce.185.1314203588849; Wed, 24 Aug 2011 09:33:08 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 09:33:08 -0700 (PDT) Date: Wed, 24 Aug 2011 18:33:08 +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] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 16:31:59 -0000 /subprotocol/ Either a single value representing the subprotocol the server is ready to use or null. The value chosen MUST be derived from the client's handshake, specifically by selecting one of the values from the "Sec-WebSocket-Protocol" field that the server is willing to use for this connection (if any). If the client's handshake did not contain such a header field, or if the server does not agree to any of the client's requested subprotocols, the only acceptable value is null. The absence of such a field is equivalent to the null value (meaning that if the server does not wish to agree to one of the suggested subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| header field in its response). The empty string is not the same as the null value for these purposes, and is not a legal value for this field. The ABNF for the value of this header field is (token), where the definitions of constructs and rules are as given in [RFC2616]. So it's stating that in case the client does not send a Sec-WebSocket-Protocol header, the server MUST NOT include such a header in the 101 response. Why?? why cannot the server include "Sec-WebSocket-Protocol: test.foo.com" in the 101 response meaning that *that* is the chosen protocol? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 24 09:37: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 5B89E21F8C30 for ; Wed, 24 Aug 2011 09:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VnUKsn+ITrd for ; Wed, 24 Aug 2011 09:37:28 -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 DCE0721F8C0F for ; Wed, 24 Aug 2011 09:37:27 -0700 (PDT) Received: by qwc23 with SMTP id 23so1032208qwc.31 for ; Wed, 24 Aug 2011 09:38:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr3738196qce.185.1314203918507; Wed, 24 Aug 2011 09:38:38 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 09:38:37 -0700 (PDT) Date: Wed, 24 Aug 2011 18:38:37 +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] Which HTTP response must be sent in case of non supported 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, 24 Aug 2011 16:37:28 -0000 Hi, I've seen this question in this maillist some times (including some other mail from me) but AFAIK there is no official reply yet. Very easy: - Client handshake includes: Sec-WebSocket-Protocol: aaa, bbb, ccc - Server does not speak aaa, bbb neither ccc, but just ddd. So I *assume* that the server MUST reject (non-101) the handshake request. Which HTTP code must it use? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 24 09:39: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 1EA0F21F8C5D for ; Wed, 24 Aug 2011 09:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.647 X-Spam-Level: X-Spam-Status: No, score=-2.647 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oio0n9kFX2e7 for ; Wed, 24 Aug 2011 09:39:15 -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 95D9121F8C0F for ; Wed, 24 Aug 2011 09:39:15 -0700 (PDT) Received: by qyk35 with SMTP id 35so912168qyk.10 for ; Wed, 24 Aug 2011 09:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.43.3 with SMTP id u3mr284295qce.261.1314204026303; Wed, 24 Aug 2011 09:40:26 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 09:40:26 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 18:40:26 +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: Re: [hybi] Which HTTP response must be sent in case of non supported 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, 24 Aug 2011 16:39:16 -0000 2011/8/24 I=C3=B1aki Baz Castillo : > Hi, I've seen this question in this maillist some times (including > some other mail from me) but AFAIK there is no official reply yet. > Very easy: > > - Client handshake includes: > =C2=A0 =C2=A0Sec-WebSocket-Protocol: aaa, bbb, ccc > > - Server does not speak aaa, bbb neither ccc, but just ddd. > > So I *assume* that the server MUST reject (non-101) the handshake > request. Which HTTP code must it use? I suggest HTTP 501 Not Implemented: 10.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource. --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Wed Aug 24 10:40: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 62E3421F8C11 for ; Wed, 24 Aug 2011 10:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.428 X-Spam-Level: X-Spam-Status: No, score=-102.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R41L2zGizZlj for ; Wed, 24 Aug 2011 10:40:01 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9C021F8BF4 for ; Wed, 24 Aug 2011 10:40:01 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 943C241665; Wed, 24 Aug 2011 11:43:30 -0600 (MDT) Message-ID: <4E5537B7.7090608@stpeter.im> Date: Wed, 24 Aug 2011 11:41:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Gabriel Montenegro References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> <4E54DF3E.6050207@isode.com> <4E550E0D.6050107@gmx.de> In-Reply-To: X-Enigmail-Version: 1.3 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 17:40:02 -0000 On 8/24/11 10:12 AM, Gabriel Montenegro wrote: > Agree with Julian. We cannot have a normative reference to HTTPbis. Well, we could, but we don't want to. :-) If we did, the Websocket spec wouldn't be published until the HTTPbis specs are published (probably sometime in 2012 if all goes well). We'll be hard at work on WS 1.1 by then. ;-) Peter -- Peter Saint-Andre https://stpeter.im/ From theturtle32@gmail.com Wed Aug 24 11:03: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 283C621F8A64 for ; Wed, 24 Aug 2011 11:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.751 X-Spam-Level: X-Spam-Status: No, score=-2.751 tagged_above=-999 required=5 tests=[AWL=0.548, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UvLy0jw0+4Gv for ; Wed, 24 Aug 2011 11:03:53 -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 88CBE21F8AF5 for ; Wed, 24 Aug 2011 11:03:53 -0700 (PDT) Received: by yie12 with SMTP id 12so1273156yie.31 for ; Wed, 24 Aug 2011 11:05:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=l1FyzlIxEVabMinpekXV0hO9J95kpcpnBYlgjKc+kAM=; b=aQV/cY+ues2s8Ga7tZgg8blmmJQYDeBPCDNpHEzZZkTsYLszFYleEnDi88njH7+2bS bkBA60BqbI8WYBUtZbKXXK254bVFO60eGrcUoMLv7r16+TNiEquIBWhqmwPFJu+mQcBj 0osAJSByqdLqfa3eWC/SoGXjIx97TP32xA38w= Received: by 10.42.156.201 with SMTP id a9mr4933018icx.459.1314209103234; Wed, 24 Aug 2011 11:05:03 -0700 (PDT) Received: from [192.168.1.78] (cpe-98-148-229-193.socal.res.rr.com [98.148.229.193]) by mx.google.com with ESMTPS id a9sm956425icy.18.2011.08.24.11.04.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 11:05:01 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (8J2) From: Brian McKelvey Date: Wed, 24 Aug 2011 11:04:55 -0700 To: =?utf-8?Q?I=C3=B1aki_Baz_Castillo?= Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 18:03:54 -0000 Because if the client didn't request it, it doesn't know how to speak it. Sent from my iPhone On Aug 24, 2011, at 9:33 AM, I=C3=B1aki Baz Castillo wrote: > /subprotocol/ > Either a single value representing the subprotocol the server > is ready to use or null. The value chosen MUST be derived > from the client's handshake, specifically by selecting one of > the values from the "Sec-WebSocket-Protocol" field that the > server is willing to use for this connection (if any). If the > client's handshake did not contain such a header field, or if > the server does not agree to any of the client's requested > subprotocols, the only acceptable value is null. The absence > of such a field is equivalent to the null value (meaning that > if the server does not wish to agree to one of the suggested > subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| > header field in its response). The empty string is not the > same as the null value for these purposes, and is not a legal > value for this field. The ABNF for the value of this header > field is (token), where the definitions of constructs and > rules are as given in [RFC2616]. >=20 >=20 > So it's stating that in case the client does not send a > Sec-WebSocket-Protocol header, the server MUST NOT include such a > header in the 101 response. Why?? why cannot the server include > "Sec-WebSocket-Protocol: test.foo.com" in the 101 response meaning > that *that* is the chosen protocol? >=20 >=20 > --=20 > I=C3=B1aki Baz Castillo > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ibc@aliax.net Wed Aug 24 11:10: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 4DB8B21F8B6B for ; Wed, 24 Aug 2011 11:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPIUgwkBxq-p for ; Wed, 24 Aug 2011 11:10:21 -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 B5CE421F8B39 for ; Wed, 24 Aug 2011 11:10:21 -0700 (PDT) Received: by qyk35 with SMTP id 35so992033qyk.10 for ; Wed, 24 Aug 2011 11:11:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr3824947qci.223.1314209485841; Wed, 24 Aug 2011 11:11:25 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 11:11:25 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 20:11:25 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Brian McKelvey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 18:10:22 -0000 2011/8/24 Brian McKelvey : > Because if the client didn't request it, it doesn't know how to speak it. So then, which protocol is supposed to be established? no one?? If the client does not suggest a protocol(s) then the server should do it in the response. If then the client does not support it, just close the connection (same case as when the 101 response contains a WS protocol not supported by the client). --=20 I=C3=B1aki Baz Castillo From jmason@rim.com Wed Aug 24 11:50: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 11E5221F8779 for ; Wed, 24 Aug 2011 11:50:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOGoXj13eymL for ; Wed, 24 Aug 2011 11:50:56 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC1D21F859E for ; Wed, 24 Aug 2011 11:50:54 -0700 (PDT) X-AuditID: 0a412830-b7c7aae000001406-74-4e55484c2c6a Received: from XHT108CNC.rim.net (xht108cnc.rim.net [10.65.22.54]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 05.8D.05126.C48455E4; Wed, 24 Aug 2011 18:51:57 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT108CNC.rim.net ([fe80::5ccc:ad5f:1697:fdbb%11]) with mapi; Wed, 24 Aug 2011 14:52:05 -0400 From: Joe Mason To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Brian McKelvey Date: Wed, 24 Aug 2011 14:52:12 -0400 Thread-Topic: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" Thread-Index: AcxiiUPgXP7KjwzYRCK5VkbyB0x3XwABYzog Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrIKsWRmVeSWpSXmKPExsXC5ShmpuvrEepncP01t8X7l9uYLKbvs7GY 9vcqswOzx7mG9+weO2fdZfdYsuQnUwBzVAOjTWJeXn5JYkmqQkpqcbKtkk9qemKOQkBRZlli cqWCS2Zxck5iZm5qkZJCZoqtkomSQkFOYnJqbmpeia1SYkFBal6Kkh2XAgawASrLzFNIzUvO T8nMS7dV8gz217WwMLXUNVSy00UCCf+4M761TmUumMBTcX/fS7YGxhfcXYycHBICJhINzy4y Q9hiEhfurWcDsYUEepgkLpzJ62LkArIXM0osmvOABSTBJqAg8fnwAyYQW0QgTWLl3CdgcWYB ZYmrx1aA2SwCqhInj30CGyQsECLRdu8cVH2oxLmf09ghbCOJc19egNXwCnhIvH+7lxVi2SlG iTWbroIVcQoESry+9gJsKCPQdd9PrWGCWCYucevJfCaIqwUkluw5D/WBqMTLx/9YIepFJe60 r2fsYuQAqteUWL9LH6JVUWJK90N2iL2CEidnPmGZwCg2C8nUWQgds5B0zELSsYCRZRWjYG5G sYGZYXJesl5RZq5eXmrJJkZw2tAw2ME4Ya/WIUYBDkYlHl5+l1A/IdbEsuLK3EOMEhzMSiK8 p86F+AnxpiRWVqUW5ccXleakFh9itAAG3ERmKe7kfGBKyyuJNzYwQOEoifOGSRv4CQmkA9NR dmpqQWoRTCsTB6dUA2MZ036ZgC29h/K0eOQMhC52Ca232uiopJi8fWXs21XyqbusbB+pL/q8 R2zRsQ3RaqrhF5YoXvmy/sFh7vels73j2Ix8OH8FrZoZxneN2UV5UnW1w809S9e/jOk90GVf /tXSyiI9/MGXw9xbWFYf2RNfJeH9WW31Ke0lwarJAtWKDoych8ySWpVYijMSDbWYi4oTAZ4J coY0AwAA Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 18:50:58 -0000 SXQncyBwZXJmZWN0bHkgdmFsaWQgZm9yIHRoZSBjbGllbnQgYW5kIHNlcnZlciB0byBub3Qg dXNlIGEgbmFtZWQgc3VicHJvdG9jb2wsIGp1c3QgYW4gYWQtaG9jIGFub255bW91cyBvbmUu ICBJJ2QgZXhwZWN0IG1vc3Qgd2ViIHNpdGVzIHRvIHdvcmsgbGlrZSB0aGlzLg0KDQo+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGh5YmktYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IEnDsWFr aSBCYXogQ2FzdGlsbG8NCj4gU2VudDogV2VkbmVzZGF5LCBBdWd1c3QgMjQsIDIwMTEgMjox MSBQTQ0KPiBUbzogQnJpYW4gTWNLZWx2ZXkNCj4gQ2M6IGh5YmlAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtoeWJpXSBQbGVhc2UgY2FscmlmeSAiNS4yLjIuIFNlbmRpbmcgdGhlIFNl cnZlcidzIE9wZW5pbmcNCj4gSGFuZHNoYWtlIg0KPiANCj4gMjAxMS84LzI0IEJyaWFuIE1j S2VsdmV5IDx0aGV0dXJ0bGUzMkBnbWFpbC5jb20+Og0KPiA+IEJlY2F1c2UgaWYgdGhlIGNs aWVudCBkaWRuJ3QgcmVxdWVzdCBpdCwgaXQgZG9lc24ndCBrbm93IGhvdyB0byBzcGVhaw0K PiBpdC4NCj4gDQo+IFNvIHRoZW4sIHdoaWNoIHByb3RvY29sIGlzIHN1cHBvc2VkIHRvIGJl IGVzdGFibGlzaGVkPyBubyBvbmU/Pw0KPiANCj4gSWYgdGhlIGNsaWVudCBkb2VzIG5vdCBz dWdnZXN0IGEgcHJvdG9jb2wocykgdGhlbiB0aGUgc2VydmVyIHNob3VsZCBkbw0KPiBpdCBp biB0aGUgcmVzcG9uc2UuIElmIHRoZW4gdGhlIGNsaWVudCBkb2VzIG5vdCBzdXBwb3J0IGl0 LCBqdXN0IGNsb3NlDQo+IHRoZSBjb25uZWN0aW9uIChzYW1lIGNhc2UgYXMgd2hlbiB0aGUg MTAxIHJlc3BvbnNlIGNvbnRhaW5zIGEgV1MNCj4gcHJvdG9jb2wgbm90IHN1cHBvcnRlZCBi eSB0aGUgY2xpZW50KS4NCj4gDQo+IA0KPiANCj4gDQo+IC0tDQo+IEnDsWFraSBCYXogQ2Fz dGlsbG8NCj4gPGliY0BhbGlheC5uZXQ+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+IGh5YmkgbWFpbGluZyBsaXN0DQo+IGh5YmlAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oeWJpDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0 YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgcHJpdmls ZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHByb3RlY3RlZCBieSB0aGUgc29s aWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHByaXZpbGVnZXMpLCBvciBjb25z dGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1h dGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlzIHBy b2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9u LCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5zbWlzc2lvbiBi eSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1 bmxhd2Z1bC4NCg== From internet-drafts@ietf.org Wed Aug 24 12:09: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 82A3C21F8C32; Wed, 24 Aug 2011 12:09:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEeD+49LUUQt; Wed, 24 Aug 2011 12:09:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18B2C21F8C09; Wed, 24 Aug 2011 12:09:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.59 Message-ID: <20110824190917.6046.22233.idtracker@ietfa.amsl.com> Date: Wed, 24 Aug 2011 12:09:17 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-12.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: Wed, 24 Aug 2011 19:09:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTT= P Working Group of the IETF. Title : The WebSocket protocol Author(s) : Ian Fette Alexey Melnikov Filename : draft-ietf-hybi-thewebsocketprotocol-12.txt Pages : 68 Date : 2011-08-24 The WebSocket protocol enables two-way communication between a client running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling). Please send feedback to the hybi@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-12= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-12.= txt From alexey.melnikov@isode.com Wed Aug 24 12:11: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 55AA421F854F for ; Wed, 24 Aug 2011 12:11:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-F5ca9Y5Rmc for ; Wed, 24 Aug 2011 12:11:25 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id C1EB321F855B for ; Wed, 24 Aug 2011 12:11:25 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 24 Aug 2011 20:12:34 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E554D10.5080109@isode.com> Date: Wed, 24 Aug 2011 20:12:16 +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: hybi@ietf.org References: <20110824190917.6046.22233.idtracker@ietfa.amsl.com> In-Reply-To: <20110824190917.6046.22233.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-12.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: Wed, 24 Aug 2011 19:11:26 -0000 internet-drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. > > Title : The WebSocket protocol > Author(s) : Ian Fette > Alexey Melnikov > Filename : draft-ietf-hybi-thewebsocketprotocol-12.txt > Pages : 68 > Date : 2011-08-24 > > This version only swaps section 4 and 5, to make the document more readable. Multiple section references were updated at the result of this. Remaining issues will be addressed in -13. From tyoshino@google.com Wed Aug 24 12:14: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 BA9C121F8B70 for ; Wed, 24 Aug 2011 12:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.884 X-Spam-Level: X-Spam-Status: No, score=-105.884 tagged_above=-999 required=5 tests=[AWL=0.092, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M4yNJV4EAtJP for ; Wed, 24 Aug 2011 12:14:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0507221F856B for ; Wed, 24 Aug 2011 12:14:51 -0700 (PDT) Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id p7OJG2GD011285 for ; Wed, 24 Aug 2011 12:16:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314213362; bh=0NDYVVN4HSdB64xKtPTVazIjKyQ=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=IiARCctPwo8iXs0F+z/WcuJO6J15ymBlJlIZw0JMrPafijoQbH3y3jZ8cRf79nC4v CncwJu+oSMvAj4xJXIHnQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=V3i/8PFBwAWugSnuVK5A59rc2SXZUYNPQkDQd82Kg2YDeyayJKK9IiGrvxvnLU7dk s2qHQARr2h9q9wcj11yiQ== Received: from yxj17 (yxj17.prod.google.com [10.190.3.81]) by hpaq3.eem.corp.google.com with ESMTP id p7OJFxoR006033 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 12:16:00 -0700 Received: by yxj17 with SMTP id 17so1324800yxj.31 for ; Wed, 24 Aug 2011 12:15:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=LAWcn9UxlFOB/Nk7DFIq4KT8d9xZutAD1u+xXZhDM+4=; b=CjgpXblcsy5xLgfZ9olqDVc63pAxiL2n3xBDDRdBQhvU192U8UtJUwO/hJYWFeVj7c tGowJclMPbiNjb0W4Ksw== Received: by 10.91.161.5 with SMTP id n5mr5316239ago.28.1314213359655; Wed, 24 Aug 2011 12:15:59 -0700 (PDT) Received: by 10.91.161.5 with SMTP id n5mr5316227ago.28.1314213359216; Wed, 24 Aug 2011 12:15:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.192.17 with HTTP; Wed, 24 Aug 2011 12:15:39 -0700 (PDT) In-Reply-To: <4E5537B7.7090608@stpeter.im> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> <4E54DF3E.6050207@isode.com> <4E550E0D.6050107@gmx.de> <4E5537B7.7090608@stpeter.im> From: Takeshi Yoshino Date: Thu, 25 Aug 2011 04:15:39 +0900 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=001485f7cad26f68e104ab4524b9 X-System-Of-Record: true Cc: "hybi@ietf.org" , Gabriel Montenegro Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 19:14:52 -0000 --001485f7cad26f68e104ab4524b9 Content-Type: text/plain; charset=ISO-8859-1 Thanks. I also don't want any more delay. I'm fine that HTTPbis is not referred. Then, things we can refer are ones defined in RFC2616. - Making style, organization consistent with HTTPbis (e.g. use of Header-Name = grammar_for_value style) is no problem. - Using any term, identifier, grammar, etc. not in RFC2616 but in HTTPbis is bad. WebSocket spec should define them in itself. That's all. --001485f7cad26f68e104ab4524b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks. I also don't want any more delay. I'm fine that HTTPbis is = not referred.=A0Then, things we can refer are ones defined in RFC2616.
=
- Making style, organization consistent with HTTPbis (e.g. u= se of Header-Name =3D grammar_for_value style) is no problem.
- Using any term, identifier, grammar, etc. not in RFC2616 but in HTTP= bis is bad. WebSocket spec should define them in itself.

That's all.
--001485f7cad26f68e104ab4524b9-- From tyoshino@google.com Wed Aug 24 12:22: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 B572D21F8C67 for ; Wed, 24 Aug 2011 12:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.89 X-Spam-Level: X-Spam-Status: No, score=-105.89 tagged_above=-999 required=5 tests=[AWL=0.086, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPO1rhTNRu+n for ; Wed, 24 Aug 2011 12:22:07 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9198F21F8C60 for ; Wed, 24 Aug 2011 12:22:06 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7OJNG2o015565 for ; Wed, 24 Aug 2011 12:23:17 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314213797; bh=JRI4Y2zegUGXnYYWtpRC77vLHU0=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=gEVsCBTl52VUcx8iTiTp2+lCFD6htlMftOjRu92p7cnalTnRg8k4API6JHcpFGL+v Ig86se6S1bW4QzZ3YJO6A== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=M0f0bMIu5Nk044Ak3AWV4h2nhWltZCY9q2BsFPXiPGQ8J5J4rD9b7UltWx2amvPEX mmyb/h2C92jIsdWdmW3jA== Received: from gwj15 (gwj15.prod.google.com [10.200.10.15]) by wpaz1.hot.corp.google.com with ESMTP id p7OJNFlX031403 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 24 Aug 2011 12:23:15 -0700 Received: by gwj15 with SMTP id 15so2119603gwj.25 for ; Wed, 24 Aug 2011 12:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=GzRbw1fszZn7ESQdyCZG2ciYlDsRFjrJaYrCHgsz/Gw=; b=qp8+zlvKmtNuNU+LLgu9l2bDagyUWXNsWHzp+C0wAAqwBZX1W7Wn1cWAkgr+M+WXHn ukWU0apuvVW2LSbrMQNw== Received: by 10.91.67.20 with SMTP id u20mr5350151agk.163.1314213795353; Wed, 24 Aug 2011 12:23:15 -0700 (PDT) Received: by 10.91.67.20 with SMTP id u20mr5350146agk.163.1314213795157; Wed, 24 Aug 2011 12:23:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.90.192.17 with HTTP; Wed, 24 Aug 2011 12:22:54 -0700 (PDT) In-Reply-To: <4E550E0D.6050107@gmx.de> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5421FF.90101@isode.com> <4E54D0AD.3050201@gmx.de> <4E54DF3E.6050207@isode.com> <4E550E0D.6050107@gmx.de> From: Takeshi Yoshino Date: Thu, 25 Aug 2011 04:22:54 +0900 Message-ID: To: Julian Reschke Content-Type: multipart/alternative; boundary=001485f7c1326ba03f04ab453ee5 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] header field ABNF, was: I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 24 Aug 2011 19:22:07 -0000 --001485f7c1326ba03f04ab453ee5 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 24, 2011 at 23:43, Julian Reschke wrote: > > My recommendation is to use RFC2616 grammar constructs, but follow the > HTTPbis style of only defining the ABNF for the header value. > Agreed. Thanks. --001485f7c1326ba03f04ab453ee5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 24, 2011 at 23:43, Julian Reschke <julian.reschke= @gmx.de> wrote:
My recommendation is to use RFC2616 grammar constructs, but follow the HTTP= bis style of only defining the ABNF for the header value.
<= div>
Agreed. Thanks.

--001485f7c1326ba03f04ab453ee5-- From theturtle32@gmail.com Wed Aug 24 12:36: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 86E6921F8CBA for ; Wed, 24 Aug 2011 12:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4u+8NDF-DL57 for ; Wed, 24 Aug 2011 12:36:59 -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 EF1C121F8CAE for ; Wed, 24 Aug 2011 12:36:58 -0700 (PDT) Received: by yie12 with SMTP id 12so1343798yie.31 for ; Wed, 24 Aug 2011 12:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=APdnNUdu9uRC1BcVy2dzGMxcf/ctzrXrIy3h000xSqE=; b=MZrFxJgWUvuy0WpnQg/YHxtcHhexgn6peY/dblsn5KCSMgiFSbHI7Io7MB2+OiZkO2 ksktw5eJ29yYF6suvH9q2AEkB4PSgOXEm4a5bEHtmFjLYyLclk9JHcI2JkZs6GCCO905 RJZOrzVsaUTSa5mxgwpB8y3tXqgCmDDdPvQ50= Received: by 10.43.134.10 with SMTP id ia10mr4669587icc.339.1314214689667; Wed, 24 Aug 2011 12:38:09 -0700 (PDT) Received: from [192.168.1.78] (cpe-98-148-229-193.socal.res.rr.com [98.148.229.193]) by mx.google.com with ESMTPS id t4sm1011280icw.19.2011.08.24.12.38.06 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Aug 2011 12:38:08 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <8D1A572F-BD9C-48F4-9825-30703A379418@gmail.com> X-Mailer: iPhone Mail (8J2) From: Brian McKelvey Date: Wed, 24 Aug 2011 12:38:02 -0700 To: Joe Mason Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 19:36:59 -0000 Yes this is the current majority use case. If the client doesn't request a s= ubprotocol, the server can make an assumption about what subprotocol to spea= k (current deployments generally only speak one subprotocol) and establish t= he connection with no defined subprotocol. Brian Sent from my iPhone On Aug 24, 2011, at 11:52 AM, Joe Mason wrote: > It's perfectly valid for the client and server to not use a named subproto= col, just an ad-hoc anonymous one. I'd expect most web sites to work like t= his. >=20 >> -----Original Message----- >> From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of >> I=C3=B1aki Baz Castillo >> Sent: Wednesday, August 24, 2011 2:11 PM >> To: Brian McKelvey >> Cc: hybi@ietf.org >> Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening >> Handshake" >>=20 >> 2011/8/24 Brian McKelvey : >>> Because if the client didn't request it, it doesn't know how to speak >> it. >>=20 >> So then, which protocol is supposed to be established? no one?? >>=20 >> If the client does not suggest a protocol(s) then the server should do >> it in the response. If then the client does not support it, just close >> the connection (same case as when the 101 response contains a WS >> protocol not supported by the client). >>=20 >>=20 >>=20 >>=20 >> -- >> I=C3=B1aki Baz Castillo >> >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicitor= -client or other applicable privileges), or constitute non-public informatio= n. Any use of this information by anyone other than the intended recipient i= s prohibited. If you have received this transmission in error, please immedi= ately reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ibc@aliax.net Wed Aug 24 12: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 5D19D21F8CDF for ; Wed, 24 Aug 2011 12:43:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuw-imwOvATp for ; Wed, 24 Aug 2011 12:43:18 -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 D1DBA21F8CDE for ; Wed, 24 Aug 2011 12:43:17 -0700 (PDT) Received: by qwc23 with SMTP id 23so1209218qwc.31 for ; Wed, 24 Aug 2011 12:44:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr3935989qci.223.1314215068838; Wed, 24 Aug 2011 12:44:28 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 12:44:28 -0700 (PDT) In-Reply-To: <8D1A572F-BD9C-48F4-9825-30703A379418@gmail.com> References: <8D1A572F-BD9C-48F4-9825-30703A379418@gmail.com> Date: Wed, 24 Aug 2011 21:44:28 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Brian McKelvey Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 19:43:18 -0000 2011/8/24 Brian McKelvey : > Yes this is the current majority use case. =C2=A0If the client doesn't re= quest a subprotocol, the server can make an assumption about what subprotoc= ol to speak (current deployments generally only speak one subprotocol) and = establish the connection with no defined subprotocol. But what is wrong if in that case the server sends a Sec-WebSocket-Protocol indicating the chosen protocol? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 24 13:13: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 7715B21F8BD5 for ; Wed, 24 Aug 2011 13:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZSYYpdFrJwBz for ; Wed, 24 Aug 2011 13:13:46 -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 C047321F8BC3 for ; Wed, 24 Aug 2011 13:13:45 -0700 (PDT) Received: by qwc23 with SMTP id 23so1238447qwc.31 for ; Wed, 24 Aug 2011 13:14:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.43.3 with SMTP id u3mr519915qce.261.1314216896802; Wed, 24 Aug 2011 13:14:56 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 13:14:56 -0700 (PDT) Date: Wed, 24 Aug 2011 22:14:56 +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] Neither Firefox 8 and Chrome 15 close connection if WS protocol in 101 mismatches 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, 24 Aug 2011 20:13:46 -0000 Testing in both Firefox 8 and Chrome 15: - The webbrowser sends the HTTP GET with: Sec-WebSocket-Protocol: aaa, bbb - The server replies 101 with: Sec-WebSocket-Protocol: ccc - The browser does not send a close frame at all. As per the spec, the browser should close the connection. The WS API states the same: http://dev.w3.org/html5/websockets/#the-websocket-interface ------------------ The connection will only be established if the server reports that it has selected one of these subprotocols. ------------------ Ok ok, this is an issue within those browsers but, *why* have they decide not to respect the spec in this point? --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 24 13:36: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 6695E21F8C89 for ; Wed, 24 Aug 2011 13:36:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2RIZ5BVDY2E for ; Wed, 24 Aug 2011 13:36:20 -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 E3ADC21F8C87 for ; Wed, 24 Aug 2011 13:36:19 -0700 (PDT) Received: by qyk34 with SMTP id 34so3023995qyk.10 for ; Wed, 24 Aug 2011 13:37:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr4016982qce.185.1314218250966; Wed, 24 Aug 2011 13:37:30 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 13:37:30 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 22:37:30 +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: Re: [hybi] Neither Firefox 8 and Chrome 15 close connection if WS protocol in 101 mismatches 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, 24 Aug 2011 20:36:20 -0000 2011/8/24 I=C3=B1aki Baz Castillo : > Ok ok, this is an issue within those browsers but, *why* have they > decide not to respect the spec in this point? Also, Chrome 15 does neither respect the WS API for the close() function: void close([Clamp] optional unsigned short code, optional DOMString reaso= n); Even if JavaScript calls: webSocket.close(1000, "Bye Bye"); Chrome 15 sends a close frame with empty body. In the other side Firefox 8 does it correctly. Hello Google? --=20 I=C3=B1aki Baz Castillo From sh@defuze.org Wed Aug 24 13:43: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 30AEF21F8CC8 for ; Wed, 24 Aug 2011 13:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3rWvwmiDWlA6 for ; Wed, 24 Aug 2011 13:43:45 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id 24FD121F8CD2 for ; Wed, 24 Aug 2011 13:43:45 -0700 (PDT) Received: by pzk33 with SMTP id 33so3102968pzk.18 for ; Wed, 24 Aug 2011 13:44:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.149.6 with SMTP id w6mr1308229wfd.290.1314218696127; Wed, 24 Aug 2011 13:44:56 -0700 (PDT) Received: by 10.142.113.8 with HTTP; Wed, 24 Aug 2011 13:44:56 -0700 (PDT) X-Originating-IP: [82.229.61.197] In-Reply-To: References: Date: Wed, 24 Aug 2011 22:44:56 +0200 Message-ID: From: Sylvain Hellegouarch To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd304948a340d04ab46628b Cc: hybi@ietf.org Subject: Re: [hybi] Neither Firefox 8 and Chrome 15 close connection if WS protocol in 101 mismatches 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, 24 Aug 2011 20:43:46 -0000 --000e0cd304948a340d04ab46628b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 24, 2011 at 10:37 PM, I=F1aki Baz Castillo wrot= e: > 2011/8/24 I=F1aki Baz Castillo : > > Ok ok, this is an issue within those browsers but, *why* have they > > decide not to respect the spec in this point? > > Also, Chrome 15 does neither respect the WS API for the close() function: > > void close([Clamp] optional unsigned short code, optional DOMString > reason); > > > Even if JavaScript calls: > > webSocket.close(1000, "Bye Bye"); > > Chrome 15 sends a close frame with empty body. > > > In the other side Firefox 8 does it correctly. Hello Google? > > > I think it'd be more useful to report those issues to the browser vendors directly rather than here :) --=20 - Sylvain http://www.defuze.org http://twitter.com/lawouach --000e0cd304948a340d04ab46628b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Aug 24, 2011 at 10:37 PM, I=F1ak= i Baz Castillo <ibc@a= liax.net> wrote:
2011/8/24 I=F1aki Baz Castillo <ibc@ali= ax.net>:
> Ok ok, this is an issue within those browsers but, *= why* have they
> decide not to respect the spec in this point?

Also, Chrome 15 does neither respect the WS API for the close() funct= ion:

=A0void close([Clamp] optional unsigned short code, optional DOMString rea= son);


Even if JavaScript calls:

=A0webSocket.close(1000, "Bye Bye");

Chrome 15 sends a close frame with empty body.


In the other side Firefox 8 does it correctly. Hello Google?


=A0=

I think it'd be more useful to report those i= ssues to the browser vendors directly rather than here :)
=A0
--
- Sylvain
http://www.defu= ze.org
http://twitter.com/la= wouach
--000e0cd304948a340d04ab46628b-- From theturtle32@gmail.com Wed Aug 24 14:27: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 D0A4D21F8D69 for ; Wed, 24 Aug 2011 14:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.316 X-Spam-Level: X-Spam-Status: No, score=-3.316 tagged_above=-999 required=5 tests=[AWL=-0.018, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zlCvG-4yEbH for ; Wed, 24 Aug 2011 14:27:26 -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 0656821F8D40 for ; Wed, 24 Aug 2011 14:27:25 -0700 (PDT) Received: by bkar4 with SMTP id r4so1458712bka.31 for ; Wed, 24 Aug 2011 14:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pS0juEF8dPQf1LRt5v6JFUngh8aoxt9/Rg5DbXAjlBE=; b=iBnClJwooWzCp6HXmeXQSOCxm1UYMtUu57dUQYj+QLgYbPQ62vgJbIjbz9HsnPfHln 27Ak3mNFyAGsk10lihMWmZNOVZf+p0PqzfXXjAK7faNKT2aYjBFuKfE8yZR83ok8Z2jQ i19fKAxmOuQn0xRYuwNT+6ZFoS6GtLifMFUEE= MIME-Version: 1.0 Received: by 10.204.157.144 with SMTP id b16mr2726972bkx.396.1314221316671; Wed, 24 Aug 2011 14:28:36 -0700 (PDT) Received: by 10.204.65.210 with HTTP; Wed, 24 Aug 2011 14:28:36 -0700 (PDT) In-Reply-To: References: <8D1A572F-BD9C-48F4-9825-30703A379418@gmail.com> Date: Wed, 24 Aug 2011 14:28:36 -0700 Message-ID: From: Brian To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0015175cd0dabc888704ab46fe54 Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 21:27:26 -0000 --0015175cd0dabc888704ab46fe54 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Because that indicates that it's not agreeing to the client's request for "no protocol." When the client doesn't request a subprotocol, it's not requesting "any" protocol -- it's requesting the specific singular unnamed protocol that they coded server to support. It's a simplification for developers who don't want to bother with subprotocols at all. In this case, the server probably only speaks the one subprotocol and the application developer didn't want to bother thinking about the negotiation of it. In this way, the definition of a subprotocol is a totally optional concept for the application developer. Brian On Wed, Aug 24, 2011 at 12:44 PM, I=F1aki Baz Castillo wrot= e: > 2011/8/24 Brian McKelvey : > > Yes this is the current majority use case. If the client doesn't reque= st > a subprotocol, the server can make an assumption about what subprotocol t= o > speak (current deployments generally only speak one subprotocol) and > establish the connection with no defined subprotocol. > > But what is wrong if in that case the server sends a > Sec-WebSocket-Protocol indicating the chosen protocol? > > -- > I=F1aki Baz Castillo > > --0015175cd0dabc888704ab46fe54 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Because that indicates that it's not agreeing to the client's reque= st for "no protocol." =A0When the client doesn't request a su= bprotocol, it's not requesting "any" protocol -- it's req= uesting the specific singular unnamed protocol that they coded server to su= pport.

It's a simplification for developers who don't want = to bother with subprotocols at all. =A0In this case, the server probably on= ly speaks the one subprotocol and the application developer didn't want= to bother thinking about the negotiation of it. =A0In this way, the defini= tion of a subprotocol is a totally optional concept for the application dev= eloper. =A0

Brian

On Wed, Aug 24, 2011 at 12= :44 PM, I=F1aki Baz Castillo <ibc@aliax.net> wrote:
2011/8/24 Brian McKelvey <theturtle32@gmail.com>:
> Yes this is the current majority use case. =A0= If the client doesn't request a subprotocol, the server can make an ass= umption about what subprotocol to speak (current deployments generally only= speak one subprotocol) and establish the connection with no defined subpro= tocol.

But what is wrong if in that case the server sends a
Sec-WebSocket-Protocol indicating the chosen protocol?

--
I=F1aki Baz Castillo
<ibc@aliax.net>

--0015175cd0dabc888704ab46fe54-- From ibc@aliax.net Wed Aug 24 14:44: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 6BC4321F8D72 for ; Wed, 24 Aug 2011 14:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CXjEDKjg2QJM for ; Wed, 24 Aug 2011 14:44:53 -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 E3D6121F8D5F for ; Wed, 24 Aug 2011 14:44:52 -0700 (PDT) Received: by qwc23 with SMTP id 23so1297486qwc.31 for ; Wed, 24 Aug 2011 14:46:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.61.104 with SMTP id s40mr4037735qch.299.1314222364220; Wed, 24 Aug 2011 14:46:04 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 14:46:04 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Aug 2011 23:46:04 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Sylvain Hellegouarch Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Neither Firefox 8 and Chrome 15 close connection if WS protocol in 101 mismatches 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, 24 Aug 2011 21:44:53 -0000 2011/8/24 Sylvain Hellegouarch : > I think it'd be more useful to report those issues to the browser vendors > directly rather than here :) Sure, I should do it, but perhaps some Mozilla/Google developer read this mail :) --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 24 14:46: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 B056C21F8D2A for ; Wed, 24 Aug 2011 14:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FTnYcB-etL+f for ; Wed, 24 Aug 2011 14:46:12 -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 2C40C21F8D17 for ; Wed, 24 Aug 2011 14:46:12 -0700 (PDT) Received: by qwc23 with SMTP id 23so1298123qwc.31 for ; Wed, 24 Aug 2011 14:47:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.2.101 with SMTP id 37mr4070159qci.223.1314222443491; Wed, 24 Aug 2011 14:47:23 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Wed, 24 Aug 2011 14:47:23 -0700 (PDT) In-Reply-To: References: <8D1A572F-BD9C-48F4-9825-30703A379418@gmail.com> Date: Wed, 24 Aug 2011 23:47:23 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Brian Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 24 Aug 2011 21:46:12 -0000 2011/8/24 Brian : > Because that indicates that it's not agreeing to the client's request for > "no protocol." =C2=A0When the client doesn't request a subprotocol, it's = not > requesting "any" protocol -- it's requesting the specific singular unname= d > protocol that they coded server to support. > It's a simplification for developers who don't want to bother with > subprotocols at all. =C2=A0In this case, the server probably only speaks = the one > subprotocol and the application developer didn't want to bother thinking > about the negotiation of it. =C2=A0In this way, the definition of a subpr= otocol > is a totally optional concept for the application developer. Ok, I understand. I still think it's too much "lazy-developer-oriented" but it's ok. Thanks. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Wed Aug 24 15:45: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 DE1F521F8512 for ; Wed, 24 Aug 2011 15:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.344 X-Spam-Level: X-Spam-Status: No, score=-2.344 tagged_above=-999 required=5 tests=[AWL=-0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+1GCwEh2p6V for ; Wed, 24 Aug 2011 15:45:51 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 09C4421F84BF for ; Wed, 24 Aug 2011 15:45:50 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Wed, 24 Aug 2011 15:46:50 -0700 From: Tobias Oberstein To: =?iso-8859-1?Q?I=F1aki_Castillo?= , "hybi@ietf.org" Date: Wed, 24 Aug 2011 15:46:49 -0700 Thread-Topic: [hybi] Neither Firefox 8 and Chrome 15 close connection if WS protocol in 101 mismatches Thread-Index: AcxinarN8W4uRcGBRs2aYJxFr2uXLwAEgqnv Message-ID: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_CA7B4BF94B35tobiasobersteintavendode_" MIME-Version: 1.0 Subject: Re: [hybi] Neither Firefox 8 and Chrome 15 close connection if WS protocol in 101 mismatches 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, 24 Aug 2011 22:45:52 -0000 --_000_CA7B4BF94B35tobiasobersteintavendode_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable for FF I think it was fixed here: https://bugzilla.mozilla.org/show_bug.cgi= ?id=3D674716 which states milestone FF8, which would fit your observation FF8 just moved to Aurora channel .. On 24.08.11 22:37, "I=F1aki Castillo" wrote: 2011/8/24 I=F1aki Baz Castillo : > Ok ok, this is an issue within those browsers but, *why* have they > decide not to respect the spec in this point? Also, Chrome 15 does neither respect the WS API for the close() function: void close([Clamp] optional unsigned short code, optional DOMString reaso= n); Even if JavaScript calls: webSocket.close(1000, "Bye Bye"); Chrome 15 sends a close frame with empty body. In the other side Firefox 8 does it correctly. Hello Google? -- I=F1aki Baz Castillo _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi --_000_CA7B4BF94B35tobiasobersteintavendode_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [hybi] Neither Firefox 8 and Chrome 15 close connection if WS pr= otocol in 101 mismatches for FF I think it was fixed here: https://bugzilla.mozilla.org/show_bug.cgi?id= =3D674716
which states milestone FF8, which would fit your observation
FF8 just moved to Aurora channel ..

On 24.08.11 22:37, "Iñaki Castillo" <ibc@aliax.net> wrote:

2011/8/24 Iñaki Baz Castillo <ibc@aliax.net>:
> Ok ok, this is an issue within those browsers but, *why* have they
> decide not to respect the spec in this point?

Also, Chrome 15 does neither respect the WS API for the close() function:
  void close([Clamp] optional unsigned short code, optional DOMSt= ring reason);


Even if JavaScript calls:

  webSocket.close(1000, "Bye Bye");

Chrome 15 sends a close frame with empty body.


In the other side Firefox 8 does it correctly. Hello Google?



--
Iñaki Baz Castillo
<ibc@aliax.net>
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org= /mailman/listinfo/hybi

--_000_CA7B4BF94B35tobiasobersteintavendode_-- From gregw@intalio.com Wed Aug 24 20:47:05 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 47FF921F8AEA for ; Wed, 24 Aug 2011 20:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjFSEKhVUvi7 for ; Wed, 24 Aug 2011 20:47:04 -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 92F1B21F8B53 for ; Wed, 24 Aug 2011 20:47:04 -0700 (PDT) Received: by vws12 with SMTP id 12so2018496vws.31 for ; Wed, 24 Aug 2011 20:48:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.93.243 with SMTP id cx19mr6156180vdb.179.1314244096172; Wed, 24 Aug 2011 20:48:16 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Wed, 24 Aug 2011 20:48:16 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 25 Aug 2011 13:48:16 +1000 Message-ID: From: Greg Wilkins To: Tobias Oberstein Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Are RSV1-3 bits really useful? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 03:47:05 -0000 On 25 August 2011 00:23, Tobias Oberstein wrote: > but why do you need the > load-balancer have any knowledge of WS? My experience of HTTP intermediaries is that there is a vast and unexpected range of value add features and I see no reason to expect that similar value add features wont be invented for WS. Even if such features are not strictly necessary or best practise, commercial realities often drive the need to differentiate. I can image that an intermediary may need to speak WS as it may take on the responsibility of sending/responding to pings. It may aggregate fragments so that app servers only deal with whole messages. It may do authentication and authorisation, SSL offload etc. It may offer broadcasting of one message to a large number of connections. Many of these features will need either configuration or some kind of signalling. For example offloaded SSL may need to communicate a client certificate, cipher strength and or session id to the application server. Aggregation may need buffer sizes configured. Intermediaries may offer different quality of service settings depending on authentication and/or application status etc. etc. Some of this configuration/signalling may well be able to be done out of band, but much of it is more obvious to do inband, ie on the actual connection that is being configured/signalled about. cheers From tobias.oberstein@tavendo.de Thu Aug 25 05:38: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 72CBF21F8634 for ; Thu, 25 Aug 2011 05:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4DQJm9Om2Kh for ; Thu, 25 Aug 2011 05:38:07 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id C43AE21F8541 for ; Thu, 25 Aug 2011 05:38:05 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Thu, 25 Aug 2011 05:39:18 -0700 From: Tobias Oberstein To: Greg Wilkins Date: Thu, 25 Aug 2011 05:38:21 -0700 Thread-Topic: [hybi] Are RSV1-3 bits really useful? Thread-Index: Acxi2dUgFmGk1mHBQfqBDGhzzwLFEQASILKg Message-ID: <634914A010D0B943A035D226786325D422C0D5D6A3@EXVMBX020-12.exch020.serverdata.net> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Are RSV1-3 bits really useful? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 12:38:07 -0000 > > but why do you need the > > load-balancer have any knowledge of WS? >=20 > My experience of HTTP intermediaries is that there is a vast and unexpect= ed > range of value add features and I see no reason to expect that similar va= lue > add features wont be invented for WS. Even if such features are not stric= tly > necessary or best practise, commercial realities often drive the need to > differentiate. I see. > I can image that an intermediary may need to speak WS as it may take > on the responsibility of sending/responding to pings. It may [cut interesting examples] As you mention this example, it brings back a question IMHO still open. With regard to message fragment ordering, the spec is explicit: """ 5.4. Fragmentation Message fragments MUST be delivered to the recipient in the order sent by the sender." http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-12#page-32 """ I assume that message ordering must also be preserved. However, what about the ordering guarantees wrt to * control frames * relation between control frames and messages/message frames ? I was reminded of that question I have, because in your example, when an intermediary replies to pings himself, this might imply that the control frames are "an independent channel" (independent from the "message channel"). So: * message/frame ordering is guaranteed within the message channel * no guarantees wrt to ordering even within the control channel * are control/message really two channels unrelated in ordering ? Whatever the answer is, I really think it should be made explicit in the sp= ec. From ibc@aliax.net Thu Aug 25 05:54: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 AF7AB21F86EA for ; Thu, 25 Aug 2011 05:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4r9nDd6hoXhG for ; Thu, 25 Aug 2011 05:54:19 -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 2109E21F86E0 for ; Thu, 25 Aug 2011 05:54:18 -0700 (PDT) Received: by qyk34 with SMTP id 34so3263162qyk.10 for ; Thu, 25 Aug 2011 05:55:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.24.131 with SMTP id v3mr492363qcb.109.1314276931907; Thu, 25 Aug 2011 05:55:31 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Thu, 25 Aug 2011 05:55:31 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5D6A3@EXVMBX020-12.exch020.serverdata.net> References: <20110824135902.GX14899@jl-vm1.vm.bytemark.co.uk> <634914A010D0B943A035D226786325D422C0D5D301@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D6A3@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 25 Aug 2011 14:55:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Are RSV1-3 bits really useful? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 12:54:19 -0000 2011/8/25 Tobias Oberstein : > However, what about the ordering guarantees wrt to > * relation between control frames and messages/message frames? There is no such relation. Control frames can be sent between text/binary frames belonging to the same WS message, but there is no relation at all. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Thu Aug 25 06:00: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 33AF121F855B for ; Thu, 25 Aug 2011 06:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sebPwX9dD+Jz for ; Thu, 25 Aug 2011 06:00:40 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id A8AA521F8514 for ; Thu, 25 Aug 2011 06:00:40 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Thu, 25 Aug 2011 06:01:52 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Thu, 25 Aug 2011 06:00:55 -0700 Thread-Topic: Draft 12 - Ordering Guarantees Thread-Index: AcxjJg7ol+fjb06WTOqD4wJQdakeeQ== Message-ID: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 13:00:41 -0000 I'd like to propose the following additions. 5.4. Fragmentation * An intermediary MUST NOT coalesce message frames accross frames with FIN = bit set. 5.5. Control Frames Control frames MUST be delivered to the recipient in the order sent by the = sender. From jat@google.com Thu Aug 25 07:47: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 EEC0921F88A0 for ; Thu, 25 Aug 2011 07:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.928 X-Spam-Level: X-Spam-Status: No, score=-105.928 tagged_above=-999 required=5 tests=[AWL=0.048, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7RzbWpEeIWt for ; Thu, 25 Aug 2011 07:47:22 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C219821F86B1 for ; Thu, 25 Aug 2011 07:47:21 -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 p7PEmXXF023968 for ; Thu, 25 Aug 2011 07:48:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314283714; bh=ZyGeIjlpnbRFyJ6TP6jAJmMRR84=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=g5iadNGjnSWdMyWVfFDUomZyttlVXGbWbkMhqfqb9Hthffb+zVx+GCsVupkc2SrpD 1djsz+QUbj28wzzWogDdg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ueDYmLmkf8lH3y80SgKQP4TyehkliBl/G8OSMXRyu9jwxLm2SCc7DvlfZpPfaQzIJ TlHyEdknSr8QMmurhRkzA== Received: from gxk3 (gxk3.prod.google.com [10.202.11.3]) by wpaz29.hot.corp.google.com with ESMTP id p7PEkrBw025124 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 25 Aug 2011 07:48:32 -0700 Received: by gxk3 with SMTP id 3so1741481gxk.6 for ; Thu, 25 Aug 2011 07:48:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=clhVkRtcZDZeUu08HU0H69ikHaNoUVZnQSOwAlR9WNI=; b=NP5bzyVtcR5LHu61jkLz9xB/2ivJ82jufTd/+Saxt+zAO6ZKQNUYQDcvY21l6TleXi i6fh6cN0ld8n55lBNGpg== Received: by 10.150.114.12 with SMTP id m12mr1089456ybc.287.1314283712319; Thu, 25 Aug 2011 07:48:32 -0700 (PDT) Received: by 10.150.114.12 with SMTP id m12mr1089448ybc.287.1314283712133; Thu, 25 Aug 2011 07:48:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Thu, 25 Aug 2011 07:48:12 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Thu, 25 Aug 2011 10:48:12 -0400 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cdf13cacbbc1f04ab55858d X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 14:47:23 -0000 --000e0cdf13cacbbc1f04ab55858d Content-Type: text/plain; charset=UTF-8 On Thu, Aug 25, 2011 at 9:00 AM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > I'd like to propose the following additions. > > 5.4. Fragmentation > > * An intermediary MUST NOT coalesce message frames accross frames with FIN > bit set. > I'm not sure how to handle this, but I think extensions may need to expand on this point. For example, a MUX extension might well do so for interleaved messages on different channels. Perhaps adding an explicit note "unless altered by a negotiated extension"? > 5.5. Control Frames > > Control frames MUST be delivered to the recipient in the order sent by the > sender. > I think this needs some flexibility for not delivering control frames at all, if the intermediary is the one best to respond to them. Consider a WS front-end that handles pings so the backend servers don't have to. -- John A. Tamplin Software Engineer (GWT), Google --000e0cdf13cacbbc1f04ab55858d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 25, 2011 at 9:00 AM, Tobias Oberstei= n <tobi= as.oberstein@tavendo.de> wrote:
I'd like to propose the following additions.

5.4. =C2=A0Fragmentation

* An intermediary MUST NOT coalesce message frames accross frames with FIN = bit set.

I'm not sure how to handle= this, but I think extensions may need to expand on this point. =C2=A0For e= xample, a MUX extension might well do so for interleaved messages on differ= ent channels. =C2=A0Perhaps adding an explicit note "unless altered by= a negotiated extension"?
=C2=A0
5.5. =C2=A0Control Frames

Control frames MUST be delivered to the recipient in the order sent by the = sender.

I think this needs some flexib= ility for not delivering control frames at all, if the intermediary is the = one best to respond to them. =C2=A0Consider a WS front-end that handles pin= gs so the backend servers don't have to.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cdf13cacbbc1f04ab55858d-- From jmason@rim.com Thu Aug 25 08:07: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 84F6521F874B for ; Thu, 25 Aug 2011 08:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAqZFLxw6uZl for ; Thu, 25 Aug 2011 08:07:56 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 90E7021F857D for ; Thu, 25 Aug 2011 08:07:56 -0700 (PDT) X-AuditID: 0a412830-b7ce5ae000004071-47-4e56658c2eb0 Received: from XHT107CNC.rim.net (xht107cnc.rim.net [10.65.12.217]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id D4.FB.16497.C85665E4; Thu, 25 Aug 2011 15:09:00 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT107CNC.rim.net ([fe80::5db:5632:3d0b:13ed%11]) with mapi; Thu, 25 Aug 2011 11:09:09 -0400 From: Joe Mason To: John Tamplin , Tobias Oberstein Date: Thu, 25 Aug 2011 11:09:08 -0400 Thread-Topic: [hybi] Draft 12 - Ordering Guarantees Thread-Index: AcxjNhRt6Z+GTaSqQVSU+QLidaYOpgAAowng Message-ID: References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_BB31C4AB95A70042A256109D461991260ADE7840XCH117CNCrimnet_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKKsWRmVeSWpSXmKPExsXC5chzU7cnNczP4PkaLYv3L7cxWTyddIDd Yt6iHhYHZo8Fm0o9liz5yeRxZeoElgDmqAZGm8S8vPySxJJUhZTU4mRbJZ/U9MQchYCizLLE 5EoFl8zi5JzEzNzUIiWFzBRbJRMlhYKcxOTU3NS8ElulxIKC1LwUJTsuBQxgA1SWmaeQmpec n5KZl26r5Bnsr2thYWqpa6hkp4sEEv5xZ5xsW89WcM+lYvXfX4wNjC+cuhg5OSQETCRWf5/C DmGLSVy4t56ti5GLQ0igl0lizZ2JjBDOIkaJCWses4FUsQkoSHw+/IAJxBYRCJbY3XAarJtZ QFni6rEVLCA2i4CqxKFbR1lBbGEBI4lLW74wQ9QbS5zo+s0GYRtJHD75FqyGV8BDYuGTC1DL FjNK/Fz7DWgQBwenQKDE1yY9kBpGoOu+n1rDBLFLXOLWk/lMEFcLSCzZc54ZwhaVePn4HytE vajEnfb1jCBjmAXyJRo+yUGsEpQ4OfMJywRG0VlIJs1CqJqFpAoirCmxfpc+RLWixJTuh+wQ toZE65y57MjiCxjZVzEK5mYUG5gZJucl6xVl5urlpZZsYgQnGQ2DHYwT9modYhTgYFTi4VVP CPMTYk0sK67MPcQowcGsJMLbHAoU4k1JrKxKLcqPLyrNSS0+xOgKDM6JzFLcyfnABJhXEm9s YICboyTOGyZt4CckkA5Ma9mpqQWpRTBzmDg4pRoYd3LKLfa9uPvyvQsMU6ZILWycW+Ra6HZr 8se1ApZWDEtOfJW+lLSj86Qw26pnd2/cY9hm9nP7So3EOx8M5rXeYdado//fmK97okBkTY7g srboQ2X3pz588XGPae+O9rv7LllxTYp0YTnMKvyppfLquzNfNf6vu8FoW69Qdc7EPWKXI/u/ M6enaCqxFGckGmoxFxUnAgBiT6qXWAMAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:07:57 -0000 --_000_BB31C4AB95A70042A256109D461991260ADE7840XCH117CNCrimnet_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 SG93IGFib3V0LCDigJxDb250cm9sIGZyYW1lcyBNVVNUIGJlIGhhbmRsZWQgaW4gdGhlIG9y ZGVyIHNlbnQgYnkgdGhlIHNlbmRlci7igJ0gIFRoYXQgbGVhdmVzIGl0IG9wZW4gV0hPIGlz IGRvaW5nIHRoZSBoYW5kbGluZy4NCg0KVGhpcyBkb2VzIGltcG9zZSBhIGxpbWl0YXRpb24g b24gaW50ZXJtZWRpYXJpZXM6IGlmIGFuIGludGVybWVkaWFyeSByZWNlaXZlcyDigJxQSU5H LCBDTE9TRSwgUElOR+KAnSBpdOKAmXMgbm90IHZhbGlkIHRvIGRvIOKAnFBPTkcsIHNlbmQg Q0xPU0UgdG8gZW5kcG9pbnQsIFBPTkfigJ0gYmVjYXVzZSB0aGVuIHRoZW4gc2Vjb25kIHBv bmcgbWF5IGdvIG91dCBiZWZvcmUgdGhlIGVuZHBvaW50IGhhbmRsZXMgdGhlIENMT1NFLg0K DQpGcm9tOiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpoeWJpLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBKb2huIFRhbXBsaW4NClNlbnQ6IFRodXJzZGF5LCBBdWd1 c3QgMjUsIDIwMTEgMTA6NDggQU0NClRvOiBUb2JpYXMgT2JlcnN0ZWluDQpDYzogaHliaUBp ZXRmLm9yZw0KU3ViamVjdDogUmU6IFtoeWJpXSBEcmFmdCAxMiAtIE9yZGVyaW5nIEd1YXJh bnRlZXMNCg0KT24gVGh1LCBBdWcgMjUsIDIwMTEgYXQgOTowMCBBTSwgVG9iaWFzIE9iZXJz dGVpbiA8dG9iaWFzLm9iZXJzdGVpbkB0YXZlbmRvLmRlPG1haWx0bzp0b2JpYXMub2JlcnN0 ZWluQHRhdmVuZG8uZGU+PiB3cm90ZToNCkknZCBsaWtlIHRvIHByb3Bvc2UgdGhlIGZvbGxv d2luZyBhZGRpdGlvbnMuDQoNCjUuNC4gIEZyYWdtZW50YXRpb24NCg0KKiBBbiBpbnRlcm1l ZGlhcnkgTVVTVCBOT1QgY29hbGVzY2UgbWVzc2FnZSBmcmFtZXMgYWNjcm9zcyBmcmFtZXMg d2l0aCBGSU4gYml0IHNldC4NCg0KSSdtIG5vdCBzdXJlIGhvdyB0byBoYW5kbGUgdGhpcywg YnV0IEkgdGhpbmsgZXh0ZW5zaW9ucyBtYXkgbmVlZCB0byBleHBhbmQgb24gdGhpcyBwb2lu dC4gIEZvciBleGFtcGxlLCBhIE1VWCBleHRlbnNpb24gbWlnaHQgd2VsbCBkbyBzbyBmb3Ig aW50ZXJsZWF2ZWQgbWVzc2FnZXMgb24gZGlmZmVyZW50IGNoYW5uZWxzLiAgUGVyaGFwcyBh ZGRpbmcgYW4gZXhwbGljaXQgbm90ZSAidW5sZXNzIGFsdGVyZWQgYnkgYSBuZWdvdGlhdGVk IGV4dGVuc2lvbiI/DQoNCjUuNS4gIENvbnRyb2wgRnJhbWVzDQoNCkNvbnRyb2wgZnJhbWVz IE1VU1QgYmUgZGVsaXZlcmVkIHRvIHRoZSByZWNpcGllbnQgaW4gdGhlIG9yZGVyIHNlbnQg YnkgdGhlIHNlbmRlci4NCg0KSSB0aGluayB0aGlzIG5lZWRzIHNvbWUgZmxleGliaWxpdHkg Zm9yIG5vdCBkZWxpdmVyaW5nIGNvbnRyb2wgZnJhbWVzIGF0IGFsbCwgaWYgdGhlIGludGVy bWVkaWFyeSBpcyB0aGUgb25lIGJlc3QgdG8gcmVzcG9uZCB0byB0aGVtLiAgQ29uc2lkZXIg YSBXUyBmcm9udC1lbmQgdGhhdCBoYW5kbGVzIHBpbmdzIHNvIHRoZSBiYWNrZW5kIHNlcnZl cnMgZG9uJ3QgaGF2ZSB0by4NCg0KLS0NCkpvaG4gQS4gVGFtcGxpbg0KU29mdHdhcmUgRW5n aW5lZXIgKEdXVCksIEdvb2dsZQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlh bCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJs ZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBB bnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGlu dGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRv IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0 ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24g b2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBh dXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuDQo= --_000_BB31C4AB95A70042A256109D461991260ADE7840XCH117CNCrimnet_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250 ZW50LVR5cGUgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1l PUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVt KSI+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYg NCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4t VVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5Ib3cgYWJvdXQsIOKA nENvbnRyb2wgZnJhbWVzIE1VU1QgYmUgaGFuZGxlZCBpbiB0aGUgb3JkZXIgc2VudCBieSB0 aGUgc2VuZGVyLuKAncKgIFRoYXQgbGVhdmVzIGl0IG9wZW4gV0hPIGlzIGRvaW5nIHRoZSBo YW5kbGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlRoaXMgZG9lcyBpbXBv c2UgYSBsaW1pdGF0aW9uIG9uIGludGVybWVkaWFyaWVzOiBpZiBhbiBpbnRlcm1lZGlhcnkg cmVjZWl2ZXMg4oCcUElORywgQ0xPU0UsIFBJTkfigJ0gaXTigJlzIG5vdCB2YWxpZCB0byBk byDigJxQT05HLCBzZW5kIENMT1NFIHRvIGVuZHBvaW50LCBQT05H4oCdIGJlY2F1c2UgdGhl biB0aGVuIHNlY29uZCBwb25nIG1heSBnbyBvdXQgYmVmb3JlIHRoZSBlbmRwb2ludCBoYW5k bGVzIHRoZSBDTE9TRS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7 cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCc+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIic+IGh5YmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNl c0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mIDwvYj5Kb2huIFRhbXBsaW48YnI+PGI+U2Vu dDo8L2I+IFRodXJzZGF5LCBBdWd1c3QgMjUsIDIwMTEgMTA6NDggQU08YnI+PGI+VG86PC9i PiBUb2JpYXMgT2JlcnN0ZWluPGJyPjxiPkNjOjwvYj4gaHliaUBpZXRmLm9yZzxicj48Yj5T dWJqZWN0OjwvYj4gUmU6IFtoeWJpXSBEcmFmdCAxMiAtIE9yZGVyaW5nIEd1YXJhbnRlZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPk9uIFRodSwgQXVn IDI1LCAyMDExIGF0IDk6MDAgQU0sIFRvYmlhcyBPYmVyc3RlaW4gJmx0OzxhIGhyZWY9Im1h aWx0bzp0b2JpYXMub2JlcnN0ZWluQHRhdmVuZG8uZGUiPnRvYmlhcy5vYmVyc3RlaW5AdGF2 ZW5kby5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD5JJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25zLjxicj48YnI+ NS40LiAmbmJzcDtGcmFnbWVudGF0aW9uPGJyPjxicj4qIEFuIGludGVybWVkaWFyeSBNVVNU IE5PVCBjb2FsZXNjZSBtZXNzYWdlIGZyYW1lcyBhY2Nyb3NzIGZyYW1lcyB3aXRoIEZJTiBi aXQgc2V0LjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkknbSBub3Qgc3Vy ZSBob3cgdG8gaGFuZGxlIHRoaXMsIGJ1dCBJIHRoaW5rIGV4dGVuc2lvbnMgbWF5IG5lZWQg dG8gZXhwYW5kIG9uIHRoaXMgcG9pbnQuICZuYnNwO0ZvciBleGFtcGxlLCBhIE1VWCBleHRl bnNpb24gbWlnaHQgd2VsbCBkbyBzbyBmb3IgaW50ZXJsZWF2ZWQgbWVzc2FnZXMgb24gZGlm ZmVyZW50IGNoYW5uZWxzLiAmbmJzcDtQZXJoYXBzIGFkZGluZyBhbiBleHBsaWNpdCBub3Rl ICZxdW90O3VubGVzcyBhbHRlcmVkIGJ5IGEgbmVnb3RpYXRlZCBleHRlbnNpb24mcXVvdDs/ PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86 cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluJz48cCBjbGFzcz1Nc29Ob3JtYWw+ NS41LiAmbmJzcDtDb250cm9sIEZyYW1lczxicj48YnI+Q29udHJvbCBmcmFtZXMgTVVTVCBi ZSBkZWxpdmVyZWQgdG8gdGhlIHJlY2lwaWVudCBpbiB0aGUgb3JkZXIgc2VudCBieSB0aGUg c2VuZGVyLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2PjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1Nc29Ob3Jt YWw+SSB0aGluayB0aGlzIG5lZWRzIHNvbWUgZmxleGliaWxpdHkgZm9yIG5vdCBkZWxpdmVy aW5nIGNvbnRyb2wgZnJhbWVzIGF0IGFsbCwgaWYgdGhlIGludGVybWVkaWFyeSBpcyB0aGUg b25lIGJlc3QgdG8gcmVzcG9uZCB0byB0aGVtLiAmbmJzcDtDb25zaWRlciBhIFdTIGZyb250 LWVuZCB0aGF0IGhhbmRsZXMgcGluZ3Mgc28gdGhlIGJhY2tlbmQgc2VydmVycyBkb24ndCBo YXZlIHRvLjxiciBjbGVhcj1hbGw+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0t IDxicj5Kb2huIEEuIFRhbXBsaW48YnI+U29mdHdhcmUgRW5naW5lZXIgKEdXVCksIEdvb2ds ZTxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8YnI+DQpUaGlz IHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRp bmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVy IGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZv cm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0 aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVs eSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9t IHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVw cm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50 cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9ib2R5PjwvaHRt bD4= --_000_BB31C4AB95A70042A256109D461991260ADE7840XCH117CNCrimnet_-- From tobias.oberstein@tavendo.de Thu Aug 25 08:14: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 26F1F21F84D1 for ; Thu, 25 Aug 2011 08:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGaGkgnV-IRz for ; Thu, 25 Aug 2011 08:14:25 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5221F84CE for ; Thu, 25 Aug 2011 08:14:24 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Thu, 25 Aug 2011 08:15:38 -0700 From: Tobias Oberstein To: John Tamplin Date: Thu, 25 Aug 2011 08:14:40 -0700 Thread-Topic: [hybi] Draft 12 - Ordering Guarantees Thread-Index: AcxjNhNpJoSsO21+QaK7+TcU/qpBAgAAFnfQ Message-ID: <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D422C0D5D7BFEXVMBX02012ex_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:14:26 -0000 --_000_634914A010D0B943A035D226786325D422C0D5D7BFEXVMBX02012ex_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG93IGFib3V0Og0KDQo1LjQuICBGcmFnbWVudGF0aW9uDQoNCiogQW4gaW50ZXJtZWRpYXJ5IE1V U1QgTk9UIGNvYWxlc2NlIG1lc3NhZ2UgZnJhbWVzIGFjY3Jvc3MgZnJhbWVzIHdpdGggRklOIGJp dCBzZXQsDQp1bmxlc3MgaW4gdGhlIGNvbnRleHQgb2YgYSBjb25uZWN0aW9uIHdoZXJlIGV4dGVu c2lvbnMga25vd24gdG8gdGhlIGludGVybWVkaWFyeQ0KaGF2ZSBiZWVuIG5lZ290aWF0ZWQgd2hp Y2ggYWxsb3cgZm9yIHN1Y2ggY29hbGVzY2luZy4NCg0KNS41LiAgQ29udHJvbCBGcmFtZXMNCg0K Q29udHJvbCBmcmFtZXMgZGVsaXZlcmVkIHRvIHRoZSByZWNpcGllbnQgTVVTVCBiZSBkZWxpdmVy ZWQgdG8gdGhlIHJlY2lwaWVudCBpbiB0aGUgb3JkZXIgc2VudCBieSB0aGUgc2VuZGVyLg0KDQo9 PQ0KDQpUaGUgbGF0dGVyIGxlYXZlcyBvcGVuIHRoZSBjYXNlIHdoZXJlIGFsbCBvciBvbmx5IHNv bWUgY29udHJvbCBmcmFtZXMgYXJlIG5vdCBkZWxpdmVyZWQgdG8gdGhlIGVuZHBvaW50IGF0IGFs bC4NCg0KSG93ZXZlciwgd2hhdCB5b3UgcG9pbnQgb3V0IHdhcyBzb21ld2hhdCBzdXJwcmlzaW5n IHRvIG1lIChiZWZvcmUgdGhlIGNvbW1lbnRzIG9mIEdyZWcgYW5kIHlvdXJzKS4NCg0KT2YgY291 cnNlIEkgc2VlIHdoYXQncyB1cCB3aXRoIHRoZSBleGFtcGxlIHlvdSBnYXZlLCBidXQgLi4NCg0K QXMgYW4gZW5kcG9pbnQsIEkgY2FuJ3QgYmUgc3VyZSB0aGF0IG15IHBlZXIgd2lsbCByZWNlaXZl IGNvbnRyb2wgZnJhbWVzIGF0IGFsbD8NCg0KU28gZm9yIGV4YW1wbGUsIGlmIEkgd2FudGVkIHRv IHVzZSB0aGUgcGF5bG9hZCBvZiBQaW5ncyBmb3IgY3JlZGl0IHJlcGwuIGluIGEgZmxhdCBNVVgg c2NoZW1lIHRoYXQgZG9lcw0KYWxsIGl0J3Mgc3R1ZmYgaW5zaWRlIHN0YW5kYXJkIFdTLCB0aGVu IEkgY291bGRuJ3QgYmUgc3VyZSB0aGF0IG15IHBlZXIgcmVjZWl2ZXMgdGhvc2UgZnJhbWVzIOKA pg0KDQpIb3cgYWJvdXQgdGhpcw0KDQpDb250cm9sIGZyYW1lcyB3aXRoIGVtcHR5IHBheWxvYWQg TUFZIGJlIGhhbmRsZWQgYnkgYW4gaW50ZXJtZWRpYXJ5IGRpcmVjdGx5IGFuZCBub3QgZGVsaXZl cmVkIHRvIHRoZSBvdGhlcndpc2UgcmVjZWl2aW5nIGVuZHBvaW50Lg0KDQpDb250cm9sIGZyYW1l cyB3aXRoIG5vbi1lbXB0eSBwYXlsb2FkIE1VU1QgYmUgZGVsaXZlcmVkIHRvIHRoZSByZWNpcGll bnQuDQoNCkhlcmUsIEkgYXNzdW1lIHRoYXQNCg0KcmVjaXBpZW50ID0gcmVjZWl2aW5nIGVuZHBv aW50DQoNCmlzIHVuZGVyc3Rvb2QuDQoNCg0KDQpWb246IEpvaG4gVGFtcGxpbiBbbWFpbHRvOmph dEBnb29nbGUuY29tXQ0KR2VzZW5kZXQ6IERvbm5lcnN0YWcsIDI1LiBBdWd1c3QgMjAxMSAxNjo0 OA0KQW46IFRvYmlhcyBPYmVyc3RlaW4NCkNjOiBoeWJpQGlldGYub3JnDQpCZXRyZWZmOiBSZTog W2h5YmldIERyYWZ0IDEyIC0gT3JkZXJpbmcgR3VhcmFudGVlcw0KDQpPbiBUaHUsIEF1ZyAyNSwg MjAxMSBhdCA5OjAwIEFNLCBUb2JpYXMgT2JlcnN0ZWluIDx0b2JpYXMub2JlcnN0ZWluQHRhdmVu ZG8uZGU8bWFpbHRvOnRvYmlhcy5vYmVyc3RlaW5AdGF2ZW5kby5kZT4+IHdyb3RlOg0KSSdkIGxp a2UgdG8gcHJvcG9zZSB0aGUgZm9sbG93aW5nIGFkZGl0aW9ucy4NCg0KNS40LiAgRnJhZ21lbnRh dGlvbg0KDQoqIEFuIGludGVybWVkaWFyeSBNVVNUIE5PVCBjb2FsZXNjZSBtZXNzYWdlIGZyYW1l cyBhY2Nyb3NzIGZyYW1lcyB3aXRoIEZJTiBiaXQgc2V0Lg0KDQpJJ20gbm90IHN1cmUgaG93IHRv IGhhbmRsZSB0aGlzLCBidXQgSSB0aGluayBleHRlbnNpb25zIG1heSBuZWVkIHRvIGV4cGFuZCBv biB0aGlzIHBvaW50LiAgRm9yIGV4YW1wbGUsIGEgTVVYIGV4dGVuc2lvbiBtaWdodCB3ZWxsIGRv IHNvIGZvciBpbnRlcmxlYXZlZCBtZXNzYWdlcyBvbiBkaWZmZXJlbnQgY2hhbm5lbHMuICBQZXJo YXBzIGFkZGluZyBhbiBleHBsaWNpdCBub3RlICJ1bmxlc3MgYWx0ZXJlZCBieSBhIG5lZ290aWF0 ZWQgZXh0ZW5zaW9uIj8NCg0KNS41LiAgQ29udHJvbCBGcmFtZXMNCg0KQ29udHJvbCBmcmFtZXMg TVVTVCBiZSBkZWxpdmVyZWQgdG8gdGhlIHJlY2lwaWVudCBpbiB0aGUgb3JkZXIgc2VudCBieSB0 aGUgc2VuZGVyLg0KDQpJIHRoaW5rIHRoaXMgbmVlZHMgc29tZSBmbGV4aWJpbGl0eSBmb3Igbm90 IGRlbGl2ZXJpbmcgY29udHJvbCBmcmFtZXMgYXQgYWxsLCBpZiB0aGUgaW50ZXJtZWRpYXJ5IGlz IHRoZSBvbmUgYmVzdCB0byByZXNwb25kIHRvIHRoZW0uICBDb25zaWRlciBhIFdTIGZyb250LWVu ZCB0aGF0IGhhbmRsZXMgcGluZ3Mgc28gdGhlIGJhY2tlbmQgc2VydmVycyBkb24ndCBoYXZlIHRv Lg0KDQotLQ0KSm9obiBBLiBUYW1wbGluDQpTb2Z0d2FyZSBFbmdpbmVlciAoR1dUKSwgR29vZ2xl DQo= --_000_634914A010D0B943A035D226786325D422C0D5D7BFEXVMBX02012ex_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FLU1haWxGb3JtYXR2b3JsYWdlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgMi4wY20gNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFu Zz1ERSBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvdyBhYm91dDo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD41LjQuICZuYnNwO0Zy YWdtZW50YXRpb248YnI+PGJyPiogQW4gaW50ZXJtZWRpYXJ5IE1VU1QgTk9UIGNvYWxlc2NlIG1l c3NhZ2UgZnJhbWVzIGFjY3Jvc3MgZnJhbWVzIHdpdGggRklOIGJpdCBzZXQsPG86cD48L286cD48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdjb2xvcjpyZWQnPnVubGVzcyBp biB0aGUgY29udGV4dCBvZiBhIGNvbm5lY3Rpb24gd2hlcmUgZXh0ZW5zaW9ucyBrbm93biB0byB0 aGUgaW50ZXJtZWRpYXJ5PG86cD48L286cD48L3NwYW4+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PGI+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+aGF2ZSBiZWVuIG5lZ290aWF0ZWQgd2hpY2gg YWxsb3cgZm9yIHN1Y2ggY29hbGVzY2luZy48bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+NS41LiAmbmJzcDtDb250cm9sIEZyYW1lczxicj48 YnI+Q29udHJvbCBmcmFtZXMgPGI+PHNwYW4gc3R5bGU9J2NvbG9yOnJlZCc+ZGVsaXZlcmVkIHRv IHRoZSByZWNpcGllbnQ8L3NwYW4+PC9iPiBNVVNUIGJlIGRlbGl2ZXJlZCB0byB0aGUgcmVjaXBp ZW50IGluIHRoZSBvcmRlciBzZW50IGJ5IHRoZSBzZW5kZXIuPG86cD48L286cD48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPj09PG86cD48 L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0Qn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj b2xvcjojMUY0OTdEJz5UaGUgbGF0dGVyIGxlYXZlcyBvcGVuIHRoZSBjYXNlIHdoZXJlIGFsbCBv ciBvbmx5IHNvbWUgY29udHJvbCBmcmFtZXMgYXJlIG5vdCBkZWxpdmVyZWQgdG8gdGhlIGVuZHBv aW50IGF0IGFsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkhvd2V2ZXIsIHdoYXQgeW91IHBvaW50IG91 dCB3YXMgc29tZXdoYXQgc3VycHJpc2luZyB0byBtZSAoYmVmb3JlIHRoZSBjb21tZW50cyBvZiBH cmVnIGFuZCB5b3VycykuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5PZiBjb3Vyc2UgSSBzZWUgd2hhdCdz IHVwIHdpdGggdGhlIGV4YW1wbGUgeW91IGdhdmUsIGJ1dCAuLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ QXMgYW4gZW5kcG9pbnQsIEkgY2FuJ3QgYmUgc3VyZSB0aGF0IG15IHBlZXIgd2lsbCByZWNlaXZl IGNvbnRyb2wgZnJhbWVzIGF0IGFsbD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlNvIGZvciBleGFtcGxl LCBpZiBJIHdhbnRlZCB0byB1c2UgdGhlIHBheWxvYWQgb2YgUGluZ3MgZm9yIGNyZWRpdCByZXBs LiBpbiBhIGZsYXQgTVVYIHNjaGVtZSB0aGF0IGRvZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+YWxsIGl0J3Mgc3R1ZmYgaW5z aWRlIHN0YW5kYXJkIFdTLCB0aGVuIEkgY291bGRuJ3QgYmUgc3VyZSB0aGF0IG15IHBlZXIgcmVj ZWl2ZXMgdGhvc2UgZnJhbWVzIOKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29O b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SG93IGFib3V0IHRoaXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFG NDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48Yj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiO2NvbG9yOnJlZCc+Q29udHJvbCBmcmFtZXMgd2l0aCA8aT5lbXB0eSBwYXlsb2FkPC9p PiBNQVkgYmUgaGFuZGxlZCBieSBhbiBpbnRlcm1lZGlhcnkgZGlyZWN0bHkgYW5kIG5vdCBkZWxp dmVyZWQgdG8gdGhlIG90aGVyd2lzZSByZWNlaXZpbmcgZW5kcG9pbnQuPG86cD48L286cD48L3Nw YW4+PC9iPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29s b3I6cmVkJz5Db250cm9sIGZyYW1lcyB3aXRoIG5vbi1lbXB0eSBwYXlsb2FkIE1VU1QgYmUgZGVs aXZlcmVkIHRvIHRoZSByZWNpcGllbnQuPG86cD48L286cD48L3NwYW4+PC9iPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGVyZSwgSSBh c3N1bWUgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm Ijtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+cmVjaXBpZW50ID0gcmVjZWl2aW5nIGVuZHBv aW50PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5pcyB1bmRlcnN0b29kLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv bG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20g NC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1hbD48 Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiInPlZvbjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IEpvaG4gVGFtcGxpbiBbbWFpbHRvOmph dEBnb29nbGUuY29tXSA8YnI+PGI+R2VzZW5kZXQ6PC9iPiBEb25uZXJzdGFnLCAyNS4gQXVndXN0 IDIwMTEgMTY6NDg8YnI+PGI+QW46PC9iPiBUb2JpYXMgT2JlcnN0ZWluPGJyPjxiPkNjOjwvYj4g aHliaUBpZXRmLm9yZzxicj48Yj5CZXRyZWZmOjwvYj4gUmU6IFtoeWJpXSBEcmFmdCAxMiAtIE9y ZGVyaW5nIEd1YXJhbnRlZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFs Pk9uIFRodSwgQXVnIDI1LCAyMDExIGF0IDk6MDAgQU0sIFRvYmlhcyBPYmVyc3RlaW4gJmx0Ozxh IGhyZWY9Im1haWx0bzp0b2JpYXMub2JlcnN0ZWluQHRhdmVuZG8uZGUiPnRvYmlhcy5vYmVyc3Rl aW5AdGF2ZW5kby5kZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD5JJ2QgbGlrZSB0byBwcm9wb3NlIHRoZSBmb2xsb3dpbmcgYWRkaXRpb25zLjxicj48YnI+ NS40LiAmbmJzcDtGcmFnbWVudGF0aW9uPGJyPjxicj4qIEFuIGludGVybWVkaWFyeSBNVVNUIE5P VCBjb2FsZXNjZSBtZXNzYWdlIGZyYW1lcyBhY2Nyb3NzIGZyYW1lcyB3aXRoIEZJTiBiaXQgc2V0 LjxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9TXNvTm9ybWFsPkknbSBub3Qgc3VyZSBob3cgdG8gaGFu ZGxlIHRoaXMsIGJ1dCBJIHRoaW5rIGV4dGVuc2lvbnMgbWF5IG5lZWQgdG8gZXhwYW5kIG9uIHRo aXMgcG9pbnQuICZuYnNwO0ZvciBleGFtcGxlLCBhIE1VWCBleHRlbnNpb24gbWlnaHQgd2VsbCBk byBzbyBmb3IgaW50ZXJsZWF2ZWQgbWVzc2FnZXMgb24gZGlmZmVyZW50IGNoYW5uZWxzLiAmbmJz cDtQZXJoYXBzIGFkZGluZyBhbiBleHBsaWNpdCBub3RlICZxdW90O3VubGVzcyBhbHRlcmVkIGJ5 IGEgbmVnb3RpYXRlZCBleHRlbnNpb24mcXVvdDs/PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48 cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PGJsb2NrcXVvdGUg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtJz48 cCBjbGFzcz1Nc29Ob3JtYWw+NS41LiAmbmJzcDtDb250cm9sIEZyYW1lczxicj48YnI+Q29udHJv bCBmcmFtZXMgTVVTVCBiZSBkZWxpdmVyZWQgdG8gdGhlIHJlY2lwaWVudCBpbiB0aGUgb3JkZXIg c2VudCBieSB0aGUgc2VuZGVyLjxvOnA+PC9vOnA+PC9wPjwvYmxvY2txdW90ZT48L2Rpdj48ZGl2 PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48cCBjbGFzcz1N c29Ob3JtYWw+SSB0aGluayB0aGlzIG5lZWRzIHNvbWUgZmxleGliaWxpdHkgZm9yIG5vdCBkZWxp dmVyaW5nIGNvbnRyb2wgZnJhbWVzIGF0IGFsbCwgaWYgdGhlIGludGVybWVkaWFyeSBpcyB0aGUg b25lIGJlc3QgdG8gcmVzcG9uZCB0byB0aGVtLiAmbmJzcDtDb25zaWRlciBhIFdTIGZyb250LWVu ZCB0aGF0IGhhbmRsZXMgcGluZ3Mgc28gdGhlIGJhY2tlbmQgc2VydmVycyBkb24ndCBoYXZlIHRv LjxiciBjbGVhcj1hbGw+PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+PC9kaXY+PHAgY2xhc3M9TXNvTm9ybWFsPi0tIDxicj5Kb2huIEEu IFRhbXBsaW48YnI+U29mdHdhcmUgRW5naW5lZXIgKEdXVCksIEdvb2dsZTxvOnA+PC9vOnA+PC9w PjwvZGl2PjwvZGl2PjwvYm9keT48L2h0bWw+ --_000_634914A010D0B943A035D226786325D422C0D5D7BFEXVMBX02012ex_-- From ibc@aliax.net Thu Aug 25 08:40: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 5B00621F85C0 for ; Thu, 25 Aug 2011 08:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djSeatJDUAZV for ; Thu, 25 Aug 2011 08:40:18 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id D214821F8593 for ; Thu, 25 Aug 2011 08:40:17 -0700 (PDT) Received: by gxk19 with SMTP id 19so2190865gxk.31 for ; Thu, 25 Aug 2011 08:41:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.145.130 with SMTP id p2mr40913207yhj.125.1314286890425; Thu, 25 Aug 2011 08:41:30 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Thu, 25 Aug 2011 08:41:30 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 25 Aug 2011 17:41:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 15:40:18 -0000 2011/8/25 Tobias Oberstein : > Control frames with empty payload MAY be handled by an intermediary direc= tly > and not delivered to the otherwise receiving endpoint. What is that??? are you suggesting a specification for a non standarized element (a "websocket intermediary")? If the WS draft does NOT define what an intermediary is, then don't add stuf in the spec about such "intermediaries", period. WebSocket is a end-to-end protocol (client-to-server), and the spec should just talk about that and not about custom/propietary/strange network elements doing non standarized stuf ("WebSocket intermediary??"). If you want to introduce the concept of a "WebSocket proxy" in the WS spec, then do it properly and define a robust mechanism for frames between the client and the proxy (which would require some routing logic, such as 'destination' field within the WS frame). It seems that some people here do know "what a websocket intermediary is" because they have some custom/propietary/non-standard network elements ready for doing something "cool" with HTTP/WS traffic, and they want WS protocol to facilitate it. This is a IETF draft, not a HowTo document in which each one can add non standard custom stuf. If a suggestion like this would be made in IETF SIP/SIMPLE Working Group, the 3rd World War would start, but here it seems that vendor-custom-needs can influence on the resulting specification just to make them happy, even if we end with a IETF RFC talking about "WebSocket intermediaries" which is defined NOWHERE. No please. I hope the IETF will stop this kind of aberrations soon. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Thu Aug 25 09:00: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 D6DB821F873A for ; Thu, 25 Aug 2011 09:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mSE3y+wKgdlO for ; Thu, 25 Aug 2011 09:00:30 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 600A021F871E for ; Thu, 25 Aug 2011 09:00:30 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Thu, 25 Aug 2011 09:01:43 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Thu, 25 Aug 2011 09:00:46 -0700 Thread-Topic: [hybi] Draft 12 - Ordering Guarantees Thread-Index: AcxjPX5VcI+dUrIQTIyTq+kVFyEAwgAAjPsw Message-ID: <634914A010D0B943A035D226786325D422C0DFC48D@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:00:30 -0000 PiAyMDExLzgvMjUgVG9iaWFzIE9iZXJzdGVpbiA8dG9iaWFzLm9iZXJzdGVpbkB0YXZlbmRvLmRl PjoNCj4gPiBDb250cm9sIGZyYW1lcyB3aXRoIGVtcHR5IHBheWxvYWQgTUFZIGJlIGhhbmRsZWQg YnkgYW4gaW50ZXJtZWRpYXJ5DQo+ID4gZGlyZWN0bHkgYW5kIG5vdCBkZWxpdmVyZWQgdG8gdGhl IG90aGVyd2lzZSByZWNlaXZpbmcgZW5kcG9pbnQuDQo+IA0KPiBXaGF0IGlzIHRoYXQ/Pz8gYXJl IHlvdSBzdWdnZXN0aW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgYSBub24gc3RhbmRhcml6ZWQNCj4g ZWxlbWVudCAoYSAid2Vic29ja2V0IGludGVybWVkaWFyeSIpPw0KPiANCj4gSWYgdGhlIFdTIGRy YWZ0IGRvZXMgTk9UIGRlZmluZSB3aGF0IGFuIGludGVybWVkaWFyeSBpcywgdGhlbiBkb24ndCBh ZGQgc3R1Zg0KPiBpbiB0aGUgc3BlYyBhYm91dCBzdWNoICJpbnRlcm1lZGlhcmllcyIsIHBlcmlv ZC4NCg0KPGN1dCBsb25nIHJhbnQ+DQoNCjEuIFJlYWQgdGhlIHNwZWMsIGl0IGRlc2NyaWJlcyBz ZW1hbnRpY3MgdXNpbmcgdGhlIHdvcmQgImludGVybWVkaWFyeSIgaW4gb3ZlciB0d28gZG96ZW5z IHBsYWNlcw0KMi4gUmVhZCB0aGUgZ3JvdXAgY2hhcnRlciAoaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL3dnL2h5YmkvY2hhcnRlcikgLi4gaXQgbGlzdHMgc2V2ZXJhbCBleGFtcGxlcyBvZiBp bnRlcm1lZGlhcmllcw0KMy4gQ2FsbSBkb3duDQoNClJlZ2FyZHMsDQpUb2JpYXMNCg== From jat@google.com Thu Aug 25 09:12: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 0695F21F855F for ; Thu, 25 Aug 2011 09:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.78 X-Spam-Level: X-Spam-Status: No, score=-105.78 tagged_above=-999 required=5 tests=[AWL=-0.104, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dna52zIfW9Xk for ; Thu, 25 Aug 2011 09:12:19 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 227C321F84E4 for ; Thu, 25 Aug 2011 09:12:18 -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 p7PGDRdu027141 for ; Thu, 25 Aug 2011 09:13:27 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314288807; bh=AbBNpEu7Y7FzV4NPZ0QscP+753M=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=vju2wqwwniWFTqHbPERPEntngZkL3Dni8dmlbA+jj5rrmwU4HGIt1kbLn6iOIn4eM GDH5f8zlw5jhYVYr/6+Rg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=x9fV5uGfDAat3i/Hqp+2JvEiwDbsFOBfAuCWDZ1l6nhbUaeNJ96d6swTfUDH3u61l qRHNbOJ64bF4Tf5BIRh/A== Received: from gwj20 (gwj20.prod.google.com [10.200.10.20]) by wpaz37.hot.corp.google.com with ESMTP id p7PGCFIt012057 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 25 Aug 2011 09:13:26 -0700 Received: by gwj20 with SMTP id 20so2168555gwj.26 for ; Thu, 25 Aug 2011 09:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=XWOsAKa+FOrQKGE6HBSA1rLz4X11TnPIrHak2+MAVmI=; b=OBKZoDoL4wZq6gUsJSxaI6/gdtPrnsOHrrQujTXavDgGdfT0xV2ky5IToceRIxZCMH UE3j9jyVqTQpCisLACmQ== Received: by 10.150.173.33 with SMTP id v33mr1158031ybe.2.1314288801251; Thu, 25 Aug 2011 09:13:21 -0700 (PDT) Received: by 10.150.173.33 with SMTP id v33mr1158023ybe.2.1314288801122; Thu, 25 Aug 2011 09:13:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Thu, 25 Aug 2011 09:13:01 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Thu, 25 Aug 2011 12:13:01 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd5c9ea1f87f304ab56b5f9 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:12:20 -0000 --000e0cd5c9ea1f87f304ab56b5f9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 25, 2011 at 11:41 AM, I=C3=B1aki Baz Castillo w= rote: > 2011/8/25 Tobias Oberstein : > > Control frames with empty payload MAY be handled by an intermediary > directly > > and not delivered to the otherwise receiving endpoint. > > What is that??? are you suggesting a specification for a non > standarized element (a "websocket intermediary")? > > If the WS draft does NOT define what an intermediary is, then don't > add stuf in the spec about such "intermediaries", period. > You appear to be the only one here who doesn't understand what a WS intermediary is. Quite simply, it is anything in the path between two WS endpoints which understands WS. They may observe traffic, they may intercept (either transparently, by being an HTTP proxy and noticing that the connection is WS, or through a yet-to-be defined method of telling the browser to use a WS proxy specifically) a WS connection and log/filter/whatever it wants to do with the traffic. Saying exactly what they may do is outside the scope of this spec, and we are unlikely to have good ideas of what you might want to do with them at this point anyway. Th= e spec's job is to make sure that when such intermediaries do arise, the rule= s of what they can do to the traffic are defined so they don't unintentionall= y break connectivity. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd5c9ea1f87f304ab56b5f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 25, 2011 at 11:41 AM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
2011/8/25 Tobias Oberstein <tobias.oberstein@tavendo.de>:
> Control frames with empty payload MAY be handled by = an intermediary directly
> and not delivered to the otherwise receiving endpoint.

What is that??? are you suggesting a specification for a non
standarized element (a "websocket intermediary")?

If the WS draft does NOT define what an intermediary is, then don't
add stuf in the spec about such "intermediaries", period.

You appear to be the only one here who doesn&#= 39;t understand what a WS intermediary is. =C2=A0Quite simply, it is anythi= ng in the path between two WS endpoints which understands WS. =C2=A0They ma= y observe traffic, they may intercept (either transparently, by being an HT= TP proxy and noticing that the connection is WS, or through a yet-to-be def= ined method of telling the browser to use a WS proxy specifically) a WS con= nection and log/filter/whatever it wants to do with the traffic. =C2=A0Sayi= ng exactly what they may do is outside the scope of this spec, and we are u= nlikely to have good ideas of what you might want to do with them at this p= oint anyway. =C2=A0The spec's job is to make sure that when such interm= ediaries do arise, the rules of what they can do to the traffic are defined= so they don't unintentionally break connectivity.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd5c9ea1f87f304ab56b5f9-- From ibc@aliax.net Thu Aug 25 09:25:27 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 533F721F8742 for ; Thu, 25 Aug 2011 09:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqaV2PIQkQqj for ; Thu, 25 Aug 2011 09:25:26 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4224921F86B6 for ; Thu, 25 Aug 2011 09:25:26 -0700 (PDT) Received: by ywe9 with SMTP id 9so2217875ywe.31 for ; Thu, 25 Aug 2011 09:26:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.131.28 with SMTP id e28mr435970yad.7.1314289599754; Thu, 25 Aug 2011 09:26:39 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Thu, 25 Aug 2011 09:26:39 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0DFC48D@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0DFC48D@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 25 Aug 2011 18:26:39 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:25:27 -0000 2011/8/25 Tobias Oberstein : > 1. Read the spec, it describes semantics using the word "intermediary" in= over two dozens places The way in which "intermediary" is defined within the spec is just a hack ("proxies and other intermediaries?"). > 2. Read the group charter (http://datatracker.ietf.org/wg/hybi/charter) .= . it lists several examples of intermediaries "HTTP-aware intermediaries like proxies, load balancers, caches, etc" Ok. > 3. Calm down Sure, just one question more. You said: > Control frames with empty payload MAY be handled by an intermediary direc= tly and not delivered to the otherwise receiving endpoint. What about if there are more than one "intermediary"? or must we assume a vendor-specific infraestructure with an HTTP load-balancer in front of a cluster of application servers? --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Thu Aug 25 09:34: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 CE25B21F8839 for ; Thu, 25 Aug 2011 09:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hg9Z4uCyxxUJ for ; Thu, 25 Aug 2011 09:34:50 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id 44CC521F85C0 for ; Thu, 25 Aug 2011 09:34:49 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Thu, 25 Aug 2011 09:36:02 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Thu, 25 Aug 2011 09:35:05 -0700 Thread-Topic: [hybi] Draft 12 - Ordering Guarantees Thread-Index: AcxjQ8ne977a3IMqSUiFMcaJvbiCywAABDxg Message-ID: <634914A010D0B943A035D226786325D422C0DFC4C9@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0DFC48D@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:34:50 -0000 PiBTdXJlLCBqdXN0IG9uZSBxdWVzdGlvbiBtb3JlLiBZb3Ugc2FpZDoNCj4gDQo+ID4gQ29udHJv bCBmcmFtZXMgd2l0aCBlbXB0eSBwYXlsb2FkIE1BWSBiZSBoYW5kbGVkIGJ5IGFuIGludGVybWVk aWFyeQ0KPiBkaXJlY3RseSBhbmQgbm90IGRlbGl2ZXJlZCB0byB0aGUgb3RoZXJ3aXNlIHJlY2Vp dmluZyBlbmRwb2ludC4NCj4gDQo+IFdoYXQgYWJvdXQgaWYgdGhlcmUgYXJlIG1vcmUgdGhhbiBv bmUgImludGVybWVkaWFyeSI/IG9yIG11c3Qgd2UgYXNzdW1lIGENCj4gdmVuZG9yLXNwZWNpZmlj IGluZnJhZXN0cnVjdHVyZSB3aXRoIGFuIEhUVFAgbG9hZC1iYWxhbmNlciBpbiBmcm9udCBvZiBh DQo+IGNsdXN0ZXIgb2YgYXBwbGljYXRpb24gc2VydmVycz8NCg0KIl9hbl8gaW50ZXJtZWRpYXJ5 IiA9IGFueSBvZiBwb3RlbnRpYWxseSBtYW55IG9uIHRoZSBwYXRoIGJldHdlZW4gdGhlIGVuZHBv aW50cw0KDQppLmUuDQoNCkEgUGluZyB3aXRoIGVtcHR5IHBheWxvYWQgbWF5IGJlIGhhbmRsZWQg YnkgYSBXUyBsb2FkLWJhbGFuY2luZyBmcm9udC1lbmQNCmRpcmVjdGx5IGJ5IHNlbmRpbmcgKGFu IGVtcHR5IHBheWxvYWQpIFBvbmcgYmFjay4NCg0KQW4gdW5zb2xpY2l0ZWQgZW1wdHkgcGF5bG9h ZCBQb25nIG1heSBiZSBmaWx0ZXJlZCBvdXQgYnkgYSBXUyBnYXRld2F5IHN5c3RlbQ0Kb3BlcmF0 ZWQgYnkgYSBtb2JpbGUgY2Fycmllci4gVGhhdCBQb25nIHdvdWxkIG5ldmVyIHJlYWNoIHRoZSBv dGhlcndpc2UNCnJlY2VpdmluZyBlbmRwb2ludCwgYW5kIGl0IHdvdWxkIGFsc28gbm90IHJlYWNo IHRoZSBsb2FkLWJhbGFuY2luZyBXUyBmcm9udGVuZA0KY2x1c3Rlci4NCg0KSG93ZXZlciwgd2hh dCBhYm92ZSBydWxlIHdvdWxkIGVzdGFibGlzaCB3YXMgdGhhdCBhIHBlZXIgc2VuZGluZyBhIFBp bmcNCndpdGggbm9uLWVtcHR5IHBheWxvYWQgY2FuIGJlIHN1cmUgdGhhdCB0aGlzIFBpbmcgd2ls bCByZWFjaCB0aGUgcmVjZWl2aW5nDQpwZWVyLg0KDQpUaGUgb3RoZXIgcHJvcG9zZWQgcnVsZXMg d291bGQgZW5zdXJlIHRoYXQgaXQgaXMgYWxzbyB3ZWxsIGRlZmluZWQgd2hhdA0KdGhlIG9yZGVy aW5nIHJlbGF0aW9uIGJldHdlZW4gdGhlIHJlY2VpdmVkIFBpbmcgYW5kIG90aGVyIHJlY2VpdmVk DQpjb250cm9sIGFuZCBub24tY29udHJvbCBmcmFtZXMgd291bGQgYmUuDQoNCkFsbCBmb3IgdGhl IGJhc2UgV1MgcHJvdG9jb2wgd2hlbiBubyBleHRlbnNpb24gaXMgYWN0aXZlLg0KDQpJZiBhbiBl eHRlbnNpb24gaXMgYWN0aXZlLCB0aGUgcnVsZXMgb2YgV1MgYWxyZWFkeSBhbGxvdyB0aGF0IGV4 dGVuc2lvbg0KdG8gZGVmaW5lIGZhci1yZWFjaGluZyBydWxlcyByZWdhcmRpbmcgcmVjZXB0aW9u IGFuZCBvcmRlcmluZyBndWFyYW50ZWVzLg0KDQpIb3dldmVyLCBJIGV4cGVjdCB0aGF0IG9ubHkg dmVyeSBmZXcgZXh0ZW5zaW9ucyB3aGljaCBzcGVjaWZ5IHNwZWNpYWwNCnJ1bGVzIG1pZ2h0IGZp bmQgdGhlIGZ1bGwgc3VwcG9ydCBmb3IgdGhlaXIgc3BlY2lmaWMgcnVsZXMgYnkgYWxsIHZlbmRv cnMgb2YNCndoYXRldmVyIGludGVybWVkaWFyaWVzLg0KDQo= From salvatore.loreto@ericsson.com Thu Aug 25 09:35: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 68C7B21F8797 for ; Thu, 25 Aug 2011 09:35:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewFxYX3ovEIW for ; Thu, 25 Aug 2011 09:35:28 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7D24F21F877B for ; Thu, 25 Aug 2011 09:35:27 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-8f-4e567a175353 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AD.CE.20773.71A765E4; Thu, 25 Aug 2011 18:36:39 +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; Thu, 25 Aug 2011 18:36:39 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 513012356 for ; Thu, 25 Aug 2011 19:36:39 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0E1345135D for ; Thu, 25 Aug 2011 19:36:39 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8FDC551010 for ; Thu, 25 Aug 2011 19:36:38 +0300 (EEST) Message-ID: <4E567A16.4050804@ericsson.com> Date: Thu, 25 Aug 2011 18:36:38 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: hybi@ietf.org References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000308080907090100070701" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:35:29 -0000 --------------000308080907090100070701 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit On 8/25/11 6:13 PM, John Tamplin wrote: > On Thu, Aug 25, 2011 at 11:41 AM, Iñaki Baz Castillo > wrote: > > 2011/8/25 Tobias Oberstein >: > > Control frames with empty payload MAY be handled by an > intermediary directly > > and not delivered to the otherwise receiving endpoint. > > What is that??? are you suggesting a specification for a non > standarized element (a "websocket intermediary")? > > If the WS draft does NOT define what an intermediary is, then don't > add stuf in the spec about such "intermediaries", period. > > > You appear to be the only one here who doesn't understand what a WS > intermediary is. Quite simply, it is anything in the path between two > WS endpoints which understands WS. They may observe traffic, they may > intercept (either transparently, by being an HTTP proxy and noticing > that the connection is WS, or through a yet-to-be defined method of > telling the browser to use a WS proxy specifically) a WS connection > and log/filter/whatever it wants to do with the traffic. Saying > exactly what they may do is outside the scope of this spec, and we are > unlikely to have good ideas of what you might want to do with them at > this point anyway. The spec's job is to make sure that when such > intermediaries do arise, the rules of what they can do to the traffic > are defined so they don't unintentionally break connectivity. (as individual) adding to the spec some text explaining what a WS intermediary would be opportune. /Sal --------------000308080907090100070701 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: 8bit On 8/25/11 6:13 PM, John Tamplin wrote:
On Thu, Aug 25, 2011 at 11:41 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2011/8/25 Tobias Oberstein <tobias.oberstein@tavendo.de>:
> Control frames with empty payload MAY be handled by an intermediary directly
> and not delivered to the otherwise receiving endpoint.

What is that??? are you suggesting a specification for a non
standarized element (a "websocket intermediary")?

If the WS draft does NOT define what an intermediary is, then don't
add stuf in the spec about such "intermediaries", period.

You appear to be the only one here who doesn't understand what a WS intermediary is.  Quite simply, it is anything in the path between two WS endpoints which understands WS.  They may observe traffic, they may intercept (either transparently, by being an HTTP proxy and noticing that the connection is WS, or through a yet-to-be defined method of telling the browser to use a WS proxy specifically) a WS connection and log/filter/whatever it wants to do with the traffic.  Saying exactly what they may do is outside the scope of this spec, and we are unlikely to have good ideas of what you might want to do with them at this point anyway.  The spec's job is to make sure that when such intermediaries do arise, the rules of what they can do to the traffic are defined so they don't unintentionally break connectivity.

(as individual)


adding to the spec some text explaining what a WS intermediary would be opportune.

/Sal
--------------000308080907090100070701-- From ibc@aliax.net Thu Aug 25 09:45: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 6F81821F8ACE for ; Thu, 25 Aug 2011 09:45:28 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTtvI6mh65rP for ; Thu, 25 Aug 2011 09:45:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 0147D21F8AA8 for ; Thu, 25 Aug 2011 09:45:26 -0700 (PDT) Received: by gwb20 with SMTP id 20so2253396gwb.31 for ; Thu, 25 Aug 2011 09:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.185.228 with SMTP id u64mr42045733yhm.91.1314290798962; Thu, 25 Aug 2011 09:46:38 -0700 (PDT) Received: by 10.147.132.18 with HTTP; Thu, 25 Aug 2011 09:46:38 -0700 (PDT) In-Reply-To: <4E567A16.4050804@ericsson.com> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> <4E567A16.4050804@ericsson.com> Date: Thu, 25 Aug 2011 18:46:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 16:45:28 -0000 2011/8/25 Salvatore Loreto : > adding to the spec some text explaining what a WS intermediary would be > opportune. Yes, please, thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Thu Aug 25 14:50: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 1014921F8B79 for ; Thu, 25 Aug 2011 14:50:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CwUuwvzAQlfW for ; Thu, 25 Aug 2011 14:50:55 -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 56E6D21F8B75 for ; Thu, 25 Aug 2011 14:50:55 -0700 (PDT) Received: by qwc23 with SMTP id 23so2023068qwc.31 for ; Thu, 25 Aug 2011 14:52:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.16 with SMTP id y16mr363280qce.185.1314309129129; Thu, 25 Aug 2011 14:52:09 -0700 (PDT) Received: by 10.229.211.68 with HTTP; Thu, 25 Aug 2011 14:52:09 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0DFC4C9@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0DFC48D@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0DFC4C9@EXVMBX020-12.exch020.serverdata.net> Date: Thu, 25 Aug 2011 23:52:09 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 21:50:56 -0000 2011/8/25 Tobias Oberstein : > A Ping with empty payload may be handled by a WS load-balancing front-end > directly by sending (an empty payload) Pong back. And how would the WS client know whether to send a Ping with body or empty body? how would it know whenever there is an intermediary or not? perhaps should the JS developer *know* it when writting the JavaScript code? Are we assuming that the webpage/JavaScript developer would be the same person building the service infraestructure (servers, load-balancers, and so)? IMHO this seems a hack and I doubt such "feature" should be included in an IETF RFC. --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Thu Aug 25 15:54: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 1279521F8B51 for ; Thu, 25 Aug 2011 15:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zcC3kQRgT1J for ; Thu, 25 Aug 2011 15:54:18 -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 A02B121F855D for ; Thu, 25 Aug 2011 15:54:14 -0700 (PDT) Received: by vws12 with SMTP id 12so3003150vws.31 for ; Thu, 25 Aug 2011 15:55:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.173.35 with SMTP id bh3mr366941vdc.380.1314312925104; Thu, 25 Aug 2011 15:55:25 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Thu, 25 Aug 2011 15:55:25 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0DFC48D@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 26 Aug 2011 08:55:25 +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] Draft 12 - Ordering Guarantees X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Aug 2011 22:54:19 -0000 On 26 August 2011 02:26, I=F1aki Baz Castillo wrote: > 2011/8/25 Tobias Oberstein : > >> 1. Read the spec, it describes semantics using the word "intermediary" i= n over two dozens places > > The way in which "intermediary" is defined within the spec is just a > hack ("proxies and other intermediaries?"). I don't think there is very much value (or even a possibility of) in nailing down what an intermediary is and what it can/can't do beyond the minimal needed. I think we need the minimal of requirements (such as the existing limitations on changing fragmentation if extensions are not understood). It is a valid question to ask if control frame order is such a minimal requirement, but I think the answer to that question is no. Intermediaries may run different ping/pong policies on a hop by hop basis. They may inject proprietary control messages on one hop but not the other. We already allow a single pong response to cover two outstanding pings, so that is in effect allowing one ping to overtake another. regards From ibc@aliax.net Fri Aug 26 06:03: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 905FC21F8ADE for ; Fri, 26 Aug 2011 06:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.72 X-Spam-Level: X-Spam-Status: No, score=-1.72 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjYbe0GRugX7 for ; Fri, 26 Aug 2011 06:03:21 -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 005D321F8AD9 for ; Fri, 26 Aug 2011 06:03:20 -0700 (PDT) Received: by qwc23 with SMTP id 23so2404476qwc.31 for ; Fri, 26 Aug 2011 06:04:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.14 with SMTP id q14mr1480369qce.122.1314363875270; Fri, 26 Aug 2011 06:04:35 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 06:04:35 -0700 (PDT) Date: Fri, 26 Aug 2011 15:04:35 +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] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:03:21 -0000 Hi, Autobahn WS server test says: --------------------------- Test Case 3.1 Description Send small text message with RSV =3D 1. Expectation The connection is failed immediately, since RSV must be 0, when no extension defining RSV meaning has been negoiated. ----------------------------- If my server replies a close control frame with status 1002, then the test marks it as "failed", it just marks it as "passed" in case my server *directly* terminates the TCP connection. Why? is it the expected behaviour? IMHO there has been a WS protocol level error, so a WS protocol message must take place rather than terminating the TCP connection. Am I wrong? Thanks. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Aug 26 06:10:11 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 3E6F521F8B4D for ; Fri, 26 Aug 2011 06:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTCd1plY+z-K for ; Fri, 26 Aug 2011 06:10:10 -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 8C0E021F8B4C for ; Fri, 26 Aug 2011 06:10:10 -0700 (PDT) Received: by qwc23 with SMTP id 23so2410947qwc.31 for ; Fri, 26 Aug 2011 06:10:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.85 with SMTP id h21mr1512464qci.46.1314364257978; Fri, 26 Aug 2011 06:10:57 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 06:10:57 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Aug 2011 15:10: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: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 13:10:11 -0000 2011/8/26 I=C3=B1aki Baz Castillo : > Hi, Autobahn WS server test says: > > --------------------------- > Test Case 3.1 > > Description > =C2=A0Send small text message with RSV =3D 1. > > Expectation > =C2=A0The connection is failed immediately, since RSV must be 0, when > =C2=A0 no extension defining RSV meaning has been negoiated. > ----------------------------- > > If my server replies a close control frame with status 1002, then the > test marks it as "failed", it just marks it as "passed" in case my > server *directly* terminates the TCP connection. Why? is it the > expected behaviour? IMHO there has been a WS protocol level error, so > a WS protocol message must take place rather than terminating the TCP > connection. Am I wrong? IMHO it's clear in the spec: ----------------------------------------------------- 7.1.7. Fail the WebSocket Connection [...] If _The WebSocket Connection is Established_ prior to the point where the endpoint is required to _Fail the WebSocket Connection_, the endpoint SHOULD send a Close frame with an appropriate status code Section 7.4 before proceeding to _Close the WebSocket Connection_. ------------------------------------------------------- So if the test suite is wrong.... good news. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Aug 26 07:08: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 7264F21F8B92 for ; Fri, 26 Aug 2011 07:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8LGPm1WmmpZ for ; Fri, 26 Aug 2011 07:08:55 -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 E359321F8B7F for ; Fri, 26 Aug 2011 07:08:54 -0700 (PDT) Received: by qwc23 with SMTP id 23so2468860qwc.31 for ; Fri, 26 Aug 2011 07:10:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.101.34 with SMTP id a34mr1603455qco.8.1314367806753; Fri, 26 Aug 2011 07:10:06 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 07:10:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Aug 2011 16:10:06 +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: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 14:08:55 -0000 2011/8/26 I=C3=B1aki Baz Castillo : > IMHO it's clear in the spec: > > ----------------------------------------------------- > 7.1.7. =C2=A0Fail the WebSocket Connection > > =C2=A0 [...] > =C2=A0 If _The WebSocket Connection is Established_ prior to the point wh= ere > =C2=A0 the endpoint is required to _Fail the WebSocket Connection_, the > =C2=A0 endpoint SHOULD send a Close frame with an appropriate status code > =C2=A0 Section 7.4 before proceeding to _Close the WebSocket Connection_. > ------------------------------------------------------- > > So if the test suite is wrong.... good news. If my WS server closes the TCP connection without sending a close frame, then Autobahn client detects it and marks as "valid" the test (since the remote has closed). But if my WS server sends a close frame and after it closes the TCP connection ("close_connection_after_writting") then Autobahn client does not detect the TCP close and closes it after 1 second (this is what the network trace says in the results web). Must investigate a bit. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Aug 26 08:38: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 710D421F8BC4 for ; Fri, 26 Aug 2011 08:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TfQte6ab07FC for ; Fri, 26 Aug 2011 08:38:02 -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 E3ABC21F8C0D for ; Fri, 26 Aug 2011 08:38:01 -0700 (PDT) Received: by qyk35 with SMTP id 35so2259845qyk.10 for ; Fri, 26 Aug 2011 08:39:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.101.34 with SMTP id a34mr1725110qco.8.1314373157916; Fri, 26 Aug 2011 08:39:17 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 08:39:17 -0700 (PDT) In-Reply-To: References: Date: Fri, 26 Aug 2011 17:39:17 +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: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:38:02 -0000 2011/8/26 I=C3=B1aki Baz Castillo : > If my WS server closes the TCP connection without sending a close > frame, then Autobahn client detects it and marks as "valid" the test > (since the remote has closed). > > But if my WS server sends a close frame and after it closes the TCP > connection ("close_connection_after_writting") then Autobahn client > does not detect the TCP close and closes it after 1 second (this is > what the network trace says in the results web). Must investigate a > bit. Apart from the above minor issue (which is more related to TCP disconnection issues) my WS server passes all the Autobahn tests :) --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Fri Aug 26 08:39: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 0E4E221F8C2A for ; Fri, 26 Aug 2011 08:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAP4BqRzgHaW for ; Fri, 26 Aug 2011 08:39:23 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7CD21F8C17 for ; Fri, 26 Aug 2011 08:39:23 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Fri, 26 Aug 2011 08:40:39 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "hybi@ietf.org" Date: Fri, 26 Aug 2011 08:39:40 -0700 Thread-Topic: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? Thread-Index: Acxj+eM40j4x5y0KTsGGTd5v4opiygADASNQ Message-ID: <634914A010D0B943A035D226786325D422C0DFC8BA@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:39:24 -0000 PiA+IDcuMS43LiDCoEZhaWwgdGhlIFdlYlNvY2tldCBDb25uZWN0aW9uDQo+ID4NCj4gPiDCoCBb Li4uXQ0KPiA+IMKgIElmIF9UaGUgV2ViU29ja2V0IENvbm5lY3Rpb24gaXMgRXN0YWJsaXNoZWRf IHByaW9yIHRvIHRoZSBwb2ludA0KPiA+IHdoZXJlDQo+ID4gwqAgdGhlIGVuZHBvaW50IGlzIHJl cXVpcmVkIHRvIF9GYWlsIHRoZSBXZWJTb2NrZXQgQ29ubmVjdGlvbl8sIHRoZQ0KPiA+IMKgIGVu ZHBvaW50IFNIT1VMRCBzZW5kIGEgQ2xvc2UgZnJhbWUgd2l0aCBhbiBhcHByb3ByaWF0ZSBzdGF0 dXMgY29kZQ0KPiA+IMKgIFNlY3Rpb24gNy40IGJlZm9yZSBwcm9jZWVkaW5nIHRvIF9DbG9zZSB0 aGUgV2ViU29ja2V0IENvbm5lY3Rpb25fLg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPg0KPiA+IFNvIGlmIHRoZSB0ZXN0IHN1 aXRlIGlzIHdyb25nLi4uLiBnb29kIG5ld3MuDQo+IA0KPiBJZiBteSBXUyBzZXJ2ZXIgY2xvc2Vz IHRoZSBUQ1AgY29ubmVjdGlvbiB3aXRob3V0IHNlbmRpbmcgYSBjbG9zZSBmcmFtZSwNCj4gdGhl biBBdXRvYmFobiBjbGllbnQgZGV0ZWN0cyBpdCBhbmQgbWFya3MgYXMgInZhbGlkIiB0aGUgdGVz dCAoc2luY2UgdGhlDQo+IHJlbW90ZSBoYXMgY2xvc2VkKS4NCj4gDQo+IEJ1dCBpZiBteSBXUyBz ZXJ2ZXIgc2VuZHMgYSBjbG9zZSBmcmFtZSBhbmQgYWZ0ZXIgaXQgY2xvc2VzIHRoZSBUQ1ANCj4g Y29ubmVjdGlvbiAoImNsb3NlX2Nvbm5lY3Rpb25fYWZ0ZXJfd3JpdHRpbmciKSB0aGVuIEF1dG9i YWhuIGNsaWVudCBkb2VzDQo+IG5vdCBkZXRlY3QgdGhlIFRDUCBjbG9zZSBhbmQgY2xvc2VzIGl0 IGFmdGVyIDEgc2Vjb25kICh0aGlzIGlzIHdoYXQgdGhlIG5ldHdvcmsNCj4gdHJhY2Ugc2F5cyBp biB0aGUgcmVzdWx0cyB3ZWIpLiBNdXN0IGludmVzdGlnYXRlIGEgYml0Lg0KDQpUaGVzZSB0ZXN0 IGNhc2VzIGFyZSBjdXJyZW50bHkgY29uc3RydWN0ZWQgc28gdGhhdCB0aGV5IGV4cGVjdA0KImZh aWwgY29ubmVjdGlvbiIgPSAicGVlciBjbG9zZXMgVENQIHdpdGhvdXQgcGVyZm9ybWluZyBXUyBj bG9zZSBoYW5kc2hha2UiDQoNCkNvbW1lbnRzOg0KDQotIFRoaXMgZml0cyB0aGUgYmVoYXZpb3Ig b2YgQ2hyb21lL0ZGIGFuZCBhbGwgb3RoZXIgbGlicw0KLSBJdCBkb2VzIG5vdCBmaXQgdGhlIFNI T1VMRCBpbiB0aGUgc3BlYw0KLSBJIHdpbGwgZXhwYW5kIHRoZSBjYXNlcy90ZXN0IHN1aXRlIHNv IHRoYXQgaXQgY2FuIGRldGVjdCBib3RoIGJlaGF2aW9ycw0KLSBOb3RlIHRoYXQgdGhpcyBpcyBz b21ld2hhdCBhbm5vdW5jZWQgb24gdGhlIHdlYiBzaXRlOiB0aGUgc3VpdGUgc3RpbGwgbGFja3Mg aW4gMiBhcmVhczogVVRGLTggYW5kIE9wZW4vQ2xvc2UgSGFuZHNoYWtlIGhhbmRsaW5nDQotIGZl ZWwgZnJlZSB0byBzdWJtaXQgcGF0Y2hlcyAuLg0KDQoNCg0KDQo= From tobias.oberstein@tavendo.de Fri Aug 26 08:42:36 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 A801C21F8B7B for ; Fri, 26 Aug 2011 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ksqU1L25n8sv for ; Fri, 26 Aug 2011 08:42:36 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id C10B321F8B5C for ; Fri, 26 Aug 2011 08:42:35 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Fri, 26 Aug 2011 08:43:52 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , "hybi@ietf.org" Date: Fri, 26 Aug 2011 08:42:53 -0700 Thread-Topic: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? Thread-Index: AcxkBlccbZ8HaB0XSB6NcK6zVFK33QAABK3A Message-ID: <634914A010D0B943A035D226786325D422C0DFC8C2@EXVMBX020-12.exch020.serverdata.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 15:42:36 -0000 PiA+IElmIG15IFdTIHNlcnZlciBjbG9zZXMgdGhlIFRDUCBjb25uZWN0aW9uIHdpdGhvdXQgc2Vu ZGluZyBhIGNsb3NlDQo+ID4gZnJhbWUsIHRoZW4gQXV0b2JhaG4gY2xpZW50IGRldGVjdHMgaXQg YW5kIG1hcmtzIGFzICJ2YWxpZCIgdGhlIHRlc3QNCj4gPiAoc2luY2UgdGhlIHJlbW90ZSBoYXMg Y2xvc2VkKS4NCj4gPg0KPiA+IEJ1dCBpZiBteSBXUyBzZXJ2ZXIgc2VuZHMgYSBjbG9zZSBmcmFt ZSBhbmQgYWZ0ZXIgaXQgY2xvc2VzIHRoZSBUQ1ANCj4gPiBjb25uZWN0aW9uICgiY2xvc2VfY29u bmVjdGlvbl9hZnRlcl93cml0dGluZyIpIHRoZW4gQXV0b2JhaG4gY2xpZW50DQo+ID4gZG9lcyBu b3QgZGV0ZWN0IHRoZSBUQ1AgY2xvc2UgYW5kIGNsb3NlcyBpdCBhZnRlciAxIHNlY29uZCAodGhp cyBpcw0KPiA+IHdoYXQgdGhlIG5ldHdvcmsgdHJhY2Ugc2F5cyBpbiB0aGUgcmVzdWx0cyB3ZWIp LiBNdXN0IGludmVzdGlnYXRlIGENCj4gPiBiaXQuDQo+IA0KPiBBcGFydCBmcm9tIHRoZSBhYm92 ZSBtaW5vciBpc3N1ZSAod2hpY2ggaXMgbW9yZSByZWxhdGVkIHRvIFRDUA0KPiBkaXNjb25uZWN0 aW9uIGlzc3VlcykgbXkgV1Mgc2VydmVyIHBhc3NlcyBhbGwgdGhlIEF1dG9iYWhuIHRlc3RzIDop DQoNCm5pY2U7KQ0KDQpXb3VsZCBiZSBoZWxwZnVsIGlmIHlvdSBjb3VsZCBwdWJsaXNoIGEgbGlu ayB0byB0aGUgZ2VuZXJhdGVkIHJlcG9ydHMNCihmb3IgbWUgdG8gbG9vayBpbnRvIHRoZSB3aXJl bG9ncyB0byBzZWUgd2hhdCBoYXBwZW5zIGluIHRoZSBjYXNlcw0KeW91IG1lbnRpb25lZCkNCg0K QWxzbzoNCmh0dHA6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvQ29tcGFyaXNvbl9vZl9XZWJTb2Nr ZXRfaW1wbGVtZW50YXRpb25zDQoNCndpdGggcmVnYXJkIHRvICJmYWlsIGNvbm5lY3Rpb24iIFNI T1VMRCBzZW5kIENsb3NlIC4uIHNlYXJjaCBwb3N0aW5ncw0KaGVyZSAuLiBJJ3ZlIGFza2VkIFRh a2VzaGkgd2h5IENocm9tZSBiZWhhdmVzIHNvIC4uIGFuc3dlcjogaXQncyBieQ0KZGVzaWduIGFu ZCBhbGxvd2VkIHNpbmNlIHNwZWMgb25seSBzYXlzIFNIT1VMRC4gc2VlIHRoZSBhcmd1bWVudHMg dGhlcmUuDQp0aGVuIGRlY2lkZSBob3cgeW91IHdhbnQgeW91ciBsaWIgdG8gYmVoYXZlIC4uLiBJ J20gbmV1dHJhbCBpbiB0aGlzIHBvaW50Lg0K From ibc@aliax.net Fri Aug 26 09:16: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 85EC121F8BB8 for ; Fri, 26 Aug 2011 09:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVB6+nR+PLHK for ; Fri, 26 Aug 2011 09:16:48 -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 B9BC521F8AAA for ; Fri, 26 Aug 2011 09:16:41 -0700 (PDT) Received: by qwc23 with SMTP id 23so2595463qwc.31 for ; Fri, 26 Aug 2011 09:17:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.1 with SMTP id t1mr1718297qci.198.1314375474497; Fri, 26 Aug 2011 09:17:54 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 09:17:54 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0DFC8BA@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0DFC8BA@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 26 Aug 2011 18:17:54 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:16:48 -0000 2011/8/26 Tobias Oberstein : > These test cases are currently constructed so that they expect > "fail connection" =3D "peer closes TCP without performing WS close handsh= ake" > > Comments: > > - This fits the behavior of Chrome/FF and all other libs Buth nothing wrong occurs if Chrome/FF receives a close frame, they just behave correctly and send a close reply. > - It does not fit the SHOULD in the spec OK :) > - I will expand the cases/test suite so that it can detect both behaviors Great. > - Note that this is somewhat announced on the web site: the suite still l= acks in 2 areas: UTF-8 and Open/Close Handshake handling And IPv6 support ;) > - feel free to submit patches .. Unfortunately I'm not a Python guy, but Ruby one :) Thanks. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Aug 26 09:21: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 9E3AE21F8C37 for ; Fri, 26 Aug 2011 09:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gB161kBN8n0Q for ; Fri, 26 Aug 2011 09:21:20 -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 DB23821F8C6A for ; Fri, 26 Aug 2011 09:21:19 -0700 (PDT) Received: by qwc23 with SMTP id 23so2599767qwc.31 for ; Fri, 26 Aug 2011 09:22:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.1 with SMTP id t1mr1724456qci.198.1314375752026; Fri, 26 Aug 2011 09:22:32 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 09:22:31 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0DFC8C2@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0DFC8C2@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 26 Aug 2011 18:22:31 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:21:20 -0000 2011/8/26 Tobias Oberstein : > Would be helpful if you could publish a link to the generated reports > (for me to look into the wirelogs to see what happens in the cases > you mentioned) Sure, I'm running the test again with the "hack" dissabled (the "hack" means not sending valid close frame before closing the TCP connection). Let me a minutes and I will upload it to my server. > Also: > http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations The problem is that my WS server is not a generic one, but it's integrated within a SIP server I'm building, so it's not useful to include it (neither it's released yet) in such list. > with regard to "fail connection" SHOULD send Close .. search postings > here .. I've asked Takeshi why Chrome behaves so .. answer: it's by > design and allowed since spec only says SHOULD. see the arguments there. > then decide how you want your lib to behave ... I'm neutral in this point= . If my server sends a close frame to Chrome-15/Firefox-8, they reply a close frame correctly. And then both sides close the TCP connection (not sure which one first), so I still don't see the problem. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From tobias.oberstein@tavendo.de Fri Aug 26 09:26: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 3AB1421F8C9E for ; Fri, 26 Aug 2011 09:26:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vi8Gzc+iqd4l for ; Fri, 26 Aug 2011 09:26:37 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7675921F8C4F for ; Fri, 26 Aug 2011 09:26:37 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Fri, 26 Aug 2011 09:27:53 -0700 From: Tobias Oberstein To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Date: Fri, 26 Aug 2011 09:26:55 -0700 Thread-Topic: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? Thread-Index: AcxkC7gw919iYg2KTP6CEcBJZqT+0gAAEKxg Message-ID: <634914A010D0B943A035D226786325D422C0DFC90A@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0DFC8BA@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 16:26:38 -0000 PiA+IFRoZXNlIHRlc3QgY2FzZXMgYXJlIGN1cnJlbnRseSBjb25zdHJ1Y3RlZCBzbyB0aGF0IHRo ZXkgZXhwZWN0ICJmYWlsDQo+ID4gY29ubmVjdGlvbiIgPSAicGVlciBjbG9zZXMgVENQIHdpdGhv dXQgcGVyZm9ybWluZyBXUyBjbG9zZSBoYW5kc2hha2UiDQo+ID4NCj4gPiBDb21tZW50czoNCj4g Pg0KPiA+IC0gVGhpcyBmaXRzIHRoZSBiZWhhdmlvciBvZiBDaHJvbWUvRkYgYW5kIGFsbCBvdGhl ciBsaWJzDQo+IA0KPiBCdXRoIG5vdGhpbmcgd3Jvbmcgb2NjdXJzIGlmIENocm9tZS9GRiByZWNl aXZlcyBhIGNsb3NlIGZyYW1lLCB0aGV5IGp1c3QNCj4gYmVoYXZlIGNvcnJlY3RseSBhbmQgc2Vu ZCBhIGNsb3NlIHJlcGx5Lg0KDQpZZXMsIHdoZW4gdGhleSBwYXNzaXZlbHkgcmVjZWl2ZSBhIGNs b3NlLg0KV2hlbiB0aGV5IGFjdGl2ZWx5ICJmYWlsIHRoZSBjb25uZWN0aW9uIiwgSSBoYXZlIG5l dmVyIHNlZW4gdGhlbSB0byBkbyBhIFdTIGNsb3NlIGhhbmRzaGFrZS4NCg0KPiA+IC0gTm90ZSB0 aGF0IHRoaXMgaXMgc29tZXdoYXQgYW5ub3VuY2VkIG9uIHRoZSB3ZWIgc2l0ZTogdGhlIHN1aXRl DQo+ID4gc3RpbGwgbGFja3MgaW4gMiBhcmVhczogVVRGLTggYW5kIE9wZW4vQ2xvc2UgSGFuZHNo YWtlIGhhbmRsaW5nDQo+IA0KPiBBbmQgSVB2NiBzdXBwb3J0IDspDQoNClVuZm9ydHVuYXRlbHks IHRoYXQgaXMgYW4gIm9uZ29pbmcgVHdpc3RlZCBpc3N1ZSI6DQoNCmh0dHA6Ly90d2lzdGVkbWF0 cml4LmNvbS90cmFjL3RpY2tldC8zMDE0DQpodHRwOi8vdHdpc3RlZG1hdHJpeC5jb20vdHJhYy93 aWtpL0lQdjYNCg0KV2hlbiBUd2lzdGVkIHN1cHBvcnRzIElQdjYsIHRoZSB0ZXN0IHN1aXRlIHdp bGwuIFVudGlsIHRoZW4sIEkgY2FuJ3QgZG8gYW55dGhpbmcsIEknbSB0b3RhbGx5IG91dCBvZiBx dWV1ZSBzcGFjZSBmb3IgYW55dGhpbmcgbmV3IC4uDQoNCg== From ibc@aliax.net Fri Aug 26 10:22: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 4015621F8C3D for ; Fri, 26 Aug 2011 10:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikRoK+XtmaNW for ; Fri, 26 Aug 2011 10:22:30 -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 68A4A21F8515 for ; Fri, 26 Aug 2011 10:22:30 -0700 (PDT) Received: by qwc23 with SMTP id 23so2653976qwc.31 for ; Fri, 26 Aug 2011 10:23:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.101.34 with SMTP id a34mr1868564qco.8.1314379426779; Fri, 26 Aug 2011 10:23:46 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 10:23:46 -0700 (PDT) In-Reply-To: References: <634914A010D0B943A035D226786325D422C0DFC8C2@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 26 Aug 2011 19:23:46 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 17:22:31 -0000 2011/8/26 I=C3=B1aki Baz Castillo : > 2011/8/26 Tobias Oberstein : >> Would be helpful if you could publish a link to the generated reports >> (for me to look into the wirelogs to see what happens in the cases >> you mentioned) > > Sure, I'm running the test again with the "hack" dissabled (the "hack" > means not sending valid close frame before closing the TCP > connection). Let me a minutes and I will upload it to my server. Ok, the issue is "fixed". I explain the "problem": When my WS servers detects a WS protocol error it sends a close frame and waits for 1.5 seconds before clossing the TCP connection (in order to let the WS client to reply its close frame). But AutoBahn test client does not wait too much and expects that the server must close the TCP connection before 1 second. So I've decreased such waiting time to 0.8 seconds and now there are no test failures. BTW the results of my server are available here: http://oversip.net/public/oversip/websocket-autobahn-results/ The WS server is a built on Ruby using EventMachine (similar to Python's Twister), running in a laptop Pentium(R) Dual-Core CPU T4400 @ 2.20GHz. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Aug 26 10:29: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 A789721F8C1C for ; Fri, 26 Aug 2011 10:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ftLfahun9HF for ; Fri, 26 Aug 2011 10:29:29 -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 E662221F8BD5 for ; Fri, 26 Aug 2011 10:29:28 -0700 (PDT) Received: by qwc23 with SMTP id 23so2659365qwc.31 for ; Fri, 26 Aug 2011 10:30:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.14 with SMTP id q14mr1845621qce.122.1314379845287; Fri, 26 Aug 2011 10:30:45 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 10:30:45 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D422C0DFC90A@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422C0DFC8BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0DFC90A@EXVMBX020-12.exch020.serverdata.net> Date: Fri, 26 Aug 2011 19:30:45 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" Subject: Re: [hybi] About Autobahn test server: why must the server close TCP connection without sending close frame first??? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 17:29:29 -0000 2011/8/26 Tobias Oberstein : >> Buth nothing wrong occurs if Chrome/FF receives a close frame, they just >> behave correctly and send a close reply. > > Yes, when they passively receive a close. > When they actively "fail the connection", I have never seen them to do a = WS close handshake. Aha, ok, so they must receive something wrong at WS level and then they would just close TCP instead of sending a WS close frame. Understood, I will test it. >> > - Note that this is somewhat announced on the web site: the suite >> > still lacks in 2 areas: UTF-8 and Open/Close Handshake handling >> >> And IPv6 support ;) > > Unfortunately, that is an "ongoing Twisted issue": > > http://twistedmatrix.com/trac/ticket/3014 > http://twistedmatrix.com/trac/wiki/IPv6 > > When Twisted supports IPv6, the test suite will. Until then, I can't do a= nything, I'm totally out of queue space for anything new .. Don't worry, the very same occurs to me in Ruby EventMachine :) --=20 I=C3=B1aki Baz Castillo From Gabriel.Montenegro@microsoft.com Fri Aug 26 11:55: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 A882F21F8515 for ; Fri, 26 Aug 2011 11:55:51 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sk4qD-vUYJEr for ; Fri, 26 Aug 2011 11:55:50 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by ietfa.amsl.com (Postfix) with ESMTP id B5A7A21F84FB for ; Fri, 26 Aug 2011 11:55:50 -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; Fri, 26 Aug 2011 11:57:07 -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.323.7; Fri, 26 Aug 2011 11:57:07 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.133]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0323.007; Fri, 26 Aug 2011 11:57:07 -0700 From: Gabriel Montenegro To: Peter Saint-Andre , Greg Wilkins Thread-Topic: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) Thread-Index: AQHMWEaeq/bfoxwWH0mV07f4/Gq6jpUvkzSA Date: Fri, 26 Aug 2011 18:57:06 +0000 Message-ID: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: <4E440808.5030907@stpeter.im> 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 18:55:51 -0000 U2FsIGFuZCBJLCBpbiBjb25zdWx0YXRpb24gd2l0aCB0aGUgZWRpdG9ycyBhbmQgUGV0ZXIgaGF2 ZSBhcnJpdmVkIGF0IGEgQ29uc2Vuc3VzIGNhbGwgb24gIzE6DQoNCgktIFJlbW92ZSBlcnJvciBj b2RlIDEwMDQgIkZyYW1lIFRvbyBMYXJnZSIuDQoNClRoZSBlZGl0b3JzIHdpbGwgcmVtb3ZlIHVz ZSBvZiB0aGlzIGNvZGUgaW4gZHJhZnQgMTMuIEF0IHRoZSBzYW1lIHRpbWUsIHRoZXkgd2lsbCBh ZGQgY2xhcmlmeWluZyB0ZXh0LiANCg0KV2Ugbm90ZSB0aGVyZSBpcyBpbnRlcmVzdCBhbmQgdGhl IHBvc3NpYmlsaXR5IG9mIGludHJvZHVjaW5nIHJlbGF0ZWQgZnVuY3Rpb25hbGl0eSwgZXJyb3Ig Y29kZXMsIGV0Yy4sIGluIHRoZSBmdXR1cmUsIHBlcmhhcHMgaW4gY29uanVuY3Rpb24gd2l0aCBt dWx0aXBsZXhpbmcgc3VwcG9ydC4NCg0KVGhhbmtzLA0KDQpHYWJyaWVsDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBQZXRlciBTYWludC1BbmRy ZQ0KPiBTZW50OiAxMSBBdWd1c3QsIDIwMTEgMDk6NDkNCj4gVG86IEdyZWcgV2lsa2lucw0KPiBD YzogaHliaUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbaHliaV0gQ09OU0VOU1VTIENBTEwgKHdhczpS ZTogV2ViU29ja2V0IEZyYW1lIFNpemUgYW5kIGxhdGVuY3kpDQo+IA0KPiBUaGlzIGlzIHlvdXIg QXJlYSBEaXJlY3RvciBzcGVha2luZy4gSSB3b3VsZCB2ZXJ5IG11Y2ggbGlrZSB0byBpc3N1ZSBh biBJRVNHIGJhbGxvdA0KPiBmb3Igb3VyIGJhc2UgZG9jdW1lbnQgaW4gdGhlIG5lYXIgZnV0dXJl LiBUaGUgV0cgbmVlZHMgdG8gZGVjaWRlIHRoaXMgbWF0dGVyIGluDQo+IG9yZGVyIGZvciB1cyB0 byBwcm9jZWVkLiBTZWUgYmVsb3cgZm9yIGRldGFpbHMuDQo+IA0KPiBPbiA4LzExLzExIDc6MzMg QU0sIEdyZWcgV2lsa2lucyB3cm90ZToNCj4gPiBPbiAxMSBBdWd1c3QgMjAxMSAxOTo1NSwgIkFu ZHkgR3JlZW4gKOael+WuieW7uCkiIDxhbmR5QHdhcm1jYXQuY29tPg0KPiB3cm90ZToNCj4gPj4g VGhlIGd1eXMgd2hvIGxpa2UgZnJhbWUgbXR1IHBsYW4gdG8gY3JlYXRlIGltcGxlbWVudGF0aW9u cyB3aGljaA0KPiA+PiBicmVhayBpZiB5b3Ugc2VuZCB0aGVtIGxlZ2FsIGZyYW1lcyBiaWdnZXIg dGhhbiBzb21lIHNpemUgdGhleSBsaWtlZA0KPiA+PiB3aGVuIHRoZXkgd3JvdGUgdGhlIGNvZGUu IFNvIHRoZXkgd2lsbCBjcmVhdGUgYW4gaW1wbGVtZW50YXRpb24gd2hpY2gNCj4gY2Fubm90IGNv cGUgd2l0aCBmcmFtZXMgYWJvdmUgYSBjZXJ0YWluIHNpemUuDQo+ID4NCj4gPiBDYW4geW91IHBs ZWFzZSB0cnkgdG8gYmUgYSBsaXR0bGUgbGVzcyBpbnN1bHRpbmcgYW5kIGRpc21pc3NpdmUgb2Yg dGhlDQo+ID4gdmlld3Mgb2Ygb3RoZXJzIHRoYXQgeW91IGRvbid0IGFncmVlIHdpdGguICBZb3Vy IHJlcHJlc2VudGF0aW9uIG9mIHRoZQ0KPiA+IG1vdGl2YXRpb25zIG9mICJ0aGUgZ3V5cyIgYWR2 b2NhdGVkIGEgZGVjbGFyYXRpb24gb2YgbWF4IGZyYW1lIGxpbWl0DQo+ID4gYXJlIGluY29ycmVj dC4NCj4gPg0KPiA+IFlvdSBhcHBlYXIgdG8gYmUgYXJndWluZyBhZ2FpbnN0IHRoZSBleGlzdGVu Y2Ugb2YgZnJhbWUgc2l6ZSBsaW1pdHMsDQo+ID4gd2hlbiB3aGF0IGlzIGJlaW5nIHByb3Bvc2Vk IGlzIHNpbXBseSB0aGUgZGVjbGFyYXRpb24gYSBsaW1pdCBJRiBpdA0KPiA+IGV4aXN0cywgd2hp Y2ggaXQgbWF5IGRvIGZvciBhIG51bWJlciBvZiByZWFzb25zIChpbmNsdWRpbmcgYnV0IG5vdA0K PiA+IGxpbWl0ZWQgdG8gc2ltcGxlIGltcGxlbWVudGF0aW9ucykgYW5kIHRoYXQgaXMgYWxsb3dl ZCB0byBleGlzdCBieSB0aGUNCj4gPiBleGlzdGVuY2Ugb2YgdGhlIGZyYW1lLXRvby1sYXJnZSBj bG9zZSBzdGF0dXMuDQo+ID4NCj4gPiBJIHdvdWxkIHVuZGVyc3RhbmQgeW91ciBwb3NpdGlvbiBi ZXR0ZXIgaWYgeW91IHdlcmUgYWR2b2NhdGluZyB0aGUNCj4gPiByZW1vdmFsIG9mIGZyYW1lLXRv by1sYXJnZSBlcnJvciwgYnV0IHlvdSd2ZSBhbHNvIGFja25vd2xlZGdlZCB0aGF0DQo+ID4gdGhl cmUgYXJlIHJlYXNvbnMgdG8gbGltaXQgZnJhbWUgc2l6ZSwgYnV0IHRoYXQgaXQgc2hvdWxkIGJl DQo+ID4gZXh0ZW5zaW9ucyB0aGF0IGRvIGl0LiAgICAgSG93ZXZlciBJIGZpbmQgaXQgYSBjb25m dXNlZCBzaXR1YXRpb24gdG8NCj4gPiBhZHZvY2F0ZSB0aGF0IG11bHRpcGxlIGV4dGVuc2lvbnMg d2lsbCBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQgZnJhbWUNCj4gPiBzaXplIGxpbWl0YXRpb24g bWVjaGFuaXNtcyB0aGF0IHdpbGwgdWx0aW1hdGVseSBiZSBwb2xpY2VkIGJ5IGENCj4gPiBmcmFt ZS10b28tbGFyZ2UgZXJyb3IgbWVjaGFuaXNtIGluIHRoZSBiYXNlIHByb3RvY29sIC0gd2hpY2gg ZG9lcyBub3QNCj4gPiBrbm93IHdoYXQgdGhlIGZyYW1lIGxpbWl0IGlzLg0KPiANCj4gQXBwYXJl bnRseSB0aGVyZSBpcyBhIGRpc2Nvbm5lY3QgaW4gdGhlIHNwZWNpZmljYXRpb246IGFzIGN1cnJl bnRseSB3cml0dGVuLCBhbg0KPiBpbXBsZW1lbnRhdGlvbiBjYW4gcmVqZWN0IGEgZnJhbWUgYmVj YXVzZSBpdCBpcyB0b28gYmlnIChlcnJvciBjb2RlIDEwMDQpLCBidXQgaXQNCj4gY2FuJ3Qgc2ln bmFsIGl0cyBtYXhpbXVtIGZyYW1lIHNpemUuDQo+IA0KPiBUaGVyZWZvcmUsIGFzIHlvdXIgQXJl YSBEaXJlY3RvciwgSSBhbSByZXF1ZXN0aW5nIGEgY29uc2Vuc3VzIGNhbGwgb24gdGhlDQo+IGZv bGxvd2luZyBhbHRlcm5hdGl2ZS4NCj4gDQo+IDEuIFJlbW92ZSBlcnJvciBjb2RlIDEwMDQgIkZy YW1lIFRvbyBMYXJnZSIuDQo+IA0KPiBvcg0KPiANCj4gMi4gUmV0YWluIGVycm9yIGNvZGUgMTAw NCwgYWRkIGFuIE9QVElPTkFMIHdheSBmb3IgYW4gZW50aXR5IHRvIHNpZ25hbCBpdHMNCj4gbWF4 aW11bSBmcmFtZSBzaXplLCBhbmQgc3BlY2lmeSB0aGF0IGFuIGltcGxlbWVudGF0aW9uIFNIT1VM RCBOT1Qgc2VuZA0KPiBmcmFtZXMgbGFyZ2VyIHRoYW4gdGhlIG1heGltdW0gZnJhbWUgc2l6ZSBz aWduYWxsZWQgYnkgaXRzIHBlZXIuDQo+IA0KPiBQbGVhc2UgcmVwbHkgdG8gdGhpcyBjb25zZW5z dXMgY2FsbCBieSB0aGUgY2xvc2Ugb2YgYnVzaW5lc3MgbmV4dCBXZWRuZXNkYXksDQo+IEF1Z3Vz dCAxNywgMjAxMS4gV2hlbiB5b3UgcmVwbHksIHBsZWFzZSBpbmRpY2F0ZSB5b3VyIHByZWZlcmVu Y2UgKCIxIiBvciAiMiIpDQo+IGFuZCBwcm92aWRlIGEgYnJpZWYgcmVhc29uLCBpZiBhcHByb3By aWF0ZS4NCj4gDQo+IFRoYW5rIHlvdS4NCj4gDQo+IFBldGVyDQo+IA0KPiAtLQ0KPiBQZXRlciBT YWludC1BbmRyZQ0KPiBodHRwczovL3N0cGV0ZXIuaW0vDQo+IA0KPiANCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gaHliaSBtYWlsaW5nIGxpc3QN Cj4gaHliaUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2h5YmkNCg== From ibc@aliax.net Fri Aug 26 12:19: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 A79E621F8C87 for ; Fri, 26 Aug 2011 12:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.645 X-Spam-Level: X-Spam-Status: No, score=-2.645 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrReAA9VHLE1 for ; Fri, 26 Aug 2011 12:19:10 -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 24A5E21F8C85 for ; Fri, 26 Aug 2011 12:19:10 -0700 (PDT) Received: by qyk35 with SMTP id 35so2427144qyk.10 for ; Fri, 26 Aug 2011 12:20:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.22.83 with SMTP id m19mr1959053qcb.236.1314386426756; Fri, 26 Aug 2011 12:20:26 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Fri, 26 Aug 2011 12:20:26 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> Date: Fri, 26 Aug 2011 21:20:26 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Gabriel Montenegro Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL (was:Re: WebSocket Frame Size and latency) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 19:19:10 -0000 2011/8/26 Gabriel Montenegro : > Sal and I, in consultation with the editors and Peter have arrived at a C= onsensus call on #1: > > =C2=A0 =C2=A0 =C2=A0 =C2=A0- Remove error code 1004 "Frame Too Large". > > The editors will remove use of this code in draft 13. At the same time, t= hey will add clarifying text. > > We note there is interest and the possibility of introducing related func= tionality, error codes, etc., in the future, perhaps in conjunction with mu= ltiplexing support. Will the core draft include some way to negotiate max frame size (and maybe also max message size)? --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Fri Aug 26 13:57: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 44DA721F8B74 for ; Fri, 26 Aug 2011 13:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnItqoGhC2xw for ; Fri, 26 Aug 2011 13:57:25 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B487721F8B6B for ; Fri, 26 Aug 2011 13:57:25 -0700 (PDT) Received: from dhcp-64-101-72-178.cisco.com (unknown [64.101.72.178]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A8B69411C7; Fri, 26 Aug 2011 15:01:06 -0600 (MDT) Message-ID: <4E580901.4000009@stpeter.im> Date: Fri, 26 Aug 2011 14:58:41 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "hybi@ietf.org" , Gabriel Montenegro , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Aug 2011 20:57:26 -0000 On 8/26/11 1:20 PM, Iñaki Baz Castillo wrote: > 2011/8/26 Gabriel Montenegro : >> Sal and I, in consultation with the editors and Peter have arrived at a Consensus call on #1: >> >> - Remove error code 1004 "Frame Too Large". >> >> The editors will remove use of this code in draft 13. At the same time, they will add clarifying text. >> >> We note there is interest and the possibility of introducing related functionality, error codes, etc., in the future, perhaps in conjunction with multiplexing support. > > Will the core draft include some way to negotiate max frame size (and > maybe also max message size)? Based on my discussions with the chairs and editors, I would say that any such parameter negotiation feature is out of scope for the WS 1.0 specification we are all working hard to finish as soon as possible. Perhaps after this community has some experience with WS 1.0 it will find the energy to work on WS 1.1 a few years from now. Because I think iterative development is a good thing, I would welcome such an effort (although I won't be your Area Director at that point). Peter -- Peter Saint-Andre https://stpeter.im/ From gregw@intalio.com Fri Aug 26 18:57: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 B95AA21F855F for ; Fri, 26 Aug 2011 18:57:34 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ka6y9DItySH for ; Fri, 26 Aug 2011 18:57:34 -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 1668021F8829 for ; Fri, 26 Aug 2011 18:57:33 -0700 (PDT) Received: by vws12 with SMTP id 12so869763vws.31 for ; Fri, 26 Aug 2011 18:58:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.171 with SMTP id a11mr1695268vdj.313.1314410331298; Fri, 26 Aug 2011 18:58:51 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Fri, 26 Aug 2011 18:58:51 -0700 (PDT) In-Reply-To: <4E580901.4000009@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> Date: Sat, 27 Aug 2011 11:58:51 +1000 Message-ID: From: Greg Wilkins To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Gabriel Montenegro Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 01:57:34 -0000 On 27 August 2011 06:58, Peter Saint-Andre wrote: > On 8/26/11 1:20 PM, I=F1aki Baz Castillo wrote: >> Will the core draft include some way to negotiate max frame size (and >> maybe also max message size)? > > Based on my discussions with the chairs and editors, I would say that > any such parameter negotiation feature is out of scope for the WS 1.0 > specification we are all working hard to finish as soon as possible. > Perhaps after this community has some experience with WS 1.0 it will > find the energy to work on WS 1.1 a few years from now. Because I think > iterative development is a good thing, I would welcome such an effort > (although I won't be your Area Director at that point). Can we at least have clarification on what close code should be used if the implementation receives a message (NOT FRAME) that it cannot handle due to some resource limitation (perhaps the message is too large, disk full, OOM exception, server too busy, etc.). 1000 is wrong because it is not successful 1001 going away is not really the right as the endpoint is still there 1002 is wrong because it is not a protocol error 1003 for can't handle data type is a possible. Maybe change the description to just that the message cannot be handled for unspecified reasons. I'm happy with some generic "can't handle the messages you're sending me" close code rather than a specific too-large code. cheers From salvatore.loreto@ericsson.com Sat Aug 27 01:14: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 96AA421F8A55 for ; Sat, 27 Aug 2011 01:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.579 X-Spam-Level: X-Spam-Status: No, score=-106.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKngyKcTjj1x for ; Sat, 27 Aug 2011 01:14:44 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 7D2ED21F8853 for ; Sat, 27 Aug 2011 01:14:44 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-d8-4e58a7c00971 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 3D.4F.20773.0C7A85E4; Sat, 27 Aug 2011 10:16:00 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Sat, 27 Aug 2011 10:16:00 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 67E7E24D8 for ; Sat, 27 Aug 2011 11:16:00 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 21B78511B9 for ; Sat, 27 Aug 2011 11:16:00 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id A9F45510D3 for ; Sat, 27 Aug 2011 11:15:59 +0300 (EEST) Message-ID: <4E58A7BE.4050907@ericsson.com> Date: Sat, 27 Aug 2011 10:15:58 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.20) Gecko/20110804 Thunderbird/3.1.12 MIME-Version: 1.0 To: "hybi@ietf.org" 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: [hybi] HyBi Meeting in Taipei: pool X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 08:14:45 -0000 Hi there, next IETF82 will be in Taipei (November 13-18, 2011): at that point we will be done with the base spec (TheWebSocketProtocol). Gabriel and I want to check with the WG whether there is enough interest/energy to meet during the IETF82 in Taipei to work on extensions (e.g. MUX), or people think we can just discuss them on the mailing list for the time being and meet face to face during IETF83 in Paris. Please let we know your opinion as soon as possible, as the Cutoff date for requests to schedule Working Group meetings is on September 26th. cheers /Sal -- Salvatore Loreto www.sloreto.com From ifette@google.com Sat Aug 27 06:57: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 0DE7821F8A7D for ; Sat, 27 Aug 2011 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.843 X-Spam-Level: X-Spam-Status: No, score=-104.843 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CrYBKuf1ixkl for ; Sat, 27 Aug 2011 06:57:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1A06D21F8A1A for ; Sat, 27 Aug 2011 06:57:01 -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 p7RDwJ3h016714 for ; Sat, 27 Aug 2011 06:58:19 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314453499; bh=sRoUcjCTSH9Hg+JiUtenjz4kNrs=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=D8uZ5qMHaZPE6anvhormKN3sGhBFq0pqS2qQa3m6Gk//tvZ8IzjbTM3ZCFCw6h0na Cn+fpW4piWDtqqdlNLbkQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=sv3ul3dhUXbq/BpSRi2Y1Pv0Q2AgJXKP987l9hgl23GKt98csMnZ2LpwYWXaldgpZ KnrMEgEoGOIHURk3xZS8A== Received: from gxk3 (gxk3.prod.google.com [10.202.11.3]) by wpaz29.hot.corp.google.com with ESMTP id p7RDwIDm005771 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 27 Aug 2011 06:58:18 -0700 Received: by gxk3 with SMTP id 3so101331gxk.20 for ; Sat, 27 Aug 2011 06:58:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ETCI6rXxmUD/Q5X15ugLdjUAoUiM9PxPE109Ae6FEzg=; b=wpwq/+YbqCSci1TKYD8m+QkkHApg3fob+Y2AWKSLMSLKSh+c1tTl1xjEVVS0V5stcj VvZ7TIpkF0NfV7IZgTiQ== Received: by 10.42.149.65 with SMTP id u1mr2404557icv.50.1314453497911; Sat, 27 Aug 2011 06:58:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.42.149.65 with SMTP id u1mr2404551icv.50.1314453497830; Sat, 27 Aug 2011 06:58:17 -0700 (PDT) Received: by 10.231.35.73 with HTTP; Sat, 27 Aug 2011 06:58:17 -0700 (PDT) In-Reply-To: <4E58A7BE.4050907@ericsson.com> References: <4E58A7BE.4050907@ericsson.com> Date: Sat, 27 Aug 2011 06:58:17 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Salvatore Loreto Content-Type: multipart/alternative; boundary=90e6ba613be0cfdbf804ab7d0d62 X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] HyBi Meeting in Taipei: pool X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ifette@google.com List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 13:57:02 -0000 --90e6ba613be0cfdbf804ab7d0d62 Content-Type: text/plain; charset=UTF-8 I would love to, but I've got a wedding in San Diego on 11/12 and then I'm supposed to give a talk in Berlin on 11/19. So, if the meeting were Wednesday there's a chance I could make it, but it's otherwise rather difficult logistically. I would certainly be interested though to work on MUX etc. -Ian On Sat, Aug 27, 2011 at 1:15 AM, Salvatore Loreto < salvatore.loreto@ericsson.com> wrote: > Hi there, > > next IETF82 will be in Taipei (November 13-18, 2011): > at that point we will be done with the base spec (TheWebSocketProtocol). > > Gabriel and I want to check with the WG whether there is enough > interest/energy to meet during > the IETF82 in Taipei to work on extensions (e.g. MUX), > or people think we can just discuss them on the mailing list for the time > being and meet face to face > during IETF83 in Paris. > > Please let we know your opinion as soon as possible, > as the Cutoff date for requests to schedule Working Group meetings is on > September 26th. > > cheers > /Sal > > -- > Salvatore Loreto > www.sloreto.com > > ______________________________**_________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/**listinfo/hybi > --90e6ba613be0cfdbf804ab7d0d62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I would love to, but I've got a wedding in San Diego on 11/12 and then = I'm supposed to give a talk in Berlin on 11/19. So, if the meeting were= Wednesday there's a chance I could make it, but it's otherwise rat= her difficult logistically. I would certainly be interested though to work = on MUX etc.

-Ian

On Sat, Aug 27, 2011 = at 1:15 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote= :
Hi there,

next IETF82 will be in Taipei (November 13-18, 2011):
at that point we will be done with the base spec (TheWebSocketProtocol).
Gabriel and I want to check with the WG whether there is enough interest/en= ergy to meet during
the IETF82 in Taipei to work on extensions (e.g. MUX),
or people think we can just discuss them on the mailing list for the time b= eing and meet face to face
during IETF83 in Paris.

Please let we know your opinion as soon as possible,
as the Cutoff date for requests to schedule Working Group meetings is on Se= ptember 26th.

cheers
/Sal

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

--90e6ba613be0cfdbf804ab7d0d62-- From andy@warmcat.com Sat Aug 27 07:19: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 3855C21F8A51 for ; Sat, 27 Aug 2011 07:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.066, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vrjmp3fHPOeK for ; Sat, 27 Aug 2011 07:19:48 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id A58E421F8834 for ; Sat, 27 Aug 2011 07:19:48 -0700 (PDT) Message-ID: <4E58FD4E.6060307@warmcat.com> Date: Sat, 27 Aug 2011 22:21:02 +0800 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Salvatore Loreto References: <4E58A7BE.4050907@ericsson.com> In-Reply-To: <4E58A7BE.4050907@ericsson.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] HyBi Meeting in Taipei: pool X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 14:19:49 -0000 On 08/27/2011 04:15 PM, Somebody in the thread at some point said: > Hi there, > > next IETF82 will be in Taipei (November 13-18, 2011): > at that point we will be done with the base spec (TheWebSocketProtocol). > > Gabriel and I want to check with the WG whether there is enough > interest/energy to meet during > the IETF82 in Taipei to work on extensions (e.g. MUX), > or people think we can just discuss them on the mailing list for the > time being and meet face to face > during IETF83 in Paris. > > Please let we know your opinion as soon as possible, > as the Cutoff date for requests to schedule Working Group meetings is on > September 26th. Unless something else comes up to conflict, since I now live in Taipei that sounds like a great idea to me. -Andy From ibc@aliax.net Sat Aug 27 09:25: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 D45D021F8B09 for ; Sat, 27 Aug 2011 09:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2c++n+gQvjI for ; Sat, 27 Aug 2011 09:25:02 -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 C584F21F87E2 for ; Sat, 27 Aug 2011 09:25:01 -0700 (PDT) Received: by qwc23 with SMTP id 23so3091630qwc.31 for ; Sat, 27 Aug 2011 09:26:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.85 with SMTP id h21mr3386604qci.46.1314462378919; Sat, 27 Aug 2011 09:26:18 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Sat, 27 Aug 2011 09:26:18 -0700 (PDT) In-Reply-To: <4E580901.4000009@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> Date: Sat, 27 Aug 2011 18:26:18 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Gabriel Montenegro , Greg Wilkins Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:25:02 -0000 2011/8/26 Peter Saint-Andre : > Based on my discussions with the chairs and editors, I would say that > any such parameter negotiation feature is out of scope for the WS 1.0 > specification we are all working hard to finish as soon as possible. > Perhaps after this community has some experience with WS 1.0 it will > find the energy to work on WS 1.1 a few years from now. Because I think > iterative development is a good thing, I would welcome such an effort > (although I won't be your Area Director at that point). Just an idea coming to my mind: 1) Client sends the HTTP GET: GET /lalala HTTP/1.1 Upgrade: websocket Connection: Upgrade Host: ws.domain.org Sec-WebSocket-Origin: http://www.domain.org Sec-WebSocket-Protocol: foo Sec-WebSocket-Key: USS3+Z6mzQg327mqqUabJw=3D=3D Sec-WebSocket-Version: 8 Sec-WebSocket-Max-Frame-Out: 65536 Sec-WebSocket-Max-Frame-In: 65536 - Sec-WebSocket-Max-Frame-Out means the max frame size the client could send to the server. - Sec-WebSocket-Max-Frame-In means the max frame size the client accepts from the server. 2) An intermediary (WOOW, I'm speaking about intermediaries!!!) can modify (or append if not present) those two headers. In case of modifying them, it can only decrease values. So let's suppose an intermediary receives the above GET and decides to decrease bot values, and sends the GET to the WS server with these headers modified: Sec-WebSocket-Max-Frame-Out: 32768 Sec-WebSocket-Max-Frame-In: 32768 3) The WS server receives the GET, inspects such values and, optionally, can decrease them (never increase), and MUST add both headers to the 101 reply (even if they are not present in the GET request), so it replies: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: af8bl6g+YNEpwsc34843OKbe9Fk=3D Sec-WebSocket-Protocol: foo Sec-WebSocket-Max-Frame-Out: 16384 Sec-WebSocket-Max-Frame-In: 32768 4) The intermediary receives the 101 and ensures that those values are not higher that the values it previously set in the GET request. 5) The client receives the 101 and already knows the max frame size it can send to the server, and the max frame size it could receive from the server. So there is a frame size negotiation mechanism that also makes "intermediaries" happy. Opinions? NOTE: instead of two headers, there could be a single one as follows: Sec-WebSocket-Max-Frame: 16384 / 32768 so first value is the client->server max frame size and second value is the server->client max frame size. --=20 I=C3=B1aki Baz Castillo From jat@google.com Sat Aug 27 09:32:47 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 736C621F8783 for ; Sat, 27 Aug 2011 09:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.733 X-Spam-Level: X-Spam-Status: No, score=-105.733 tagged_above=-999 required=5 tests=[AWL=-0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XCvxo77m4X6o for ; Sat, 27 Aug 2011 09:32:47 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88C21F8772 for ; Sat, 27 Aug 2011 09:32:44 -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 p7RGY3p7012347 for ; Sat, 27 Aug 2011 09:34:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314462843; bh=hrZMBm2JE06r5ifaSf9zRuPxYnI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BXpBLk/yBjuIYbFUOu1bzKUuQtQbrOoGvGLZC0s0D2p8aS8r7F+tGTjopBIavBkuX aaoUl/t6OwSaIZqrOtwXQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=k8SfFFPxk9EBD4MDzoSQ/uvvbBTaW94SLf37MlG/eKOg0xcrY+O4Mq9tH/h7DZsUM BderN3LzaJ3qJDMxkR56A== Received: from ywm3 (ywm3.prod.google.com [10.192.13.3]) by wpaz29.hot.corp.google.com with ESMTP id p7RGY2Ac014020 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 27 Aug 2011 09:34:02 -0700 Received: by ywm3 with SMTP id 3so4481071ywm.2 for ; Sat, 27 Aug 2011 09:34:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=iA0pZpL/UBUN7ocF3qNIkAOXBRbXaDcCBaHny8wEjvg=; b=i6DzNllVZ3L/LlZyv0A0U7/hKuMlSptpmKuMaaoeXYz5/PPOxuausfpSvF6vp/E3H1 tAL5UToO63B/ZoMYsl2Q== Received: by 10.151.59.14 with SMTP id m14mr3450104ybk.401.1314462842278; Sat, 27 Aug 2011 09:34:02 -0700 (PDT) Received: by 10.151.59.14 with SMTP id m14mr3450091ybk.401.1314462842124; Sat, 27 Aug 2011 09:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Sat, 27 Aug 2011 09:33:42 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> From: John Tamplin Date: Sat, 27 Aug 2011 12:33:42 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=00151750ebe4c6798404ab7f3adc X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:32:47 -0000 --00151750ebe4c6798404ab7f3adc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2011 at 12:26 PM, I=C3=B1aki Baz Castillo w= rote: > Just an idea coming to my mind: > How is this anything more than a potential way of implementing option #2, which was rejected? --=20 John A. Tamplin Software Engineer (GWT), Google --00151750ebe4c6798404ab7f3adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Aug 27, 2011 at 12:26 PM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
Just an idea coming to my mind:

How is = this anything more than a potential way of implementing option #2, which wa= s rejected?=C2=A0

--
John A. Tamplin
Softw= are Engineer (GWT), Google
--00151750ebe4c6798404ab7f3adc-- From ibc@aliax.net Sat Aug 27 09:41: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 EE77021F86AA for ; Sat, 27 Aug 2011 09:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctuwFuRj59Ir for ; Sat, 27 Aug 2011 09:41:19 -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 09CF221F862F for ; Sat, 27 Aug 2011 09:41:18 -0700 (PDT) Received: by qwc23 with SMTP id 23so3096062qwc.31 for ; Sat, 27 Aug 2011 09:42:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.14 with SMTP id q14mr3386888qce.122.1314463358175; Sat, 27 Aug 2011 09:42:38 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Sat, 27 Aug 2011 09:42:38 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> Date: Sat, 27 Aug 2011 18:42:38 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 16:41:20 -0000 2011/8/27 John Tamplin : > On Sat, Aug 27, 2011 at 12:26 PM, I=C3=B1aki Baz Castillo = wrote: >> >> Just an idea coming to my mind: > > How is this anything more than a potential way of implementing option #2, > which was rejected? AFAIK the problem with option #2 is that it does not define a way for including an intermediary in such frame size negotiation (this is what I suppose after reading other related threads). The mechanism I've suggested theorically solves that requirement and allows an intermediary to take active part in the negotiation. With my suggestion, the intermediary can impose its own restrictions so there is no need at all for reassembling frames in the intermediary. NOTE: Of course, an intermediary should not be WS "message" aware. It should work at "transport" level (so just WS frames). Just the endpoint should be WS message/protocol aware. --=20 I=C3=B1aki Baz Castillo From jat@google.com Sat Aug 27 10:17: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 AA81721F876F for ; Sat, 27 Aug 2011 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.731 X-Spam-Level: X-Spam-Status: No, score=-105.731 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti9cL7IKEBuQ for ; Sat, 27 Aug 2011 10:17: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 12DEE21F85C6 for ; Sat, 27 Aug 2011 10:17:05 -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 p7RHINIm004394 for ; Sat, 27 Aug 2011 10:18:24 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314465504; bh=QFWnSqXBtWmTjZzGoWAjgRLgYgg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=KSaMjZn2nSwLohR3Wn3cP0OlkZDZZCwZ4L1d7sczeRR+b0gxNRjrhLiAmxQDipxXp krYLk2hvuhZpyVsuBq19Q== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=PGy30npviVSXZZbrkis7fZdgh+JDDXHM2nuAzMhfvjbf0uINfdQYoUhGEIc4rP8EA b++1u3gQtEMpmR1nXETHA== Received: from yib12 (yib12.prod.google.com [10.243.65.76]) by hpaq7.eem.corp.google.com with ESMTP id p7RHILg1012057 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sat, 27 Aug 2011 10:18:22 -0700 Received: by yib12 with SMTP id 12so3030914yib.24 for ; Sat, 27 Aug 2011 10:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=E+aIahU4UhQEZyZ+bssi5u77CwqWmdYHaR8C65Oef1I=; b=Pm/cAVNs8xWZkeWZ9h+8feVJZ60lXFDkL0oUu4mzay/bmvty5udTLeddvEWu10f8UV CilEkiU+OuJmLheFRg9w== Received: by 10.150.150.34 with SMTP id x34mr3351638ybd.59.1314465501235; Sat, 27 Aug 2011 10:18:21 -0700 (PDT) Received: by 10.150.150.34 with SMTP id x34mr3351630ybd.59.1314465501096; Sat, 27 Aug 2011 10:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Sat, 27 Aug 2011 10:18:01 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> From: John Tamplin Date: Sat, 27 Aug 2011 13:18:01 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd6d02e432cfb04ab7fd930 X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins , Gabriel Montenegro Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 17:17:06 -0000 --000e0cd6d02e432cfb04ab7fd930 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Aug 27, 2011 at 12:42 PM, I=C3=B1aki Baz Castillo w= rote: > AFAIK the problem with option #2 is that it does not define a way for > including an intermediary in such frame size negotiation (this is what > I suppose after reading other related threads). The mechanism I've > suggested theorically solves that requirement and allows an > intermediary to take active part in the negotiation. > Option #2 said peer, which would apply equally to an intermediary terminating the TCP connection as well as the ultimate endpoint. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd6d02e432cfb04ab7fd930 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Aug 27, 2011 at 12:42 PM, I=C3=B1aki Baz= Castillo <ibc@aliax.= net> wrote:
AFAIK the problem with option #2 is that it does not define a way for
including an intermediary in such frame size negotiation (this is what
I suppose after reading other related threads). The mechanism I've
suggested theorically solves that requirement and allows an
intermediary to take active part in the negotiation.
<= br>
Option #2 said peer, which would apply equally to an intermed= iary terminating the TCP connection as well as the ultimate endpoint.=C2=A0=

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd6d02e432cfb04ab7fd930-- From gregw@intalio.com Sat Aug 27 14:58: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 54CC821F8B65 for ; Sat, 27 Aug 2011 14:58:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.775 X-Spam-Level: X-Spam-Status: No, score=-2.775 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SLONV1eYeo1P for ; Sat, 27 Aug 2011 14:58:00 -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 C271321F8B64 for ; Sat, 27 Aug 2011 14:58:00 -0700 (PDT) Received: by vxi29 with SMTP id 29so4371212vxi.31 for ; Sat, 27 Aug 2011 14:59:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.89.146 with SMTP id bo18mr228412vdb.246.1314482360305; Sat, 27 Aug 2011 14:59:20 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Sat, 27 Aug 2011 14:59:20 -0700 (PDT) In-Reply-To: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> Date: Sun, 28 Aug 2011 07:59:20 +1000 Message-ID: From: Greg Wilkins To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= , "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2011 21:58:01 -0000 I=F1aki, As much as I support the declaration of any size limits, I don't think we managed to convince enough people to establish any consensus around that idea in any of the many ways that it could be implemented. The AD has called consensus on #1, so I think we should move on.... for example to consider what standard action to take if the message cannot be handled for reasons including being too large (as per my previous email). cheers From ibc@aliax.net Sun Aug 28 15:38: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 1C8AD21F872A for ; Sun, 28 Aug 2011 15:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4P9UwUopWMKT for ; Sun, 28 Aug 2011 15:38:34 -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 8344B21F8713 for ; Sun, 28 Aug 2011 15:38:34 -0700 (PDT) Received: by qwc23 with SMTP id 23so3521983qwc.31 for ; Sun, 28 Aug 2011 15:39:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.14 with SMTP id q14mr4946334qce.122.1314571196959; Sun, 28 Aug 2011 15:39:56 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Sun, 28 Aug 2011 15:39:56 -0700 (PDT) Date: Mon, 29 Aug 2011 00:39:56 +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] Client offers invalid WS protocols, what must the server do? 101??? 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, 28 Aug 2011 22:38:35 -0000 Hi, the draft (12) says: /subprotocol/ Either a single value representing the subprotocol the server is ready to use or null. The value chosen MUST be derived from the client's handshake, specifically by selecting one of the values from the "Sec-WebSocket-Protocol" field that the server is willing to use for this connection (if any). If the client's handshake did not contain such a header field, or if the server does not agree to any of the client's requested subprotocols, the only acceptable value is null. The absence of such a field is equivalent to the null value (meaning that if the server does not wish to agree to one of the suggested subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| header field in its response). So if the server just supports protocols "aaa" and "bbb" but the client offers "ccc" and "ddd", the above text states that the server must reply 101 without Sec-WebSocket-Protocol header. So then, *what* are the client and the server supposed to speak now?? If the client has ***explicitly*** offered protocols "ccc" and "ddd" and the server does not support them, the server should REJECT the WS handshake, sure, rather than sending a 101. IMHO "501 Not Implemented" could be a good HTTP response for this case. The WebSocket handshake (HTTP GET + 101) is a negotiation between client and server. If the negotiation fails, the WS GET request MUST be rejected rather than accepted. The current text seems to allow ugly JavaScript developers to set a random protocol string (just for funny) in the Websocket JS API for the function "connect(URL, protocols)". Please make it strict. Regards. --=20 I=C3=B1aki Baz Castillo From stpeter@stpeter.im Mon Aug 29 10:07:05 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 66AB321F8AB9 for ; Mon, 29 Aug 2011 10:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JquyMJ6JAYP for ; Mon, 29 Aug 2011 10:07:04 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5A521F8AB8 for ; Mon, 29 Aug 2011 10:07:04 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id E429A4174A; Mon, 29 Aug 2011 11:11:00 -0600 (MDT) Message-ID: <4E5BC78C.5070802@stpeter.im> Date: Mon, 29 Aug 2011 11:08:28 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 17:07:05 -0000 On 8/27/11 3:59 PM, Greg Wilkins wrote: > Iñaki, > > As much as I support the declaration of any size limits, I don't think > we managed to convince enough people to establish any consensus around > that idea in any of the many ways that it could be implemented. > > The AD has called consensus on #1, so I think we should move on.... > for example to consider what standard action to take if the message > cannot be handled for reasons including being too large (as per my > previous email). In side discussions among the working group chairs and document editors during the recent consensus call thread, I suggested one possible compromise: an error condition like "policy-violation" as a catch-all that the server or client could return if it has received data that violates some local service policy (message size, frame size, sending rate, etc.). However, such an error condition would probably lead to a rat hole about designing a general policy framework, and as far as I can see the WG does not have a strong interest in working on such a beast at this time (although it might do so in the future). Peter -- Peter Saint-Andre https://stpeter.im/ From gregw@intalio.com Mon Aug 29 16:21: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 4E6D921F86AB for ; Mon, 29 Aug 2011 16:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.923 X-Spam-Level: X-Spam-Status: No, score=-2.923 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyU9M6qJPCD5 for ; Mon, 29 Aug 2011 16:21:17 -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 9214B21F8BB5 for ; Mon, 29 Aug 2011 16:21:17 -0700 (PDT) Received: by vws12 with SMTP id 12so2904400vws.31 for ; Mon, 29 Aug 2011 16:22:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.173.35 with SMTP id bh3mr667127vdc.380.1314660162594; Mon, 29 Aug 2011 16:22:42 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Mon, 29 Aug 2011 16:22:42 -0700 (PDT) In-Reply-To: <4E5BC78C.5070802@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> Date: Tue, 30 Aug 2011 09:22:42 +1000 Message-ID: From: Greg Wilkins To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 23:21:18 -0000 On 30 August 2011 03:08, Peter Saint-Andre wrote: > In side discussions among the working group chairs and document editors > during the recent consensus call thread, I suggested one possible > compromise: an error condition like "policy-violation" as a catch-all > that the server or client could return if it has received data that > violates some local service policy (message size, frame size, sending > rate, etc.). However, such an error condition would probably lead to a > rat hole about designing a general policy framework, and as far as I can > see the WG does not have a strong interest in working on such a beast at > this time (although it might do so in the future). So I still don't know what close code to use if I get a message that is larger than the application has given me permission to accept? I'm currently sending a 1003, but that is a mis-use according to the description. regards From stpeter@stpeter.im Mon Aug 29 16:23: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 4B0EA21F8C0F for ; Mon, 29 Aug 2011 16:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.518 X-Spam-Level: X-Spam-Status: No, score=-102.518 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0xOgsXy3yS9b for ; Mon, 29 Aug 2011 16:23:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A8BA521F8BDC for ; Mon, 29 Aug 2011 16:23:17 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A1B834174A; Mon, 29 Aug 2011 17:27:15 -0600 (MDT) Message-ID: <4E5C1FBA.9040804@stpeter.im> Date: Mon, 29 Aug 2011 17:24:42 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Aug 2011 23:23:18 -0000 On 8/29/11 5:22 PM, Greg Wilkins wrote: > On 30 August 2011 03:08, Peter Saint-Andre wrote: >> In side discussions among the working group chairs and document editors >> during the recent consensus call thread, I suggested one possible >> compromise: an error condition like "policy-violation" as a catch-all >> that the server or client could return if it has received data that >> violates some local service policy (message size, frame size, sending >> rate, etc.). However, such an error condition would probably lead to a >> rat hole about designing a general policy framework, and as far as I can >> see the WG does not have a strong interest in working on such a beast at >> this time (although it might do so in the future). > > So I still don't know what close code to use if I get a message that > is larger than the application has given me permission to accept? > > I'm currently sending a 1003, but that is a mis-use according to the > description. If we were to pursue that approach, I think we'd need to define a new code for policy violation. Peter -- Peter Saint-Andre https://stpeter.im/ From gregw@intalio.com Mon Aug 29 17:08: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 960DA21F8BA0 for ; Mon, 29 Aug 2011 17:08:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNGQEX7841rj for ; Mon, 29 Aug 2011 17:08:41 -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 074CC21F8B84 for ; Mon, 29 Aug 2011 17:08:40 -0700 (PDT) Received: by vxi29 with SMTP id 29so5910836vxi.31 for ; Mon, 29 Aug 2011 17:10:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.21.109 with SMTP id u13mr725639vde.447.1314663006669; Mon, 29 Aug 2011 17:10:06 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Mon, 29 Aug 2011 17:10:06 -0700 (PDT) Date: Tue, 30 Aug 2011 10:10:06 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Access-Control-Allow-Origin ? 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, 30 Aug 2011 00:08:41 -0000 Now that we have moved to use the normal Origin header, I'm wondering if we should not also use the standard Access-Control-Allow-Origin response. With XHR and CORs the flow goes: 1) Browser sends preflight request with Origin set. 2) Server checks origin sends response with Access-Control-Allow-Origin 3) The client is then the policy enforcement point as it configures the browser sandbox accordingly With WS, the flow is different: 1) Browser sends handshake request with Origin 2) Server checks the origin and is the policy enforcement point. It either accepts or reject the connection. The issue with this is that it means that the server has to have policy enforcement logic within the protocol layer. Typically (google CORS filter) on servers, CORs has been handled by adding a filter in front of the normal resource handling that implements the origin checking and sets the allow header accordingly. The server does not actually enforce the policy. It would be great if we enabled use of these same server side CORs filters with WS. To do so, we only need to require that the handshake 101 response contains the Access-Control-Allow-Origin header for any handshakes that contain an origin header and that the server thinks is cross origin. The client then becomes the policy enforcement point and can close the connection if it does not have this header, but may accept it if it thinks the connection is not cross origin. Note that the server is still able to enforce the policy if it wishes and not accept the connection. So this is really an extra requirement on browser clients, if they send a cross origin connection, they MUST set the origin header in the handshake and they MUST check for a Access-Control-Allow-Origin header in the 101. For non cross origin connections, they can either not send the Origin, or can not check for the allow header. Servers SHOULD send an Access-Control-Allow-Origin header in the 101 if there is an Origin header in the handshake and the origin is Acceptable to them. thoughts? From gregw@intalio.com Mon Aug 29 17:52: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 860F921F8C53 for ; Mon, 29 Aug 2011 17:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.925 X-Spam-Level: X-Spam-Status: No, score=-2.925 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4ocCUD3WOKg for ; Mon, 29 Aug 2011 17:52:25 -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 F3D7C21F8C50 for ; Mon, 29 Aug 2011 17:52:24 -0700 (PDT) Received: by vxi29 with SMTP id 29so5935628vxi.31 for ; Mon, 29 Aug 2011 17:53:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.22.5 with SMTP id z5mr3721676vde.112.1314665630753; Mon, 29 Aug 2011 17:53:50 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Mon, 29 Aug 2011 17:53:50 -0700 (PDT) In-Reply-To: <4E5C1FBA.9040804@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> <4E5C1FBA.9040804@stpeter.im> Date: Tue, 30 Aug 2011 10:53:50 +1000 Message-ID: From: Greg Wilkins To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL 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, 30 Aug 2011 00:52:25 -0000 On 30 August 2011 09:24, Peter Saint-Andre wrote: > On 8/29/11 5:22 PM, Greg Wilkins wrote: >> So I still don't know what close code to use if I get a message that >> is larger than the application has given me permission to accept? >> >> I'm currently sending a 1003, but that is a mis-use according to the >> description. > > If we were to pursue that approach, I think we'd need to define a new > code for policy violation. But we are going to have to pursue some approach. I just did an experiment and send a stream of 32k continuation frames to FF6 and FF7. Both of them just closed the connection after 487 frames. The server just got a broken pipe (and gave a 1006 to the app) and the client got an onclose callback with wasClean set to false. So that looks to both client and server as just a network failure. The client application would be totally justified in just reopening the connection and trying whatever operation it wanted to do again. The server would continue trying to send large messages blissfully unaware that it was breaking clients. I'm not saying that we need a specific close code, but we need something at least to distinguish it from a general network failure. If an endpoint is closing for a specific reason, then just closing the TCP/IP connection making it look like a network failure and many applications will just retry. regards From stpeter@stpeter.im Mon Aug 29 18:32:47 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 8E05D21F85B8 for ; Mon, 29 Aug 2011 18:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TsNeE+HUEhOc for ; Mon, 29 Aug 2011 18:32:47 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id E96E321F85B1 for ; Mon, 29 Aug 2011 18:32:46 -0700 (PDT) Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id A14EE4174A; Mon, 29 Aug 2011 19:36:45 -0600 (MDT) Message-ID: <4E5C3E0B.4020700@stpeter.im> Date: Mon, 29 Aug 2011 19:34:03 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> <4E5C1FBA.9040804@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL 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, 30 Aug 2011 01:32:47 -0000 On 8/29/11 6:53 PM, Greg Wilkins wrote: > On 30 August 2011 09:24, Peter Saint-Andre wrote: >> On 8/29/11 5:22 PM, Greg Wilkins wrote: >>> So I still don't know what close code to use if I get a message that >>> is larger than the application has given me permission to accept? >>> >>> I'm currently sending a 1003, but that is a mis-use according to the >>> description. >> >> If we were to pursue that approach, I think we'd need to define a new >> code for policy violation. > > But we are going to have to pursue some approach. > > I just did an experiment and send a stream of 32k continuation frames > to FF6 and FF7. Both of them just closed the connection after 487 > frames. Yes, that's an example of what I would call a policy violation. > The server just got a broken pipe (and gave a 1006 to the > app) and the client got an onclose callback with wasClean set to > false. So that looks to both client and server as just a network > failure. The client application would be totally justified in just > reopening the connection and trying whatever operation it wanted to do > again. The server would continue trying to send large messages > blissfully unaware that it was breaking clients. > > I'm not saying that we need a specific close code, but we need > something at least to distinguish it from a general network failure. > If an endpoint is closing for a specific reason, then just closing the > TCP/IP connection making it look like a network failure and many > applications will just retry. Just retrying forever seems sub-optimal to me... Peter -- Peter Saint-Andre https://stpeter.im/ From gregw@intalio.com Mon Aug 29 19:02: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 C943321F8B05 for ; Mon, 29 Aug 2011 19:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.926 X-Spam-Level: X-Spam-Status: No, score=-2.926 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5nwQRsYvvdPf for ; Mon, 29 Aug 2011 19:02:24 -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 344DF21F8AFF for ; Mon, 29 Aug 2011 19:02:24 -0700 (PDT) Received: by vws12 with SMTP id 12so2999608vws.31 for ; Mon, 29 Aug 2011 19:03:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.172.174 with SMTP id bd14mr350962vdc.246.1314669830048; Mon, 29 Aug 2011 19:03:50 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Mon, 29 Aug 2011 19:03:49 -0700 (PDT) In-Reply-To: <4E5C3E0B.4020700@stpeter.im> References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> <4E5C1FBA.9040804@stpeter.im> <4E5C3E0B.4020700@stpeter.im> Date: Tue, 30 Aug 2011 12:03:49 +1000 Message-ID: From: Greg Wilkins To: Peter Saint-Andre Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL 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, 30 Aug 2011 02:02:24 -0000 On 30 August 2011 11:34, Peter Saint-Andre wrote: > Just retrying forever seems sub-optimal to me... Totally agree. Good implementations should have backoffs and retry limits. However in the case of message too large, even 1 retry is sub-optimal. It's never going to work and every retry is a waste of bandwidth. Currently we have 1 close code for NORMAL close and then a few specific close code for specific cases. But without a shit-happens close code, the entire mechanism is less worthwhile because we lose the ability to tell the difference between a deliberate close on error and a network failure. We have 1003, which is bad data type. That's kind of a very specific policy failure. Can't we just broaden the description of that to say bad message - ie the message could not be handled for unspecified reasons - might be bad data type, might be too large, etc. The main semantic is like a HTTP 4xx - the failure is something to do with the message and not something to do with the server. cheers From andy@warmcat.com Mon Aug 29 19:04: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 2C88621F8B6D for ; Mon, 29 Aug 2011 19:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.235 X-Spam-Level: X-Spam-Status: No, score=-2.235 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wLz7+K4CSjuX for ; Mon, 29 Aug 2011 19:04:18 -0700 (PDT) Received: from warmcat.com (warmcat.com [87.106.134.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9C87C21F8B6B for ; Mon, 29 Aug 2011 19:04:18 -0700 (PDT) Message-ID: <4E5C4571.2030502@warmcat.com> Date: Tue, 30 Aug 2011 10:05:37 +0800 From: =?UTF-8?B?IkFuZHkgR3JlZW4gKOael+WuieW7uCki?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Greg Wilkins References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> <4E5C1FBA.9040804@stpeter.im> <4E5C3E0B.4020700@stpeter.im> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL 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, 30 Aug 2011 02:04:19 -0000 On 08/30/2011 10:03 AM, Somebody in the thread at some point said: > On 30 August 2011 11:34, Peter Saint-Andre wrote: >> Just retrying forever seems sub-optimal to me... > > Totally agree. Good implementations should have backoffs and retry limits. > > However in the case of message too large, even 1 retry is sub-optimal. > It's never going to work and every retry is a waste of bandwidth. > > Currently we have 1 close code for NORMAL close and then a few > specific close code for specific cases. But without a shit-happens > close code, the entire mechanism is less worthwhile because we lose > the ability to tell the difference between a deliberate close on error > and a network failure. > > We have 1003, which is bad data type. That's kind of a very specific > policy failure. Can't we just broaden the description of that to say > bad message - ie the message could not be handled for unspecified > reasons - might be bad data type, might be too large, etc. The main > semantic is like a HTTP 4xx - the failure is something to do with the > message and not something to do with the server. Sounds pretty reasonable (and cheap) to me. -Andy From Martin.Thomson@commscope.com Tue Aug 30 00:04: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 E9A0E21F8AF1 for ; Tue, 30 Aug 2011 00:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=-0.034, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfQlRxnP6YIy for ; Tue, 30 Aug 2011 00:04:06 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id B151621F8AD2 for ; Tue, 30 Aug 2011 00:04:06 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-35-4e5c8bb7d2b8 Received: from ACDCE7HC2.commscope.com ( [10.86.20.103]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 97.BD.19263.7BB8C5E4; Tue, 30 Aug 2011 02:05:27 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 30 Aug 2011 02:05:26 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 30 Aug 2011 15:05:22 +0800 From: "Thomson, Martin" To: Greg Wilkins , Hybi Date: Tue, 30 Aug 2011 15:05:40 +0800 Thread-Topic: [hybi] Access-Control-Allow-Origin ? Thread-Index: AcxmqS8/NZxjg73qThKS02FW2zCr+AAOfFsA Message-ID: <8B0A9FCBB9832F43971E38010638454F040F1C12AC@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [hybi] Access-Control-Allow-Origin ? 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, 30 Aug 2011 07:04:08 -0000 On 2011-08-30 at 10:10:06, Greg Wilkins wrote: > It would be great if we enabled use of these same server side CORs > filters with WS. To do so, we only need to require that the > handshake 101 response contains the Access-Control-Allow-Origin header=20 > for any handshakes that contain an origin header and that the server > thinks is cross origin. =20 Sounds like a good idea. Consistent with the philosophy of "HTTP before Up= grade". --Martin From len.holgate@gmail.com Tue Aug 30 00:44: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 A81C921F8B5A for ; Tue, 30 Aug 2011 00:44:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wCrM79gPhADR for ; Tue, 30 Aug 2011 00:44:02 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFB8A21F881C for ; Tue, 30 Aug 2011 00:44:01 -0700 (PDT) Received: by wyg8 with SMTP id 8so5274144wyg.31 for ; Tue, 30 Aug 2011 00:45:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=X2LtJfDINJY0fwKLdJZciqzbuDNr88s4wv5NOwKoMKY=; b=CRo9TJKG3DSNF7zo9jv48vYBdeL+vfuRefHcHNfm43mOQD0LDfGr+2VkSoyV0ptc06 1zPw/pMMHZyqmWxrXVLgVlHcaaY09Soe8uu8W8uCyNY0Gbgdz8Uowczm5FPu8UrQR2lp 5d+oVvJW2ELTsoh9ZoyXzcZIgR23qM6CnjzuM= Received: by 10.227.202.209 with SMTP id ff17mr1518631wbb.78.1314690328075; Tue, 30 Aug 2011 00:45:28 -0700 (PDT) Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id fg5sm4388022wbb.6.2011.08.30.00.45.26 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 00:45:27 -0700 (PDT) From: "Len Holgate" To: "'Hybi'" References: <4E47FDB5.6070207@isode.com><4E482192.7050507@gmail.com> Date: Tue, 30 Aug 2011 08:44:54 +0100 Message-ID: <0ba401cc66e8$b7293a40$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: Acxa36Y7tFdwJmHyTHyrwXVIUMlAuQMBy8WA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Subject: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 07:44:02 -0000 Could someone explain the rationale behind how changing the header field for origin from Sec-WebSocket-Origin to Origin in v11 of the draft doesn't require a protocol version change? Surely an implementation of draft 08 which advertises itself as Sec-WebSocket-Version: 8 can now fail to interoperate with an implementation of draft 11 or 12 which also avertises itself as Sec-WebSocket-Version: 8. At the very least, a draft 08 implementation will now incorrectly interpret browser clients (implementing 11 or later) as non browser clients and if there are any draft 08 implementations that use origin specific "access control"... Likewise the Sec-WebSocket-Version change also breaks protocol compatibility in that a draft 08 client would expect the response from the server to include the WebSocket-Version header and a draft 11 server only has to send it if the handshake fails... Len From alexey.melnikov@isode.com Tue Aug 30 02:43: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 93FBE21F8B54 for ; Tue, 30 Aug 2011 02:43:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e+mLANl2ZWiF for ; Tue, 30 Aug 2011 02:43:20 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id C7A6B21F8B8A for ; Tue, 30 Aug 2011 02:43:19 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 10:44:45 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CB106.8020108@isode.com> Date: Tue, 30 Aug 2011 10:44:38 +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: Len Holgate References: <4E47FDB5.6070207@isode.com><4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> In-Reply-To: <0ba401cc66e8$b7293a40$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Hybi' Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 09:43:20 -0000 Hi, Len Holgate wrote: >Could someone explain the rationale behind how changing the header field for >origin from Sec-WebSocket-Origin to Origin in v11 of the draft doesn't >require a protocol version change? > >Surely an implementation of draft 08 which advertises itself as >Sec-WebSocket-Version: 8 can now fail to interoperate with an implementation >of draft 11 or 12 which also avertises itself as Sec-WebSocket-Version: 8. > >At the very least, a draft 08 implementation will now incorrectly interpret >browser clients (implementing 11 or later) as non browser clients and if >there are any draft 08 implementations that use origin specific "access >control"... > Maybe not bumping the version number was a mistake. The server can handle either type of client, but this is not explicitly mentioned in the draft. >Likewise the Sec-WebSocket-Version change also breaks protocol compatibility >in that a draft 08 client would expect the response from the server to >include the WebSocket-Version header and a draft 11 server only has to send >it if the handshake fails... > I don't think I've made any intentional change in this area, I think I've only clarified the text that was already in the document. Please describe the behaviour you would like to see. From alexey.melnikov@isode.com Tue Aug 30 02:47: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 8B85E21F8BBF for ; Tue, 30 Aug 2011 02:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.556 X-Spam-Level: X-Spam-Status: No, score=-102.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdDg63XQ6lCl for ; Tue, 30 Aug 2011 02:47:39 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id C5C7E21F8BBD for ; Tue, 30 Aug 2011 02:47:38 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 10:49:05 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CB20A.3090800@isode.com> Date: Tue, 30 Aug 2011 10:48:58 +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: Salvatore Loreto References: <634914A010D0B943A035D226786325D422C0D5D6BA@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D422C0D5D7BF@EXVMBX020-12.exch020.serverdata.net> <4E567A16.4050804@ericsson.com> In-Reply-To: <4E567A16.4050804@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Draft 12 - Ordering Guarantees 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, 30 Aug 2011 09:47:39 -0000 Salvatore Loreto wrote: > On 8/25/11 6:13 PM, John Tamplin wrote: > >> On Thu, Aug 25, 2011 at 11:41 AM, I=C3=B1aki Baz Castillo > > wrote: >> >> 2011/8/25 Tobias Oberstein > >: >> > Control frames with empty payload MAY be handled by an >> intermediary directly >> > and not delivered to the otherwise receiving endpoint. >> >> What is that??? are you suggesting a specification for a non >> standarized element (a "websocket intermediary")? >> >> If the WS draft does NOT define what an intermediary is, then don't >> add stuf in the spec about such "intermediaries", period. >> >> >> You appear to be the only one here who doesn't understand what a WS=20 >> intermediary is. Quite simply, it is anything in the path between=20 >> two WS endpoints which understands WS. They may observe traffic,=20 >> they may intercept (either transparently, by being an HTTP proxy and=20 >> noticing that the connection is WS, or through a yet-to-be defined=20 >> method of telling the browser to use a WS proxy specifically) a WS=20 >> connection and log/filter/whatever it wants to do with the traffic.=20 >> Saying exactly what they may do is outside the scope of this spec,=20 >> and we are unlikely to have good ideas of what you might want to do=20 >> with them at this point anyway. The spec's job is to make sure that=20 >> when such intermediaries do arise, the rules of what they can do to=20 >> the traffic are defined so they don't unintentionally break connectivity. > > (as individual) > > > adding to the spec some text explaining what a WS intermediary would=20 > be opportune. Sal, Can you suggest some text? =20 From len.holgate@gmail.com Tue Aug 30 02:59: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 A3CF521F8B56 for ; Tue, 30 Aug 2011 02:59:59 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySbQW4G-eTe5 for ; Tue, 30 Aug 2011 02:59:59 -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 0292F21F8B54 for ; Tue, 30 Aug 2011 02:59:58 -0700 (PDT) Received: by wwf5 with SMTP id 5so4375960wwf.13 for ; Tue, 30 Aug 2011 03:01:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=E6gLnsv7274pAuueqxxr6qEp812OCBNdBaVfgg1GpcQ=; b=PJxfh+0Bd0Ll2Mw+MGwk2lRSo2ireixx4CV3pSUTCTunqymS32gDuVGmu42vQorv6G MnjMUk5TzS7mt+MP4cI0NAw+Pw+WB4Z2hpnwx9jtDafW78FJGD0LO1Mjjxb5MqzvVjJm nO1vwULzBwolnSjCPs8wR66+pCtiPuX7bzaD4= Received: by 10.227.13.83 with SMTP id b19mr4802278wba.88.1314698485294; Tue, 30 Aug 2011 03:01:25 -0700 (PDT) Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id ff10sm2562165wbb.45.2011.08.30.03.01.23 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 03:01:24 -0700 (PDT) From: "Len Holgate" To: "'Alexey Melnikov'" References: <4E47FDB5.6070207@isode.com><4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> Date: Tue, 30 Aug 2011 11:00:53 +0100 Message-ID: <0bcd01cc66fb$b5320380$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4E5CB106.8020108@isode.com> Thread-Index: Acxm+XYH72RKxLRVS0iOtcSUx4zRCAAAdzWw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 09:59:59 -0000 > Maybe not bumping the version number was a mistake. The server can > handle either type of client, but this is not explicitly mentioned in > the draft. How? If the server is only looking for Sec-WebSocket-Origin (which a valid 08 draft server could be) then it wont see the Origin header from the v11 client. > I don't think I've made any intentional change in this area, I think > I've only clarified the text that was already in the document. Please > describe the behaviour you would like to see. My mistake, I thought that the server echoed the version back on successful connection, it doesn't. Lem From alexey.melnikov@isode.com Tue Aug 30 04:01: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 E59C221F854C for ; Tue, 30 Aug 2011 04:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cX7bCGNiJjU1 for ; Tue, 30 Aug 2011 04:01:01 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 7BD9621F8548 for ; Tue, 30 Aug 2011 04:00:59 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:02:25 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CB8F1.4080301@isode.com> Date: Tue, 30 Aug 2011 11:18:25 +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: Takeshi Yoshino References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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, 30 Aug 2011 11:01:02 -0000 Takeshi Yoshino wrote: > Hi Alexey, > > I have some questions about section 5.2.2. and 5.3. > > ---- > > implied WSP rule -> implied LWS rule ? Changed "implied WSP" to "implied *LWS" as per RFC 2616. > ---- > > Are > Sec-WebSocket-Protocol-Client, Sec-WebSocket-Version-Client, Sec-WebSocket-Protocol-Server, Sec-WebSocket-Version-Server > just names of ABNF rules? > > i.e. Sec-WebSocket-Protocol-Client is the grammar for the right hand > side of the Sec-WebSocket-Protocol header in client handshake? I think I've clarified this by the following new text: (for example the Sec-WebSocket-Key ABNF rule describes the Sec-WebSocket-Key header field). Note that the following ABNF conventions are used in this section: Some names of the rules correspond to names of the corresponding header fields Such rules express values of the corresponding header fields, for example the Sec-WebSocket-Key ABNF rule describes the Sec-WebSocket-Key header field. ABNF rules with the "-Client" suffix in the name are only used in requests sent by the client to the server; ABNF rules with the "-Server" suffix in the name are only used in responses sent by the server to the client. For example, the ABNF rule Sec-WebSocket-Protocol-Client describes syntax of the Sec-WebSocket-Protocol header field sent by the client to the server. > ---- > > This ABNF doesn't cover 1, 2, ... 99 > version = "0" | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) > ; 0-255 I think I got it right this time: NZDIGIT = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" version = DIGIT | (NZDIGIT DIGIT) | ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) ; Limited to 0-255 range From alexey.melnikov@isode.com Tue Aug 30 04:01: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 4982D21F8556 for ; Tue, 30 Aug 2011 04:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.408 X-Spam-Level: X-Spam-Status: No, score=-102.408 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HigGPt+BoNQ for ; Tue, 30 Aug 2011 04:01:03 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC7921F8549 for ; Tue, 30 Aug 2011 04:01:01 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:02:27 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CBD0D.9030401@isode.com> Date: Tue, 30 Aug 2011 11:35:57 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Bug in draft-11 (Connection header) 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, 30 Aug 2011 11:01:04 -0000 I=C3=B1aki Baz Castillo wrote: >Page 31: > > 3. If the response lacks a "Connection" header field or the > "Connection" header field contains a value that is not an ASCII > case-insensitive match for the value "Upgrade", the client MUST > _Fail the WebSocket Connection_. > > >"Connection" header allows a list of tokens separated by comma. So the >following is valid (in fact Firefox 8 uses it): > > Connection: keep-alive, upgrade > >However the text above invalidates sich header value since: > > the "Connection" header field contains a value that is not an ASCII > case-insensitive match for the value "Upgrade" > > >Please replace it with: > > 3. If the response lacks a "Connection" header field or the > "Connection" header field does not contain a value that is an ASCII > case-insensitive match for the value "Upgrade", the client MUST > _Fail the WebSocket Connection_. > Ok, I've used your text, but changed "value" to "token". From alexey.melnikov@isode.com Tue Aug 30 04:02: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 A433121F8BDC for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=-0.103, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVEjr2qoN-M5 for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id E258921F8B5D for ; Tue, 30 Aug 2011 04:02:39 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:02:52 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CBEA0.2080605@isode.com> Date: Tue, 30 Aug 2011 11:42:40 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 11:02:40 -0000 I=C3=B1aki Baz Castillo wrote: >Hi, the draft (12) says: > > /subprotocol/ > Either a single value representing the subprotocol the server > is ready to use or null. The value chosen MUST be derived > from the client's handshake, specifically by selecting one of > the values from the "Sec-WebSocket-Protocol" field that the > server is willing to use for this connection (if any). If the > client's handshake did not contain such a header field, or if > the server does not agree to any of the client's requested > subprotocols, the only acceptable value is null. The absence > of such a field is equivalent to the null value (meaning that > if the server does not wish to agree to one of the suggested > subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| > header field in its response). > > >So if the server just supports protocols "aaa" and "bbb" but the >client offers "ccc" and "ddd", the above text states that the server >must reply 101 without Sec-WebSocket-Protocol header. > >So then, *what* are the client and the server supposed to speak now?? >If the client has ***explicitly*** offered protocols "ccc" and "ddd" >and the server does not support them, the server should REJECT the WS >handshake, sure, rather than sending a 101. IMHO "501 Not Implemented" >could be a good HTTP response for this case. > =20 > Subprotocols are optional in the WebSocket protocols. So the client=20 can't say that a particular extension is required. It can only close the=20 connection after the handshake completes without it. >The WebSocket handshake (HTTP GET + 101) is a negotiation between >client and server. If the negotiation fails, the WS GET request MUST >be rejected rather than accepted. > >The current text seems to allow ugly JavaScript developers to set a >random protocol string (just for funny) in the Websocket JS API for >the function "connect(URL, protocols)". Please make it strict. > From alexey.melnikov@isode.com Tue Aug 30 04:02: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 A43D021F8C06 for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.405 X-Spam-Level: X-Spam-Status: No, score=-102.405 tagged_above=-999 required=5 tests=[AWL=-0.106, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gRLmGH6HMR6 for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D275221F8559 for ; Tue, 30 Aug 2011 04:02:39 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:02:35 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CBDB6.5020901@isode.com> Date: Tue, 30 Aug 2011 11:38:46 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Please calrify "5.2.2. Sending the Server's Opening Handshake" 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, 30 Aug 2011 11:02:40 -0000 I=C3=B1aki Baz Castillo wrote: > /subprotocol/ > Either a single value representing the subprotocol the server > is ready to use or null. The value chosen MUST be derived > from the client's handshake, specifically by selecting one of > the values from the "Sec-WebSocket-Protocol" field that the > server is willing to use for this connection (if any). If the > client's handshake did not contain such a header field, or if > the server does not agree to any of the client's requested > subprotocols, the only acceptable value is null. The absence > of such a field is equivalent to the null value (meaning that > if the server does not wish to agree to one of the suggested > subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| > header field in its response). The empty string is not the > same as the null value for these purposes, and is not a legal > value for this field. The ABNF for the value of this header > field is (token), where the definitions of constructs and > rules are as given in [RFC2616]. > > >So it's stating that in case the client does not send a >Sec-WebSocket-Protocol header, the server MUST NOT include such a >header in the 101 response. Why?? why cannot the server include >"Sec-WebSocket-Protocol: test.foo.com" in the 101 response meaning >that *that* is the chosen protocol? > Because the server is not allowed to select something not advertised by=20 the client. I think the text is correct as written, so no change. From alexey.melnikov@isode.com Tue Aug 30 04:02: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 ACAE521F8B5D for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.399 X-Spam-Level: X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aLxZ+PniECn for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 36DEC21F8BB2 for ; Tue, 30 Aug 2011 04:02:40 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:03:04 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CBEDE.1030608@isode.com> Date: Tue, 30 Aug 2011 11:43:42 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Suggested new WS status code: 1008 "Extension Required" 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, 30 Aug 2011 11:02:40 -0000 I=C3=B1aki Baz Castillo wrote: >Following the rationale in other thread, I suggest the following new >WS status code: > > 1008 > > 1008 is just sent from client to server when the client decides to > disconnect due to lack of some extension in the server's > Sec-WebSocket-Extensions header during 101 response. > It MAY contain the name of the extension (or extensions separated > by comma) in the frame payload data after the status code. > > >This would be useful to inform the server (so it can log it) the >reason of the client's disconnect after WS handshake. > I am personally Ok with adding this. But I would like to hear some=20 comments from the WG. From ibc@aliax.net Tue Aug 30 04:10: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 59C1B21F8C43 for ; Tue, 30 Aug 2011 04:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgVXUhdJ9s4U for ; Tue, 30 Aug 2011 04:10: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 C901321F8C44 for ; Tue, 30 Aug 2011 04:10:23 -0700 (PDT) Received: by qwc23 with SMTP id 23so4581184qwc.31 for ; Tue, 30 Aug 2011 04:11:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.85 with SMTP id h21mr43810qci.46.1314702693573; Tue, 30 Aug 2011 04:11:33 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Tue, 30 Aug 2011 04:11:33 -0700 (PDT) In-Reply-To: <4E5CBEA0.2080605@isode.com> References: <4E5CBEA0.2080605@isode.com> Date: Tue, 30 Aug 2011 13:11:33 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 11:10:24 -0000 2011/8/30 Alexey Melnikov : > Subprotocols are optional in the WebSocket protocols. So the client can't > say that a particular extension is required. It can only close the > connection after the handshake completes without it. That does not answer to all my previous rationale. To summarize: Why should the WS server accept (so 101) a WS handshake when the client offers WS protocols NOT supported by the WS server? I don't mean that the client does not provide Sec-WebSocket-Protocol header, I mean that the client *provides * it, but offered protocols are NOT supported by the server. Why should the server then accept such WS session? what are they supposed to speak? IMHO it's really clear that the server should not accept the WS handshake. --=20 I=C3=B1aki Baz Castillo From alexey.melnikov@isode.com Tue Aug 30 04:15:36 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 5F5E321F8C08 for ; Tue, 30 Aug 2011 04:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.396 X-Spam-Level: X-Spam-Status: No, score=-102.396 tagged_above=-999 required=5 tests=[AWL=-0.097, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TB+M19If3dW8 for ; Tue, 30 Aug 2011 04:15:36 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id D779E21F8AFA for ; Tue, 30 Aug 2011 04:15:35 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:17:02 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CC6A7.7030304@isode.com> Date: Tue, 30 Aug 2011 12:16:55 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E5CBEA0.2080605@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 11:15:36 -0000 I=C3=B1aki Baz Castillo wrote: >2011/8/30 Alexey Melnikov : > =20 > >>Subprotocols are optional in the WebSocket protocols. So the client can't >>say that a particular extension is required. It can only close the >>connection after the handshake completes without it. >> =20 >> > >That does not answer to all my previous rationale. To summarize: > >Why should the WS server accept (so 101) a WS handshake when the >client offers WS protocols NOT supported by the WS server? I don't >mean that the client does not provide Sec-WebSocket-Protocol header, I >mean that the client *provides * it, but offered protocols are NOT >supported by the server. > Because by definition the list of extensions in the=20 Sec-WebSocket-Protocol header field is optional for the server to=20 support. If we want to have "you must support this extension, or we fail=20 the handshake", then we need another mechanism to tell the server. >Why should the server then accept such WS >session? what are they supposed to speak? IMHO it's really clear that >the server should not accept the WS handshake. > =20 > From ibc@aliax.net Tue Aug 30 04:17: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 DCA0021F8C08 for ; Tue, 30 Aug 2011 04:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwweLlyhx8tu for ; Tue, 30 Aug 2011 04:17:20 -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 EAF1E21F8B77 for ; Tue, 30 Aug 2011 04:17:19 -0700 (PDT) Received: by qwc23 with SMTP id 23so4584498qwc.31 for ; Tue, 30 Aug 2011 04:18:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.1 with SMTP id t1mr6715385qci.198.1314703125130; Tue, 30 Aug 2011 04:18:45 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Tue, 30 Aug 2011 04:18:45 -0700 (PDT) In-Reply-To: <4E5CC6A7.7030304@isode.com> References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> Date: Tue, 30 Aug 2011 13:18:45 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 11:17:21 -0000 2011/8/30 Alexey Melnikov : >> Why should the WS server accept (so 101) a WS handshake when the >> client offers WS protocols NOT supported by the WS server? I don't >> mean that the client does not provide Sec-WebSocket-Protocol header, I >> mean that the client *provides * it, but offered protocols are NOT >> supported by the server. >> > Because by definition the list of extensions in the Sec-WebSocket-Protoco= l > header field is optional for the server to support. If we want to have "y= ou > must support this extension, or we fail the handshake", then we need anot= her > mechanism to tell the server. Ok, so after client offers "Sec-WebSocket-Protocol: aaa, bbb" and the server provides NO such header in the 101 response.... what are client and server supposed to speak now? --=20 I=C3=B1aki Baz Castillo From alexey.melnikov@isode.com Tue Aug 30 04:24: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 A3D6821F8C1E for ; Tue, 30 Aug 2011 04:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.696 X-Spam-Level: X-Spam-Status: No, score=-101.696 tagged_above=-999 required=5 tests=[AWL=-0.793, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nRjc8awefxFY for ; Tue, 30 Aug 2011 04:24:24 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id DA7D521F8C1D for ; Tue, 30 Aug 2011 04:24:23 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 12:25:50 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CC8B8.7090702@isode.com> Date: Tue, 30 Aug 2011 12:25:44 +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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 11:24:24 -0000 I=C3=B1aki Baz Castillo wrote: >2011/8/30 Alexey Melnikov : > =20 > >>>Why should the WS server accept (so 101) a WS handshake when the >>>client offers WS protocols NOT supported by the WS server? I don't >>>mean that the client does not provide Sec-WebSocket-Protocol header, I >>>mean that the client *provides * it, but offered protocols are NOT >>>supported by the server. >>> =20 >>> >>Because by definition the list of extensions in the Sec-WebSocket-Protocol >>header field is optional for the server to support. If we want to have "yo= u >>must support this extension, or we fail the handshake", then we need anoth= er >>mechanism to tell the server. >> =20 >> >Ok, so after client offers "Sec-WebSocket-Protocol: aaa, bbb" and the >server provides NO such header in the 101 response.... what are client >and server supposed to speak now? > =20 > If the client really expected the extensions to be mandatory, it has to=20 send Close. From ibc@aliax.net Tue Aug 30 04:27: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 8F5DB21F8BE9 for ; Tue, 30 Aug 2011 04:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.646 X-Spam-Level: X-Spam-Status: No, score=-2.646 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8cQlESbrcox for ; Tue, 30 Aug 2011 04:27:33 -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 A1B8B21F8BB3 for ; Tue, 30 Aug 2011 04:27:33 -0700 (PDT) Received: by qwc23 with SMTP id 23so4589288qwc.31 for ; Tue, 30 Aug 2011 04:29:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.14 with SMTP id q14mr6721920qce.122.1314703740640; Tue, 30 Aug 2011 04:29:00 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Tue, 30 Aug 2011 04:29:00 -0700 (PDT) In-Reply-To: <4E5CC8B8.7090702@isode.com> References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> Date: Tue, 30 Aug 2011 13:29:00 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Alexey Melnikov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 11:27:34 -0000 2011/8/30 Alexey Melnikov : > If the client really expected the extensions to be mandatory, it has to s= end > Close. A new close status code just to say "the WS protocol negotiation has obviously failed so I close the connection"? --=20 I=C3=B1aki Baz Castillo From alexey.melnikov@isode.com Tue Aug 30 06:40: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 BADF421F8A7A for ; Tue, 30 Aug 2011 06:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S6WnLnC4nQeT for ; Tue, 30 Aug 2011 06:40:44 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id 003E021F8A57 for ; Tue, 30 Aug 2011 06:40:43 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 14:42:05 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5CE8A5.4070604@isode.com> Date: Tue, 30 Aug 2011 14:41:57 +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: Joonas Lehtolahti References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] Server-side requirements in draft 10 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, 30 Aug 2011 13:40:44 -0000 Hi Joonas, Joonas Lehtolahti wrote: > In draft-ietf-hybi-thewebsocketprotocol-10 in Server-side > Requirements (section 5.2.), and more specifically subsection 5.2.1. > Reading the Client's Opening Handshake, I noticed that the > requirements do not list that the client's handshake must contain the > upgrade headers (Upgrade: websocket, Connection: upgrade). > > Based on that, even though it is required for the client to send > those headers, it is not necessary for the server to see those > headers to still consider the connection attempt as a valid WebSocket > handshake as long as it has the other required parts such as > Sec-WebSocket-Protocol. This would allow the server to complete the > handshake and ask for protocol upgrade without the client requesting > for upgrade. In other words even if the client violated the spec for > handshake, the server would still accept it. > > Is this an oversight or actually intentional? This is an oversight, fixed in my copy of the document. > As far as I understood from RFC2616 (HTTP/1.1) the Upgrade header > from server can only be sent in response to client indicating > willingness to upgrade protocols. Therefore accepting a HTTP request > without Upgrade headers as a valid WebSocket handshake and then > responding with server handshake including the Upgrade headers would > be violating the idea behind the headers in my opinion (I did not see > the HTTP spec actually forbidding server from sending Upgrade headers > without client requesting it, but it seems implicit it should not > happen). From gregw@intalio.com Tue Aug 30 06:54: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 5043621F8C04 for ; Tue, 30 Aug 2011 06:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.994 X-Spam-Level: X-Spam-Status: No, score=-1.994 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LsmHkRx5z7K for ; Tue, 30 Aug 2011 06:54:45 -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 581AB21F8BF9 for ; Tue, 30 Aug 2011 06:54:43 -0700 (PDT) Received: by vws12 with SMTP id 12so3488815vws.31 for ; Tue, 30 Aug 2011 06:56:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.171 with SMTP id a11mr1212083vdj.313.1314712568272; Tue, 30 Aug 2011 06:56:08 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 30 Aug 2011 06:56:07 -0700 (PDT) In-Reply-To: <4E5CBEDE.1030608@isode.com> References: <4E5CBEDE.1030608@isode.com> Date: Tue, 30 Aug 2011 23:56:07 +1000 Message-ID: From: Greg Wilkins To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Suggested new WS status code: 1008 "Extension Required" 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, 30 Aug 2011 13:54:45 -0000 On 30 August 2011 20:43, Alexey Melnikov wrote: > I=F1aki Baz Castillo wrote: > >> Following the rationale in other thread, I suggest the following new >> WS status code: >> >> =A01008 > > I am personally Ok with adding this. But I would like to hear some commen= ts > from the WG. I don't have any issues with such a code.... other than my concern that we have a few specific codes, but no general s**t happened close code. I'm not sure the server can do anything meaningful with the code, other than log it to gather evidence that it needs to implement the missing extension. cheers From ibc@aliax.net Tue Aug 30 07:49: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 A4FB621F8BDC for ; Tue, 30 Aug 2011 07:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.902, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_LOLITA1=1.865, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOd4LuV2aYz8 for ; Tue, 30 Aug 2011 07:49:33 -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 2054821F8BD5 for ; Tue, 30 Aug 2011 07:49:29 -0700 (PDT) Received: by qyk34 with SMTP id 34so2294825qyk.10 for ; Tue, 30 Aug 2011 07:50:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.1.99 with SMTP id 35mr6906446qce.84.1314715856904; Tue, 30 Aug 2011 07:50:56 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Tue, 30 Aug 2011 07:50:56 -0700 (PDT) In-Reply-To: References: <4E5CBEDE.1030608@isode.com> Date: Tue, 30 Aug 2011 16:50:56 +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] Suggested new WS status code: 1008 "Extension Required" 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, 30 Aug 2011 14:49:33 -0000 2011/8/30 Greg Wilkins : > I'm not sure the server can do anything meaningful with the code, > other than log it to gather evidence that it needs to implement the > missing extension. Right. That is useful enough IMHO. Logging and debugging is important. Knowing the reason a client closed the connection after the WS handshake is good in any case. --=20 I=C3=B1aki Baz Castillo From jat@google.com Tue Aug 30 08:40:32 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 7E97B21F8CC7 for ; Tue, 30 Aug 2011 08:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.729 X-Spam-Level: X-Spam-Status: No, score=-105.729 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctUr3Lg4K6eA for ; Tue, 30 Aug 2011 08:40:32 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id DE23321F8CD6 for ; Tue, 30 Aug 2011 08:40:31 -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 p7UFfwIQ004038 for ; Tue, 30 Aug 2011 08:41:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314718919; bh=Pz31TmAY3LlqNXYoplSGa1mBHf8=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ma5bCKI1bCFFWHUwVnaq3zWU1iTscDHuQ4/YeMnTfNFn1ma3zb33x1+5ZaNUQIfbx tq0VLtTzThOpZ78PJuJHA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=oBEwjnR24rn5vvSk+U9AFTlDUwOGi1US9V/D68bH9LyVztjXNjmPh2UA9ZQEpiNKV IeBSnaNPQscVsUX3OUwHA== Received: from gwaa20 (gwaa20.prod.google.com [10.200.27.20]) by hpaq6.eem.corp.google.com with ESMTP id p7UFevhX007955 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 30 Aug 2011 08:41:57 -0700 Received: by gwaa20 with SMTP id a20so6036050gwa.0 for ; Tue, 30 Aug 2011 08:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=yRvp+SuNtziZ99QsPeAHTPgKaOdOjcDcTjNNhjZw9HQ=; b=F2Ar2gqbCYYoeLlMfCjcQhw4LlPxvQ00KYzoPLPSStsShmK1msA7Gkwk/MsaAQdLIh nyxh+bytF7bnVLuTFlEQ== Received: by 10.150.48.8 with SMTP id v8mr2445754ybv.401.1314718917247; Tue, 30 Aug 2011 08:41:57 -0700 (PDT) Received: by 10.150.48.8 with SMTP id v8mr2445746ybv.401.1314718917102; Tue, 30 Aug 2011 08:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 30 Aug 2011 08:41:37 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> From: John Tamplin Date: Tue, 30 Aug 2011 11:41:37 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd70d3c088b9604abbada54 X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 15:40:32 -0000 --000e0cd70d3c088b9604abbada54 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2011 at 7:29 AM, I=C3=B1aki Baz Castillo wr= ote: > 2011/8/30 Alexey Melnikov : > > If the client really expected the extensions to be mandatory, it has to > send > > Close. > > A new close status code just to say "the WS protocol negotiation has > obviously failed so I close the connection"? We don't need a separate close code for every possible reason -- there will be too many, and we will certainly miss many ones that would actually be used. Instead, we need more generic error codes describing categories of failures. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd70d3c088b9604abbada54 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 30, 2011 at 7:29 AM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
2011/8/30 Alexey Melnikov <alexey.melnikov@isode.com>:
> If the client really expected the extensions t= o be mandatory, it has to send
> Close.

A new close status code just to say "the WS protocol negotiation= has
obviously failed so I close the connection"?
We don't need a separate close code for every possible reason -= - there will be too many, and we will certainly miss many ones that would a= ctually be used. =C2=A0Instead, we need more generic error codes describing= categories of failures.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd70d3c088b9604abbada54-- From alexey.melnikov@isode.com Tue Aug 30 08:41: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 7246E21F8781 for ; Tue, 30 Aug 2011 08:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.525 X-Spam-Level: X-Spam-Status: No, score=-102.525 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ST5v+yFMDPL for ; Tue, 30 Aug 2011 08:41:27 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id AC39A21F877B for ; Tue, 30 Aug 2011 08:41:27 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Tue, 30 Aug 2011 16:42:54 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5D04F8.30801@isode.com> Date: Tue, 30 Aug 2011 16:42:48 +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: John Tamplin References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 30 Aug 2011 15:41:28 -0000 John Tamplin wrote: > On Tue, Aug 30, 2011 at 7:29 AM, I=C3=B1aki Baz Castillo > wrote: > > 2011/8/30 Alexey Melnikov >: > > If the client really expected the extensions to be mandatory, it > has to send > > Close. > > A new close status code just to say "the WS protocol negotiation has > obviously failed so I close the connection"? > > > We don't need a separate close code for every possible reason -- there=20 > will be too many, and we will certainly miss many ones that would=20 > actually be used. Instead, we need more generic error codes=20 > describing categories of failures. I think we need both. More specific error codes are better, if=20 introduced early. From jat@google.com Tue Aug 30 08:50: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 4D88521F8CE7 for ; Tue, 30 Aug 2011 08:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.926 X-Spam-Level: X-Spam-Status: No, score=-105.926 tagged_above=-999 required=5 tests=[AWL=0.050, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQ3cwkonfBDm for ; Tue, 30 Aug 2011 08:50:29 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id C352221F8CED for ; Tue, 30 Aug 2011 08:50:13 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p7UFpdw3019149 for ; Tue, 30 Aug 2011 08:51:40 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314719500; bh=LGp6fa+CWWMPM301LnSJNQKaHbE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ddN5hy0Zm7hcKEY+aJPibZFYWlXmlvXegLXVFzhb/W7PBGDd97jXMnA2xze2HuDHk hZWgi66b5B/CX019vjVCQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=CNnjO8mxYeKxkvF6yyyCZY6QakoWrXnuqUiWrBqRxBXLGTNQsLkTLPgeZh9/00Hav tyxwPPyZ5CBLnDthK+L2g== Received: from ywo7 (ywo7.prod.google.com [10.192.15.7]) by wpaz1.hot.corp.google.com with ESMTP id p7UFpcvd032339 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 30 Aug 2011 08:51:38 -0700 Received: by ywo7 with SMTP id 7so13284645ywo.25 for ; Tue, 30 Aug 2011 08:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ifKCDUc7Ka7c0P139A4IfO7syXqTDjBySecBN7h1bsM=; b=Shh1JsQIB3jOHZXDfVAetWJneS6qFVniMkwvIxmpcu4NjxU5lB3cXrOr//aArtR8cl q6IzldUhRMEFDhVGM5Lg== Received: by 10.150.14.6 with SMTP id 6mr6298772ybn.173.1314719498282; Tue, 30 Aug 2011 08:51:38 -0700 (PDT) Received: by 10.150.14.6 with SMTP id 6mr6298764ybn.173.1314719498127; Tue, 30 Aug 2011 08:51:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.49.7 with HTTP; Tue, 30 Aug 2011 08:51:18 -0700 (PDT) In-Reply-To: <0bcd01cc66fb$b5320380$0a00a8c0@Venus> References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> From: John Tamplin Date: Tue, 30 Aug 2011 11:51:18 -0400 Message-ID: To: Len Holgate Content-Type: multipart/alternative; boundary=000e0cd7551caa4a4c04abbafc1a X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 15:50:33 -0000 --000e0cd7551caa4a4c04abbafc1a Content-Type: text/plain; charset=UTF-8 On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate wrote: > > Maybe not bumping the version number was a mistake. The server can > > handle either type of client, but this is not explicitly mentioned in > > the draft. > > How? If the server is only looking for Sec-WebSocket-Origin (which a valid > 08 draft server could be) then it wont see the Origin header from the v11 > client. I server implementing v08 and v11 can look for both, the same way existing servers support older versions of the protocol. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd7551caa4a4c04abbafc1a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate <len.holgate@gma= il.com> wrote:
> Maybe not bumping the version number was a mistake. = The server can
> handle either type of client, but this is not explicitly mentioned in<= br> > the draft.

How? If the server is only looking for Sec-WebSocket-Origin (which a = valid
08 draft server could be) then it wont see the Origin header from the v11 client.

I server implementing v08 and v11 c= an look for both, the same way existing servers support older versions of t= he protocol.

--
John A. Tamplin
Software E= ngineer (GWT), Google
--000e0cd7551caa4a4c04abbafc1a-- From len.holgate@gmail.com Tue Aug 30 09:11: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 073F821F8D09 for ; Tue, 30 Aug 2011 09:11:58 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Sf0-rvIA6y6 for ; Tue, 30 Aug 2011 09:11:57 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 89FB521F8C40 for ; Tue, 30 Aug 2011 09:11:56 -0700 (PDT) Received: by wyg8 with SMTP id 8so5681460wyg.31 for ; Tue, 30 Aug 2011 09:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=4nEWzfCsQrMi5OG8s+rkpDdsyfZhMCLbxF3wWFIWGmY=; b=kQ6jR1/kG777RRKaPWgfdf45S7p1PyU2n/e3U22KM6tAWnoe/VpPSoSdwEbwIaEq8E DN7ZkNu3mJ1UPH6ca5dnnkZj0BHuJenrmrhNIIwV27hY7R935Gm1xQ+ow6z6sFbi30VI SdDE9f5sxrypRhxE5ckXFUezgHxQ0njClRL4g= Received: by 10.227.9.207 with SMTP id m15mr3160211wbm.59.1314720780787; Tue, 30 Aug 2011 09:13:00 -0700 (PDT) Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id fj19sm4748566wbb.32.2011.08.30.09.12.58 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 09:12:59 -0700 (PDT) From: "Len Holgate" To: "'John Tamplin'" References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> Date: Tue, 30 Aug 2011 17:12:26 +0100 Message-ID: <0c9101cc672f$9dab6100$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcxnLLUDoUbgk3fjR5u61qN23IVMrQAAr4MQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 16:11:58 -0000 A new server, yes, anything existing that thinks it implements protocol version 8 now doesn't implement draft HyBi-11's version of protocol version 8... > -----Original Message----- > From: John Tamplin [mailto:jat@google.com] > Sent: 30 August 2011 16:51 > To: Len Holgate > Cc: Alexey Melnikov; Hybi > Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin > > On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate > wrote: > > > > Maybe not bumping the version number was a mistake. > The server can > > handle either type of client, but this is not > explicitly mentioned in > > the draft. > > > How? If the server is only looking for > Sec-WebSocket-Origin (which a valid > 08 draft server could be) then it wont see the Origin > header from the v11 > client. > > > I server implementing v08 and v11 can look for both, the same > way existing servers support older versions of the protocol. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > From theturtle32@gmail.com Tue Aug 30 10:19: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 DAD1621F8DA5 for ; Tue, 30 Aug 2011 10:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yq-dXrfXH-mo for ; Tue, 30 Aug 2011 10:19:47 -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 3F31621F8D8D for ; Tue, 30 Aug 2011 10:19:47 -0700 (PDT) Received: by bkar4 with SMTP id r4so6320438bka.31 for ; Tue, 30 Aug 2011 10:21:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+0RT8H3u0zB9Q3Uv2Ek/r+9FeQuuo7qVhy6iMbfqAEo=; b=QUBPKN+llenI9cePdqdqYtXkkFEKrIIQz5zPJoXGOzhygX6PXx5wlusS9ENNGFGWbO lM7wiB4SRYbvnikDD3Su1Tp4IXAN3a09VGv/tAd8HM91l9R//JPtdXns/9fTxYUHZRmQ 76MZgq4RJNK/Np951a552hR5G7/57oJHbPzw8= MIME-Version: 1.0 Received: by 10.204.135.6 with SMTP id l6mr275102bkt.284.1314724874304; Tue, 30 Aug 2011 10:21:14 -0700 (PDT) Received: by 10.204.150.72 with HTTP; Tue, 30 Aug 2011 10:21:14 -0700 (PDT) In-Reply-To: <0c9101cc672f$9dab6100$0a00a8c0@Venus> References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> <0c9101cc672f$9dab6100$0a00a8c0@Venus> Date: Tue, 30 Aug 2011 10:21:14 -0700 Message-ID: From: Brian To: Len Holgate Content-Type: multipart/alternative; boundary=0015174753c21c3c0d04abbc3d10 Cc: Hybi Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 17:19:49 -0000 --0015174753c21c3c0d04abbc3d10 Content-Type: text/plain; charset=ISO-8859-1 Yes. The protocol version needs to be incremented when there is a non-backward-compatible handshake change as well as when there is a non-backward-compatible change to the framing. If we're changing the name of the origin header, we absolutely need to also increment the version number. Brian On Tue, Aug 30, 2011 at 9:12 AM, Len Holgate wrote: > A new server, yes, anything existing that thinks it implements protocol > version 8 now doesn't implement draft HyBi-11's version of protocol version > 8... > > > -----Original Message----- > > From: John Tamplin [mailto:jat@google.com] > > Sent: 30 August 2011 16:51 > > To: Len Holgate > > Cc: Alexey Melnikov; Hybi > > Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin > > > > On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate > > wrote: > > > > > > > Maybe not bumping the version number was a mistake. > > The server can > > > handle either type of client, but this is not > > explicitly mentioned in > > > the draft. > > > > > > How? If the server is only looking for > > Sec-WebSocket-Origin (which a valid > > 08 draft server could be) then it wont see the Origin > > header from the v11 > > client. > > > > > > I server implementing v08 and v11 can look for both, the same > > way existing servers support older versions of the protocol. > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --0015174753c21c3c0d04abbc3d10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. =A0The protocol version needs to be incremented when there is a non-ba= ckward-compatible handshake change as well as when there is a non-backward-= compatible change to the framing. =A0If we're changing the name of the = origin header, we absolutely need to also increment the version number.

Brian


On Tue, Aug 30, 2011 at 9:= 12 AM, Len Holgate <len.holgate@gmail.com> wrote:
A new server, yes, anything existing that thinks it implements protocol
version 8 now doesn't implement draft HyBi-11's version of protocol= version
8...

> -----Original Message-----
> From: John Tamplin [mailto:jat@googl= e.com]
> Sent: 30 August 2011 16:51
> To: Len Holgate
> Cc: Alexey Melnikov; Hybi
> Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin
>
> On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate
> <len.holgate@gmail.com= > wrote:
>
>
> =A0 =A0 =A0 > Maybe not bumping the version number was a mistake. > The server can
> =A0 =A0 =A0 > handle either type of client, but this is not
> explicitly mentioned in
> =A0 =A0 =A0 > the draft.
>
>
> =A0 =A0 =A0 How? If the server is only looking for
> Sec-WebSocket-Origin (which a valid
> =A0 =A0 =A0 08 draft server could be) then it wont see the Origin
> header from the v11
> =A0 =A0 =A0 client.
>
>
> I server implementing v08 and v11 can look for both, the same
> way existing servers support older versions of the protocol.
>
> --
> John A. Tamplin
> Software Engineer (GWT), Google
>
>

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

--0015174753c21c3c0d04abbc3d10-- From mcmanus@ducksong.com Tue Aug 30 10:24: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 3003C21F8DBB for ; Tue, 30 Aug 2011 10:24: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fGSGr2GMB3S for ; Tue, 30 Aug 2011 10:24:20 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 5B82B21F8DBA for ; Tue, 30 Aug 2011 10:24:20 -0700 (PDT) Received: by linode.ducksong.com (Postfix, from userid 1000) id 6F89A10195; Tue, 30 Aug 2011 13:25:46 -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 1870210191; Tue, 30 Aug 2011 13:25:39 -0400 (EDT) From: Patrick McManus To: Brian In-Reply-To: References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> <0c9101cc672f$9dab6100$0a00a8c0@Venus> Content-Type: text/plain; charset="UTF-8" Date: Tue, 30 Aug 2011 13:25:37 -0400 Message-ID: <1314725137.1799.28.camel@ds9> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 17:24:21 -0000 I'd much rather see the silly aesthetic name change reverted, so we could get some testing continuity and experience in order to find actual meaningful shortcomings in the protocol. On Tue, 2011-08-30 at 10:21 -0700, Brian wrote: > Yes. The protocol version needs to be incremented when there is a > non-backward-compatible handshake change as well as when there is a > non-backward-compatible change to the framing. If we're changing the > name of the origin header, we absolutely need to also increment the > version number. > > Brian > > > On Tue, Aug 30, 2011 at 9:12 AM, Len Holgate > wrote: > A new server, yes, anything existing that thinks it implements > protocol > version 8 now doesn't implement draft HyBi-11's version of > protocol version > 8... > > > > -----Original Message----- > > From: John Tamplin [mailto:jat@google.com] > > Sent: 30 August 2011 16:51 > > To: Len Holgate > > Cc: Alexey Melnikov; Hybi > > Subject: Re: [hybi] On changing Sec-WebSocket-Origin to > Origin > > > > On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate > > wrote: > > > > > > > Maybe not bumping the version number was a mistake. > > The server can > > > handle either type of client, but this is not > > explicitly mentioned in > > > the draft. > > > > > > How? If the server is only looking for > > Sec-WebSocket-Origin (which a valid > > 08 draft server could be) then it wont see the Origin > > header from the v11 > > client. > > > > > > I server implementing v08 and v11 can look for both, the > same > > way existing servers support older versions of the protocol. > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google > > > > > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From theturtle32@gmail.com Tue Aug 30 10:32: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 4593521F8C7F for ; Tue, 30 Aug 2011 10:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFo3dZiglR6c for ; Tue, 30 Aug 2011 10:32:24 -0700 (PDT) Received: from mail-pz0-f45.google.com (mail-pz0-f45.google.com [209.85.210.45]) by ietfa.amsl.com (Postfix) with ESMTP id C34B421F8C6F for ; Tue, 30 Aug 2011 10:32:24 -0700 (PDT) Received: by pzk33 with SMTP id 33so22938046pzk.18 for ; Tue, 30 Aug 2011 10:33:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=g3/6UK/RqzBEJKZr79KYYVuBb4orG19Y9Et/FjJneN8=; b=bHAgivs2aPOm8WBpvNeJbvEvbJWFRfW7p3Qql77J9wYjOyUJQRObbLqqF2vptoIUcg 9v/si1Wse4Juss8QvT2jFEIlcIsh2efhbJZXyVUauwLNhuReLSb4zvF0kpSjaCsZYwm3 jWB2flCd5PQQbzHs1oDK6BMySrEe6vyiYzvpA= Received: by 10.142.193.6 with SMTP id q6mr3040318wff.164.1314725632630; Tue, 30 Aug 2011 10:33:52 -0700 (PDT) Received: from [192.168.1.78] (cpe-98-148-229-193.socal.res.rr.com [98.148.229.193]) by mx.google.com with ESMTPS id x1sm821338wfc.13.2011.08.30.10.33.50 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Aug 2011 10:33:51 -0700 (PDT) References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> <0c9101cc672f$9dab6100$0a00a8c0@Venus> <1314725137.1799.28.camel@ds9> In-Reply-To: <1314725137.1799.28.camel@ds9> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <0ABBCBD4-80E5-4AC4-8F19-87F199A184BC@gmail.com> X-Mailer: iPhone Mail (8J2) From: Brian McKelvey Date: Tue, 30 Aug 2011 10:33:36 -0700 To: Patrick McManus Cc: Hybi Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 17:32:25 -0000 I don't have a strong feeling on the origin header, only that the version is= incremented if there's a backward incompatible change in the handshake. Sent from my iPhone On Aug 30, 2011, at 10:25 AM, Patrick McManus wrote: > I'd much rather see the silly aesthetic name change reverted, so we > could get some testing continuity and experience in order to find actual > meaningful shortcomings in the protocol. >=20 > On Tue, 2011-08-30 at 10:21 -0700, Brian wrote: >> Yes. The protocol version needs to be incremented when there is a >> non-backward-compatible handshake change as well as when there is a >> non-backward-compatible change to the framing. If we're changing the >> name of the origin header, we absolutely need to also increment the >> version number. >>=20 >> Brian >>=20 >>=20 >> On Tue, Aug 30, 2011 at 9:12 AM, Len Holgate >> wrote: >> A new server, yes, anything existing that thinks it implements >> protocol >> version 8 now doesn't implement draft HyBi-11's version of >> protocol version >> 8... >>=20 >>=20 >>> -----Original Message----- >>> From: John Tamplin [mailto:jat@google.com] >>> Sent: 30 August 2011 16:51 >>> To: Len Holgate >>> Cc: Alexey Melnikov; Hybi >>> Subject: Re: [hybi] On changing Sec-WebSocket-Origin to >> Origin >>>=20 >>> On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate >>> wrote: >>>=20 >>>=20 >>>> Maybe not bumping the version number was a mistake. >>> The server can >>>> handle either type of client, but this is not >>> explicitly mentioned in >>>> the draft. >>>=20 >>>=20 >>> How? If the server is only looking for >>> Sec-WebSocket-Origin (which a valid >>> 08 draft server could be) then it wont see the Origin >>> header from the v11 >>> client. >>>=20 >>>=20 >>> I server implementing v08 and v11 can look for both, the >> same >>> way existing servers support older versions of the protocol. >>>=20 >>> -- >>> John A. Tamplin >>> Software Engineer (GWT), Google >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >>=20 >>=20 >>=20 >> _______________________________________________ >> hybi mailing list >> hybi@ietf.org >> https://www.ietf.org/mailman/listinfo/hybi >=20 >=20 From len.holgate@gmail.com Tue Aug 30 10:47: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 A69F821F8DB4 for ; Tue, 30 Aug 2011 10:47:20 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mU8zHgPUiHyf for ; Tue, 30 Aug 2011 10:47:20 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id A1B2F21F8DAF for ; Tue, 30 Aug 2011 10:47:19 -0700 (PDT) Received: by wwe5 with SMTP id 5so3659316wwe.1 for ; Tue, 30 Aug 2011 10:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=4LTClhWRZ9yBZFk97fwQAg7+E4qW188//uRgfq0qfTs=; b=gjx5SGYb2kmZmqdC92WUSIbnpJKnvZ1fba8PXqmKReWcIqXDgYdWiGb1y3J/y2ryQl c1MQY4uYSVb8OuTORZQLk3Cvu/44sIty/eljrGf+rRUdAa7qYN1FsoDX8wLtuXnhqX9z rpMJ5yUEYQei76+C9VsOL7eUAFhuHnoGjsSYo= Received: by 10.216.134.83 with SMTP id r61mr1050864wei.22.1314726527004; Tue, 30 Aug 2011 10:48:47 -0700 (PDT) Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id y31sm3771294weq.40.2011.08.30.10.48.45 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 10:48:46 -0700 (PDT) From: "Len Holgate" To: "'Tobias Oberstein'" References: <634914A010D0B943A035D226786325D422BFBFBF15@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 30 Aug 2011 18:48:13 +0100 Message-ID: <0cc701cc673c$fec42d70$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <634914A010D0B943A035D226786325D422BFBFBF15@EXVMBX020-12.exch020.serverdata.net> Thread-Index: AcxXwXL4sJmmuO3yQXO+aY/Hi+VaIwAYSzfAA8BrwIA= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: hybi@ietf.org Subject: [hybi] Autobahn test suite 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, 30 Aug 2011 17:47:20 -0000 Tobias, Thank you for providing such a useful test suite. It has complemented my own unit testing of my implementation and has helped me nail a few bugs in my code. Everything passes, well, except that 9.4.1 and 9.5.1 seem to randomly fail (with the Autobahn test server as well as my own server). My server seems to think that your client test closes the connection cleanly on it (TCP recv returns 0) part way through the test... This results in the 'default' error which implies a timeout but I've tried increasing the timeout to 200 seconds and it still fails after around 6 with the same issues; and sometimes it works... Results, if you're interested, here: http://www.serverframework.com/ServerFramework/6.5/WebSockets/ Thanks again. Len http://www.lenholgate.com http://www.serverframework.com From len.holgate@gmail.com Tue Aug 30 10:48: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 C004F21F8D98 for ; Tue, 30 Aug 2011 10:48:00 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctEFyL0Wfi2h for ; Tue, 30 Aug 2011 10:48:00 -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 C824521F8D70 for ; Tue, 30 Aug 2011 10:47:59 -0700 (PDT) Received: by wwf5 with SMTP id 5so4706317wwf.13 for ; Tue, 30 Aug 2011 10:49:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=na+YaXYRZ2wuWinq6/paoKiKn65OzfMdzBtdMwLBeqY=; b=l3pbTbPzkWOPzmE1ZmvTzqonzC5BrH8FxtElzVmY7EmT4AZYDNbbsuJOZjoC/83ke7 vxjrq5Yy1U59LbBWKgFHixCXEupVzaKKNjAtTxvMuCw6B0iurQuNck0ytduLcPGdaFBO 5bKp/ZezjrCT+dyA0475R+wlhyzioAYDF+gzs= Received: by 10.227.2.72 with SMTP id 8mr5188553wbi.99.1314726566005; Tue, 30 Aug 2011 10:49:26 -0700 (PDT) Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id n20sm4815127wbh.33.2011.08.30.10.49.24 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 10:49:25 -0700 (PDT) From: "Len Holgate" To: "'Brian McKelvey'" , "'Patrick McManus'" References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> <0c9101cc672f$9dab6100$0a00a8c0@Venus> <1314725137.1799.28.camel@ds9> <0ABBCBD4-80E5-4AC4-8F19-87F199A184BC@gmail.com> Date: Tue, 30 Aug 2011 18:48:53 +0100 Message-ID: <0cd401cc673d$16031af0$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <0ABBCBD4-80E5-4AC4-8F19-87F199A184BC@gmail.com> Thread-Index: AcxnOvyQv6AUS97jS/eolV9qzmMmOgAAhXDQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 17:48:00 -0000 Agreed. > -----Original Message----- > From: Brian McKelvey [mailto:theturtle32@gmail.com] > Sent: 30 August 2011 18:34 > To: Patrick McManus > Cc: Len Holgate; Hybi > Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin > > I don't have a strong feeling on the origin header, only that > the version is incremented if there's a backward incompatible > change in the handshake. > > Sent from my iPhone > > On Aug 30, 2011, at 10:25 AM, Patrick McManus > wrote: > > > I'd much rather see the silly aesthetic name change reverted, so we > > could get some testing continuity and experience in order > to find actual > > meaningful shortcomings in the protocol. > > > > On Tue, 2011-08-30 at 10:21 -0700, Brian wrote: > >> Yes. The protocol version needs to be incremented when there is a > >> non-backward-compatible handshake change as well as when there is a > >> non-backward-compatible change to the framing. If we're > changing the > >> name of the origin header, we absolutely need to also increment the > >> version number. > >> > >> Brian > >> > >> > >> On Tue, Aug 30, 2011 at 9:12 AM, Len Holgate > > >> wrote: > >> A new server, yes, anything existing that thinks it > implements > >> protocol > >> version 8 now doesn't implement draft HyBi-11's version of > >> protocol version > >> 8... > >> > >> > >>> -----Original Message----- > >>> From: John Tamplin [mailto:jat@google.com] > >>> Sent: 30 August 2011 16:51 > >>> To: Len Holgate > >>> Cc: Alexey Melnikov; Hybi > >>> Subject: Re: [hybi] On changing Sec-WebSocket-Origin to > >> Origin > >>> > >>> On Tue, Aug 30, 2011 at 6:00 AM, Len Holgate > >>> wrote: > >>> > >>> > >>>> Maybe not bumping the version number was a mistake. > >>> The server can > >>>> handle either type of client, but this is not > >>> explicitly mentioned in > >>>> the draft. > >>> > >>> > >>> How? If the server is only looking for > >>> Sec-WebSocket-Origin (which a valid > >>> 08 draft server could be) then it wont see the Origin > >>> header from the v11 > >>> client. > >>> > >>> > >>> I server implementing v08 and v11 can look for both, the > >> same > >>> way existing servers support older versions of the protocol. > >>> > >>> -- > >>> John A. Tamplin > >>> Software Engineer (GWT), Google > >>> > >>> > >> > >> > >> > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > >> > >> > >> > >> _______________________________________________ > >> hybi mailing list > >> hybi@ietf.org > >> https://www.ietf.org/mailman/listinfo/hybi > > > > > From tobias.oberstein@tavendo.de Tue Aug 30 10:55: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 6F42D21F8DFE for ; Tue, 30 Aug 2011 10:55:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLVDrXaRmIxw for ; Tue, 30 Aug 2011 10:55:22 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id B8BCE21F8DE5 for ; Tue, 30 Aug 2011 10:55:22 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Tue, 30 Aug 2011 10:56:50 -0700 From: Tobias Oberstein To: Patrick McManus , Brian Date: Tue, 30 Aug 2011 10:55:49 -0700 Thread-Topic: [hybi] On changing Sec-WebSocket-Origin to Origin Thread-Index: AcxnOeP1OTPEr1hpQRWpbaeG0jRZ8wAA70DA Message-ID: <634914A010D0B943A035D226786325D422C0DFD243@EXVMBX020-12.exch020.serverdata.net> References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> <0c9101cc672f$9dab6100$0a00a8c0@Venus> <1314725137.1799.28.camel@ds9> In-Reply-To: <1314725137.1799.28.camel@ds9> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Hybi Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 30 Aug 2011 17:55:23 -0000 > I'd much rather see the silly aesthetic name change reverted, so we could= get > some testing continuity and experience in order to find actual meaningful > shortcomings in the protocol. +1 Maybe we could queue up a header name change for the future to merge into a= ny protocol change that would necessarily require bumping up the version (shou= ld there be such change). From tobias.oberstein@tavendo.de Tue Aug 30 11:16: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 E6D4921F8B86 for ; Tue, 30 Aug 2011 11:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.497 X-Spam-Level: X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id coh0k9C1GaMx for ; Tue, 30 Aug 2011 11:16:22 -0700 (PDT) Received: from EXHUB020-1.exch020.serverdata.net (exhub020-1.exch020.serverdata.net [206.225.164.28]) by ietfa.amsl.com (Postfix) with ESMTP id 970C221F84EC for ; Tue, 30 Aug 2011 11:16:21 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.209]) by EXHUB020-1.exch020.serverdata.net ([206.225.164.28]) with mapi; Tue, 30 Aug 2011 11:17:49 -0700 From: Tobias Oberstein To: Len Holgate Date: Tue, 30 Aug 2011 11:16:48 -0700 Thread-Topic: Autobahn test suite Thread-Index: AcxXwXL4sJmmuO3yQXO+aY/Hi+VaIwAYSzfAA8BrwIAABtLQcA== Message-ID: <634914A010D0B943A035D226786325D422C0DFD271@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D422BFBFBF15@EXVMBX020-12.exch020.serverdata.net> <0cc701cc673c$fec42d70$0a00a8c0@Venus> In-Reply-To: <0cc701cc673c$fec42d70$0a00a8c0@Venus> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Autobahn test suite 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, 30 Aug 2011 18:16:23 -0000 Len, > Thank you for providing such a useful test suite. It has complemented my > own unit testing of my implementation and has helped me nail a few bugs i= n > my code. Thanks! Thats nice to hear. =20 > Everything passes, well, except that 9.4.1 and 9.5.1 seem to randomly fai= l > (with the Autobahn test server as well as my own server). My server seems > to think that your client test closes the connection cleanly on it (TCP r= ecv > returns 0) part way through the test... This results in the 'default' err= or which > implies a timeout but I've tried increasing the timeout to 200 seconds an= d it > still fails after around 6 with the same issues; and sometimes it works..= . Few comments .. don't know if it helps: - those cases are really extreme (fragment size 64 with payload 8M, chopsiz= e =3D 1 octet) - did you run on loopback or remote? you could try different platform and/o= r loopback/remote .. - don't know your Python background: when you change a CaseXX.py, you need = to do "python setup.py install" again to get that into site-packages. Also, try a= dd a print timeout somewhere to see if the change really happens, because it's strange that it= doesnt obey - you can reenable wirelog for those cases (and decrease the payload to som= ething small;), so you can see what happens on wire - to really find out what happens, you'd probably needed to run the tests r= emote and sniff the traffic (wireshark/tcpdump) Lastly, your project is commercial, but you might nevertheless be intereste= d in putting it onto http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations I'll extend the test suite to cover UTF-8/Handshake (open/close) as soon as= I find time again .. should those issues persist for you, we can try to nail it down (t= hen, because for the moment, I'm a bit overwhelmed with other stuff) Cheers, Tobias From len.holgate@gmail.com Tue Aug 30 11:47: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 0E77021F8D3F for ; Tue, 30 Aug 2011 11:47:29 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1ck-kQgsLKO for ; Tue, 30 Aug 2011 11:47:28 -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 44E2921F8D36 for ; Tue, 30 Aug 2011 11:47:28 -0700 (PDT) Received: by wwf5 with SMTP id 5so4746510wwf.13 for ; Tue, 30 Aug 2011 11:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=5YnkafplK7eQOJnoozpE0CW3tJ8Fys5zE4EWckbz5ak=; b=rtu6UnC6PMGJd6/Jy/lJaT7dVena3hV+NC9E5b6zIcnWzOcYViSYtMYvH6gMT58jrU TeZdw/G/7/qHU6TFFszRFRAkR52NIk99/WjtDNjoOrDIfVDN+fb4KkOQGbGRvS5di9Lu ChkIWZvZ3rZ+fF/rqxcTGU1kyNwtn2pb6fmIw= Received: by 10.227.59.73 with SMTP id k9mr5432950wbh.81.1314730135720; Tue, 30 Aug 2011 11:48:55 -0700 (PDT) Received: from Venus (cpc4-glfd6-2-0-cust201.6-2.cable.virginmedia.com [80.5.68.202]) by mx.google.com with ESMTPS id fm9sm4852081wbb.44.2011.08.30.11.48.54 (version=SSLv3 cipher=OTHER); Tue, 30 Aug 2011 11:48:55 -0700 (PDT) From: "Len Holgate" To: "'Tobias Oberstein'" References: <634914A010D0B943A035D226786325D422BFBFBF15@EXVMBX020-12.exch020.serverdata.net> <0cc701cc673c$fec42d70$0a00a8c0@Venus> <634914A010D0B943A035D226786325D422C0DFD271@EXVMBX020-12.exch020.serverdata.net> Date: Tue, 30 Aug 2011 19:48:22 +0100 Message-ID: <0cfb01cc6745$659994b0$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <634914A010D0B943A035D226786325D422C0DFD271@EXVMBX020-12.exch020.serverdata.net> Thread-Index: AcxXwXL4sJmmuO3yQXO+aY/Hi+VaIwAYSzfAA8BrwIAABtLQcAABRtyg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: hybi@ietf.org Subject: Re: [hybi] Autobahn test suite 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, 30 Aug 2011 18:47:29 -0000 > - those cases are really extreme (fragment size 64 with > payload 8M, chopsize = 1 octet) Yes, I know. The issue doesn't seem to be on my side anymore, but it may well be. > - did you run on loopback or remote? you could try different > platform and/or loopback/remote .. So far it's all been on loopback. When I get a moment I may run it remotely and grab the wireshark logs. > - don't know your Python background: when you change a > CaseXX.py, you need to do > "python setup.py install" again to get that into > site-packages. Also, try add a print timeout > somewhere to see if the change really happens, because it's > strange that it doesnt obey I worked that out eventually. The timeout does seem to be changed as the error then states the new timeout value. The actual test still terminates after 6 secs or so though. > - you can reenable wirelog for those cases (and decrease the > payload to something small;), I've enabled the wirelog, that didn't show much, except that the test thinks it has sent everything and started the timeout and then that I close the connection. At present, since it's the only failing test I'm not going to spend that much time on it. Are any of the other tests multi-fragment with 1 byte chopsize? If not I'll add one that's a bit more manageable and see if I can find out what's wrong in my code. > Lastly, your project is commercial, but you might > nevertheless be interested in putting it > onto > > http://en.wikipedia.org/wiki/Comparison_of_WebSocket_implementations Ok, I wasn't sure if commercial stuff could be added. > I'll extend the test suite to cover UTF-8/Handshake > (open/close) as soon as I find time > again .. should those issues persist for you, we can try to > nail it down (then, because > for the moment, I'm a bit overwhelmed with other stuff) I know the feeling. More tests would be good, but the test suite as it stands has been very useful to me. Len From Martin.Thomson@commscope.com Tue Aug 30 16:18: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 DE69821F8C7E for ; Tue, 30 Aug 2011 16:18:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0JjE6I0WCmZy for ; Tue, 30 Aug 2011 16:18:51 -0700 (PDT) Received: from cdcsmgw02.commscope.com (fw.commscope.com [198.135.207.129]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10D21F8C81 for ; Tue, 30 Aug 2011 16:18:50 -0700 (PDT) X-AuditID: 0a0404e9-b7cd4ae000004b3f-e4-4e5d702e2807 Received: from ACDCE7HC1.commscope.com ( [10.86.20.102]) by cdcsmgw02.commscope.com (Symantec Brightmail Gateway) with SMTP id 5E.5D.19263.E207D5E4; Tue, 30 Aug 2011 18:20:14 -0500 (CDT) Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.159.2; Tue, 30 Aug 2011 18:20:14 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 31 Aug 2011 07:20:11 +0800 From: "Thomson, Martin" To: Alexey Melnikov , Takeshi Yoshino Date: Wed, 31 Aug 2011 07:20:30 +0800 Thread-Topic: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.txt Thread-Index: AcxnBFK/MXfz03/STtWBbJ1ZugrTRQAZqzoQ Message-ID: <8B0A9FCBB9832F43971E38010638454F040F1C1332@SISPE7MB1.commscope.com> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5CB8F1.4080301@isode.com> In-Reply-To: <4E5CB8F1.4080301@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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, 30 Aug 2011 23:18:52 -0000 On 2011-08-30 at 20:18:25, Alexey Melnikov wrote: > I think I got it right this time: >=20 > NZDIGIT =3D "1" / "2" / "3" / "4" / "5" / "6" / > "7" / "8" / "9" > version =3D DIGIT | (NZDIGIT DIGIT) | > ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) > ; Limited to 0-255 range Not quite: '/' instead of '|'. And you can do ("2" ((("0"/"1"/"2"/"3"/"4") DIGIT)/("5" ("0"/"1"/"2"/"3"/"4= "/"5")))) if you want to be properly pedantic. Either that, or simply: version =3D 1*3DIGIT ; 0-255 only --Martin From tyoshino@google.com Tue Aug 30 19:50: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 65BB521F8CF8 for ; Tue, 30 Aug 2011 19:50:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.891 X-Spam-Level: X-Spam-Status: No, score=-105.891 tagged_above=-999 required=5 tests=[AWL=0.085, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzkiq5r5pGdC for ; Tue, 30 Aug 2011 19:50: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 A6F3F21F8C7F for ; Tue, 30 Aug 2011 19:50:33 -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 p7V2q28S024283 for ; Tue, 30 Aug 2011 19:52:02 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314759122; bh=zw8fvIPotLO2/nxVCvVaQK01fZ4=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=d+zdBJD4cTErk4paE4YyumnZ6GYm+QTM60QW8p2XKQqo8HjXDDq4RRCTh05qw6qpl MNsp95+t/Y+iG184agzAw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=OaaYbkIu2vj72+G6J8jD/8y/8nELADyjWXTX/8yUP8s5smWDXYyKsoRoXfbQ8Yd3r Lz36Fh/uvIDfF0jOV73gQ== Received: from gxk23 (gxk23.prod.google.com [10.202.11.23]) by wpaz13.hot.corp.google.com with ESMTP id p7V2pfVe011985 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 30 Aug 2011 19:52:01 -0700 Received: by gxk23 with SMTP id 23so236703gxk.14 for ; Tue, 30 Aug 2011 19:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f2yKPpxUiF2fGe8DL30A3k+Iro0usOEzLEnnh9txIl8=; b=qFNmfMkKTuXfLVBhCU3tJNspT0djxzhi7a+hFugHuADH12O/uCKcMp5oXeLBkjK6wr J89MjYnsfx7D1AIZSR3w== Received: by 10.150.114.16 with SMTP id m16mr7446156ybc.399.1314759120973; Tue, 30 Aug 2011 19:52:00 -0700 (PDT) Received: by 10.150.114.16 with SMTP id m16mr7446149ybc.399.1314759120793; Tue, 30 Aug 2011 19:52:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.151.44.11 with HTTP; Tue, 30 Aug 2011 19:51:39 -0700 (PDT) In-Reply-To: <8B0A9FCBB9832F43971E38010638454F040F1C1332@SISPE7MB1.commscope.com> References: <20110823102713.23958.79728.idtracker@ietfa.amsl.com> <4E538213.7020207@isode.com> <4E5CB8F1.4080301@isode.com> <8B0A9FCBB9832F43971E38010638454F040F1C1332@SISPE7MB1.commscope.com> From: Takeshi Yoshino Date: Wed, 31 Aug 2011 11:51:39 +0900 Message-ID: To: "Thomson, Martin" Content-Type: multipart/alternative; boundary=000e0cd5d0ea5c2fa004abc4364f X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-11.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: Wed, 31 Aug 2011 02:50:34 -0000 --000e0cd5d0ea5c2fa004abc4364f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 30, 2011 at 19:18, Alexey Melnikov wrote: > implied WSP rule -> implied LWS rule ? >> > > Changed "implied WSP" to "implied *LWS" as per RFC 2616. Thanks I think I've clarified this by the following new text: > Looks good. On Wed, Aug 31, 2011 at 08:20, Thomson, Martin wrote: > On 2011-08-30 at 20:18:25, Alexey Melnikov wrote: > > NZDIGIT = "1" / "2" / "3" / "4" / "5" / "6" / > > "7" / "8" / "9" > > version = DIGIT | (NZDIGIT DIGIT) | > > ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) > > ; Limited to 0-255 range > > Not quite: '/' instead of '|'. > This will be in the section 4.3. where RFC2616 ABNF is used. OTOH, in 4.2.2.-3-4, there's no note about which ABNF is used. Please add the note, or I think we can remove the rules in this subsection as it's also defined in 4.3. > And you can do ("2" ((("0"/"1"/"2"/"3"/"4") DIGIT)/("5" > ("0"/"1"/"2"/"3"/"4"/"5")))) if you want to be properly pedantic. > > Either that, or simply: > version = 1*3DIGIT ; 0-255 only I'm fine with this simple version, too. Maybe we might want to add "no leading zeros" note. Thanks, Takeshi --000e0cd5d0ea5c2fa004abc4364f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Aug 30, 2011 at 19:18, Alexey Melnikov=A0<alexey.melnikov@= isode.com>=A0wrote:
implied WSP rule -> implied LWS rule ?

Changed= "implied WSP" to "implied *LWS" as per RFC 2616.

Thanks

I think I've clarified this by the following new text:

Looks good.
=A0
On Wed, Aug 31, 2011 at 08:20, Thomson, Martin = <Marti= n.Thomson@commscope.com> wrote:
On 2011-08-30 at 20:18:25, Alexey Melni= kov wrote:
> =A0 =A0 =A0 =A0 =A0 =A0 NZDIGIT =A0 =A0 =A0 =3D =A0"= ;1" / "2" / "3" / "4" / "5" / = "6" /
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"7&quo= t; / "8" / "9"
> =A0 =A0 =A0 =A0 =A0 =A0 version =3D DIGIT | (NZDIGIT DIGIT) |
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ("1" DIGIT DIGIT= ) | ("2" DIGIT DIGIT)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ; Limited to 0-255 range
Not quite: '/' instead of '|'.
<= br>
This will be in the section 4.3. where RFC2616 ABNF is used.<= /div>

OTOH, in 4.2.2.-3-4, there's no note abou= t which ABNF is used. Please add the note, or I think we can remove the rul= es in this subsection as it's also defined in 4.3.
=A0
And you can do ("2&= quot; ((("0"/"1"/"2"/"3"/"4&qu= ot;) DIGIT)/("5" ("0"/"1"/"2"/"= ;3"/"4"/"5")))) if you want to be properly pedanti= c.

Either that, or simply:
version =3D 1*3DIGIT ; 0-255 only

I'm f= ine with this simple version, too. Maybe we might want to add "no lead= ing zeros" note.

Thanks,
Takeshi
--000e0cd5d0ea5c2fa004abc4364f-- From alexey.melnikov@isode.com Wed Aug 31 03:12: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 7BDD221F8B14 for ; Wed, 31 Aug 2011 03:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dy-ftyrtfLKu for ; Wed, 31 Aug 2011 03:12:13 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id A26DA21F8B13 for ; Wed, 31 Aug 2011 03:12:12 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 31 Aug 2011 11:13:40 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5E0948.8090308@isode.com> Date: Wed, 31 Aug 2011 11:13:28 +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: Len Holgate References: <4E47FDB5.6070207@isode.com> <4E482192.7050507@gmail.com> <0ba401cc66e8$b7293a40$0a00a8c0@Venus> <4E5CB106.8020108@isode.com> <0bcd01cc66fb$b5320380$0a00a8c0@Venus> <0c9101cc672f$9dab6100$0a00a8c0@Venus> <1314725137.1799.28.camel@ds9> <0ABBCBD4-80E5-4AC4-8F19-87F199A184BC@gmail.com> <0cd401cc673d$16031af0$0a00a8c0@Venus> In-Reply-To: <0cd401cc673d$16031af0$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Hybi' Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin 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, 31 Aug 2011 10:12:13 -0000 The version will be incremented in -13, so the error of not incrementing it earlier should be short lived. Len Holgate wrote: >Agreed. > > >>-----Original Message----- >>From: Brian McKelvey [mailto:theturtle32@gmail.com] >>Sent: 30 August 2011 18:34 >>To: Patrick McManus >>Cc: Len Holgate; Hybi >>Subject: Re: [hybi] On changing Sec-WebSocket-Origin to Origin >> >>I don't have a strong feeling on the origin header, only that >>the version is incremented if there's a backward incompatible >>change in the handshake. >> >> From alexey.melnikov@isode.com Wed Aug 31 07:47: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 925B621F8B9C for ; Wed, 31 Aug 2011 07:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.898 X-Spam-Level: X-Spam-Status: No, score=-100.898 tagged_above=-999 required=5 tests=[AWL=-1.560, BAYES_00=-2.599, FRT_LOLITA1=1.865, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SuGD-w7h4KUH for ; Wed, 31 Aug 2011 07:47:21 -0700 (PDT) Received: from rufus.isode.com (rufus.isode.com [62.3.217.251]) by ietfa.amsl.com (Postfix) with ESMTP id C55F221F8B91 for ; Wed, 31 Aug 2011 07:47:20 -0700 (PDT) Received: from [192.168.1.124] ((unknown) [62.3.217.253]) by rufus.isode.com (submission channel) via TCP with ESMTPA id ; Wed, 31 Aug 2011 15:48:50 +0100 X-SMTP-Protocol-Errors: NORDNS Message-ID: <4E5E497F.20705@isode.com> Date: Wed, 31 Aug 2011 15:47:27 +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: <4E5CBEDE.1030608@isode.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Suggested new WS status code: 1008 "Extension Required" 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, 31 Aug 2011 14:47:21 -0000 Greg Wilkins wrote: >On 30 August 2011 20:43, Alexey Melnikov wrote: > =20 > >>I=F1aki Baz Castillo wrote: =20 >> >>>Following the rationale in other thread, I suggest the following new >>>WS status code: >>> >>> 1008 >>> =20 >>> >>I am personally Ok with adding this. But I would like to hear some comment= s >>from the WG. >> =20 >> I've added it as 1010. >I don't have any issues with such a code.... other than my concern >that we have a few specific codes, but no general s**t happened close >code. >I'm not sure the server can do anything meaningful with the code, >other than log it to gather evidence that it needs to implement the >missing extension. > Right. =20 From phil127@gmail.com Wed Aug 31 09:17: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 D0FCE21F8B5E for ; Wed, 31 Aug 2011 09:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.539 X-Spam-Level: X-Spam-Status: No, score=-3.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFWYw1JKMUmG for ; Wed, 31 Aug 2011 09:17:16 -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 CDBB721F8BF4 for ; Wed, 31 Aug 2011 09:17:15 -0700 (PDT) Received: by bkar4 with SMTP id r4so1210121bka.31 for ; Wed, 31 Aug 2011 09:18:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=pxtTKgTbhSBt676xBSm3xsojcmFDtyQfyZFGc2mXQtI=; b=AtPWnJkSfa3dSgFv28rka+jkiJH5nHv7QUA8SghL6H0N4Md+kVv3LqFg4+nZvBwRXC RCZ9HUMG9UqMac+24B+Hz9qP0pc7gdeRXR0FNfP1utRVZPotn5cBc6i0q5by0qpY6g6X 0PSY98Mmkn8mn1lmjMUJqlWx2o+Mj2tzPgp5Y= Received: by 10.204.135.18 with SMTP id l18mr380624bkt.341.1314807518073; Wed, 31 Aug 2011 09:18:38 -0700 (PDT) Received: from [212.201.70.0] ([212.201.70.0]) by mx.google.com with ESMTPS id h26sm432143bkt.52.2011.08.31.09.18.36 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Aug 2011 09:18:36 -0700 (PDT) Message-ID: <4E5E5EDA.6000606@gmail.com> Date: Wed, 31 Aug 2011 18:18:34 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: hybi@ietf.org References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> In-Reply-To: <4E5D04F8.30801@isode.com> X-Enigmail-Version: 1.3.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 16:17:16 -0000 I agree with Inaki that an error code for unsupported subprotocols would be useful. But I think it would be cleaner if the server would send it right as part of the handshake instead of the client. So far it looks to me as if WS connections that make use of sub protocols serve completely different use cases than those that don't. On the one hand, we have proprietary, "internal" endpoints that will solely be implementation details of a web application. The actual protocol used on top of WS will be tailor-made to that specific web-application and may change any time without notice. In fact, the application might even switch to a completely different technology than WS any time. Both WS client and server will be controlled by the same developers. As defining a formal subprotocol in such a case doesn't make much sense, the protocol header will likely not be used. On the other hand, we may have standardized, "external", WS-based APIs, the same way e.g. SOAP and OAUTH can be layered on top of HTTP today. Here, clients and servers from different parties will have to speak with each other, some of which might not even run in a browser or might otherwise be hard to update. Here, standardized subprotocols and the negotiation mechanism will be of much use. However, I don't see much overlap in those two use-cases right now. I don't see many cases where a server that doesn't support a certain standardized protocols could reasonably fall back to a proprietary default protocol. This also makes the subprotocol header less useful IMO, since it implies that the client doesn't actually lists all protocols it supports in the header - it might or might not also support an unnamed, proprietary protocol. Why can't we take the presence of a subprotocol header in the client request as a hint that the client wants to speak a "standard" protocol? Then it would be reasoneable for the server to reject the connection if none of those standard protocols are supported. However, if the client sends no protocol header, then the server can still accept the connection and speak an unnamed, proprietary protocol. Am 30.08.2011 17:42, schrieb Alexey Melnikov: > John Tamplin wrote: > >> On Tue, Aug 30, 2011 at 7:29 AM, Iñaki Baz Castillo > > wrote: >> >> 2011/8/30 Alexey Melnikov > >: >> > If the client really expected the extensions to be mandatory, it >> has to send >> > Close. >> >> A new close status code just to say "the WS protocol negotiation has >> obviously failed so I close the connection"? >> >> >> We don't need a separate close code for every possible reason -- >> there will be too many, and we will certainly miss many ones that >> would actually be used. Instead, we need more generic error codes >> describing categories of failures. > > I think we need both. More specific error codes are better, if > introduced early. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From ibc@aliax.net Wed Aug 31 09:30: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 E506021F8D5B for ; Wed, 31 Aug 2011 09:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W+u8k8uvupNb for ; Wed, 31 Aug 2011 09:30:59 -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 4834921F8D54 for ; Wed, 31 Aug 2011 09:30:59 -0700 (PDT) Received: by qyk34 with SMTP id 34so3109646qyk.10 for ; Wed, 31 Aug 2011 09:32:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.85 with SMTP id h21mr484537qci.46.1314808349576; Wed, 31 Aug 2011 09:32:29 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Wed, 31 Aug 2011 09:32:29 -0700 (PDT) In-Reply-To: <4E5E5EDA.6000606@gmail.com> References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> Date: Wed, 31 Aug 2011 18:32:29 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Philipp Serafin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 16:31:00 -0000 2011/8/31 Philipp Serafin : > Why can't we take the presence of a subprotocol header in the client > request as a hint that the client wants to speak a "standard" protocol? > Then it would be reasoneable for the server to reject the connection if > none of those standard protocols are supported. > However, if the client sends no protocol header, then the server can > still accept the connection and speak an unnamed, proprietary protocol. That's exactly what I meant, but I did it worse :) Thanks a lot. --=20 I=C3=B1aki Baz Castillo From bruce@callenish.com Wed Aug 31 11:11: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 7BF6421F8E6D for ; Wed, 31 Aug 2011 11:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOKqzpuPlEIn for ; Wed, 31 Aug 2011 11:11:57 -0700 (PDT) Received: from biz82.inmotionhosting.com (biz82.inmotionhosting.com [74.124.202.87]) by ietfa.amsl.com (Postfix) with ESMTP id 9A1C821F8E6B for ; Wed, 31 Aug 2011 11:11:57 -0700 (PDT) Received: from [24.108.144.160] (helo=[192.168.145.11]) by biz82.inmotionhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1QypHz-00017m-6b; Wed, 31 Aug 2011 11:13:27 -0700 Message-ID: <4E5E79C4.2080100@callenish.com> Date: Wed, 31 Aug 2011 11:13:24 -0700 From: Bruce Atherton User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Philipp Serafin References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> In-Reply-To: <4E5E5EDA.6000606@gmail.com> Content-Type: text/plain; charset=UTF-8; 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] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 18:11:58 -0000 On 31/08/2011 9:18 AM, Philipp Serafin wrote: > I agree with Inaki that an error code for unsupported subprotocols would > be useful. But I think it would be cleaner if the server would send it > right as part of the handshake instead of the client. > > So far it looks to me as if WS connections that make use of sub > protocols serve completely different use cases than those that don't. > > On the one hand, we have proprietary, "internal" endpoints that will > solely be implementation details of a web application. The actual > protocol used on top of WS will be tailor-made to that specific > web-application and may change any time without notice. In fact, the > application might even switch to a completely different technology than > WS any time. Both WS client and server will be controlled by the same > developers. > As defining a formal subprotocol in such a case doesn't make much sense, > the protocol header will likely not be used. I think your analysis is mixing a few concerns. To me, there are two questions to answer when considering this issue: Is the subprotocol custom or standard? Is it running on an application-specific endpoint or a standard browser/server? When both the subprotocol and the endpoints are custom, there are still benefits to using the subprotocol field. It allows versioning, for example. It also allows you to limit the subprotocols used at the endpoints so you can support things like pricing based on subprotocols deployed to a particular customer. When the subprotocol is custom and the endpoints are standard, then a subprotocol layers on top of the default subprotocol. This may be useful if, for example, you want to deploy a vendor's widget that uses Websockets to your page. It allows your server to implement the specific protocol for talking to the widget. And consider if you had multiple widgets each from a different vendor on the same page. I would think that browsers will deal with an attempt to open multiple connections to the same URL with different subprotocols by MUXing them. I could be wrong about that, but it would provide a nice mechanism for dealing with the multiple vendor problem. When the subprotocol is standard and one of the endpoints is custom, there is still a benefit to specifying a subprotocol as it enhances the chances of interoperability with other implementations. When both the subprotocol and the endpoints are standard, right now it is the same as when the subprotocol is custom. But in the future, browsers and servers may provide architectures for extending the subprotocols they support. Imagine tunneling SIP and RTP over Websockets so that everyone visiting a particular web page was given the option of joining a conference call. That may be a useful enough feature that eventually browsers actually include support for the SIP and RTP subprotocols natively. Regarding the server sending the error code, that would eliminate the ability for a client to fall back to the raw binary/text subprotocol if the server doesn't support any of the specific subprotocols. I don't think that is a good idea. From ibc@aliax.net Wed Aug 31 11:28: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 9863121F8DBE for ; Wed, 31 Aug 2011 11:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pTDCM5t6KEKz for ; Wed, 31 Aug 2011 11:28:00 -0700 (PDT) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADF821F8DB9 for ; Wed, 31 Aug 2011 11:27:59 -0700 (PDT) Received: by qwc9 with SMTP id 9so961847qwc.27 for ; Wed, 31 Aug 2011 11:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.197.133 with SMTP id ek5mr566499qab.281.1314815370608; Wed, 31 Aug 2011 11:29:30 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Wed, 31 Aug 2011 11:29:30 -0700 (PDT) In-Reply-To: <4E5E79C4.2080100@callenish.com> References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> Date: Wed, 31 Aug 2011 20:29:30 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Bruce Atherton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 18:28:00 -0000 2011/8/31 Bruce Atherton : > Imagine tunneling SIP and RTP over Websockets No please. SIP over WebSocket and RTP over UDP as WebRTC claims :) --=20 I=C3=B1aki Baz Castillo From phil127@gmail.com Wed Aug 31 11:30: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 4245E21F8DED for ; Wed, 31 Aug 2011 11:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ENBFM4dgscuZ for ; Wed, 31 Aug 2011 11:30:25 -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 7940F21F8DC7 for ; Wed, 31 Aug 2011 11:30:25 -0700 (PDT) Received: by qyk34 with SMTP id 34so3205732qyk.10 for ; Wed, 31 Aug 2011 11:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PGCPzQXYH2esYD/ulMjry+vEJHxJP54Qs3iKhesoz1k=; b=fpqfFLtdfWzYrfkn2G562SThpKQ7/YrNeG+DKnJ4zPA5RVlvZzZdo3yXMbth2MK5Af JQNjrVPEKZzGZ4ryYciGJhtV93wPP4rsjSxni8sKCHR65HKj0VnoAOjS2Wc4Ctn8b5X1 6BZiDskYOtOc+3YKjHOs3Ox84e4JfjXHMPkOo= Received: by 10.229.63.140 with SMTP id b12mr613791qci.27.1314815516094; Wed, 31 Aug 2011 11:31:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.44.21 with HTTP; Wed, 31 Aug 2011 11:31:26 -0700 (PDT) In-Reply-To: <4E5E79C4.2080100@callenish.com> References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> From: Philipp Serafin Date: Wed, 31 Aug 2011 20:31:26 +0200 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=0016e649bcf6c8335004abd157fe Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 18:30:26 -0000 --0016e649bcf6c8335004abd157fe Content-Type: text/plain; charset=UTF-8 > > > I think your analysis is mixing a few concerns. To me, there are two > questions to answer when considering this issue: Is the subprotocol custom > or standard? Is it running on an application-specific endpoint or a standard > browser/server? > I'm sorry for being imprecise. When talking about developer-controlled clients in the web application case, I meant the client-side part of web apps that still run inside the browser. So the developers have control of the server and the javascript component that runs inside the browser, but NOT of the actual WS client implementation. > Regarding the server sending the error code, that would eliminate the > ability for a client to fall back to the raw binary/text subprotocol if the > server doesn't support any of the specific subprotocols. I don't think that > is a good idea. > > But how would such a fallback look like? Unless your talking about a CS year one chat server, "text" is no proper protocol on itself, like "XML" and "JSON" are not enough to know the type of a document - you need to layer some additional structure on top of that. If a client sends a protocol header, I don't see why it can't indicate ALL protocols it supports for this connection. If the server supports none of those protocols, and if neither client nor server are part of a single web application (so there is no implicit custom protocol they could both understand), I don't see how a sucessful connection could be established. As I understood it, subprotocol names don't need to be registered but can be chosen ad-hoc. So it shouldn't be hard to choose a protocol name even if you just want to use it for the public web api of your site. I agree with your other use cases though. --0016e649bcf6c8335004abd157fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think your analysis is mixing a few concerns. To me, there are two questi= ons to answer when considering this issue: Is the subprotocol custom or sta= ndard? Is it running on an application-specific endpoint or a standard brow= ser/server?

I'm sorry for being imprecise. When ta= lking about developer-controlled clients in the web application case, I mea= nt the client-side part of web apps that still run inside the browser. So t= he developers have control of the server and the javascript component that = runs inside the browser, but NOT of the actual WS client implementation.=C2= =A0

=C2=A0
Regarding the server sending the error code, that would eliminate the abili= ty for a client to fall back to the raw binary/text subprotocol if the serv= er doesn't support any of the specific subprotocols. I don't think = that is a good idea.


But how would such a fallback look like? Unless= your talking about a CS year one chat server, "text" is no prope= r protocol on itself, like "XML" and "JSON" are not eno= ugh to know the type of a document - you need to layer some additional stru= cture on top of that.=C2=A0

If a client sends a protocol header, I don't see wh= y it can't indicate ALL protocols it supports for this connection. If t= he server supports none of those protocols, and if neither client nor serve= r are part of a single web application (so there is no implicit custom prot= ocol they could both understand), I don't see how a sucessful connectio= n could be established.

As I understood it, subprotocol names don't need to= be registered but can be chosen ad-hoc. So it shouldn't be hard to cho= ose a protocol name even if you just want to use it for the public web api = of your site.

I agree with your other use cases though.
--0016e649bcf6c8335004abd157fe-- From internet-drafts@ietf.org Wed Aug 31 11:42: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 28A8121F8DF0; Wed, 31 Aug 2011 11:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fePKAgdiPxML; Wed, 31 Aug 2011 11:42:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4CE21F8DA4; Wed, 31 Aug 2011 11:42:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2011 11:42:07 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-thewebsocketprotocol-13.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: Wed, 31 Aug 2011 18:42:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTT= P Working Group of the IETF. Title : The WebSocket protocol Author(s) : Ian Fette Alexey Melnikov Filename : draft-ietf-hybi-thewebsocketprotocol-13.txt Pages : 73 Date : 2011-08-31 The WebSocket protocol enables two-way communication between a client running untrusted code running in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the Origin-based security model commonly used by Web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g. using XMLHttpRequest or <iframe>s and long polling). Please send feedback to the hybi@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-13= .txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-thewebsocketprotocol-13.= txt From stpeter@stpeter.im Wed Aug 31 11:48: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 4749721F8E6A for ; Wed, 31 Aug 2011 11:48:18 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hR3JpHm0Hlcl for ; Wed, 31 Aug 2011 11:48:17 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id A784C21F8E68 for ; Wed, 31 Aug 2011 11:48:17 -0700 (PDT) Received: from leavealone.cisco.com (unknown [128.107.239.233]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D6E074174A for ; Wed, 31 Aug 2011 12:52:25 -0600 (MDT) Message-ID: <4E5E824A.3020101@stpeter.im> Date: Wed, 31 Aug 2011 12:49:46 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: hybi@ietf.org References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> In-Reply-To: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.3.1 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [hybi] what's next 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, 31 Aug 2011 18:48:18 -0000 On 8/31/11 12:42 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the BiDirectional or Server-Initiated HTTP Working Group of the IETF. > > Title : The WebSocket protocol > Author(s) : Ian Fette > Alexey Melnikov > Filename : draft-ietf-hybi-thewebsocketprotocol-13.txt > Pages : 73 > Date : 2011-08-31 First, a big thank-you to Ian and Alexey for submitting -13 so quickly! As far as we know, this version addresses all of the feedback and open issues resulting from the Working Group Last Call, and is ready for presentation to the IESG. The chairs will update the "proto writeup" tomorrow morning (European time) and then I will issue the IESG ballot, for consideration on the IESG telechat next Thursday. Peter -- Peter Saint-Andre https://stpeter.im/ From ibc@aliax.net Wed Aug 31 12:20: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 E596721F8F33 for ; Wed, 31 Aug 2011 12:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Nade-I8oyU0 for ; Wed, 31 Aug 2011 12:20:28 -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 510DC21F8F12 for ; Wed, 31 Aug 2011 12:20:28 -0700 (PDT) Received: by qyk35 with SMTP id 35so692985qyk.10 for ; Wed, 31 Aug 2011 12:21:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.42.14 with SMTP id q14mr642895qce.122.1314818518803; Wed, 31 Aug 2011 12:21:58 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Wed, 31 Aug 2011 12:21:57 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> Date: Wed, 31 Aug 2011 21:21:57 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Philipp Serafin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 19:20:29 -0000 2011/8/31 Philipp Serafin : > If a client sends a protocol header, I don't see why it can't indicate AL= L > protocols it supports for this connection. If the server supports none of > those protocols, and if neither client nor server are part of a single we= b > application (so there is no implicit custom protocol they could both > understand), I don't see how a sucessful connection could be established. Of course. Say the opposite means allowing ugly/annoying pseudo negotiation= s. --=20 I=C3=B1aki Baz Castillo From jat@google.com Wed Aug 31 12:25: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 63CC421F8F5F for ; Wed, 31 Aug 2011 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.778 X-Spam-Level: X-Spam-Status: No, score=-105.778 tagged_above=-999 required=5 tests=[AWL=-0.102, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id arV5z+Y576pF for ; Wed, 31 Aug 2011 12:25:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id CB3CF21F8F46 for ; Wed, 31 Aug 2011 12:25:34 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p7VJR4pb007717 for ; Wed, 31 Aug 2011 12:27:04 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314818824; bh=PStP/iLzKRHF1imtHROhRYtD1Tg=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jSahfzAo6YSGggSY7K1PVG0X/9/GIlTlLP9ImUnX6tWwQ9WWZaxA6lj8LoD62A5Qu RElRsLnkzMbHaA1lzKUkw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=uvI9A9RuC66dLde1yblGvG5AFg+rDnluAEYCvHw/PCG5GCpo3P/2B2bWdsksnfca8 ZJUNDz+G59NAfmNFuMa4g== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq5.eem.corp.google.com with ESMTP id p7VJO1ut030914 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 12:27:03 -0700 Received: by qwj9 with SMTP id 9so839107qwj.21 for ; Wed, 31 Aug 2011 12:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=uP3Cfkeyq/uoR/zLbguBmICva5lfjPGUKK8N3Nn2zpU=; b=hrnWEK/SXTj5kljVI/bFayw1w1JAjODD6W1cRAjTDPKEvsfDdjphUtYgfXb9EPbTvD 4UKgrJUlWfudwdNuGaUQ== Received: by 10.229.29.9 with SMTP id o9mr625600qcc.265.1314818822622; Wed, 31 Aug 2011 12:27:02 -0700 (PDT) Received: by 10.229.29.9 with SMTP id o9mr625588qcc.265.1314818822323; Wed, 31 Aug 2011 12:27:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.137 with HTTP; Wed, 31 Aug 2011 12:26:42 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> From: John Tamplin Date: Wed, 31 Aug 2011 15:26:42 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0016364274c0d93dbf04abd21cba X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 19:25:40 -0000 --0016364274c0d93dbf04abd21cba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2011 at 3:21 PM, I=C3=B1aki Baz Castillo wr= ote: > 2011/8/31 Philipp Serafin : > > If a client sends a protocol header, I don't see why it can't indicate > ALL > > protocols it supports for this connection. If the server supports none = of > > those protocols, and if neither client nor server are part of a single > web > > application (so there is no implicit custom protocol they could both > > understand), I don't see how a sucessful connection could be establishe= d. > > Of course. Say the opposite means allowing ugly/annoying pseudo > negotiations. Personally, I see little value at this point for subprotocols. They basically represent an agreement between the application end points for a protocol to run on top of WS. Since the app developer owns both endpoints, they can already use whatever protocol they like. It is a convenient place to send selection between multiple protocols out-of-band, but no more. Maybe in the future there are standard subprotocols, and you could have som= e off-the-shelf product to offload those subprotocols, but initially there seems to be little value so I don' t think we need to go overboard imaginin= g things that would be useful with only limited experience with WS itself. --=20 John A. Tamplin Software Engineer (GWT), Google --0016364274c0d93dbf04abd21cba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 31, 2011 at 3:21 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
2011/8/31 Philipp Serafin <phil127@gmail.com>:
> If a client sends a protocol header, I don'= ;t see why it can't indicate ALL
> protocols it supports for this connection. If the server supports none= of
> those protocols, and if neither client nor server are part of a single= web
> application (so there is no implicit custom protocol they could both > understand), I don't see how a sucessful connection could be estab= lished.

Of course. Say the opposite means allowing ugly/annoying pseudo negot= iations.

Personally, I see little value at = this point for subprotocols. =C2=A0They basically represent an agreement be= tween the application end points for a protocol to run on top of WS. =C2=A0= Since the app developer owns both endpoints, they can already use whatever = protocol they like. =C2=A0It is a convenient place to send selection betwee= n multiple protocols out-of-band, but no more.

Maybe in the future there are standard subprotocols, an= d you could have some off-the-shelf product to offload those subprotocols, = but initially there seems to be little value so I don' t think we need = to go overboard imagining things that would be useful with only limited exp= erience with WS itself.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--0016364274c0d93dbf04abd21cba-- From jmason@rim.com Wed Aug 31 12:33: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 39DA221F8F25 for ; Wed, 31 Aug 2011 12:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.776 X-Spam-Level: X-Spam-Status: No, score=-5.776 tagged_above=-999 required=5 tests=[AWL=-0.573, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFzBxxCochCf for ; Wed, 31 Aug 2011 12:33:57 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id A5EF221F8EE5 for ; Wed, 31 Aug 2011 12:33:57 -0700 (PDT) X-AuditID: 0a41282f-b7ce3ae000000258-3e-4e5e8ceaf561 Received: from XHT103CNC.rim.net (xht103cnc.rim.net [10.65.22.51]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id 3A.FE.00600.AEC8E5E4; Wed, 31 Aug 2011 19:35:07 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT103CNC.rim.net ([fe80::f9b5:81ad:6043:dcb%11]) with mapi; Wed, 31 Aug 2011 15:35:27 -0400 From: Joe Mason To: Alexey Melnikov , Greg Wilkins Date: Wed, 31 Aug 2011 15:35:24 -0400 Thread-Topic: [hybi] Suggested new WS status code: 1008 "Extension Required" Thread-Index: Acxn7RtwyhGip+sgRQy+YmjAUxmf9gAJ8ybg Message-ID: References: <4E5CBEDE.1030608@isode.com> <4E5E497F.20705@isode.com> In-Reply-To: <4E5E497F.20705@isode.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrEKsWRmVeSWpSXmKPExsXC5ShmrPu6J87P4OttZosZq4ssJvQ+Y7F4 /3IbkwOzx5IlP5k8/j+dw+5xqtkwgDmqgdEmMS8vvySxJFUhJbU42VbJJzU9MUchoCizLDG5 UsElszg5JzEzN7VISSEzxVbJREmhICcxOTU3Na/EVimxoCA1L0XJjksBA9gAlWXmKaTmJeen ZOal2yp5BvvrWliYWuoaKtnpIoGEf9wZm3ZaFPxirLj34x1TA+NRxi5GTg4JAROJ5Q0bmSBs MYkL99azdTFycQgJ9DBJXGv5wQjhLGKUuPyxjRmkik1AQeLz4QdgHSICwRKd/Z3sIDazgLLE 1WMrWEBsFgFViXUf+sA2CAt4S8zatJ4Fot5H4uD+W8wQtpHEgkPH2UBsXgEPidU7fjNBLLvM KPHy+lVWkASngLrEkm1fwIoYgc77fmoNE8QycYlbT+ZDnS0gsWTPeWYIW1Ti5eN/rBD1ohJ3 2tczQtTrSdyYOoUNwtaWWLbwNTPEYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNgbkax gZlBcl6yXlFmrl5easkmRnDi0NDfwdi3V+sQowAHoxIPL39FnJ8Qa2JZcWXuIUYJDmYlEd5p gUAh3pTEyqrUovz4otKc1OJDjBbAoJvILMWdnA9Mankl8cYGBigcJXHeYGkDPyGBdGBKyk5N LUgtgmll4uCUAiazkyk3LP3CtxcsnCQQuy37QdedyXONeDV8DgjU/vaUrHp+UIV9i+gLd0v7 JY1MHz+0GZn5vi359X1TvNCydwJHHeYnxGZMZZvS7Pog5tK0NbfirvMfOp7E1832daW60b5L cxW3WK4v5H+ww3XmugqjRpv5/q+UWa/lRk1VfS4/8/oRnZuhR/KUWIozEg21mIuKEwHVWz5S NQMAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] Suggested new WS status code: 1008 "Extension Required" 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, 31 Aug 2011 19:33:58 -0000 > I've added it as 1010. Why not combine this with the other issue I=F1aki identified, and make it "E= xtension or subprotocol required"? (I suggest this instead of a separate co= de mainly to avoid a ballooning number of error codes.) Joe --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From jmason@rim.com Wed Aug 31 12:39: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 DC2EB21F8F96 for ; Wed, 31 Aug 2011 12:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzJ5fKd-+rOm for ; Wed, 31 Aug 2011 12:39:21 -0700 (PDT) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id 5649E21F8F92 for ; Wed, 31 Aug 2011 12:39:21 -0700 (PDT) X-AuditID: 0a412830-b7c12ae0000051a7-c7-4e5e8e3ab605 Received: from XHT103CNC.rim.net (xht103cnc.rim.net [10.65.22.51]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 1A.6F.20903.A3E8E5E4; Wed, 31 Aug 2011 19:40:43 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT103CNC.rim.net ([fe80::f9b5:81ad:6043:dcb%11]) with mapi; Wed, 31 Aug 2011 15:40:51 -0400 From: Joe Mason To: =?iso-2022-jp?B?IkFuZHkgR3JlZW4gKBskQk5TMEJXLxsoQiki?= , Greg Wilkins Date: Wed, 31 Aug 2011 15:40:50 -0400 Thread-Topic: [hybi] CONSENSUS CALL Thread-Index: AcxmuVqLf3oI6DZ7SXWjXyKPHUWWVQBXHhmg Message-ID: References: <4E43A719.50401@warmcat.com> <4E440808.5030907@stpeter.im> <4E580901.4000009@stpeter.im> <4E5BC78C.5070802@stpeter.im> <4E5C1FBA.9040804@stpeter.im> <4E5C3E0B.4020700@stpeter.im> <4E5C4571.2030502@warmcat.com> In-Reply-To: <4E5C4571.2030502@warmcat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-2022-jp" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsXC5ShmrGvdF+dnsGgjm8XmSVPYLCb0PmOx eP9yG5MDs8eSJT+ZPP4/ncPusfnJadYA5qgGRpvEvLz8ksSSVIWU1OJkWyWf1PTEHIWAosyy xORKBZfM4uScxMzc1CIlhcwUWyUTJYWCnMTk1NzUvBJbpcSCgtS8FCU7LgUMYANUlpmnkJqX nJ+SmZduq+QZ7K9rYWFqqWuoZKeLBBL+cWccejifpeAjc8WR28UNjL+Zuhg5OSQETCR6Tqxk gbDFJC7cW8/WxcjFISTQwyTx6s0lFghnEaPE4zfTmEGq2AQUJD4ffgDWLSJQKPHx8E2wbmYB ZYmrx1aA2SwCqhKbLvaygdjCAkoSU/auYuxi5ACqV5Zo+lYP0WokMfH7KrCRvAIeEv/6mlgh dv1kl5i2bg0rSIJTQFui7fBcMJsR6Lrvp9YwQewSl7j1ZD7UBwISS/acZ4awRSVePv4HVS8q cad9PSNEvb7EnomnoO7Ulli28DXUYkGJkzOfsExgFJuFZOwsJC2zkLTMQtKygJFlFaNgbkax gZlhcl6yXlFmrl5easkmRnDq0DDYwThhr9YhRgEORiUe3j8VcX5CrIllxZW5hxglOJiVRHin BQKFeFMSK6tSi/Lji0pzUosPMVoAQ24isxR3cj4wreWVxBsbGKBwlMR5w6QN/IQE0oEJKTs1 tSC1CKaViYNTqoFRtP7FUn3fxAkS9yqqlNeaKO+1PeETNTHuSgR3wQfvm6b/Op9sYHI5t1U0 r1ac3Xy10s3Hzc7N0sUWjV2LbXf+qS28l6e33qYgpf32A7XbjyaI31aenm64OkHvN+9XO+GF v9U2/Vb9NWH5R9eHIjuk5DcoVX4zYV48KfBIuIh4wcTbTEz+fwyUWIozEg21mIuKEwES2cHi NgMAAA== Cc: "hybi@ietf.org" Subject: Re: [hybi] CONSENSUS CALL 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, 31 Aug 2011 19:39:22 -0000 > > We have 1003, which is bad data type. That's kind of a very specific > > policy failure. Can't we just broaden the description of that to say > > bad message - ie the message could not be handled for unspecified > > reasons - might be bad data type, might be too large, etc. The > main > > semantic is like a HTTP 4xx - the failure is something to do with the > > message and not something to do with the server. > > Sounds pretty reasonable (and cheap) to me. +1 on this. --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From ibc@aliax.net Wed Aug 31 12:48: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 F0C1D21F8FC7 for ; Wed, 31 Aug 2011 12:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rGX5VFa1EcWp for ; Wed, 31 Aug 2011 12:48:18 -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 6182B21F8FC3 for ; Wed, 31 Aug 2011 12:48:18 -0700 (PDT) Received: by qyk35 with SMTP id 35so709416qyk.10 for ; Wed, 31 Aug 2011 12:49:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.68.1 with SMTP id t1mr641509qci.198.1314820189123; Wed, 31 Aug 2011 12:49:49 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Wed, 31 Aug 2011 12:49:49 -0700 (PDT) In-Reply-To: References: <4E5CBEDE.1030608@isode.com> <4E5E497F.20705@isode.com> Date: Wed, 31 Aug 2011 21:49:49 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Joe Mason Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Suggested new WS status code: 1008 "Extension Required" 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, 31 Aug 2011 19:48:19 -0000 2011/8/31 Joe Mason : >> I've added it as 1010. > > Why not combine this with the other issue I=C3=B1aki identified, and make= it "Extension or subprotocol required"? =C2=A0(I suggest this instead of a= separate code mainly to avoid a ballooning number of error codes.) Note that I suggested both ways for rejecting a WS session: 1) Clients provides extensions "aaa" and "bbb" in the HTTP GET but server just provides "aaa" in HTTP 101, so the client decides to close the WS session by sending a (now) 1010 code. 2) Clients provides extensions "aaa" and "bbb" in the HTTP GET but server requires "ccc" so replies HTTP 421 "Extension Required" with a Sec-WebSocket-Extensions containing the required extensions the client must support. Note that 421 "Extension Required" does not exist in HTTP but just in SIP, but I see no reason to copy it in WebSocket protocol. --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Wed Aug 31 13:04: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 97FA021F8FDF for ; Wed, 31 Aug 2011 13:04:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Cozpt067oqA for ; Wed, 31 Aug 2011 13:04:04 -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 EEF3621F8FDE for ; Wed, 31 Aug 2011 13:04:03 -0700 (PDT) Received: by qyk34 with SMTP id 34so3264716qyk.10 for ; Wed, 31 Aug 2011 13:05:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.85 with SMTP id h21mr686767qci.46.1314821134489; Wed, 31 Aug 2011 13:05:34 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Wed, 31 Aug 2011 13:05:34 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> Date: Wed, 31 Aug 2011 22:05:34 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 20:04:04 -0000 2011/8/31 John Tamplin : > Personally, I see little value at this point for subprotocols. =C2=A0They > basically represent an agreement between the application end points for a > protocol to run on top of WS. > Since the app developer owns both endpoints, What? and what about HTTP API's? don't you expect that there will also exist WS API's so I can develope, for example, a Linux KDE desktop application/widget that connects to Gmail via WebSocket (Google WS API) to check my mail in realtime??? You work in Google, you should know it, am I wrong? A protocol MUST NOT be designed taking that wrong assumption into account. This is a protocol, not a JavaScript "feature" to make the text blinking or ringing in Chrome. > they can already use whatever protocol they like. =C2=A0It is a convenien= t place > to send selection between multiple protocols out-of-band, but no more. > Maybe in the future there are standard subprotocols, and you could have s= ome > off-the-shelf product to offload those subprotocols, Me (and others AFAIK) are just proposing that, in *case* the client provides a WS protocol in the HTTP GET, and the server *does not* support such protocol, then the server MUST reject the WS handshake (which means a 4XX error code rather than "101 I don't know what we are supposed to speak now but I accept the WS session"). Is it to hard? does it break so much? Of course, what you propose is just valid for allowing a stupid JS developer coding a JS application that connects to the WS server by providing "Sec-WebSocket-Protocol: i-dont-know-programming.but-i-am-cool.com". > but initially there > seems to be little value so I don' t think we need to go overboard imagin= ing > things that would be useful with only limited experience with WS itself. The protocol is being written right now, not within 4 years when all the people and browsers extensively use WebSocket and it's not possible to change nothing. This is not an experiment, it's an Internet protocol. Regards. --=20 I=C3=B1aki Baz Castillo From julian.reschke@gmx.de Wed Aug 31 13:05: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 2B7E121F8FE1 for ; Wed, 31 Aug 2011 13:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.152 X-Spam-Level: X-Spam-Status: No, score=-104.152 tagged_above=-999 required=5 tests=[AWL=-1.553, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J0lF1MKWxmd9 for ; Wed, 31 Aug 2011 13:05:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 3474F21F8FDE for ; Wed, 31 Aug 2011 13:05:01 -0700 (PDT) Received: (qmail invoked by alias); 31 Aug 2011 20:06:31 -0000 Received: from p508FA8FA.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.168.250] by mail.gmx.net (mp042) with SMTP; 31 Aug 2011 22:06:31 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19yH8NVEiJyaxNqqbY2ew1ASSV1ldnnHIfYGGuSdc +WvQwsjBxLw2eE Message-ID: <4E5E9440.5070803@gmx.de> Date: Wed, 31 Aug 2011 22:06:24 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Peter Saint-Andre References: <20110831184207.1514.64093.idtracker@ietfa.amsl.com> <4E5E824A.3020101@stpeter.im> In-Reply-To: <4E5E824A.3020101@stpeter.im> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] what's next 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, 31 Aug 2011 20:05:02 -0000 On 2011-08-31 20:49, Peter Saint-Andre wrote: > First, a big thank-you to Ian and Alexey for submitting -13 so quickly! > > As far as we know, this version addresses all of the feedback and open > issues resulting from the Working Group Last Call, and is ready for > presentation to the IESG. The chairs will update the "proto writeup" > tomorrow morning (European time) and then I will issue the IESG ballot, > for consideration on the IESG telechat next Thursday. > > Peter > ... I don't see my comment regarding extension-param syntax resolved... From phil127@gmail.com Wed Aug 31 13:07: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 EFC5C21F8DA7 for ; Wed, 31 Aug 2011 13:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.394 X-Spam-Level: X-Spam-Status: No, score=-3.394 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OD8VbPPaF9UA for ; Wed, 31 Aug 2011 13:07:33 -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 3457621F8DA0 for ; Wed, 31 Aug 2011 13:07:33 -0700 (PDT) Received: by bkar4 with SMTP id r4so1436328bka.31 for ; Wed, 31 Aug 2011 13:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type; bh=12rBpu14naMOKU8F0U+RvHw+UIeDzMcSZWS9PHXPdKg=; b=G+A4Chw3tjOTbHLFQwKC0e7nVVrjO0QmIrEx5oV69WwceRtS78J7vsfHoWEf35rlVR lP6rkVuZkR6ciJ7I4mhYWRS9vHq4tG4LIt84KqQQ12exiM9Pl/mTSUQz63dukiVkFnDl boctFeaRoPINmUnlcqmEn5WVH+MkQE5AVIyXY= Received: by 10.204.157.2 with SMTP id z2mr472406bkw.107.1314821340984; Wed, 31 Aug 2011 13:09:00 -0700 (PDT) Received: from [212.201.70.0] ([212.201.70.0]) by mx.google.com with ESMTPS id zu10sm497731bkb.5.2011.08.31.13.08.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Aug 2011 13:09:00 -0700 (PDT) Message-ID: <4E5E94D8.4070302@gmail.com> Date: Wed, 31 Aug 2011 22:08:56 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= , Hybi References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: multipart/alternative; boundary="------------080202060703020306050702" Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 20:07:34 -0000 This is a multi-part message in MIME format. --------------080202060703020306050702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Am 31.08.2011 22:05, schrieb Iñaki Baz Castillo: > Me (and others AFAIK) are just proposing that, in *case* the client > provides a WS protocol in the HTTP GET, and the server *does not* > support such protocol, then the server MUST reject the WS handshake > (which means a 4XX error code rather than "101 I don't know what we > are supposed to speak now but I accept the WS session"). Exactly. --------------080202060703020306050702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Am 31.08.2011 22:05, schrieb Iñaki Baz Castillo: 
Me (and others AFAIK) are just proposing that, in *case* the client
provides a WS protocol in the HTTP GET, and the server *does not*
support such protocol, then the server MUST reject the WS handshake
(which means a 4XX error code rather than "101 I don't know what we
are supposed to speak now but I accept the WS session").
Exactly.
--------------080202060703020306050702-- From jat@google.com Wed Aug 31 13:17: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 271D221F8CE7 for ; Wed, 31 Aug 2011 13:17:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=-0.098, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mjdMwK7acv6e for ; Wed, 31 Aug 2011 13:17:36 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 3B0EE21F8CC3 for ; Wed, 31 Aug 2011 13:17:36 -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 p7VKJ6vj022262 for ; Wed, 31 Aug 2011 13:19:06 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314821946; bh=WhbwjwKLzeeEiEKm9w3dRbhyETE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=NAdKHMFoVcoHoGCKY0r2pkOH0VACn65LmXJEh+xFkLDkeFyal/Qj0z3mzAeS/z7o8 GEGxn3RSFtb1wFwT3nDRA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=GTaeeG8bYR/s3D5u7sKJCJxe/4MALPLVQmAIb92NUiuKKPvKbCSw9p2gb76W/K3ok O+i7UD5/IWSib2j7Nj92A== Received: from qwj9 (qwj9.prod.google.com [10.241.195.73]) by hpaq7.eem.corp.google.com with ESMTP id p7VKFu3E001316 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 31 Aug 2011 13:19:05 -0700 Received: by qwj9 with SMTP id 9so779933qwj.7 for ; Wed, 31 Aug 2011 13:19:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=aHjIkuGO9oDLdMfHTHcP7lyYPihMegug4/B7RSOXZOo=; b=nHDu4CiJE2S/nBMNeq0KtDLNjSiDaTBlT1UTzjycJBPpjtVohFxEGeZqgFrVf4iIx8 T51zAYCCi/1kVj8+sehw== Received: by 10.229.72.162 with SMTP id m34mr672025qcj.189.1314821945264; Wed, 31 Aug 2011 13:19:05 -0700 (PDT) Received: by 10.229.72.162 with SMTP id m34mr672019qcj.189.1314821945063; Wed, 31 Aug 2011 13:19:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.137 with HTTP; Wed, 31 Aug 2011 13:18:45 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> From: John Tamplin Date: Wed, 31 Aug 2011 16:18:45 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=0016e6506b60fa79c504abd2d67b X-System-Of-Record: true Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 20:17:37 -0000 --0016e6506b60fa79c504abd2d67b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2011 at 4:05 PM, I=C3=B1aki Baz Castillo wr= ote: > What? and what about HTTP API's? don't you expect that there will also > exist WS API's so I can develope, for example, a Linux KDE desktop > application/widget that connects to Gmail via WebSocket (Google WS > API) to check my mail in realtime??? You work in Google, you should > know it, am I wrong? > Since you brought it up, lets take such an example. You can connect using the GData APIs to get your calendar information, etc. over HTTP today. You can do that despite the fact that HTTP doesn't support a subprotocol defining what that API looks like. It works because you read the docs and wrote code to speak the "subprotocol" over that connection, despite the fac= t that it wasn't announced. Likewise, you could do exactly the same in WS whether or not a hypothetical GData service over WebSocket used a subprotocol. > A protocol MUST NOT be designed taking that wrong assumption into > account. This is a protocol, not a JavaScript "feature" to make the > text blinking or ringing in Chrome. > The protocol is defined, and a subprotocol cannot change the framing or representation of messages in the base protocol. To me, that limits the value of subprotocol as out-of-band identification of what the next layer u= p plans to do with that channel, similar to a MIME type for HTTP. I don't se= e where your suggestion this is a Javascript feature enters into it. > Of course, what you propose is just valid for allowing a stupid JS > developer coding a JS application that connects to the WS server by > providing "Sec-WebSocket-Protocol: > i-dont-know-programming.but-i-am-cool.com". Your attitude is not conducive to constructive conversation. --=20 John A. Tamplin Software Engineer (GWT), Google --0016e6506b60fa79c504abd2d67b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 31, 2011 at 4:05 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:
What? and what about HTTP API's? don't you expect that there will a= lso
exist WS API's so I can develope, for example, a Linux KDE desktop
application/widget that connects to Gmail via WebSocket (Google WS
API) to check my mail in realtime??? You work in Google, you should
know it, am I wrong?
=C2=A0
Since you brough= t it up, lets take such an example. =C2=A0You can connect using the GData A= PIs to get your calendar information, etc. over HTTP today. =C2=A0You can d= o that despite the fact that HTTP doesn't support a subprotocol definin= g what that API looks like. =C2=A0It works because you read the docs and wr= ote code to speak the "subprotocol" over that connection, despite= the fact that it wasn't announced.

Likewise, you could do exactly the same in WS whether o= r not a hypothetical GData service over WebSocket used a subprotocol.
=
=C2=A0
A protocol MUST NOT be designed taking that wrong assumption into
account. This is a protocol, not a JavaScript "feature" to make t= he
text blinking or ringing in Chrome.

The= protocol is defined, and a subprotocol cannot change the framing or repres= entation of messages in the base protocol. =C2=A0To me, that limits the val= ue of subprotocol as out-of-band identification of what the next layer up p= lans to do with that channel, similar to a MIME type for HTTP. =C2=A0I don&= #39;t see where your suggestion this is a Javascript feature enters into it= .
=C2=A0
Of course, what you propose is just valid for allowing a stupid JS
developer coding a JS application that connects to the WS server by
providing "Sec-WebSocket-Protocol:
i-dont-know-programming.but-i-am-cool.com".
= =C2=A0
Your attitude is not conducive to constructive conversatio= n.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--0016e6506b60fa79c504abd2d67b-- From phil127@gmail.com Wed Aug 31 13:21: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 81B4321F8B31 for ; Wed, 31 Aug 2011 13:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.536 X-Spam-Level: X-Spam-Status: No, score=-3.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9iljfdHzBDsI for ; Wed, 31 Aug 2011 13:21:17 -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 5422921F8B2D for ; Wed, 31 Aug 2011 13:21:17 -0700 (PDT) Received: by bkar4 with SMTP id r4so1451583bka.31 for ; Wed, 31 Aug 2011 13:22:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; bh=xvKQ2B/EM8F4GnJzd35DRy8q/C94vUH9nC+wf1KZeGY=; b=czA8HRsXNJzjspgRjwU86dMMzBFfieu8l2NcNCtyD8iCgxoPFzto9NbMLpZm7dxBh+ DLOIRw6dMsGDSLSLnAWYbZokiGEFaqL9i/tiu59QIvsKX1ELldjWVLqmaAk1j404w41M CA3Vy8lpY5s/0iDpT2cGjZlGFHY37icHWJxTM= Received: by 10.204.133.7 with SMTP id d7mr526333bkt.104.1314821146278; Wed, 31 Aug 2011 13:05:46 -0700 (PDT) Received: from [212.201.70.0] ([212.201.70.0]) by mx.google.com with ESMTPS id v27sm302443bkt.48.2011.08.31.13.05.44 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Aug 2011 13:05:45 -0700 (PDT) Message-ID: <4E5E9416.2040206@gmail.com> Date: Wed, 31 Aug 2011 22:05:42 +0200 From: Philipp Serafin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: John Tamplin References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> In-Reply-To: X-Enigmail-Version: 1.3.1 Content-Type: multipart/alternative; boundary="------------040205080405080303010403" Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 20:21:18 -0000 This is a multi-part message in MIME format. --------------040205080405080303010403 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit I may be wrong, but this looks like a feature that would be really cheap to specify and implement now (even if we don't know if it'll actually be of much use) but very hard later when we'd have to take lots and lots of back-compat issues into consideration. I'd just hate to see subprotocols go the way of the HTTP Accept header, which is practically unuseable in the browser world today, even though it would solve some real-world problems. (As shown by the &type=... URL params in many APIs) Am 31.08.2011 21:26, schrieb John Tamplin: > On Wed, Aug 31, 2011 at 3:21 PM, Iñaki Baz Castillo > wrote: > > 2011/8/31 Philipp Serafin >: > > If a client sends a protocol header, I don't see why it can't > indicate ALL > > protocols it supports for this connection. If the server > supports none of > > those protocols, and if neither client nor server are part of a > single web > > application (so there is no implicit custom protocol they could both > > understand), I don't see how a sucessful connection could be > established. > > Of course. Say the opposite means allowing ugly/annoying pseudo > negotiations. > > > Personally, I see little value at this point for subprotocols. They > basically represent an agreement between the application end points > for a protocol to run on top of WS. Since the app developer owns both > endpoints, they can already use whatever protocol they like. It is a > convenient place to send selection between multiple protocols > out-of-band, but no more. > > Maybe in the future there are standard subprotocols, and you could > have some off-the-shelf product to offload those subprotocols, but > initially there seems to be little value so I don' t think we need to > go overboard imagining things that would be useful with only limited > experience with WS itself. > > -- > John A. Tamplin > Software Engineer (GWT), Google --------------040205080405080303010403 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit I may be wrong, but this looks like a feature that would be really cheap to specify and implement now (even if we don't know if it'll actually be of much use) but very hard later when we'd have to take lots and lots of back-compat issues into consideration.

I'd just hate to see subprotocols go the way of the HTTP Accept header, which is practically unuseable in the browser world today, even though it would solve some real-world problems. (As shown by the &type=... URL params in many APIs)

Am 31.08.2011 21:26, schrieb John Tamplin:
On Wed, Aug 31, 2011 at 3:21 PM, Iñaki Baz Castillo <ibc@aliax.net> wrote:
2011/8/31 Philipp Serafin <phil127@gmail.com>:
> If a client sends a protocol header, I don't see why it can't indicate ALL
> protocols it supports for this connection. If the server supports none of
> those protocols, and if neither client nor server are part of a single web
> application (so there is no implicit custom protocol they could both
> understand), I don't see how a sucessful connection could be established.

Of course. Say the opposite means allowing ugly/annoying pseudo negotiations.

Personally, I see little value at this point for subprotocols.  They basically represent an agreement between the application end points for a protocol to run on top of WS.  Since the app developer owns both endpoints, they can already use whatever protocol they like.  It is a convenient place to send selection between multiple protocols out-of-band, but no more.

Maybe in the future there are standard subprotocols, and you could have some off-the-shelf product to offload those subprotocols, but initially there seems to be little value so I don' t think we need to go overboard imagining things that would be useful with only limited experience with WS itself. 

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

--------------040205080405080303010403-- From julian.reschke@gmx.de Wed Aug 31 13:21: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 16FE321F8DBF for ; Wed, 31 Aug 2011 13:21:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.138 X-Spam-Level: X-Spam-Status: No, score=-104.138 tagged_above=-999 required=5 tests=[AWL=-1.539, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qJ5mjpY0JqMX for ; Wed, 31 Aug 2011 13:21:54 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 089B421F8B84 for ; Wed, 31 Aug 2011 13:21:53 -0700 (PDT) Received: (qmail invoked by alias); 31 Aug 2011 20:23:23 -0000 Received: from p508FA8FA.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.168.250] by mail.gmx.net (mp003) with SMTP; 31 Aug 2011 22:23:23 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+ASK4Ulh2AXK/3F9r86S38l60rVLk30QO/Z0Lx+t Q+3ljWcGoVV6AF Message-ID: <4E5E983A.2000004@gmx.de> Date: Wed, 31 Aug 2011 22:23:22 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: [hybi] header definitions in -13 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, 31 Aug 2011 20:21:55 -0000 Hi, I realize that everybody is getting tired of tuning the document. I also realize that that IANA considerations at least have been reorganized -- thanks for that. Anyway... I really believe that a document that defines a new header field should have an easy-to-find subsection for each header field that defines the syntax and semantics. That doesn't mean that that part needs to say *everything* about that header field, but it should be there as a starting point. Right now this is not the case. Best regards, Julian From ibc@aliax.net Wed Aug 31 14:02: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 0A5B721F8F74 for ; Wed, 31 Aug 2011 14:02:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCTvsFVyRHkj for ; Wed, 31 Aug 2011 14:02:23 -0700 (PDT) Received: from mail-qw0-f42.google.com (mail-qw0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 38A3B21F8F70 for ; Wed, 31 Aug 2011 14:02:23 -0700 (PDT) Received: by qwi4 with SMTP id 4so706029qwi.15 for ; Wed, 31 Aug 2011 14:03:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.65.85 with SMTP id h21mr734583qci.46.1314824631261; Wed, 31 Aug 2011 14:03:51 -0700 (PDT) Received: by 10.229.219.141 with HTTP; Wed, 31 Aug 2011 14:03:51 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> Date: Wed, 31 Aug 2011 23:03:51 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 21:02:24 -0000 2011/8/31 John Tamplin : > On Wed, Aug 31, 2011 at 4:05 PM, I=C3=B1aki Baz Castillo = wrote: >> >> What? and what about HTTP API's? don't you expect that there will also >> exist WS API's so I can develope, for example, a Linux KDE desktop >> application/widget that connects to Gmail via WebSocket (Google WS >> API) to check my mail in realtime??? You work in Google, you should >> know it, am I wrong? > > > Since you brought it up, lets take such an example. =C2=A0You can connect= using > the GData APIs to get your calendar information, etc. over HTTP today. = =C2=A0You > can do that despite the fact that HTTP doesn't support a subprotocol > defining what that API looks like. =C2=A0It works because you read the do= cs and > wrote code to speak the "subprotocol" over that connection, despite the f= act > that it wasn't announced. > Likewise, you could do exactly the same in WS whether or not a hypothetic= al > GData service over WebSocket used a subprotocol. Yes, sure I can ignore WS subprotocols, just not use them at all in my WS application (server and client). The point is: if the protocol introduces a mechanism (an *optional* mechanism) for negotiating a WS subprotocol, and the client wants to use it, why couldn't the server reject the WS session if the server does not support such protocol? why is that so terrible? You can just ignore it in your apps. Now let me expose an example (assuming my suggestion for a HTTP 4XX response code): - Let's suppose Google provides a WS API to connect to ws://gmail.com. Initially it provides the WS "v01.gmail.com" subprotocol. - Lot of desktop/mobile applications (not just web browsers) implement it to check the mail. - After two years Google introduces improvements in the service which becomes "v02.gmail.com" WS subprotocol. Google still supports boh protocols in the same WS URL. - Some clients are upgraded, some others not. - After 3 years Google decides to drop the support for "v01.gmail.com". - Non upgraded clients, which still offer "sec-WebSocket-Protocol: v01.gmail.com" would be rejected by some HTTP 4XX code which is good, because if such 4XX becomes an standard the application could prompt a warning to the user "cannot connect to the service due to WebSocket subprotocol incompatibility". What is the alternative if Sec-WebSocket-Protocol is not used at all? Clients would fail "at some point" because the exchanged messages are not compatible. The client WS application has no way to describe the problem to the user (neither to their authors). Of course, you can decide to use another URL path for version 02 and you are done, of course. But, why do you want to avoid that me or others relying on the ellegant protocol mechanism I've described in my example? In other words: why is so bad for you my suggestion? you can just ignore it as it's an optional mechanism, why is then a problem? >> A protocol MUST NOT be designed taking that wrong assumption into >> account. This is a protocol, not a JavaScript "feature" to make the >> text blinking or ringing in Chrome. > > The protocol is defined, and a subprotocol cannot change the framing or > representation of messages in the base protocol. =C2=A0To me, that limits= the > value of subprotocol as out-of-band identification of what the next layer= up > plans to do with that channel, similar to a MIME type for HTTP. Ok, don't use it if you don't consider it useful, but the protocol already includes it (as an optional mechanism). I'm just suggesting that, for those who consider it useful, it should be better defined (a specific HTTP 4XX code in case the server does not support WS subprotocol(s) offered by the client). >> Of course, what you propose is just valid for allowing a stupid JS >> developer coding a JS application that connects to the WS server by >> providing "Sec-WebSocket-Protocol: >> i-dont-know-programming.but-i-am-cool.com". > > Your attitude is not conducive to constructive conversation. It was just a joke, sorry. I just meant that the *only* "problem" with my suggestion could occur is case a JavaScript developer decides to offer an unexisting WS subprotocol in his JavaScript code. There is absolutely no reason to expect that. Regards. --=20 I=C3=B1aki Baz Castillo From asoliman@microsoft.com Wed Aug 31 14:32: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 99F0021F8DC7 for ; Wed, 31 Aug 2011 14:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.399 X-Spam-Level: X-Spam-Status: No, score=-9.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TCzUSOfrUf4 for ; Wed, 31 Aug 2011 14:32:23 -0700 (PDT) Received: from smtp.microsoft.com (mail3.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id DF6DF21F8DC6 for ; Wed, 31 Aug 2011 14:32:22 -0700 (PDT) Received: from TK5EX14HUBC105.redmond.corp.microsoft.com (157.54.80.48) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 31 Aug 2011 14:33:54 -0700 Received: from TK5EX14MBXC139.redmond.corp.microsoft.com ([169.254.7.114]) by TK5EX14HUBC105.redmond.corp.microsoft.com ([157.54.80.48]) with mapi id 14.01.0323.007; Wed, 31 Aug 2011 14:33:54 -0700 From: Ahmed Soliman To: Ahmed Soliman , Greg Wilkins , Hybi Thread-Topic: [hybi] websocket test suite Thread-Index: AQHMTYLTnPwMA5ROPUezUY2S/9CJVJUC93AAgAAeXwCAESfEIIAjcH9A Date: Wed, 31 Aug 2011 21:33:53 +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.71] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] websocket test suite 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, 31 Aug 2011 21:32:23 -0000 Greg, Are you still planning to add any of these scenarios to the jetty server? -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Ahm= ed Soliman Sent: Tuesday, August 09, 2011 2:45 AM To: Greg Wilkins; Hybi Subject: Re: [hybi] websocket test suite Greg, I have the following comments: 1. Scenario to add: * Receive/send control frames (e.g. close frame) within a fragmented messa= ge. Verify that client/server responds with a close frame. 2. Focusing on interoperability testing: Shouldn't we narrow the tests bel= ow to focus on interoperability testing? I think some of the negative test= s below fit better in functional testing rather than interoperability test= ing? What do you think?=20 3. Standard process/test implementation: I think this will make it easier t= o share test implementations and verify interoperability between different = protocol implementations. Any thoughts around this? (e.g. cre ating server endpoints per scenario for server implementation, u= sing sub-protocol to select between fragmented message/non-fragmented messa= ge, .... etc) Thanks, Ahmed -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gre= g Wilkins Sent: Thursday, July 28, 2011 8:15 PM To: Hybi Subject: Re: [hybi] websocket test suite Here is a first cut at a list of tests for section 4 of the spec. Are thes= e the kinds of tests people were thinking about? If so, then I'm happy to go the next step of detail and start providing mor= e detail for each test. Obviously some implementation are not going to be able to send some of the = invalid frames or force fragmentation, so some suites will have to record s= ome tests as skipped, or only testing in one direction etc. 4.2 Base Framing Tests ---------------------- * 7 bit length: send/receive frames of length 0-125 * 16 bit length: send/receive frames of length 126-128, 65536 * 63 bit length: send/receive frames of length 65537 * Non zero RSV: send frames with non zero reserved bits and no extension. V= erify connection is failed. * Known Opcodes: send/receive frames with text,binary,ping,pong opcodes (co= ntinuation & close tested separately). * Unknown Opcodes: send frames with unknown opcodes 3-7, B-F. Verify connec= tion is failed. 4.3 Client to Server Masking ---------------------------- ??? 4.4 Fragmentation ----------------- * 1 fragment message: send/receive message in 1 fragment * 2 fragment message: send/receive message in 2 fragments * 3 fragment message: send/receive message in 3 fragments * Injected control: send/receive 2 fragment message with unsolicited pong m= essage between frames * Fragmented control: send fragmented ping. Verify that connection is faile= d. * Interleaved fragments: send a fragment with FIN set and Continuation opco= de. Verify that connection is failed. * Handled control: send/receive 2 fragment message with ping message betwee= n frames and last frame delayed. Verify pong is received before last frame = is sent. * 7 bit fragment: send/receive message with initial/middle/final fragments = of sizes 0-125 * 16 bit fragment: send/receive message with initial/middle/final fragments= of sizes 126-128,65536 * 64 bit fragment: send/receive message with initial/middle/finalfragments = of size 65537 4.5.1 Close Frames ------------------ * Orderly Close: On an idle connection, send a close and receive a close. * Busy Close: send a close to an endpoint that has sent the first fragment = of a message. * Simultaneous Close: send a close on both ends of a connection. * Message after close: attempt to send a message after a close. Verify mess= age is not received. * Idle close: ?? * Error Close: ?? 4.5.2 Ping ---------- * Empty ping: Send an empty ping, verify pong is received. * Non empty ping: Send a non empty ping, verify pong is received. 4.5.3 Pong ---------- * Empty pong: Send an empty ping, verify pong is received and is empty. * Non empty pong: Send a non empty ping, verify pong is received and has ma= tching content. * Outstanding ping: Send two pings with different content, reply with conte= nt for only the second. Verify connection stays open. * Unsolicited pong: Send/recv unsolicited pong. 4.5.4 Data Frames ----------------- * UTF-8 Text 0000-007f: Send/receive text message with characters in code p= oint range U+0000 to U+007F * UTF-8 Text 0080-07ff: Send/receive text message with characters in code p= oint range U+0080 to U+07FF * UTF-8 Text 0800-ffff: Send/receive text message with characters in code p= oint range U+0800 to U+FFFF * UTF-8 Text 010000-10ffff: Send/receive text message with characters in co= de point range U+010000 to U+10FFFF * Illegal bytes UTF-8: Send message with invalid UTF-8 byte sequence. Verify message is not received. * Illegal codes UTF-8: Send message with invalid UTF-8 code points. Verify message is not received. * Binary frames: Send/receive message containing illegal UTF-8 bytes sequen= ces and code points as binary message. _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From theturtle32@gmail.com Wed Aug 31 14:57:36 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 05BED21F8F3C for ; Wed, 31 Aug 2011 14:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5R6C83xd2W4 for ; Wed, 31 Aug 2011 14:57:35 -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 E151E21F8F32 for ; Wed, 31 Aug 2011 14:57:34 -0700 (PDT) Received: by bkar4 with SMTP id r4so1543292bka.31 for ; Wed, 31 Aug 2011 14:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5joIZm1/0O+aAWOjnhnOYLm0Qf0a+Dqykf1wKbmy/K8=; b=EkAMb73JtTcf2eat9GUZlZ+RBqb6AJjQT3Is5vOWz7qO3A+yW56J2KNcxgfHIB1lFE xk3uVGMkDm6R3HoP8t9acn6RkXiMvqZ8W/IIJgxAc1Agicejmd0R7N4lR9yye2VOVUh8 5ZQKYHcRWEo3iMMe3hekhsLnT00cDgHgtEjqY= MIME-Version: 1.0 Received: by 10.204.128.148 with SMTP id k20mr555872bks.24.1314827945404; Wed, 31 Aug 2011 14:59:05 -0700 (PDT) Received: by 10.204.150.72 with HTTP; Wed, 31 Aug 2011 14:59:05 -0700 (PDT) In-Reply-To: <4E5E94D8.4070302@gmail.com> References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> <4E5E94D8.4070302@gmail.com> Date: Wed, 31 Aug 2011 14:59:05 -0700 Message-ID: From: Brian To: Philipp Serafin Content-Type: multipart/alternative; boundary=0015174c43a6a06a4904abd43ccc Cc: Hybi Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 21:57:36 -0000 --0015174c43a6a06a4904abd43ccc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. This requirement should be in the spec. Frankly, I implemented my WebSocket libraries this way as it's the only thing that makes any sense. = I just assumed that's how it was supposed to be. It didn't really occur to m= e that the protocol was underspecified here. There is absolutely no reasonable use case for the server to fall back to an unspecified default protocol and accept the connection if it doesn't know any of the requested subprotocols from the client, just like there's no acceptable use case for the server to accept the connection with a subprotocol not contained in the list of subprotocols requested by the client. If the client requests a lis= t of subprotocols, that is to be taken as the canonical list of the only subprotocols it knows how to speak. Anything else will fail. It should respond with a 4xx HTTP error code. The *only* time a server should accept the connection with a default unspecified subprotocol is when the client doesn't request any subprotocols at all. That's really the end of the story. This minor enhancement to the spec would be trivial and shouldn't hold anything else up. Brian On Wed, Aug 31, 2011 at 1:08 PM, Philipp Serafin wrote: > Am 31.08.2011 22:05, schrieb I=F1aki Baz Castillo: > > Me (and others AFAIK) are just proposing that, in **case** the client > provides a WS protocol in the HTTP GET, and the server **does not** > support such protocol, then the server MUST reject the WS handshake > (which means a 4XX error code rather than "101 I don't know what we > are supposed to speak now but I accept the WS session"). > > Exactly. > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --0015174c43a6a06a4904abd43ccc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes. =A0This requirement should be in the spec. =A0Frankly, I implemented m= y WebSocket libraries this way as it's the only thing that makes any se= nse. =A0I just assumed that's how it was supposed to be. =A0It didn'= ;t really occur to me that the protocol was underspecified here. =A0There i= s absolutely no reasonable use case for the server to fall back to an unspe= cified default protocol and accept the connection if it doesn't know an= y of the requested subprotocols from the client, just like there's no a= cceptable use case for the server to accept the connection with a subprotoc= ol not contained in the list of subprotocols requested by the client. =A0If= the client requests a list of subprotocols, that is to be taken as the can= onical list of the only subprotocols it knows how to speak. =A0Anything els= e will fail. =A0It should respond with a 4xx HTTP error code.

The *only* time a server should accept the connection with a= default unspecified subprotocol is when the client doesn't request any= subprotocols at all. =A0That's really the end of the story.

This minor enhancement to the spec would be trivial and shou= ldn't hold anything else up.

Brian


On Wed, Aug 31,= 2011 at 1:08 PM, Philipp Serafin <phil127@gmail.com> wrote:
=20 =20 =20
Am 31.08.2011 22:05, schrieb I=F1aki Baz Castillo: 
Me (and others AFAIK) are just proposing that, in *case* the client
provides a WS protocol in the HTTP GET, and the server *doe=
s not*
support such protocol, then the server MUST reject the WS handshake
(which means a 4XX error code rather than "101 I don't know what w=
e
are supposed to speak now but I accept the WS session").
Exactly.

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


--0015174c43a6a06a4904abd43ccc-- From buskanaka@gmail.com Wed Aug 31 16:57:47 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 2DEC821F8CE8 for ; Wed, 31 Aug 2011 16:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R2-slgQaucw for ; Wed, 31 Aug 2011 16:57:46 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 61B1D21F8CE7 for ; Wed, 31 Aug 2011 16:57:46 -0700 (PDT) Received: by fxe6 with SMTP id 6so197069fxe.31 for ; Wed, 31 Aug 2011 16:59:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; 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; bh=8SDjZws5QbiHsCBHSB3dEIGlBFTPH5QGUY8xQg4pwBw=; b=exS5WKZlxW5AuEvZjCl1M2rRK+8vlsg3e301HnbzMFFx1/fsPsUDVQwLrR5b19/4yc XxOBUbaLDCyURGZ3SamOn3yxKQZuP7rog5ZMyQPoNd2dag8biUVy09C7cI62UYgpNL0D 1ENuUd58TN3it5OyynRGQiINr43IvMA19Mc6I= Received: by 10.223.47.75 with SMTP id m11mr653225faf.55.1314835153221; Wed, 31 Aug 2011 16:59:13 -0700 (PDT) MIME-Version: 1.0 Sender: buskanaka@gmail.com Received: by 10.223.100.5 with HTTP; Wed, 31 Aug 2011 16:58:53 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> <4E5E94D8.4070302@gmail.com> From: Joel Martin Date: Wed, 31 Aug 2011 18:58:53 -0500 X-Google-Sender-Auth: 3xAroPBSzFj_9Tk5CJV9ffDohQE Message-ID: To: Brian Content-Type: multipart/alternative; boundary=001517493c563ef7cb04abd5eae1 Cc: Hybi Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 31 Aug 2011 23:57:47 -0000 --001517493c563ef7cb04abd5eae1 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 31, 2011 at 4:59 PM, Brian wrote: > Yes. This requirement should be in the spec. Frankly, I implemented my > WebSocket libraries this way as it's the only thing that makes any sense. I > just assumed that's how it was supposed to be. It didn't really occur to me > that the protocol was underspecified here. +1. This was also my assumption in implementing websockify. One of the protocols is mandatory if specified and the server may only respond successfully if it supports one of them. Also, should the server really be able to specify a protocol if the client didn't specify any? It seems that if the client doesn't specify a protocol then that ought to mean "no protocol" rather than "any protocol". Regards, Joel Martin (kanaka) --001517493c563ef7cb04abd5eae1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 31, 2011 at 4:59 PM, Brian <theturtle32@gmail.com= > wrote:
Yes. =A0This requirement should be in the spec. =A0Frankly, I implemented m= y WebSocket libraries this way as it's the only thing that makes any se= nse. =A0I just assumed that's how it was supposed to be. =A0It didn'= ;t really occur to me that the protocol was underspecified here. =A0
=A0
+1. This was also my assumption in implementing websocki= fy. One of the protocols is mandatory if specified and the server may only = respond successfully if it supports one of them.=A0

Also, should the server really be able to specify a protocol if the client = didn't specify any? It seems that if the client doesn't specify a p= rotocol then that ought to mean "no protocol" rather than "a= ny protocol".

Regards,

Joel Martin (kanaka)<= /div>
--001517493c563ef7cb04abd5eae1-- From theturtle32@gmail.com Wed Aug 31 17:05: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 61E9D21F8D63 for ; Wed, 31 Aug 2011 17:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.482 X-Spam-Level: X-Spam-Status: No, score=-3.482 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cLvXa90HiTS5 for ; Wed, 31 Aug 2011 17:05:25 -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 5AD5121F8D62 for ; Wed, 31 Aug 2011 17:05:25 -0700 (PDT) Received: by bkar4 with SMTP id r4so1639719bka.31 for ; Wed, 31 Aug 2011 17:06:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jpGVCnYAvNkcu8M8H/0SfzgKeWO7mdH8YXWV/aqNOvQ=; b=gUVnEFlrd/20RuMZr1VHCHEymnxxjXNvSgRsjTMlb9852bDt+Q0YPONOm6Z6Fgeblq +IQlgoRyZ+nf92ZdNQ6oIHKoFb9HdFzgIhi1p+grEHwQtnyh10bPUsjpq0WUjYe+x5f9 W7vKAFpRRAPiULOl7S6wZieBuq0MZWnWRyxpc= MIME-Version: 1.0 Received: by 10.204.133.18 with SMTP id d18mr556778bkt.76.1314835616262; Wed, 31 Aug 2011 17:06:56 -0700 (PDT) Received: by 10.204.150.72 with HTTP; Wed, 31 Aug 2011 17:06:56 -0700 (PDT) In-Reply-To: References: <4E5CBEA0.2080605@isode.com> <4E5CC6A7.7030304@isode.com> <4E5CC8B8.7090702@isode.com> <4E5D04F8.30801@isode.com> <4E5E5EDA.6000606@gmail.com> <4E5E79C4.2080100@callenish.com> <4E5E94D8.4070302@gmail.com> Date: Wed, 31 Aug 2011 17:06:56 -0700 Message-ID: From: Brian To: Joel Martin Content-Type: multipart/alternative; boundary=001517477f36d868ac04abd605e8 Cc: Hybi Subject: Re: [hybi] Client offers invalid WS protocols, what must the server do? 101??? 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, 01 Sep 2011 00:05:26 -0000 --001517477f36d868ac04abd605e8 Content-Type: text/plain; charset=ISO-8859-1 As far as I'm concerned, the server shouldn't be able to specify a subprotocol if the client didn't request one. If the client didn't request a given subprotocol, it doesn't know how to speak it. That's a failure case, plain and simple. The only "I don't care" exception that is acceptable is when the client requests no subprotocol, and the server specifies no subprotocol in response. Cheers, Brian On Wed, Aug 31, 2011 at 4:58 PM, Joel Martin wrote: > On Wed, Aug 31, 2011 at 4:59 PM, Brian wrote: > >> Yes. This requirement should be in the spec. Frankly, I implemented my >> WebSocket libraries this way as it's the only thing that makes any sense. I >> just assumed that's how it was supposed to be. It didn't really occur to me >> that the protocol was underspecified here. > > > +1. This was also my assumption in implementing websockify. One of the > protocols is mandatory if specified and the server may only respond > successfully if it supports one of them. > > Also, should the server really be able to specify a protocol if the client > didn't specify any? It seems that if the client doesn't specify a protocol > then that ought to mean "no protocol" rather than "any protocol". > > Regards, > > Joel Martin (kanaka) > --001517477f36d868ac04abd605e8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As far as I'm concerned, the server shouldn't be able to specify a = subprotocol if the client didn't request one. =A0If the client didn'= ;t request a given subprotocol, it doesn't know how to speak it. =A0Tha= t's a failure case, plain and simple.

The only "I don't care" exception that is acce= ptable is when the client requests no subprotocol, and the server specifies= no subprotocol in response.

Cheers,
Brian=


On Wed, Aug 31, 2011 at 4:58 PM, Jo= el Martin <hyb= i@martintribe.org> wrote:
On Wed, Aug 31, 2011 at 4:59 P= M, Brian <theturtle32@gmail.com> wrote:
Yes. =A0This requirement should be in the spec. =A0Frankly, I implemented m= y WebSocket libraries this way as it's the only thing that makes any se= nse. =A0I just assumed that's how it was supposed to be. =A0It didn'= ;t really occur to me that the protocol was underspecified here. =A0
=A0
+1. This was also my assumption in implementing we= bsockify. One of the protocols is mandatory if specified and the server may= only respond successfully if it supports one of them.=A0

Also, should the server really be able to specify a protocol if the client = didn't specify any? It seems that if the client doesn't specify a p= rotocol then that ought to mean "no protocol" rather than "a= ny protocol".

Regards,

Joel Martin (kanaka)

--001517477f36d868ac04abd605e8-- From gregw@intalio.com Wed Aug 31 17:46: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 1967721F8DA0 for ; Wed, 31 Aug 2011 17:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.315 X-Spam-Level: X-Spam-Status: No, score=-2.315 tagged_above=-999 required=5 tests=[AWL=-0.538, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_14=0.6, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IbEUMHFt6dY for ; Wed, 31 Aug 2011 17:46:00 -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 47D6421F8D9D for ; Wed, 31 Aug 2011 17:46:00 -0700 (PDT) Received: by vws12 with SMTP id 12so1281523vws.31 for ; Wed, 31 Aug 2011 17:47:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.21.109 with SMTP id u13mr968635vde.447.1314838051537; Wed, 31 Aug 2011 17:47:31 -0700 (PDT) Received: by 10.52.185.133 with HTTP; Wed, 31 Aug 2011 17:47:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Sep 2011 10:47:31 +1000 Message-ID: From: Greg Wilkins To: Ahmed Soliman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] websocket test suite 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, 01 Sep 2011 00:46:01 -0000 Ahmed, The autobahn test suite looks to be way ahead of where I got to. My plan was to integrate jetty to autobahn tests and then review those tests to see if they can be improved or not. cheers On 1 September 2011 07:33, Ahmed Soliman wrote: > Greg, > > Are you still planning to add any of these scenarios to the jetty server? > > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of A= hmed Soliman > Sent: Tuesday, August 09, 2011 2:45 AM > To: Greg Wilkins; Hybi > Subject: Re: [hybi] websocket test suite > > Greg, > > I have the following comments: > 1. Scenario to add: > =A0 =A0 =A0 =A0* Receive/send control frames (e.g. close frame) within a = fragmented message. Verify that client/server responds with a close frame. > > 2. Focusing on interoperability testing: =A0Shouldn't we narrow the tests= below to focus on interoperability testing? =A0I think some of the negativ= e tests below =A0fit better in functional testing rather than interoperabil= ity testing? What do you think? > 3. Standard process/test implementation: I think this will make it easier= to share test implementations and verify interoperability between differen= t protocol implementations. Any thoughts around this? > (e.g. cre ating server endpoints per scenario for server implementation, = =A0using sub-protocol to select between fragmented message/non-fragmented m= essage, .... etc) > > Thanks, > Ahmed > > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of G= reg Wilkins > Sent: Thursday, July 28, 2011 8:15 PM > To: Hybi > Subject: Re: [hybi] websocket test suite > > Here is a first cut at a list of tests for section 4 of the spec. =A0Are = these the kinds of tests people were thinking about? > If so, then I'm happy to go the next step of detail and start providing m= ore detail for each test. > > Obviously some implementation are not going to be able to send some of th= e invalid frames or force fragmentation, so some suites will have to record= some tests as skipped, or only testing in one direction etc. > > > > > 4.2 Base Framing Tests > ---------------------- > > * 7 bit length: send/receive frames of length 0-125 > * 16 bit length: send/receive frames of length 126-128, 65536 > * 63 bit length: send/receive frames of length 65537 > > * Non zero RSV: send frames with non zero reserved bits and no extension.= Verify connection is failed. > > * Known Opcodes: send/receive frames with text,binary,ping,pong opcodes (= continuation & close tested separately). > * Unknown Opcodes: send frames with unknown opcodes 3-7, B-F. Verify conn= ection is failed. > > > 4.3 Client to Server Masking > ---------------------------- > > ??? > > > 4.4 Fragmentation > ----------------- > > * 1 fragment message: send/receive message in 1 fragment > * 2 fragment message: send/receive message in 2 fragments > * 3 fragment message: send/receive message in 3 fragments > * Injected control: send/receive 2 fragment message with unsolicited pong= message between frames > * Fragmented control: send fragmented ping. Verify that connection is fai= led. > * Interleaved fragments: send a fragment with FIN set and Continuation op= code. Verify that connection is failed. > * Handled control: send/receive 2 fragment message with ping message betw= een frames and last frame delayed. Verify pong is received before last fram= e is sent. > * 7 bit fragment: send/receive message with initial/middle/final fragment= s of sizes 0-125 > * 16 bit fragment: send/receive message with initial/middle/final fragmen= ts of sizes 126-128,65536 > * 64 bit fragment: send/receive message with initial/middle/finalfragment= s of size 65537 > > > 4.5.1 Close Frames > ------------------ > * Orderly Close: On an idle connection, send a close and receive a close. > * Busy Close: send a close to an endpoint that has sent the first fragmen= t of a message. > * Simultaneous Close: send a close on both ends of a connection. > * Message after close: attempt to send a message after a close. Verify me= ssage is not received. > * Idle close: ?? > * Error Close: ?? > > > 4.5.2 Ping > ---------- > * Empty ping: Send an empty ping, verify pong is received. > * Non empty ping: Send a non empty ping, verify pong is received. > > > 4.5.3 Pong > ---------- > * Empty pong: Send an empty ping, verify pong is received and is empty. > * Non empty pong: Send a non empty ping, verify pong is received and has = matching content. > * Outstanding ping: Send two pings with different content, reply with con= tent for only the second. Verify connection stays open. > * Unsolicited pong: Send/recv unsolicited pong. > > > 4.5.4 Data Frames > ----------------- > * UTF-8 Text 0000-007f: Send/receive text message with characters in code= point range =A0U+0000 to U+007F > * UTF-8 Text 0080-07ff: Send/receive text message with characters in code= point range =A0U+0080 to U+07FF > * UTF-8 Text 0800-ffff: Send/receive text message with characters in code= point range =A0U+0800 to U+FFFF > * UTF-8 Text 010000-10ffff: Send/receive text message with characters in = code point range =A0U+010000 to U+10FFFF > * Illegal bytes UTF-8: Send message with invalid UTF-8 byte sequence. > Verify message is not received. > * Illegal codes UTF-8: Send message with invalid UTF-8 code points. > Verify message is not received. > * Binary frames: Send/receive message containing illegal UTF-8 bytes sequ= ences and code points as binary message. > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From gregw@intalio.com Wed Aug 31 19:00: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 5051421F8D67 for ; Wed, 31 Aug 2011 19:00:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.908 X-Spam-Level: X-Spam-Status: No, score=-2.908 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saGdYPkjyS-R for ; Wed, 31 Aug 2011 19:00: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 ABF9A21F8D32 for ; Wed, 31 Aug 2011 19:00:33 -0700 (PDT) Received: by vxi29 with SMTP id 29so1193661vxi.31 for ; Wed, 31 Aug 2011 19:02:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.34.171 with SMTP id a11mr916513vdj.313.1314842525143; Wed, 31 Aug 2011 19:02:05 -0700 (PDT) Received: by 10.52.185.133 with HTTP; Wed, 31 Aug 2011 19:02:05 -0700 (PDT) Date: Thu, 1 Sep 2011 12:02:05 +1000 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Subject: [hybi] Draft 13 - a bit too historical about the masking debate 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, 01 Sep 2011 02:00:34 -0000 Draft 13 contains a lot of text about the reasons for masking. That must not have been easy to write and for the most part it reads well. However I'm not sure we should go into so much detail about the history of the disagreements and the process. Specifically I think the following paragraph: To avoid such attacks on deployed intermediaries, the working group decided to adopt a solution that would provably protect against such attacks. There were many proposed solutions that people argued "should" protect against the above attacks, such as adding in more random data and null bytes to the handshake, starting each frame with a byte that has the first (highest order) bit set such that the data appears to be non-ASCII, and so forth, but in the end none of these solutions were provably secure. The deployed intermediaries were already not conforming to existing specifications, and given that we can't possibly enumerate all of the ways in which such nonconformities could exhibit themselves and that we cannot exhaustively discover and test each nonconformant intermediary against each possible attack, there was consensus to adopt an approach that did not require people to reason about how nonconformant intermediaries might behave. Namely, the working group decided to mask all data from the client to the server, so that the remote script (attacker) does not have control over how the data being sent appears on the wire, and thus cannot construct a message that could be mis- interpreted by an intermediary as an HTTP request. could be changed to to something like To provably avoid such attacks on deployed intermediaries, it is not sufficient to prefix application supplied data with framing that is not compliant HTTP, as it is not possible to exhaustively discover and test that each nonconformant intermediary does not skip such non HTTP framing and act incorrectly on the frame payload. Thus the defence adopted is to mask all data from the client to the server, so that the remote script (attacker) does not have control over how the data being sent appears on the wire, and thus cannot construct a message that could be misinterpreted by an intermediary as an HTTP request. From w@1wt.eu Wed Aug 31 22:53: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 4EBBA21F8B31 for ; Wed, 31 Aug 2011 22:53:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.106 X-Spam-Level: X-Spam-Status: No, score=-4.106 tagged_above=-999 required=5 tests=[AWL=-2.063, BAYES_00=-2.599, HELO_IS_SMALL6=0.556] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqpdwC614NPF for ; Wed, 31 Aug 2011 22:53:11 -0700 (PDT) Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 03DF021F8B30 for ; Wed, 31 Aug 2011 22:53:10 -0700 (PDT) Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id p815sbho004987; Thu, 1 Sep 2011 07:54:37 +0200 Date: Thu, 1 Sep 2011 07:54:37 +0200 From: Willy Tarreau To: Greg Wilkins Message-ID: <20110901055437.GS2075@1wt.eu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: Hybi Subject: Re: [hybi] Draft 13 - a bit too historical about the masking debate 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, 01 Sep 2011 05:53:12 -0000 Hi Greg, On Thu, Sep 01, 2011 at 12:02:05PM +1000, Greg Wilkins wrote: > Draft 13 contains a lot of text about the reasons for masking. That > must not have been easy to write and for the most part it reads well. > However I'm not sure we should go into so much detail about the > history of the disagreements and the process. Specifically I think > the following paragraph: > > To avoid such attacks on deployed intermediaries, the working group > decided to adopt a solution that would provably protect against such > attacks. There were many proposed solutions that people argued > "should" protect against the above attacks, such as adding in more > random data and null bytes to the handshake, starting each frame with > a byte that has the first (highest order) bit set such that the data > appears to be non-ASCII, and so forth, but in the end none of these > solutions were provably secure. The deployed intermediaries were > already not conforming to existing specifications, and given that we > can't possibly enumerate all of the ways in which such > nonconformities could exhibit themselves and that we cannot > exhaustively discover and test each nonconformant intermediary > against each possible attack, there was consensus to adopt an > approach that did not require people to reason about how > nonconformant intermediaries might behave. Namely, the working group > decided to mask all data from the client to the server, so that the > remote script (attacker) does not have control over how the data > being sent appears on the wire, and thus cannot construct a message > that could be mis- interpreted by an intermediary as an HTTP request. > > > could be changed to to something like > > To provably avoid such attacks on deployed intermediaries, it is not > sufficient to prefix application supplied data with framing that is not > compliant HTTP, as it is not possible to exhaustively discover and test > that each nonconformant intermediary does not skip such non HTTP > framing and act incorrectly on the frame payload. Thus the defence > adopted is to mask all data from the client to the server, so that the > remote script (attacker) does not have control over how the data being > sent appears on the wire, and thus cannot construct a message that > could be misinterpreted by an intermediary as an HTTP request. Well, I have nothing against the original version, but yours looks fine to me too and is shorter. One thing I like in the first one is that it insists more on convincing the reader that there's no point claiming that this masking is stupid and useless. But we probably don't really care what people will think once the draft is released anyway. Willy From sustrik@250bpm.com Wed Aug 31 23:55: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 A127421F8B23 for ; Wed, 31 Aug 2011 23:55:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWzpAmE3aCIc for ; Wed, 31 Aug 2011 23:55:50 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24FA121F8B19 for ; Wed, 31 Aug 2011 23:55:50 -0700 (PDT) Received: from [10.9.1.2] (chello089173046084.chello.sk [89.173.46.84]) by mail.moloch.sk (Postfix) with ESMTPSA id DF7151833E03 for ; Thu, 1 Sep 2011 08:57:21 +0200 (CEST) Message-ID: <4E5F2CD9.1050208@250bpm.com> Date: Thu, 01 Sep 2011 08:57:29 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110805 Thunderbird/3.1.12 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] multiplexing 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, 01 Sep 2011 06:55:50 -0000 Hi, Draft 13 says: "A secondary use-case for fragmentation is for multiplexing, where it is not desirable for a large message on one logical channel to monopolize the output channel, so the MUX needs to be free to split the message into smaller fragments to better share the output channel." The above doesn't play well with TCP pushback. If there are two streams passed on top of single TCP connection, and the application doesn't keep up with reading one stream, the other stream gets stuck as well. Is the intention not to use pushback as a means of flow control? In other words, if you can't process a message immediately, you must read it anyway so as not to block other streams? That sounds like a recipe for running out of memory. Martin