From sm@elandsys.com Fri Feb 1 02:43:43 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5B321F883E for ; Fri, 1 Feb 2013 02:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NFvrQP2qzN1s for ; Fri, 1 Feb 2013 02:43:42 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id B63FD21F882F for ; Fri, 1 Feb 2013 02:43:42 -0800 (PST) Received: from SUBMAN.elandsys.com ([197.224.135.114]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r11AhOIt002473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2013 02:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1359715415; bh=pKhEk0L4dQ2tFbdpboya5lzzgOjdqEoXu+ghcW2NfwQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=SgGUOODhOMgY/QfmIGg9qNRWfFIVfkGf3ZYp+tDfdlwZ7eU0ZPmA//hDVukxBQpKp TUlB30kdJu9JByFc2ubO/FnVhwuSrbwD9YmJYqjVQhYTdOwyToJBGf0i/TfxkOpq6C bzbSwobDg0Fspsz26thhCHnRkoKHWZXE6ofCtZmE= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1359715415; i=@elandsys.com; bh=pKhEk0L4dQ2tFbdpboya5lzzgOjdqEoXu+ghcW2NfwQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=K3Aju2ozsvUd6zrzySJ/0skjTvhfjXNzawsGh7obEzAyEaMh0A2Jxno4ftI82ZtOr j/pH2ZTAxkaD+VBx7BtmEx6RGEskAaosE2qUsbHPsVDLTSyrp5eSD960m+tRd9Q1SZ nDzxa7m2YGzu/U4yv4Dtg7Ls2J+gfPoK6P2n+lY8= Message-Id: <6.2.5.6.2.20130131235748.09ed41b8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 01 Feb 2013 00:02:37 -0800 To: Simone Bordet From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: hybi@ietf.org Subject: Re: [hybi] WebSocket connection throttling clarification requested X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 10:43:43 -0000 Hi Simone, At 01:48 24-01-2013, Simone Bordet wrote: >I'd like to propose to remove this requirement and changing it a >non-normative section as a suggestion for browser implementations. If the removal of the requirement is proposed through an erratum, the erratum will likely be rejected (see http://www.ietf.org/iesg/statement/errata-processing.html ). I suggest commenting on the message at http://www.ietf.org/mail-archive/web/hybi/current/msg09961.html Regards, S. Moonesamy From martin.thomson@gmail.com Fri Feb 1 06:27:39 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0377721F8FF4 for ; Fri, 1 Feb 2013 06:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.074 X-Spam-Level: X-Spam-Status: No, score=-4.074 tagged_above=-999 required=5 tests=[AWL=-0.476, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, WEIRD_PORT=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EmEmTUXyEwo for ; Fri, 1 Feb 2013 06:27:38 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id C848C21F8DF8 for ; Fri, 1 Feb 2013 06:27:34 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so2980958wgb.5 for ; Fri, 01 Feb 2013 06:27:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=8uVqdEn2HTmFq3PtJA9zZhUyhyKybeTEVtTPdFFwsKo=; b=rhwJaZPx9oFMXdsa2xsxPwq3wh7ipuaf04vvZFSchDu7Xbmb0tcBOyTVzprBdkAFSY XME0zVAC8C39PpoMqFqYj5JCPIWCBrg7zciXYASjQadxvd8Jxz4MqC2jmSwq8mlCHVX0 bqEPKueTAOJ9lgtAWjVooeZsMqaLEh1Td6hysyR462VI+6d1GamJ8kG6VD82nOXmSY99 a+o0AJe7qsgJg0HQANNC/Ioctu+Hzc2JkEasJCpnTHPAzyirBmsa5yFx+jrp1kKjrjsS PrfudFDwTOQjwt+tXHlMCVnLykLjLaJDfmzJnaJ4h495n1dgoFHcCLAJifaPfUMo3yaY RLnA== MIME-Version: 1.0 X-Received: by 10.194.123.105 with SMTP id lz9mr22210254wjb.43.1359728853596; Fri, 01 Feb 2013 06:27:33 -0800 (PST) Received: by 10.194.161.234 with HTTP; Fri, 1 Feb 2013 06:27:33 -0800 (PST) In-Reply-To: <20130201073846.78956B1E003@rfc-editor.org> References: <20130201073846.78956B1E003@rfc-editor.org> Date: Fri, 1 Feb 2013 23:27:33 +0900 Message-ID: From: Martin Thomson To: RFC Errata System Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "hybi@ietf.org" , presnick@qti.qualcomm.com, ifette+ietf@google.com, Gabriel Montenegro , Barry Leiba Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:27:39 -0000 Is this "host and port" or "IP and port" ? That too is unclear. If I'm sharding a.example.com and b.example.com and they are served on the same VIP, is the expectation that wss://a.example.com/ and wss://b.example.com/ can't have concurrent connection attempts? On 1 February 2013 16:38, RFC Errata System wro= te: > > The following errata report has been submitted for RFC6455, > "The WebSocket Protocol". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6455&eid=3D3473 > > -------------------------------------- > Type: Editorial > Reported by: Adam Rice > > Section: 4.1 > > Original Text > ------------- > 2. If the client already has a WebSocket connection to the remote > host (IP address) identified by /host/ and port /port/ pair, even > if the remote host is known by another name, the client MUST wait > until that connection has been established or for that connection > to have failed. There MUST be no more than one connection in a > CONNECTING state. If multiple connections to the same IP address > are attempted simultaneously, the client MUST serialize them so > that there is no more than one connection at a time running > through the following steps. > > Corrected Text > -------------- > 2. If the client already has a WebSocket connection to the remote > host (IP address) identified by /host/ and port /port/ pair, even > if the remote host is known by another name, the client MUST wait > until that connection has been established or for that connection > to have failed. There MUST be no more than one connection in a > CONNECTING state. If multiple connections to the same /host/ and > /port/ pair are attempted simultaneously, the client MUST serializ= e > them so that there is no more than one connection at a time runnin= g > through the following steps. > > Notes > ----- > The original wording makes it ambiguous whether distinct ports on the sam= e host are considered distinct for throttling purposes. The first sentence = implies that the throttling should be applied per (host,port) pair, whereas= the final sentence implies it is only based on IP address. > > Implementations of both interpretations appear to exist in the wild. > > I propose disambiguating in favour of the (host,port) interpretation, bec= ause the host-only interpretation allows for a potential denial-of-service = attack targeted against hosts which drop packets to unused ports. > > For example, an attacker from a different origin can create several hundr= ed WebSockets to "wss://google.com:81/". Each one will attempt to connect i= n serial, and take tens of seconds to time out. > > If the user then attempts to use an application which legitimately uses a= WebSocket to "wss://google.com:443/", then due to the throttling to google= .com it will not be able to connect until all of the attacker's connections= have timed out. > > The user will perceive that the legitimate application is malfunctioning,= since there is no visible sign that they are being attacked. From the serv= er end, the attack is only apparent in the firewall logs. The actual rate o= f SYN packets dropped will be small and unlikely to trigger an alert. > > On the other hand, with the (host,port) interpretation, connections to go= ogle.com:81 do not block connections to google.com:443, and this attack is = completely ineffective. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6455 (draft-ietf-hybi-thewebsocketprotocol-17) > -------------------------------------- > Title : The WebSocket Protocol > Publication Date : December 2011 > Author(s) : I. Fette, A. Melnikov > Category : PROPOSED STANDARD > Source : BiDirectional or Server-Initiated HTTP > Area : Applications > Stream : IETF > Verifying Party : IESG > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From tyoshino@google.com Sun Feb 3 22:30:47 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A152021F8984 for ; Sun, 3 Feb 2013 22:30:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Twb-EGZRxiG8 for ; Sun, 3 Feb 2013 22:30:47 -0800 (PST) Received: from mail-ve0-f172.google.com (mail-ve0-f172.google.com [209.85.128.172]) by ietfa.amsl.com (Postfix) with ESMTP id D1B8B21F8959 for ; Sun, 3 Feb 2013 22:30:46 -0800 (PST) Received: by mail-ve0-f172.google.com with SMTP id cz11so2968315veb.3 for ; Sun, 03 Feb 2013 22:30:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=1PPT9NZJWe5AfXNCr4g8rnGr+HypGPAn649ni2+7LHU=; b=JZ1yjgJO9tKOznbKCw6RhSDggIhvg7FamcJzSJPTcAfmXieVpafWnT+FnnUL1N1exn uwUwuRVuF3VNJmQNiPKITresRyN0r5A8fS+8ZVHd8vwI5mSryv+axk3oDWZl/ffA+Olo 4fUG1EqIIXIn6wYbgp/g2FhJDeA7/38e5OtFBoO73f7MgkfXuAbYXwd69kV4F/djw5+5 NVLVVzVPOCrGTiSDlqVVQ2bJ9CPngexsrsQXm52zi2FRU3ZYuPOBvNXGow24hRRYjLpt JPsWaI9UaBPlW1FhqZG6Zn22U+shDyfmpQ1+3k8Q6YIAv6Rh7KdOov27YXbrZT/NdLmt NYgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:content-type:x-gm-message-state; bh=1PPT9NZJWe5AfXNCr4g8rnGr+HypGPAn649ni2+7LHU=; b=QmpYx946UMHsQDU4IAUIQWgYMdmQy8LO5gErPzP1kKMqp8eZ3f9sQ8F1rPZJ/7G/W0 YaIqYyuX/CHAK3dkAsIHmW2FN5FIwzj5/tv72GvPDUXPVuxmJzAeuPszMzxDsU6MK0T2 0KegNLB+0pcRaYLHDC5mLowzDydt3zM7QgJ17au9XSrXHVse4KmPa9xS+hIwh7goxWE3 W6+Zd0cRGAFLIl2riUHtacbwV1O38zi2q8i2m/Uny5Rl49qupEHYr8n4xlOk/oNCfBNy ZmwN9lCsK+NEKcf+v5PVeuwux97ViGTYntU+XMd37+V1MgNfcBaZK1ZfiGME4H8zaF+K e7GQ== X-Received: by 10.52.89.83 with SMTP id bm19mr3421055vdb.123.1359959446196; Sun, 03 Feb 2013 22:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.134.34 with HTTP; Sun, 3 Feb 2013 22:30:26 -0800 (PST) In-Reply-To: <6.2.5.6.2.20130131235748.09ed41b8@resistor.net> References: <6.2.5.6.2.20130131235748.09ed41b8@resistor.net> From: Takeshi Yoshino Date: Mon, 4 Feb 2013 15:30:26 +0900 Message-ID: To: "hybi@ietf.org" Content-Type: multipart/alternative; boundary=20cf307f3264b312cb04d4e03bfa X-Gm-Message-State: ALoCoQnvpVHCUuha196zPWK8XC91sYY+aYWLpJII61ebxbwFuSXUHlc1RGt52kXiQdm6KelwB5tTqiEI01yMSaEwdkHIv9QlOEblYuONhhe79D+rjo/ynYdKHVgisl/ksbWOAq8U+jIzKCNZZ5VyyneGEwvAgtKRzniiY2U+lhvZ9vGPoTYWGGLpoH3r8sT0dSLODhq0G5dG Subject: Re: [hybi] WebSocket connection throttling clarification requested X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 06:30:47 -0000 --20cf307f3264b312cb04d4e03bfa Content-Type: text/plain; charset=ISO-8859-1 +1 to both Simone and Adam's suggestion. How about just adding an erratum of host-port clarification not to confuse readers, and plan (hold for document update) to change the MUST to SHOULD? --20cf307f3264b312cb04d4e03bfa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1 to both Simone and Ada= m's suggestion.

How about just adding an erratum of host-port cla= rification not to confuse readers, and plan (hold for document update) to c= hange the MUST to SHOULD?

--20cf307f3264b312cb04d4e03bfa-- From tyoshino@google.com Sun Feb 3 22:50:08 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72AC21F892B for ; Sun, 3 Feb 2013 22:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.726 X-Spam-Level: X-Spam-Status: No, score=-102.726 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FU8FcuKoYCLp for ; Sun, 3 Feb 2013 22:50:07 -0800 (PST) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by ietfa.amsl.com (Postfix) with ESMTP id B90A921F891A for ; Sun, 3 Feb 2013 22:50:06 -0800 (PST) Received: by mail-vb0-f49.google.com with SMTP id s24so3648956vbi.22 for ; Sun, 03 Feb 2013 22:50:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=ru5t3uMzdebMkCHvBmKKWhC6DkVrin1ZtvbAmfPgjX0=; b=hNvahSjRtxVMLYKgpDrVQG+NiEve+qOxi6T44MPRuAPVkF5cB78CJrT5waBB+wZ0w8 UgehUIDfPokVZ2oKlfP53yU7i0LvgDSP7FM7+vd/Sk8rwIreeFukLEegmRW66JvWuKXM gv7f2p3tkpO4ne1yHOHOHb3jQ8H4MAfGX2letauIrZRXUP44i9iJA6yf6/5lciju11ot 7JlknayQviMf875TwYl4+0lrRvju8MsYsHV8jb3b4ziTnJPcMBEXkHrTr4UAmcQYhb7V CKa62hrfeo59A8SiAueH+y6PRy8I3UNZ6CGxi6joHJhPEcetp/vskgUSWoowhxfiuSuj P1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=ru5t3uMzdebMkCHvBmKKWhC6DkVrin1ZtvbAmfPgjX0=; b=WQWmWV6+nTXpILVpLElwOmPbemZh6y3cvTcb+pVYW52azbvC+sK/AoYjntPCfdIIJG 5wsYX3VgG6cyQIfNaa4Vo+rVYjlFHbCCS1waQRTO28hRlxHjHEVFgXDlvUden1UGNmIg MrQaO1VbJjWmg0QsVikK545V1ilKX8CCdaAvm9Z6HsvAFhozgh8ZMYa82WZFMAYwyKn8 bY5SbinMsEpfSb3qmAtJKXqH1HdOEDz2EiQSQN0xu+icjx9fC74zfs8QLhWO22bCLUTw Oy6B5lUOAZkuei2xLDpCp9ksUndFX3SBN7vypFf0yCc7X67hCm5OFwJg6dexegveTJr8 747g== X-Received: by 10.220.149.82 with SMTP id s18mr20940678vcv.14.1359960605917; Sun, 03 Feb 2013 22:50:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.134.34 with HTTP; Sun, 3 Feb 2013 22:49:45 -0800 (PST) In-Reply-To: References: <20130201073846.78956B1E003@rfc-editor.org> From: Takeshi Yoshino Date: Mon, 4 Feb 2013 15:49:45 +0900 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=f46d043d64a3d3030004d4e0800c X-Gm-Message-State: ALoCoQmFoA6zBMv2tjaQ5WtaaoFzHiQLRC1HLHiqJzB5UzQq+6hrv1un9hVjrjvS1UptO8gTuBzXnv026USJjO+Gkqj1o9lPwt8A2fagzZ+JqXXEoD0aBb73Qsar2U8voPqYAQYZEvOstnip2XYC7HAqqExlCriyPSK4iCvUjFplOnIGexiACRX7GVSU0ekEgOLtomQwoa9m Cc: "hybi@ietf.org" , presnick@qti.qualcomm.com, "ifette+ietf@google.com" , Gabriel Montenegro , Barry Leiba , RFC Errata System Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 06:50:08 -0000 --f46d043d64a3d3030004d4e0800c Content-Type: text/plain; charset=ISO-8859-1 FYI: The text (without /port/) was introduced by Ian Hickson on this release (April 2009). http://tools.ietf.org/rfcdiff?url2=draft-hixie-thewebsocketprotocol-11.txt MUST was added to the sentence by bulk addition of MUSTs/SHOULDs on this release. Even before this was specified as MUST indirectly by the introduction text for this algorithm. http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-04.txt /port/ was added on this release. I couldn't find discussion led to this change on the list. http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-thewebsocketprotocol-07.txt On Fri, Feb 1, 2013 at 11:27 PM, Martin Thomson wrote: > Is this "host and port" or "IP and port" ? That too is unclear. If > Yes... /host/ in the spec is not always IP address. According to hixie-11, it was intended to mean IP and he added the text "even if the remote host is known by another name" (I'm not saying everybody in HyBi later agreed with the text interpreting it that way). > I'm sharding a.example.com and b.example.com and they are served on > the same VIP, is the expectation that wss://a.example.com/ and > wss://b.example.com/ can't have concurrent connection attempts? I think we should do so (no concurrent connection to a.example.com and b.example.com). Throttling based on domain name / port pair might make sense if a.example.com and b.example.com has different backends as you said and the LB having the VIP has much more processing power than backends. But as anybody can have A record pointing to the IP address (x.x.x.x) of a.example.com, an attacker can prepare a.attacker.com, b.attacker.com, ... pointing to x.x.x.x and feed a script connecting to ws://a.attacker.com, ... to bypass the throttling (domain name based). --f46d043d64a3d3030004d4e0800c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI:

The text = (without /port/) was introduced by Ian Hickson on this release (April 2009)= .
http://tools.ietf.org/rfcdiff?url2= =3Ddraft-hixie-thewebsocketprotocol-11.txt=A0
MUST was added to the sentence by bulk addition of MUSTs/SHOULDs on this re= lease. Even before this was specified as MUST indirectly by the introductio= n text for this algorithm.
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-thewebsocketprotocol= -04.txt=A0
/port/ was added on this release. I couldn= 't find discussion led to this change on the list.
http://tools.ietf.org/rfcdiff?url2=3Ddraft-ie= tf-hybi-thewebsocketprotocol-07.txt=A0

On Fri, Feb 1, 2013 at 11:27 PM, Marti= n Thomson <martin.thomson@gmail.com> wrote:
Is this "host and port" or "IP and port&quo= t; ? =A0That too is unclear. =A0If

Yes... /host/ in the spec is not always IP= address. According to hixie-11, it was intended to mean IP and he added th= e text "even=A0if the remote host is known by another name" (I= 9;m not saying everybody in HyBi later agreed with the text interpreting it= that way).=A0
=A0
I'm sharding a.examp= le.com and b.example= .com and they are served on
the same VIP, is the expectation that wss://a.example.com/ and
wss://b.example.com/ can't have concurrent connection attempts?

I think we should do so (no concurrent connection to a.example.com and b.example.com). Throttling based on domain name / port pair might ma= ke sense if a.example.com and b.example.com has different backends as you s= aid and the LB having the VIP has much more processing power than backends.= But as anybody can have A record pointing to the IP address (x.x.x.x) of <= a href=3D"http://a.example.com">a.example.com, an attacker can prepare = a.attacker.com, b.attacker.com, ... pointing to x.x.x.x and feed a script = connecting to ws://a.attacker.com, ..= . to bypass the throttling (domain name based).

--f46d043d64a3d3030004d4e0800c-- From ricea@google.com Mon Feb 4 00:20:31 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1390721F874B for ; Mon, 4 Feb 2013 00:20:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.975 X-Spam-Level: X-Spam-Status: No, score=-102.975 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szS2BWtQY35q for ; Mon, 4 Feb 2013 00:20:30 -0800 (PST) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by ietfa.amsl.com (Postfix) with ESMTP id 4E08A21F8901 for ; Mon, 4 Feb 2013 00:20:30 -0800 (PST) Received: by mail-vc0-f182.google.com with SMTP id fl17so3768029vcb.27 for ; Mon, 04 Feb 2013 00:20:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JZ0KNTcm3HN8uXy5fwdKcd8tw9Xok+EMXcoGC8aYN+c=; b=igJADIy6pCQmsJN4h0CfPt+ypuyAtXB6FZmkq88T0Cl8uCY9ib6n8k+H1a+G/A0p0/ a8oPgOpFdykQLxcOdMl2IkUCEJP5n0AQnobmEL4S6c+D5QO7miEXQ5pqdC5EMypeVWMT 3kzLmM1yLUd29/fy6mxsVaPQwS0PYnPM9JFApGCuQJclI7dHca1sL81EW0lqMTPunhwy b4Zu7CAbZ6v1wEIR1Tt4WPRRMi6ukznhIH2U7DIAY/XyPb34hjzVcLg8EG9eOiFoK/sn CNOSbE5no0Z+U9EjGBfeA92qLKgQpnXwb18/QRl7Or+y4f4tFf2b9e/6QQk8tlQ3I8wt ln/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=JZ0KNTcm3HN8uXy5fwdKcd8tw9Xok+EMXcoGC8aYN+c=; b=h42Iu4+W5G8Yidn8Pybwt2QmQUrou6hbGR/dqqxETDHIWcG29w272YiCJISSW4j7IZ J9K36FJdm5nLmy5jYV/NO33RzxYT+BL8brFE43kKyTXEW+JcZ14FNg7HmXO2Ub/xzl1+ 6yh0/4AhbJxEkdZ1MFzW/Sq+5M0RhZc/8kQoCAsBcHY/QlnHYET6n3xgsYS6HQ98fpl5 CCsZcYlDYS7qt+KheY47gvZr8VG3vMo+CNyCkVIZTRucnxcjl8xoG2Kfu8vU0YAdGl83 LdykG+puXUjuR0kZA42FUqQcyVafxzpZ2g46svJRR5HxeeTEG3imv7gUFHzeySpC8MJ0 q6FA== MIME-Version: 1.0 X-Received: by 10.52.176.202 with SMTP id ck10mr18336554vdc.42.1359966029680; Mon, 04 Feb 2013 00:20:29 -0800 (PST) Received: by 10.58.114.197 with HTTP; Mon, 4 Feb 2013 00:20:29 -0800 (PST) In-Reply-To: References: <20130201073846.78956B1E003@rfc-editor.org> Date: Mon, 4 Feb 2013 17:20:29 +0900 Message-ID: From: Adam Rice To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3071cfc41b0fdf04d4e1c4e3 X-Gm-Message-State: ALoCoQm+zu31ANKyXkp/4oHdflQi+vqYFxQVmdALylgz+2R28A6pwjydVpe0bfcoKJ+R77DvyyITnM8POEGUoah95NgBL+FzdEBZ5hYI0lV4FNRuR31aeZUcSwPn/Pw/hu5yr8nbE1HlkA8lauovviwIW2V24GsgvBK86JgjuJFf14UBpklzbHfh1TpbKnUS0G6wQbFMEBlY X-Mailman-Approved-At: Mon, 04 Feb 2013 02:49:19 -0800 Cc: "hybi@ietf.org" , presnick@qti.qualcomm.com, ifette+ietf@google.com, Gabriel Montenegro , Barry Leiba , RFC Errata System Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2013 08:20:31 -0000 --20cf3071cfc41b0fdf04d4e1c4e3 Content-Type: text/plain; charset=ISO-8859-1 On 1 February 2013 23:27, Martin Thomson wrote: > Is this "host and port" or "IP and port" ? That too is unclear. If > I'm sharding a.example.com and b.example.com and they are served on > the same VIP, is the expectation that wss://a.example.com/ and > wss://b.example.com/ can't have concurrent connection attempts? I was assuming that in the first sentence the text "connection to the remote host (IP address) ... even if the remote host is known by another name" made the interpretation of "IP address" unambiguous. But section 4.1 says that /host/ is defined in section 3, and section 3 actually defines /host/ as "host = >", ie. the host portion of the URI. So now I don't know. --20cf3071cfc41b0fdf04d4e1c4e3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On 1 February 2013 23:27, Martin Thomson <martin.thomson@gmail.com> wrote:
Is this "host and port&quo= t; or "IP and port" ? =A0That too is unclear. =A0If
I'm sharding a.example.com and b.example.com and they are served on
the same VIP, is the expectation that wss://a.example.com/ and
wss://= b.example.com/ can't have concurrent connection attempts?

I was assuming that in the first sentence the text &= quot;connection to the remote=A0host (IP address) ... even if the = remote host is known by another name" made the interpretation of "= ;IP address" unambiguous.

But section 4.1 says that /host/ is defined in= section 3, and section 3 =A0actually defines /host/ as "host =3D <host, defined in [RFC3986], Section=A03.2.2>", ie. the host portion of the URI.

So now I don't know.
--20cf3071cfc41b0fdf04d4e1c4e3-- From martin.thomson@gmail.com Tue Feb 5 05:00:37 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5A721F87A6 for ; Tue, 5 Feb 2013 05:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.87 X-Spam-Level: X-Spam-Status: No, score=-4.87 tagged_above=-999 required=5 tests=[AWL=-1.272, BAYES_00=-2.599, 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 XAlPBEykYMh5 for ; Tue, 5 Feb 2013 05:00:37 -0800 (PST) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by ietfa.amsl.com (Postfix) with ESMTP id 00EDB21F865B for ; Tue, 5 Feb 2013 05:00:36 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id es5so95548wgb.29 for ; Tue, 05 Feb 2013 05:00:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hqL5bDwI1q2YPNinPDUttHAIM1Lu/kbEDR5on0NdmNM=; b=IWK2IWfC+ziTCPa5SllMNSlgLTGJ7qAWsBFGOsZfA1sQaeR7dxXDLyKXvycUaAV5sf O7MeHUznvJPJXSqYvWRBCFywokTG54QApnDMQCDpUG+6gcpGYfQJBY598Z1YKUDqovLq SMA8ap6N+ajlDUj2DquFwUITFOs2bQ5dGdnr+Uz+e9dczLz/ScncFBfGCxJTc6mSXg/p sGrnWfzj3RTaaQ1WJwrmiIRnYQfT+h7K9BHCL62uMk8lgO4l5ikG8wiNY7/QjCLdC0FX qYmp9CakF9DoIXhfKWMHx8I066cgtm6sKUR8dpNic11LPwVaHTZQzf1rKyWYyhsvmwXQ Uv5Q== MIME-Version: 1.0 X-Received: by 10.180.80.35 with SMTP id o3mr17175399wix.9.1360069227815; Tue, 05 Feb 2013 05:00:27 -0800 (PST) Received: by 10.194.5.135 with HTTP; Tue, 5 Feb 2013 05:00:27 -0800 (PST) Received: by 10.194.5.135 with HTTP; Tue, 5 Feb 2013 05:00:27 -0800 (PST) In-Reply-To: References: <20130201073846.78956B1E003@rfc-editor.org> Date: Tue, 5 Feb 2013 08:00:27 -0500 Message-ID: From: Martin Thomson To: Adam Rice Content-Type: multipart/alternative; boundary=f46d044287f231a25504d4f9cb9a Cc: "hybi@ietf.org" , presnick@qti.qualcomm.com, ifette+ietf@google.com, Gabriel Montenegro , Barry Leiba , RFC Errata System Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Feb 2013 13:00:38 -0000 --f46d044287f231a25504d4f9cb9a Content-Type: text/plain; charset=UTF-8 That is approximately where my reasoning lead. I think that the *safe* option is to have one connection per name. On Feb 4, 2013 3:20 AM, "Adam Rice" wrote: > On 1 February 2013 23:27, Martin Thomson wrote: > >> Is this "host and port" or "IP and port" ? That too is unclear. If >> I'm sharding a.example.com and b.example.com and they are served on >> the same VIP, is the expectation that wss://a.example.com/ and >> wss://b.example.com/ can't have concurrent connection attempts? > > > I was assuming that in the first sentence the text "connection to the > remote host (IP address) ... even if the remote host is known by another > name" made the interpretation of "IP address" unambiguous. > > But section 4.1 says that /host/ is defined in section 3, and section 3 > actually defines /host/ as "host = Section 3.2.2 >", ie. > the host portion of the URI. > > So now I don't know. > --f46d044287f231a25504d4f9cb9a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That is approximately where my reasoning lead. I think that the *safe* o= ption is to have one connection per name.

On Feb 4, 2013 3:20 AM, "Adam Rice" &l= t;ricea@google.com> wrote:
--f46d044287f231a25504d4f9cb9a-- From salvatore.loreto@ericsson.com Wed Feb 13 23:45:59 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54DEB11E809C for ; Wed, 13 Feb 2013 23:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.248 X-Spam-Level: X-Spam-Status: No, score=-106.248 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 NVcoIbQR9Kku for ; Wed, 13 Feb 2013 23:45:57 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8366F21E8042 for ; Wed, 13 Feb 2013 23:45:51 -0800 (PST) X-AuditID: c1b4fb25-b7f366d000004d10-5f-511c962e2ff6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 5B.4A.19728.E269C115; Thu, 14 Feb 2013 08:45:50 +0100 (CET) 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.279.1; Thu, 14 Feb 2013 08:45:50 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B48DD2ADD for ; Thu, 14 Feb 2013 09:45:49 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 5857F54319 for ; Thu, 14 Feb 2013 09:45:47 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 126F953F90 for ; Thu, 14 Feb 2013 09:45:47 +0200 (EET) Message-ID: <511C962C.8080904@ericsson.com> Date: Thu, 14 Feb 2013 09:45:48 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: hybi@ietf.org References: <20130201073846.78956B1E003@rfc-editor.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000705090901010303060602" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+Jvja7eNJlAg5+rxS3ev9zG5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ8dB1gLnoZX/G99ztjAeMO+i5GDQ0LAROJnJ3MXIyeQKSZx 4d56ti5GLg4hgZOMEhe6n7FAOBsYJdZd6WaGcM4xSjx88RKq7CCjxNUTPVBlpxglVj6ewAwy l1dAW+LjnVCQuSwCqhIH/y5kBLHZBMwknj/cArZPVCAZqOQaK4jNKyAocXLmExYQWwTI7t66 BmyMsICdxPEZgRDj25gktuw6ywZSwykQKHFl6kmwOcwCYRIT53SyQ/ygJnH13CawuJCAlkTv 2U6mCYzCs5CsmIWkBcK2lbgw5zpUXF5i+9s5zBC2rsSF/1NQxBcwsq1iZM9NzMxJLzfaxAgM /YNbfqvuYLxzTuQQozQHi5I4b7jrhQAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjB5GMzeL ZRXpLy3bMyk6W+7KwQ9SDkFVT2dsPjGnVK+Zh1/9lsMUrper+sWfG93nfunz66rqj5peS92E Zy/36ppJC138qLTyluPzj6xlbZ7VHjIL457+fHDS5UuE7p+o+xdU80TZfq/TLpEu+F53xiR3 rtqKlLNqj45Ntjnd58GtKD+lMjM6RImlOCPRUIu5qDgRAHDLAhtLAgAA Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 07:45:59 -0000 --------------000705090901010303060602 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit the original idea was to serialize the tentative to connect to the same IP address (especially in the case several /host/ names share the same IP address); IMO it becomes clear if you read the second paragraph of the bullet #2 and the NOTE. 2. If the client already has a WebSocket connection to the remote host (IP address) identified by /host/ and port /port/ pair, even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same IP address are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps. If the client cannot determine the IP address of the remote host (for example, because all communication is being done through a proxy server that performs DNS queries itself), then the client MUST assume for the purposes of this step that each host name refers to a distinct remote host, and instead the client SHOULD limit the total number of simultaneous pending connections to a reasonably low number (e.g., the client might allow simultaneous pending connections to a.example.com and b.example.com, but if thirty simultaneous connections to a single host are requested, that may not be allowed). For example, in a web browser context, the client needs to consider the number of tabs the user has open in setting a limit to the number of simultaneous pending connections. NOTE: This makes it harder for a script to perform a denial-of- service attack by just opening a large number of WebSocket connections to a remote host. A server can further reduce the load on itself when attacked by pausing before closing the connection, as that will reduce the rate at which the client reconnects. -- Salvatore Loreto, PhD www.sloreto.com On 2/5/13 3:00 PM, Martin Thomson wrote: > > That is approximately where my reasoning lead. I think that the *safe* > option is to have one connection per name. > > On Feb 4, 2013 3:20 AM, "Adam Rice" > wrote: > > On 1 February 2013 23:27, Martin Thomson > wrote: > > Is this "host and port" or "IP and port" ? That too is > unclear. If > I'm sharding a.example.com and > b.example.com and they are served on > the same VIP, is the expectation that wss://a.example.com/ > and > wss://b.example.com/ can't have > concurrent connection attempts? > > > I was assuming that in the first sentence the text "connection to > the remote host (IP address) ... even if the remote host is known > by another name" made the interpretation of "IP address" unambiguous. > > But section 4.1 says that /host/ is defined in section 3, and > section 3 actually defines /host/ as "host = [RFC3986], Section 3.2.2 > >", ie. the host > portion of the URI. > > So now I don't know. > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------000705090901010303060602 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
the original idea was to serialize the tentative to connect to the same IP address (especially in
the case several /host/ names share the same IP address);
IMO it becomes clear if you read the second paragraph of the bullet #2 and the NOTE.


   2.  If the client already has a WebSocket connection to the remote
       host (IP address) identified by /host/ and port /port/ pair, even
       if the remote host is known by another name, the client MUST wait
       until that connection has been established or for that connection
       to have failed.  There MUST be no more than one connection in a
       CONNECTING state.  If multiple connections to the same IP address
       are attempted simultaneously, the client MUST serialize them so
       that there is no more than one connection at a time running
       through the following steps.
       If the client cannot determine the IP address of the remote host
       (for example, because all communication is being done through a
       proxy server that performs DNS queries itself), then the client
       MUST assume for the purposes of this step that each host name
       refers to a distinct remote host, and instead the client SHOULD
       limit the total number of simultaneous pending connections to a
       reasonably low number (e.g., the client might allow simultaneous
       pending connections to a.example.com and b.example.com, but if
       thirty simultaneous connections to a single host are requested,
       that may not be allowed).  For example, in a web browser context,
       the client needs to consider the number of tabs the user has open
       in setting a limit to the number of simultaneous pending
       connections.


       NOTE: This makes it harder for a script to perform a denial-of-
       service attack by just opening a large number of WebSocket
       connections to a remote host.  A server can further reduce the
       load on itself when attacked by pausing before closing the
       connection, as that will reduce the rate at which the client
       reconnects.


-- 
Salvatore Loreto, PhD
www.sloreto.com


On 2/5/13 3:00 PM, Martin Thomson wrote:

That is approximately where my reasoning lead. I think that the *safe* option is to have one connection per name.

On Feb 4, 2013 3:20 AM, "Adam Rice" <ricea@google.com> wrote:
On 1 February 2013 23:27, Martin Thomson <martin.thomson@gmail.com> wrote:
Is this "host and port" or "IP and port" ?  That too is unclear.  If
I'm sharding a.example.com and b.example.com and they are served on
the same VIP, is the expectation that wss://a.example.com/ and
wss://b.example.com/ can't have concurrent connection attempts?

I was assuming that in the first sentence the text "connection to the remote host (IP address) ... even if the remote host is known by another name" made the interpretation of "IP address" unambiguous.

But section 4.1 says that /host/ is defined in section 3, and section 3  actually defines /host/ as "host = <host, defined in [RFC3986], Section 3.2.2>", ie. the host portion of the URI.

So now I don't know.


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

--------------000705090901010303060602-- From salvatore.loreto@ericsson.com Thu Feb 14 00:19:42 2013 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6068F21F8419 for ; Thu, 14 Feb 2013 00:19:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.248 X-Spam-Level: X-Spam-Status: No, score=-104.248 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YInG7GoLjknE for ; Thu, 14 Feb 2013 00:19:28 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84721F84FB for ; Thu, 14 Feb 2013 00:19:27 -0800 (PST) X-AuditID: c1b4fb2d-b7f316d0000028db-63-511c9e0e594e Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id C7.12.10459.E0E9C115; Thu, 14 Feb 2013 09:19:26 +0100 (CET) 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.279.1; Thu, 14 Feb 2013 09:19:26 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E5B042ADF for ; Thu, 14 Feb 2013 10:19:25 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id BDF6354204 for ; Thu, 14 Feb 2013 10:19:23 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 6A17E53CB1 for ; Thu, 14 Feb 2013 10:19:23 +0200 (EET) Message-ID: <511C9E0D.9050606@ericsson.com> Date: Thu, 14 Feb 2013 10:19:25 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: hybi@ietf.org References: <20130201073846.78956B1E003@rfc-editor.org> <511C962C.8080904@ericsson.com> In-Reply-To: <511C962C.8080904@ericsson.com> Content-Type: multipart/alternative; boundary="------------050404070504070904010708" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+JvjS7fPJlAg75pKhbvX25jcmD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoodBxgLZqZWtB1/ydLA+Myji5GTQ0LARGLijU5GCFtM4sK9 9WwgtpDASUaJq7uZuhi5gOwNjBIN+/+xQTjnGCVur2tnhnAOMkrs3LiSFcI5xSixYdVNZpB+ XgFtiZktt1hAbBYBVYnHSzcxgdhsAmYSzx9uAasRFUiW+HjnGitEvaDEyZlPwOpFgOzurWuA ajg4hAXsJI7PCISYv4xJ4sz3RrA5nAI6Eve+9IPVMwuESew5No0J4gc1iavnNjFD/KAl0Xu2 k2kCo/AsJCtmIWmBsG0lLsy5DhWXl9j+dg4zhK0rceH/FBTxBYxsqxjZcxMzc9LLDTcxAoP/ 4JbfujsYT50TOcQozcGiJM4b5nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjX+szndiI OaGzo6e8n2lbHXnAfUeLQfzMlrZvB6zPJDIGlZ8VP7d8rb3XzY64Uzl/PpY3HvsTf3vvs42f p8/pTnhlI+MpKXfOon6R9/bpv5RqYu7t+Vq7WWddzOxYt2OqP6ZfTJ+zRPPu8r/rEy443j2/ tqvo8urpj17cmPfyz+a6FT7flzvKXVRiKc5INNRiLipOBAB41C5gTAIAAA== Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 08:19:42 -0000 --------------050404070504070904010708 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit to be clear, I am sympathetic with the need to better clarify the text and serialize on both |host| and |port| but with the meaning of IP and |port| -- Salvatore Loreto, PhD www.sloreto.com On 2/14/13 9:45 AM, Salvatore Loreto wrote: > the original idea was to serialize the tentative to connect to the > same IP address (especially in > the case several /host/ names share the same IP address); > IMO it becomes clear if you read the second paragraph of the bullet #2 > and the NOTE. > > > 2. If the client already has a WebSocket connection to the remote > host (IP address) identified by /host/ and port /port/ pair, even > if the remote host is known by another name, the client MUST wait > until that connection has been established or for that connection > to have failed. There MUST be no more than one connection in a > CONNECTING state. If multiple connections to the same IP address > are attempted simultaneously, the client MUST serialize them so > that there is no more than one connection at a time running > through the following steps. > If the client cannot determine the IP address of the remote host > (for example, because all communication is being done through a > proxy server that performs DNS queries itself), then the client > MUST assume for the purposes of this step that each host name > refers to a distinct remote host, and instead the client SHOULD > limit the total number of simultaneous pending connections to a > reasonably low number (e.g., the client might allow simultaneous > pending connections to a.example.com and b.example.com, but if > thirty simultaneous connections to a single host are requested, > that may not be allowed). For example, in a web browser context, > the client needs to consider the number of tabs the user has open > in setting a limit to the number of simultaneous pending > connections. > > > NOTE: This makes it harder for a script to perform a denial-of- > service attack by just opening a large number of WebSocket > connections to a remote host. A server can further reduce the > load on itself when attacked by pausing before closing the > connection, as that will reduce the rate at which the client > reconnects. > > > -- > Salvatore Loreto, PhD > www.sloreto.com > > > On 2/5/13 3:00 PM, Martin Thomson wrote: >> >> That is approximately where my reasoning lead. I think that the >> *safe* option is to have one connection per name. >> >> On Feb 4, 2013 3:20 AM, "Adam Rice" > > wrote: >> >> On 1 February 2013 23:27, Martin Thomson >> > wrote: >> >> Is this "host and port" or "IP and port" ? That too is >> unclear. If >> I'm sharding a.example.com and >> b.example.com and they are served on >> the same VIP, is the expectation that wss://a.example.com/ >> and >> wss://b.example.com/ can't have >> concurrent connection attempts? >> >> >> I was assuming that in the first sentence the text "connection to >> the remote host (IP address) ... even if the remote host is known >> by another name" made the interpretation of "IP address" unambiguous. >> >> But section 4.1 says that /host/ is defined in section 3, and >> section 3 actually defines /host/ as "host = > [RFC3986], Section 3.2.2 >> >", ie. the >> host portion of the URI. >> >> So now I don't know. >> >> >> >> _______________________________________________ >> 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 --------------050404070504070904010708 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit
to be clear, I am sympathetic with the need to better clarify the text and serialize
on both |host| and |port| but with the meaning of IP and |port|

-- 
Salvatore Loreto, PhD
www.sloreto.com


      

      

      On 2/14/13 9:45 AM, Salvatore Loreto wrote:

    

    

      
      
the original idea was to serialize
        the tentative to connect to the same IP address (especially in

        the case several /host/ names share the same IP address);

        IMO it becomes clear if you read the second paragraph of the
        bullet #2 and the NOTE.

        

        

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

        
       If the client cannot determine the IP address of the remote host
       (for example, because all communication is being done through a
       proxy server that performs DNS queries itself), then the client
       MUST assume for the purposes of this step that each host name
       refers to a distinct remote host, and instead the client SHOULD
       limit the total number of simultaneous pending connections to a
       reasonably low number (e.g., the client might allow simultaneous
       pending connections to a.example.com and b.example.com, but if
       thirty simultaneous connections to a single host are requested,
       that may not be allowed).  For example, in a web browser context,
       the client needs to consider the number of tabs the user has open
       in setting a limit to the number of simultaneous pending
       connections.


       NOTE: This makes it harder for a script to perform a denial-of-
       service attack by just opening a large number of WebSocket
       connections to a remote host.  A server can further reduce the
       load on itself when attacked by pausing before closing the
       connection, as that will reduce the rate at which the client
       reconnects.

        

        

        
-- 
Salvatore Loreto, PhD
www.sloreto.com

        

        

        On 2/5/13 3:00 PM, Martin Thomson wrote:

      

      

        
That is approximately where my reasoning lead. I think that
          the *safe* option is to have one connection per name.

        
On Feb 4, 2013 3:20 AM, "Adam Rice"
          <ricea@google.com>

          wrote:

          

            
On 1 February 2013 23:27, Martin Thomson <martin.thomson@gmail.com>
              wrote:

              

                

                  
Is

                    this "host and port" or "IP and port" ?  That too is
                    unclear.  If

                    I'm sharding a.example.com
                    and b.example.com
                    and they are served on

                    the same VIP, is the expectation that wss://a.example.com/
                    and

                    wss://b.example.com/
                    can't have concurrent connection attempts?

                  


                  

                  
I was assuming that in the first sentence the
                    text "connection

                      to the remote host

                      (IP address) ... even if the remote host is known
                      by another name" made the interpretation of "IP
                      address" unambiguous.

                  


                    

                  
But

                      section 4.1 says that /host/ is defined in section
                      3, and section 3  actually defines /host/ as "host = <host, defined in
                    [RFC3986],
                      Section 3.2.2>",

                      ie. the host portion of the URI.

                  


                    

                  
So now I don't know.

                

              

            

          

        

        

        

        

        
_______________________________________________
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


    

    

    

  


--------------050404070504070904010708--

From barryleiba.mailing.lists@gmail.com  Thu Feb 14 07:57:01 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF0C21F8806 for ; Thu, 14 Feb 2013 07:57:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.927
X-Spam-Level: 
X-Spam-Status: No, score=-102.927 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3xIwkUK-NIT for ; Thu, 14 Feb 2013 07:57:00 -0800 (PST)
Received: from mail-ve0-f169.google.com (mail-ve0-f169.google.com [209.85.128.169]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFF321F8561 for ; Thu, 14 Feb 2013 07:56:59 -0800 (PST)
Received: by mail-ve0-f169.google.com with SMTP id 15so2268314vea.0 for ; Thu, 14 Feb 2013 07:56:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=pAZNXSh0e4lPbNm7TiiydgU4zTFcTVV9qLOQ5RMAySI=; b=dvi30hfBIhTUmkoa/1vDLegWEbNHVQKA/BMaSFNrZYqSuOy/x/AKMrUalxd4UkBVc1 OYe5ro6YfpIIKqXrbH8XsBp5HLmXdhcEdlEnLCJFva5YSAXBlRS2K881MJW/nJ+ASV43 cE5F3+PaONwoTKm0EHfYpUBBO8P/vSc0oMdLY8hM6Ooff2VADHGmVOEmoYg0B5p+tyRF xEPNF7TJJ1aU88hDyf7DxIFaJ2EQshjMj+sEWTZvNsgQBInWTLzESEXI8NDFx1GwM3qP SEr0NqakEjLICnP1QqH1CIVtelosYL/sVf0/qh4xlFIlh+LeaJXTud8TosnzJalk/zoN Xcbw==
MIME-Version: 1.0
X-Received: by 10.58.188.48 with SMTP id fx16mr35260885vec.22.1360857419248; Thu, 14 Feb 2013 07:56:59 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Thu, 14 Feb 2013 07:56:59 -0800 (PST)
In-Reply-To: 
References: <20130201073846.78956B1E003@rfc-editor.org>   
Date: Thu, 14 Feb 2013 10:56:59 -0500
X-Google-Sender-Auth: 8bJ9iq9gsIDifWZ0H5QKfz3QMLM
Message-ID: 
From: Barry Leiba 
To: Martin Thomson ,  Salvatore Loreto , Adam Rice 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Pete Resnick , "hybi@ietf.org" , "ifette+ietf@google.com" 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 15:57:01 -0000

On 1 February 2013 23:27, Martin Thomson  wrote:
>
> Is this "host and port" or "IP and port" ?  That too is unclear.  If
> I'm sharding a.example.com and b.example.com and they are served on
> the same VIP, is the expectation that wss://a.example.com/ and
> wss://b.example.com/ can't have concurrent connection attempts?

On Feb 4, 2013 3:20 AM, "Adam Rice"  wrote:
> I was assuming that in the first sentence the text "connection to the
> remote host (IP address) ... even if the remote host is known by another
> name" made the interpretation of "IP address" unambiguous.
>
> But section 4.1 says that /host/ is defined in section 3, and section 3
> actually defines /host/ as "host =  3.2.2>", ie. the host portion of the URI.
>
> So now I don't know.

On Tue, Feb 5, 2013 at 8:00 AM, Martin Thomson  wrote:
> That is approximately where my reasoning lead. I think that the *safe*
> option is to have one connection per name.
>

On Thu, Feb 14, 2013 at 2:45 AM, Salvatore Loreto
 wrote:
> the original idea was to serialize the tentative to connect to the same IP
> address (especially in the case several /host/ names share the same IP
> address); IMO it becomes clear if you read the second paragraph of the
> bullet #2 and the NOTE.

OK... so how do you folks propose that your ADs resolve this errata report?

The options are as follows:

1. It's just wrong, and we should mark it "Rejected".  (This doesn't
seem like where you're going.)

2. It's absolutely correct as it is, and we should mark it "Verified".
 (It doesn't seem like it's this either.)

3. It's essentially correct, but needs some editing.  You can provide
the edits and we can edit it and then mark it "Verified".

4. It's true that there's a problem, but the resolution is beyond the
scope of an erratum.  We can either leave it as it is or edit it (to
tweak the proposed resolution and/or to explain the difficulty in
resolving it), and then mark it "Held for Document Update".

Barry, Applications AD

From barryleiba.mailing.lists@gmail.com  Thu Feb 14 08:46:53 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2528721F844F for ; Thu, 14 Feb 2013 08:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.929
X-Spam-Level: 
X-Spam-Status: No, score=-102.929 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxlUoNu8ypSq for ; Thu, 14 Feb 2013 08:46:52 -0800 (PST)
Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by ietfa.amsl.com (Postfix) with ESMTP id 24A5121F85EA for ; Thu, 14 Feb 2013 08:46:52 -0800 (PST)
Received: by mail-ve0-f173.google.com with SMTP id oz10so2304659veb.32 for ; Thu, 14 Feb 2013 08:46:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JHDXcitYP7lJYViwDUlurOUqIbO9Iedm5hyQcf1N8tI=; b=B5yTTam0iulnuZuxSqvtYQdA1uU0COcG87E1nJNnpnaJ0C0I0meQJ6YE1bueukgPJE OSqcgfuLIlwJLfYOfVFy+juPWuaxLVtHZsUcQx8BZL24WViI1bmndMakJ+svosGslrrs eZtIvr8X6UzJwCYK15WCSFEic0TDwtBIurOGH9PpXs2FOvGXduCFa7+Ek14T5D7QXCGX LsLQkCqhuXZdTZLQzY28wns1+7/K7aK8xKs51BNrlyNsL7aur12HLwqTKz5v6Tujl1vW n8v9FCa7wlYgYIj38ALqutAQfCi/GVGYErqQ5Q8h4xxhh5i10GhIYsB+j2iCCqxMh32f fNsg==
MIME-Version: 1.0
X-Received: by 10.52.98.104 with SMTP id eh8mr3214443vdb.20.1360860411536; Thu, 14 Feb 2013 08:46:51 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Thu, 14 Feb 2013 08:46:51 -0800 (PST)
In-Reply-To: 
References: <20130201073846.78956B1E003@rfc-editor.org>    
Date: Thu, 14 Feb 2013 11:46:51 -0500
X-Google-Sender-Auth: Ta95b24d-JDZyd7Vpvpkvv8ds7U
Message-ID: 
From: Barry Leiba 
To: Martin Thomson ,  Salvatore Loreto , Adam Rice 
Content-Type: text/plain; charset=ISO-8859-1
Cc: Pete Resnick , "hybi@ietf.org" , "ifette+ietf@google.com" 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 14 Feb 2013 16:46:53 -0000

Comment relayed (with permission) from someone who isn't subscribed to the list:

---------- Forwarded message ----------
From: Joakim Erdfelt 
Date: Thu, Feb 14, 2013 at 11:31 AM
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
To: Barry Leiba 

Sorry, i don't have access to the ietf mailing list.

Speaking as a developer of the websocket implementation on the Java /
Eclipse Jetty side ...

This section is really just for Web Browsers to implement, not a
general purpose requirement for the protocol for all use cases and
implementations.

Some scenarios ...

Web Socket Proxies.

many websocket users -> websocket proxy -> destination server

In this scenario, if the questioned part of the RFC is enforced, then
a websocket proxy cannot exist. as the websocket proxy itself would be
in violation.

Also, the requirements of the pending websocket mux extension makes
the language of this section in RFC6455 interesting.
Is this requirement placed on the desire to connect to the destination
websocket server (you can call this the logical connection), or the
physical connection?

Mux also makes the above proxy scenario fun to noodle out.

--
Joakim Erdfelt 
webtide.com
Developer advice, services and support
from the Jetty & CometD experts
eclipse.org/jetty - cometd.org

From ricea@google.com  Fri Feb 15 02:35:29 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353FA21F8A22 for ; Fri, 15 Feb 2013 02:35:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.976
X-Spam-Level: 
X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e302I9V+Q2In for ; Fri, 15 Feb 2013 02:35:28 -0800 (PST)
Received: from mail-bk0-f47.google.com (mail-bk0-f47.google.com [209.85.214.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5276B21F862E for ; Fri, 15 Feb 2013 02:35:27 -0800 (PST)
Received: by mail-bk0-f47.google.com with SMTP id jc3so1445725bkc.6 for ; Fri, 15 Feb 2013 02:35:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FUuvjO914Loj/ueJkQ2trBpJFzkmHtg7OgwqnajrMxU=; b=j3mXFXEILG60tTa6lmTKAucLXfT8T6H7ZfKySXKF5Y0g/+gU2t6XJjHdKwCMsxyfu6 o3JivQufB3VT1JSE76GTCVqXJUL0VCLVZ+o2plGOvpxEByR/TfA5Z0DSvIdomTejULZR 38C/3xIgAcWb2CbCPv9r/vhDP0jcLEvvNmbqA6zJ678DLw9d8pXn5lEEfQvU341cwyWc 1ckC0MTx1venRNTOI0HVmkVpk5CJcGS+a3rTfZQa/lTMzJyrO0cmkEtYwT/I7RiyboZB NeeclAD+BHRSvZouR6vLg0gNMxK2Zy9hztKN14o1zcQGoQCpdU9kfjBHyWyDDadmUsBT dL9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=FUuvjO914Loj/ueJkQ2trBpJFzkmHtg7OgwqnajrMxU=; b=VLNebVhsL/HwHVxC03ZsiM9u00hanm3K/uA5Pya53E22esseIA3AdAWrLR9okxfbAY y574NUko5gtUgNx8tUZodcDWw+qLZ/YGAHOQ0s/ySFbcQmkPgSLcJT/ncukD/OAjlNRs Qs1Db5h3zBvzGYt5Jy11rv0Q37OeHJ8qNIoLXGzgVZrJ/B9NzqmudHsifVjHj54/OpOx 2oLwB/Vp+NjFeUcm7USFn5NDHlDhgCDxcKxKhZMFZx/26nNrSVVg1nq8+THhbqAyvRoT NzWT8JXcz/44BsAk73Ud/sTTwR2JItQL/CKcPgXirm46Q3JXKGdGiZn4HI8PliIjG6ze WIDA==
MIME-Version: 1.0
X-Received: by 10.204.147.86 with SMTP id k22mr608751bkv.82.1360924526177; Fri, 15 Feb 2013 02:35:26 -0800 (PST)
Received: by 10.205.17.199 with HTTP; Fri, 15 Feb 2013 02:35:26 -0800 (PST)
In-Reply-To: 
References: <20130201073846.78956B1E003@rfc-editor.org>    
Date: Fri, 15 Feb 2013 19:35:26 +0900
Message-ID: 
From: Adam Rice 
To: Barry Leiba 
Content-Type: multipart/alternative; boundary=0015174c1686f2efe604d5c0ee99
X-Gm-Message-State: ALoCoQl0b9OQTZQwFN1cPXQhEpysyMk1zRqa8JjfAuPsXOmimxHy5hMcgETc+fecRcCC2foE4C0PIEPu3nA3J1tpCFYV0/kiNTuuuo9dOn4bVTJJUfbILyLAHqizAr8PPbIlGHYoN4PIfIDkZf7U5TZss44/yBM5335gSnJhE2w9xjeJSshiQGftaJNIop06VgnisqFw21sX
X-Mailman-Approved-At: Fri, 15 Feb 2013 02:39:17 -0800
Cc: "ifette+ietf@google.com" , Pete Resnick , "hybi@ietf.org" 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 10:35:29 -0000

--0015174c1686f2efe604d5c0ee99
Content-Type: text/plain; charset=ISO-8859-1

On 15 February 2013 00:56, Barry Leiba  wrote:

>
> OK... so how do you folks propose that your ADs resolve this errata report?
>
> The options are as follows:
>
> 1. It's just wrong, and we should mark it "Rejected".  (This doesn't
> seem like where you're going.)
>
> 2. It's absolutely correct as it is, and we should mark it "Verified".
>  (It doesn't seem like it's this either.)
>
> 3. It's essentially correct, but needs some editing.  You can provide
> the edits and we can edit it and then mark it "Verified".
>
> 4. It's true that there's a problem, but the resolution is beyond the
> scope of an erratum.  We can either leave it as it is or edit it (to
> tweak the proposed resolution and/or to explain the difficulty in
> resolving it), and then mark it "Held for Document Update".


I would like to take option 3. I would like to propose the following text
to clarify the intent of RFC6455 while preserving the meaning:

   2.  If the client already has a WebSocket connection to the same IP
       address and port pair, even if the remote host is known by another
       name, the client MUST wait until that connection has been established
       or for that connection to have failed.  There MUST be no more than
       one connection in a CONNECTING state.  If multiple connections to the
       same IP address and port pair are attempted simultaneously, the
       client MUST serialize them so that there is no more than one
       connection at a time running through the following steps.

The following paragraph already indicates what must be done in the case
where the IP address cannot be determined, so this change should not create
any difficulties in the case where the connection is tunnelled via an
HTTP(S) or SOCKS5 proxy.

I think the issue that this section creates problems for WebSocket proxies
and non-browser clients cannot be handled without changing the meaning of
the text, and so I would like to deal with that separately.

Thank you,
Adam Rice

--0015174c1686f2efe604d5c0ee99
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable


On 15 February 2013 00:56, Barry Leiba=A0<barryleiba@computer.org>=A0wrote:



OK... so how do you folks propose that your ADs=
 resolve this errata report?

The options are as follows:

1. I=
t's just wrong, and we should mark it "Rejected". =A0(This do=
esn't

seem like where you're going.)

2. It's absolutely correct as=
 it is, and we should mark it "Verified".
=A0(It doesn't s=
eem like it's this either.)

3. It's essentially correct, but=
 needs some editing. =A0You can provide

the edits and we can edit it and then mark it "Verified".

=
4. It's true that there's a problem, but the resolution is beyond t=
he
scope of an erratum. =A0We can either leave it as it is or edit it (t=
o

tweak the proposed resolution and/or to explain the difficulty in
resolv=
ing it), and then mark it "Held for Document Update".
=A0
I would like to take option 3.=A0I would like to propose th=
e following text to clarify the intent of RFC6455 while preserving the mean=
ing:


=
=A0 =A02. =A0If the client already ha=
s a WebSocket connection to the same IP


=A0 =A0 =A0 =A0address and port =
pair, even if the remote host is known by another
=A0 =A0 =A0 =A0name, the client MUST wait unt=
il that connection has been established


=A0 =A0 =A0 =A0or for that conne=
ction to have failed. =A0There MUST be no more than
=A0 =A0 =A0 =A0one connection in a CONNECTI=
NG state. =A0If multiple connections to the


=A0 =A0 =A0 =A0same IP address a=
nd port pair are attempted simultaneously, the
=A0 =A0 =A0 =A0client MUST serialize them so th=
at there is no more than one


=A0 =A0 =A0 =A0connection at a t=
ime running through the following steps.

The following paragraph already indicates what must be done in the ca=
se where the IP address cannot be determined, so this change should not cre=
ate any difficulties in the case where the connection is=A0tunnelled=A0via =
an HTTP(S) or SOCKS5 proxy.



I think the issue that this section creates problems fo=
r WebSocket proxies and non-browser clients cannot be handled without chang=
ing the meaning of the text, and so I would like to deal with that separate=
ly.



Thank you,
Adam Rice





--0015174c1686f2efe604d5c0ee99--

From salvatore.loreto@ericsson.com  Fri Feb 15 02:56:15 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C60A21F8658 for ; Fri, 15 Feb 2013 02:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.137
X-Spam-Level: 
X-Spam-Status: No, score=-106.137 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 oYH0i+u7TTLZ for ; Fri, 15 Feb 2013 02:56:13 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 38E4721F8692 for ; Fri, 15 Feb 2013 02:56:13 -0800 (PST)
X-AuditID: c1b4fb2d-b7f316d0000028db-ef-511e13eaf522
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 62.F7.10459.AE31E115; Fri, 15 Feb 2013 11:54:34 +0100 (CET)
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.279.1; Fri, 15 Feb 2013 11:54:34 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id E4CDD2ADD; Fri, 15 Feb 2013 12:54:33 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 7F4675438C; Fri, 15 Feb 2013 12:54:31 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0289B51445; Fri, 15 Feb 2013 12:54:30 +0200 (EET)
Message-ID: <511E13E8.7030604@ericsson.com>
Date: Fri, 15 Feb 2013 12:54:32 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Adam Rice 
References: <20130201073846.78956B1E003@rfc-editor.org>     
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------070109080708050707010303"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM+Jvje4rYblAgweH1S0OLb7EavH+5TYm i2ML3zFZXDvzj9HiytUWZouz3z0c2DxaVvUye+ycdZfdY8GmUo8lS34yeSya+owxgDWKyyYl NSezLLVI3y6BK+PR0oyC2Y4V/5vXMDYwNul3MXJySAiYSFzftZUNwhaTuHBvPZDNxSEkcJJR 4n/fPShnA6PErtetLBDOLkaJbTensUM4axkl+g89YYZwtjFKHDo3iQVkGK+AtkTPzi1gg1kE VCXe3roMZrMJmEk8f7iFGcQWFUiW+HjnGitEvaDEyZlPwHpFBBQkDh0+xQRiMwvcYZS4f8+v i5GDQ1jATuL4jECIXROYJZ5s2APWyykQKHFz1Tl2iPowiQcT3rJAPKQmcfXcJrBdQgJaEr1n O5kmMIrMQrJuFpIWCNtW4sKc61C2vMT2t3OYIWxdiQv/p6CIL2BkW8XInpuYmZNebriJERhr B7f81t3BeOqcyCFGaQ4WJXHeMNcLAUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYveemHJ5e mXn198Mllzas53f+fjfuUAVv4k+uVgOPkOq17re+L1XRC1x1Ivq4sv1zuTVvFdSdzywS21ay dFG/3Dm/DyuzMuYq90zgX/TopsVxpwvis+s3x5odKAu9zvx3hYZ29uZCn4dM689MdL/z7Z56 6tZwu9Cic8xrtrxjOCZysDS/+FPaFyWW4oxEQy3mouJEAMsFqCiDAgAA
Cc: "ifette+ietf@google.com" , "hybi@ietf.org" , Pete Resnick , Barry Leiba 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 10:56:15 -0000

--------------070109080708050707010303
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

I agree with Adam on option 3
and also on the fact that we should not (and we are not allowed to)
change the meaning of the current text

Salvatore

-- 
Salvatore Loreto, PhD
www.sloreto.com


On 2/15/13 12:35 PM, Adam Rice wrote:
> On 15 February 2013 00:56, Barry Leiba  > wrote:
>
>
>     OK... so how do you folks propose that your ADs resolve this
>     errata report?
>
>     The options are as follows:
>
>     1. It's just wrong, and we should mark it "Rejected".  (This doesn't
>     seem like where you're going.)
>
>     2. It's absolutely correct as it is, and we should mark it "Verified".
>      (It doesn't seem like it's this either.)
>
>     3. It's essentially correct, but needs some editing.  You can provide
>     the edits and we can edit it and then mark it "Verified".
>
>     4. It's true that there's a problem, but the resolution is beyond the
>     scope of an erratum.  We can either leave it as it is or edit it (to
>     tweak the proposed resolution and/or to explain the difficulty in
>     resolving it), and then mark it "Held for Document Update".
>
> I would like to take option 3. I would like to propose the following 
> text to clarify the intent of RFC6455 while preserving the meaning:
>
>    2.  If the client already has a WebSocket connection to the same IP
>        address and port pair, even if the remote host is known by another
>        name, the client MUST wait until that connection has been 
> established
>        or for that connection to have failed.  There MUST be no more than
>        one connection in a CONNECTING state.  If multiple connections 
> to the
>        same IP address and port pair are attempted simultaneously, the
>        client MUST serialize them so that there is no more than one
>        connection at a time running through the following steps.
>
> The following paragraph already indicates what must be done in the 
> case where the IP address cannot be determined, so this change should 
> not create any difficulties in the case where the connection 
> is tunnelled via an HTTP(S) or SOCKS5 proxy.
>
> I think the issue that this section creates problems for WebSocket 
> proxies and non-browser clients cannot be handled without changing the 
> meaning of the text, and so I would like to deal with that separately.
>
> Thank you,
> Adam Rice
>
>



--------------070109080708050707010303
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    
I agree with Adam on option 3 

      and also on the fact that we should not (and we are not allowed
      to)

      change the meaning of the current text

      

      Salvatore

      
-- 
Salvatore Loreto, PhD
www.sloreto.com

      

      On 2/15/13 12:35 PM, Adam Rice wrote:

    

    

      
      
On 15 February 2013 00:56, Barry Leiba <barryleiba@computer.org> wrote:

        

          


          

          OK... so how do you folks propose that your ADs resolve this
          errata report?

          

          The options are as follows:

          

          1. It's just wrong, and we should mark it "Rejected".  (This
          doesn't

          seem like where you're going.)

          

          2. It's absolutely correct as it is, and we should mark it
          "Verified".

           (It doesn't seem like it's this either.)

          

          3. It's essentially correct, but needs some editing.  You can
          provide

          the edits and we can edit it and then mark it "Verified".

          

          4. It's true that there's a problem, but the resolution is
          beyond the

          scope of an erratum.  We can either leave it as it is or edit
          it (to

          tweak the proposed resolution and/or to explain the difficulty
          in

          resolving it), and then mark it "Held for Document Update".

        
 

        I would like to take option 3. I
          would like to propose the following text to clarify the intent
          of RFC6455 while preserving the meaning:
        

          

          

        

            
   2.  If the
                client already has a WebSocket connection to the same IP

            
       address and
                port pair, even if the remote host is known by another

            
       name, the
                client MUST wait until that connection has been
                established

            
       or for that
                connection to have failed.  There MUST be no more than

            
       one
                connection in a CONNECTING state.  If multiple
                connections to the

            
       same IP
                address and port pair are attempted simultaneously, the

            
       client MUST
                serialize them so that there is no more than one

            
       connection
                at a time running through the following steps.

            


            

            

              
The following paragraph already indicates what must
                be done in the case where the IP address cannot be
                determined, so this change should not create any
                difficulties in the case where the connection
                is tunnelled via an HTTP(S) or SOCKS5 proxy.

              


              

              
I think the issue that this section creates problems
                for WebSocket proxies and non-browser clients cannot be
                handled without changing the meaning of the text, and so
                I would like to deal with that separately.

            

            


            

            
Thank you,

            
Adam Rice

          

        


          

        

      

    

    

    

  


--------------070109080708050707010303--

From ifette@google.com  Fri Feb 15 02:56:37 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CF821F89DC for ; Fri, 15 Feb 2013 02:56:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.676
X-Spam-Level: 
X-Spam-Status: No, score=-102.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_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e6yS9Nw6wAJt for ; Fri, 15 Feb 2013 02:56:36 -0800 (PST)
Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5C1B021F8A3E for ; Fri, 15 Feb 2013 02:56:36 -0800 (PST)
Received: by mail-oa0-f54.google.com with SMTP id n12so3532760oag.41 for ; Fri, 15 Feb 2013 02:56:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=LF1mjNkrvsY3Yd5J5s3tnQ+apIikENzUznff3A3hwVY=; b=dKzvviVQwJCP5ywrwjipJaOZ0sfO481oOjWbSM2pYe+anJQiM9U7fjprl0NTwbUCyK agl6TGXQc9pgB9K2HeluRGqWX0sK0FijurEiNymydwDP95kY6JubGZ6nYck2bLV2lchQ RiD7GA7hN02L6eoGMagX47fpiVln7Lk0M8hpTP4+AKX2Zn4LTCAwKFM36SqDAbE/NtO7 yA1AY6MwujKn+IVi1ssFGCPe0ULbBjbTNUgYpS0D0clAQMc8CjxIcDlvwM08LoIpPZvL uEZ6CHSyQ555ZE5+Frs2OEhf/CYenTpWMufw0JdO5ZQNP3kG0XgOSN8otlmhsxpAYO1o NdaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=LF1mjNkrvsY3Yd5J5s3tnQ+apIikENzUznff3A3hwVY=; b=ZieuHPG7uMwEg+l2xRr/aIn1YUeZgKdSQBO1VhqOGMkM8uQsNAGvneN01ME2dTqH+e LvX3MeAD0b34K9hArggqcZ+7ULY5xAKfcJW6V0JBRCpyN5tHxN/yXRfr83H1NHS3I+8D Lv/B1SHP7gfRueUlNKu3QwUtDqgcNj3GY/+PQ/FAoVJ5Pdi+vySWcNjUHwSvZRlI5/2L GQtwx+HMMvhmnnd+DTJ/4U9Cej24yxquqbISc1hkXrqwRf/2e8W6paw9I6VG/o2dArSx VxYCOxYkxxT8pmcHHHvWSaaIvXU/XZV2htCR/LnRHiIgJd9YAl3TcfLm1rpHF4IpuFA3 OU0A==
MIME-Version: 1.0
X-Received: by 10.60.7.199 with SMTP id l7mr1319557oea.136.1360925787333; Fri, 15 Feb 2013 02:56:27 -0800 (PST)
Received: by 10.182.79.231 with HTTP; Fri, 15 Feb 2013 02:56:27 -0800 (PST)
In-Reply-To: <511E13E8.7030604@ericsson.com>
References: <20130201073846.78956B1E003@rfc-editor.org>      <511E13E8.7030604@ericsson.com>
Date: Fri, 15 Feb 2013 02:56:27 -0800
Message-ID: 
From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= 
To: Salvatore Loreto 
Content-Type: multipart/alternative; boundary=e89a8fb1ed4c1ea58104d5c13a30
X-Gm-Message-State: ALoCoQk795RT3L9kRYvH99CV29VcouWvu9hIzXuhE1XhBf5mUBEAGa3WaDNvLHy13cayQYKkOsYqjpFadKg5U9gFcUrWOrABxRkWwIf0+RCGS1ax417W3ZMl3gvtpFVQ6xB1Ikkj1cduxtUVz8O0noPYqZ3FviNAiDoS0y6vnoFXkBr36kMvgEK0hFsrmoyE0NVdpmaL6a7E
Cc: "hybi@ietf.org" , Adam Rice , Pete Resnick , "ifette+ietf@google.com" , Barry Leiba 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
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, 15 Feb 2013 10:56:37 -0000

--e89a8fb1ed4c1ea58104d5c13a30
Content-Type: text/plain; charset=UTF-8

Agree. The original intent of the text was to serialize connections to an
 pair. Apologies for the unclear text.

On Fri, Feb 15, 2013 at 2:54 AM, Salvatore Loreto <
salvatore.loreto@ericsson.com> wrote:

>  I agree with Adam on option 3
> and also on the fact that we should not (and we are not allowed to)
> change the meaning of the current text
>
> Salvatore
>
> --
> Salvatore Loreto, PhDwww.sloreto.com
>
>
> On 2/15/13 12:35 PM, Adam Rice wrote:
>
> On 15 February 2013 00:56, Barry Leiba  wrote:
>
>>
>>  OK... so how do you folks propose that your ADs resolve this errata
>> report?
>>
>> The options are as follows:
>>
>> 1. It's just wrong, and we should mark it "Rejected".  (This doesn't
>> seem like where you're going.)
>>
>> 2. It's absolutely correct as it is, and we should mark it "Verified".
>>  (It doesn't seem like it's this either.)
>>
>> 3. It's essentially correct, but needs some editing.  You can provide
>> the edits and we can edit it and then mark it "Verified".
>>
>> 4. It's true that there's a problem, but the resolution is beyond the
>> scope of an erratum.  We can either leave it as it is or edit it (to
>> tweak the proposed resolution and/or to explain the difficulty in
>> resolving it), and then mark it "Held for Document Update".
>
>
> I would like to take option 3. I would like to propose the following text
> to clarify the intent of RFC6455 while preserving the meaning:
>
>     2.  If the client already has a WebSocket connection to the same IP
>        address and port pair, even if the remote host is known by another
>        name, the client MUST wait until that connection has been
> established
>        or for that connection to have failed.  There MUST be no more than
>        one connection in a CONNECTING state.  If multiple connections to
> the
>        same IP address and port pair are attempted simultaneously, the
>        client MUST serialize them so that there is no more than one
>        connection at a time running through the following steps.
>
>  The following paragraph already indicates what must be done in the case
> where the IP address cannot be determined, so this change should not create
> any difficulties in the case where the connection is tunnelled via an
> HTTP(S) or SOCKS5 proxy.
>
>  I think the issue that this section creates problems for WebSocket
> proxies and non-browser clients cannot be handled without changing the
> meaning of the text, and so I would like to deal with that separately.
>
>  Thank you,
> Adam Rice
>
>
>
>
>

--e89a8fb1ed4c1ea58104d5c13a30
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Agree. The original intent of the text was to serialize connections to an &=
lt;IP Address, Port> pair. Apologies for the unclear text.

On Fri, Feb 15, 2013 at 2:54 AM, Salvatore Loreto <salvatore.loreto@ericsson.com> wrote:



 =20
   =20
 =20
  

    
I agree with Adam on option 3 

      and also on the fact that we should not (and we are not allowed
      to)

      change the meaning of the current text

      

      Salvatore


      
--=20
Salvatore Loreto, PhD
www.sloreto.com
      

      On 2/15/13 12:35 PM, Adam Rice wrote:

    

    

     =20
      
On 15 February 2013 00:56, Barry Leiba=C2=A0<=
barryleiba@computer.org>=C2=A0wrote:

        

          


          

          OK... so how do you folks propose that your ADs resolve this
          errata report?

          

          The options are as follows:

          

          1. It's just wrong, and we should mark it "Rejected"=
;. =C2=A0(This
          doesn't

          seem like where you're going.)

          

          2. It's absolutely correct as it is, and we should mark it
          "Verified".

          =C2=A0(It doesn't seem like it's this either.)

          

          3. It's essentially correct, but needs some editing. =C2=A0Yo=
u can
          provide

          the edits and we can edit it and then mark it "Verified"=
;.

          

          4. It's true that there's a problem, but the resolution i=
s
          beyond the

          scope of an erratum. =C2=A0We can either leave it as it is or edi=
t
          it (to

          tweak the proposed resolution and/or to explain the difficulty
          in

          resolving it), and then mark it "Held for Document Update&qu=
ot;.

        
=C2=A0

        I would like to take option 3.=C2=A0I
          would like to propose the following text to clarify the intent
          of RFC6455 while preserving the meaning:
        

          

          

        

            
=C2=A0 =C2=A02. =C2=
=A0If the
                client already has a WebSocket connection to the same IP

            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0address and
                port pair, even if the remote host is known by another

            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0name, the
                client MUST wait until that connection has been
                established

            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0or for that
                connection to have failed. =C2=A0There MUST be no more than=


            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0one
                connection in a CONNECTING state. =C2=A0If multiple
                connections to the

            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0same IP
                address and port pair are attempted simultaneously, the

            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0client MUST
                serialize them so that there is no more than one
            
=C2=A0 =C2=A0 =C2=A0=
 =C2=A0connection
                at a time running through the following steps.

            


            

            

              
The following paragraph already indicates what must
                be done in the case where the IP address cannot be
                determined, so this change should not create any
                difficulties in the case where the connection
                is=C2=A0tunnelled=C2=A0via an HTTP(S) or SOCKS5 proxy.
              


              

              
I think the issue that this section creates problems
                for WebSocket proxies and non-browser clients cannot be
                handled without changing the meaning of the text, and so
                I would like to deal with that separately.

            

            


            

            
Thank you,

            
Adam Rice

          

        


          

        

      

    

    

    

  






--e89a8fb1ed4c1ea58104d5c13a30--

From barryleiba@gmail.com  Fri Feb 15 06:32:59 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C7C21F8733 for ; Fri, 15 Feb 2013 06:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.034
X-Spam-Level: 
X-Spam-Status: No, score=-102.034 tagged_above=-999 required=5 tests=[AWL=-0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRoXnjqHPaVP for ; Fri, 15 Feb 2013 06:32:59 -0800 (PST)
Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 80C4321F8716 for ; Fri, 15 Feb 2013 06:32:58 -0800 (PST)
Received: by mail-la0-f43.google.com with SMTP id ek20so3510737lab.30 for ; Fri, 15 Feb 2013 06:32:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=CthEwSMNu3zs7//Y+Ma77FPvyW28EIVlCX+WAK1+bb4=; b=oW9fX4ArqbH7dFQ26r+8ts7U6S2t+pzRN/wsj5cH24VxrFF9URcWlt5qpvpuJH+MoD 8Hl1DihvTy4UVl/W8rCwjlLF0UKoaUkrNguGdtRXNDOREvPNQNWb9/CJ/Npw+3prDTfX digU6JEs22jFwhJE76Zh/Ed3xWA+7ajISwDZYfvK5enKXyawNcA73B8nVj0lTAkZ5DoY +3wHTM00AbaMpO7gzPw4I7rHDeuwh8f9i4XCRhijOiuf3IkbymrG8OIvFJqeifwqn/4g FfEMCcwFSpDSnZNnnm1mIZl2Eq0pjeA6K7+FYp8TPdz0MS+zSjpBvIKzCiUWViRmLTdD Y5rg==
MIME-Version: 1.0
X-Received: by 10.112.13.136 with SMTP id h8mr2196303lbc.4.1360938777135; Fri, 15 Feb 2013 06:32:57 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.112.47.168 with HTTP; Fri, 15 Feb 2013 06:32:57 -0800 (PST)
In-Reply-To: 
References: <20130201073846.78956B1E003@rfc-editor.org>     
Date: Fri, 15 Feb 2013 09:32:57 -0500
X-Google-Sender-Auth: iB8xqeFWYnRJJ7rVKuU8n5G4V60
Message-ID: 
From: Barry Leiba 
To: Adam Rice 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "ifette+ietf@google.com" , Pete Resnick , "hybi@ietf.org" 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 14:32:59 -0000

>> 3. It's essentially correct, but needs some editing.  You can provide
>> the edits and we can edit it and then mark it "Verified".
>
> I would like to take option 3. I would like to propose the following text to
> clarify the intent of RFC6455 while preserving the meaning:
>
>    2.  If the client already has a WebSocket connection to the same IP
>        address and port pair, even if the remote host is known by another
>        name, the client MUST wait until that connection has been established
>        or for that connection to have failed.  There MUST be no more than
>        one connection in a CONNECTING state.  If multiple connections to the
>        same IP address and port pair are attempted simultaneously, the
>        client MUST serialize them so that there is no more than one
>        connection at a time running through the following steps.
>
> The following paragraph already indicates what must be done in the case
> where the IP address cannot be determined, so this change should not create
> any difficulties in the case where the connection is tunnelled via an
> HTTP(S) or SOCKS5 proxy.
>
> I think the issue that this section creates problems for WebSocket proxies
> and non-browser clients cannot be handled without changing the meaning of
> the text, and so I would like to deal with that separately.

Great; Salvatore and Ian agree with this.  I'm happy to hear more
agreement or objections; if I don't hear objections in the next couple
of days, I'll go with this.

Barry

From simone.bordet@gmail.com  Fri Feb 15 09:56:18 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46C321F8808 for ; Fri, 15 Feb 2013 09:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-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 bc69bciJSPZ3 for ; Fri, 15 Feb 2013 09:56:18 -0800 (PST)
Received: from mail-wi0-x22a.google.com (wi-in-x022a.1e100.net [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id A0B2521F8722 for ; Fri, 15 Feb 2013 09:56:16 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hm11so1673880wib.3 for ; Fri, 15 Feb 2013 09:56:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VYiuFGjbwjbu8Sw1DSHcb8bW4KkY3rjl2HLHyRo5gVg=; b=pHf6dmZXlpWibCHw26S7UKVhTo9QpE83rgBKHOEkVdxuFXOFKJmM8YH/zM2Uovgnsp qLb9q8khBh8Low/tbiG1zMDL9xYk0zsN3VOiqg3XA9BpWaPA6f4y1d0jsQSBUYMsOVjD S5Xhf9RPte57mdGKqMXs7xOCamMVVy8EMElifRw1qnLZ4uZuspwJ0yQXPUJ+7X1A+0Sa 3ajM4qGzsjm14ec/ajaRlSLFvWuI65uqkSw9kXYJ7Nyw058Ff8IChzDbu+SYw3KmOR2u HdiKCEHy79B00Qw1gbDV0VCtH8XIzZlOFN5T+qFq9nH8gCTDzBZ4Nqn05FWYLmHhWbht ynnA==
MIME-Version: 1.0
X-Received: by 10.180.76.84 with SMTP id i20mr5958875wiw.9.1360950975702; Fri, 15 Feb 2013 09:56:15 -0800 (PST)
Sender: simone.bordet@gmail.com
Received: by 10.217.96.195 with HTTP; Fri, 15 Feb 2013 09:56:15 -0800 (PST)
In-Reply-To: 
References: <20130201073846.78956B1E003@rfc-editor.org>     
Date: Fri, 15 Feb 2013 18:56:15 +0100
X-Google-Sender-Auth: u4GaGEfhZUY2DTMgGmBfHBRK1XE
Message-ID: 
From: Simone Bordet 
To: Adam Rice 
Content-Type: text/plain; charset=UTF-8
Cc: "hybi@ietf.org" , Pete Resnick , Barry Leiba , "ifette+ietf@google.com" 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 17:56:18 -0000

Hi,

On Fri, Feb 15, 2013 at 11:35 AM, Adam Rice  wrote:

> I think the issue that this section creates problems for WebSocket proxies
> and non-browser clients cannot be handled without changing the meaning of
> the text, and so I would like to deal with that separately.

You have my +1 in advance for this :)
Let us know if something is needed to get this separate change going
(not familiar with IETF procedures).

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
http://intalio.com
Developer advice, training, services and support
from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

From martin.thomson@gmail.com  Fri Feb 15 11:56:19 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1D721F868B for ; Fri, 15 Feb 2013 11:56:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.696
X-Spam-Level: 
X-Spam-Status: No, score=-4.696 tagged_above=-999 required=5 tests=[AWL=-1.097, 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 2CLF4w2+nUAB for ; Fri, 15 Feb 2013 11:56:19 -0800 (PST)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id C8E2421F863C for ; Fri, 15 Feb 2013 11:56:18 -0800 (PST)
Received: by mail-wi0-f182.google.com with SMTP id hi18so1609062wib.9 for ; Fri, 15 Feb 2013 11:56:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=BsYo9Dut3MPIO9Z0vC1oBEEGHU2q/zCuX6qd3EhPXTo=; b=DzPrtv8cQuT4v+xFnXr/TARRCPWhWtiMflmC6koqmKqt29/35eaFkdG/zb/b2MxWY0 gtpDDb6iqAtAnIm6qgqt791E8WZRINOkS5VB47SAEe/7TJF0bdxiVoICGWJpWXkOE85x RrGs+YWgH1C869pLPXvGwd6eshUCzuSiojPuxMF8veIWmBRAdZucGOgwlOHK6Ab3mWJ0 T4UEFN9C+aZO6HHe8KUW1CdBrCTlqqGPXOR+jX4QhZn/+rFhNFUEu7nlEn1enEXI5LmP 4volJkgfqdRHr/QiXwNzlEcKQgW4KymKOpqVMJxzN+FDp4rzmGoTOP83RL5ooU31DvTN Lf8g==
MIME-Version: 1.0
X-Received: by 10.180.77.9 with SMTP id o9mr8319232wiw.16.1360958178028; Fri, 15 Feb 2013 11:56:18 -0800 (PST)
Received: by 10.194.5.135 with HTTP; Fri, 15 Feb 2013 11:56:17 -0800 (PST)
In-Reply-To: 
References: <20130201073846.78956B1E003@rfc-editor.org>     
Date: Fri, 15 Feb 2013 11:56:17 -0800
Message-ID: 
From: Martin Thomson 
To: Adam Rice 
Content-Type: text/plain; charset=UTF-8
Cc: "hybi@ietf.org" , Pete Resnick , Barry Leiba , "ifette+ietf@google.com" 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 15 Feb 2013 19:56:19 -0000

Thanks Adam, this works nicely.

For extra clarity on the key 'MUST' sentence:
OLD:
There MUST be no more than
       one connection in a CONNECTING state.
NEW:
There MUST be no more than
       one connection in the CONNECTING state for any IP and port.

On 15 February 2013 02:35, Adam Rice  wrote:
> On 15 February 2013 00:56, Barry Leiba  wrote:
>
>>
>> OK... so how do you folks propose that your ADs resolve this errata
>> report?
>>
>> The options are as follows:
>>
>> 1. It's just wrong, and we should mark it "Rejected".  (This doesn't
>> seem like where you're going.)
>>
>> 2. It's absolutely correct as it is, and we should mark it "Verified".
>>  (It doesn't seem like it's this either.)
>>
>> 3. It's essentially correct, but needs some editing.  You can provide
>> the edits and we can edit it and then mark it "Verified".
>>
>> 4. It's true that there's a problem, but the resolution is beyond the
>> scope of an erratum.  We can either leave it as it is or edit it (to
>> tweak the proposed resolution and/or to explain the difficulty in
>> resolving it), and then mark it "Held for Document Update".
>
>
> I would like to take option 3. I would like to propose the following text to
> clarify the intent of RFC6455 while preserving the meaning:
>
>    2.  If the client already has a WebSocket connection to the same IP
>        address and port pair, even if the remote host is known by another
>        name, the client MUST wait until that connection has been established
>        or for that connection to have failed.  There MUST be no more than
>        one connection in a CONNECTING state.  If multiple connections to the
>        same IP address and port pair are attempted simultaneously, the
>        client MUST serialize them so that there is no more than one
>        connection at a time running through the following steps.
>
> The following paragraph already indicates what must be done in the case
> where the IP address cannot be determined, so this change should not create
> any difficulties in the case where the connection is tunnelled via an
> HTTP(S) or SOCKS5 proxy.
>
> I think the issue that this section creates problems for WebSocket proxies
> and non-browser clients cannot be handled without changing the meaning of
> the text, and so I would like to deal with that separately.
>
> Thank you,
> Adam Rice
>
>

From w@1wt.eu  Fri Feb 15 23:26:20 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980EA21F857A for ; Fri, 15 Feb 2013 23:26:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.136
X-Spam-Level: 
X-Spam-Status: No, score=-6.136 tagged_above=-999 required=5 tests=[AWL=-4.093, 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 SyW670fLenrW for ; Fri, 15 Feb 2013 23:26:20 -0800 (PST)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0121F846C for ; Fri, 15 Feb 2013 23:26:18 -0800 (PST)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r1G7Q4Cm015445; Sat, 16 Feb 2013 08:26:04 +0100
Date: Sat, 16 Feb 2013 08:26:04 +0100
From: Willy Tarreau 
To: Martin Thomson 
Message-ID: <20130216072604.GK13100@1wt.eu>
References: <20130201073846.78956B1E003@rfc-editor.org>      
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: "ifette+ietf@google.com" , Pete Resnick , "hybi@ietf.org" , Adam Rice , Barry Leiba 
Subject: Re: [hybi] [Editorial Errata Reported] RFC6455 (3473)
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 16 Feb 2013 07:26:20 -0000

Hi,

On Fri, Feb 15, 2013 at 11:56:17AM -0800, Martin Thomson wrote:
> Thanks Adam, this works nicely.
> 
> For extra clarity on the key 'MUST' sentence:
> OLD:
> There MUST be no more than
>        one connection in a CONNECTING state.
> NEW:
> There MUST be no more than
>        one connection in the CONNECTING state for any IP and port.

Fine by me as well.

Regards,
Willy


From salvatore.loreto@ericsson.com  Wed Feb 20 05:28:49 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E471D21F873C for ; Wed, 20 Feb 2013 05:28:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.153
X-Spam-Level: 
X-Spam-Status: No, score=-106.153 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 fIFi0RY0sA5g for ; Wed, 20 Feb 2013 05:28:49 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 658A721F871F for ; Wed, 20 Feb 2013 05:28:48 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-9f-5124cf8fc523
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 8F.B3.19728.F8FC4215; Wed, 20 Feb 2013 14:28:47 +0100 (CET)
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.279.1; Wed, 20 Feb 2013 14:28:46 +0100
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3])	by mail.lmf.ericsson.se (Postfix) with ESMTP id C33D0244D	for ; Wed, 20 Feb 2013 15:28:46 +0200 (EET)
Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 98252543F9	for ; Wed, 20 Feb 2013 15:28:44 +0200 (EET)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1])	by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 375885438B	for ; Wed, 20 Feb 2013 15:28:44 +0200 (EET)
Message-ID: <5124CF8E.2000406@ericsson.com>
Date: Wed, 20 Feb 2013 15:28:46 +0200
From: Salvatore Loreto 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: "hybi@ietf.org" 
References: <5124943C.4080503@ericsson.com>
In-Reply-To: <5124943C.4080503@ericsson.com>
X-Forwarded-Message-Id: <5124943C.4080503@ericsson.com>
Content-Type: multipart/alternative; boundary="------------040807040503020008020605"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsUyM+JvjW7/eZVAg9n/lSzev9zG5MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujB2LZrIWvHKoePnoBHMD4xOTLkZODgkBE4mre1qYIWwxiQv3 1rN1MXJxCAmcZJTo+PaLGcLZwCgx/ft7dgjnHKPE47/zoMoOMkr8PfCOCcI5xSjxYdV6JpBh vALaEv2XzoLZLAKqEt3t/1lBbDYBM4nnD7eALRQVSJb49+gII0S9oMTJmU9YQGwRAWWJri8n wGxhAR+J/ScWsYPYQkAzJ215ATaTU0BH4nLXNaArOIAON5dYNb8eJMwsECbxc9YDVoh/1CSu ntvEDNGqJdF7tpNpAqPILCTbZiFpmQU0iVnAXuLB1jKIsLxE89bZzBC2vsT1O/dZkcUXMLKt YmTPTczMSS832sQIjImDW36r7mC8c07kEKM0B4uSOG+464UAIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYx7jDZcmNGzfybDg2BO+wt/t0nqvd/A7/bldefKMOa6ovezzzk+qTF0848+M2OT xUWJW7WGW6bLHni3e87FyK37PorGOArM5c24sl9RbKKnz7eAaUsrb89JjhWZsjHX27n2zaxS IfOued/WxZu5z/5h9HDrh8McFg0he4QC/NbfmvtC+1axdlyqEktxRqKhFnNRcSIAy6owh1cC AAA=
Subject: [hybi] Fwd: publication request: draft-ietf-hybi-permessage-compression-05
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 20 Feb 2013 13:28:50 -0000

--------------040807040503020008020605
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit

FYI

I have sent a publication request to the IESG for the 
permessage-compression draft.

cheers
Salvatore

-------- Original Message --------
Subject: 	publication request: draft-ietf-hybi-permessage-compression-05
Date: 	Wed, 20 Feb 2013 11:15:40 +0200
From: 	Salvatore Loreto 
To: 	Barry Leiba , "iesg-secretary@ietf.org" 

CC: 	Gabriel Montenegro 



Dear Barry

I am requesting the publication for the draft:
"WebSocket Per-message Compression"
draft-ietf-hybi-permessage-compression-05

the Writeup is below.
For it I have used the proposed version at:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate

best regards
Salvatore


Document Writeup
1. Summary

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director

Abstract
This document specifies a framework for creating WebSocket extensions
that add compression functionality to the WebSocket Protocol.
Extensions based on this framework compress the payload of non-control
WebSocket messages using a specified compression algorithm.
One reserved bit RSV1 in the WebSocket frame header is allocated to
control application of compression for each message. This document
also specifies one specific compression extension using DEFLATE.


2. Review and Consensus


The Compression extension has been discussed extensively within the HyBi
almost since the beginning of the WebSocket standardization process,
however at the time the wg decided, in order to speed up the process and
not increase even more the discussion, not to standardize any extension
in the main WebSocket spec but postpone all of them.
The initial version of the draft was based on per-frame compression, but
then in IETF84 meeting, in Vancouver, the HyBi WG discussed the change
from per-frame to per-message compression
(http://www.ietf.org/mail-archive/web/hybi/current/msg09729.html).
The chairs sensed the WG’s consensus in the room to go ahead with this
change (http://www.ietf.org/mail-archive/web/hybi/current/msg09816.html)

The wg hasn't faced any significant point of difficulty or controversial.

Chrome supports the old perframe deflate draft. However they are going
to update it to the latest one soon.
pywebsocket (http://code.google.com/p/pywebsocket/ ) supports
permessage-compression-04 but needs some changes
on extension parameters parsing to be 05 compliant.

Jetty webserver has supports the permessage-compression draft but an
older version of the draft.



3. Intellectual Property

The author has confirmed conformance with BCPs 78 and 79.


4. Other Points


The draft reference as Informative: RFC1951 "DEFLATE Compressed Data
Format Specification version 1.3"
that appear in the DOWNREF registry.

There is no new IANA registry created by this document.





--------------040807040503020008020605
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit


  

    
  
  
    FYI

    

    I have sent a publication request to the IESG for the
    permessage-compression draft.

    


      cheers

      Salvatore

      

      -------- Original Message --------
      

        
          

            Subject:
            
            publication request:
              draft-ietf-hybi-permessage-compression-05
          

          

            Date: 
            Wed, 20 Feb 2013 11:15:40 +0200
          

          

            From: 
            Salvatore Loreto <salvatore.loreto@ericsson.com>
          

          

            To: 
            Barry Leiba <barryleiba@computer.org>,
              "iesg-secretary@ietf.org" <iesg-secretary@ietf.org>
          

          

            CC: 
            Gabriel Montenegro
              <Gabriel.Montenegro@microsoft.com>
          

        
      

      

      

      
Dear Barry

I am requesting the publication for the draft:
"WebSocket Per-message Compression" 
draft-ietf-hybi-permessage-compression-05

the Writeup is below.
For it I have used the proposed version at:
http://trac.tools.ietf.org/group/iesg/trac/wiki/DraftShepherdWriteupWgAlternate

best regards
Salvatore


Document Writeup
1. Summary

Salvatore Loreto is the document shepherd

Barry Leiba is the responsible Area Director

Abstract
This document specifies a framework for creating WebSocket extensions 
that add compression functionality to the WebSocket Protocol.
Extensions based on this framework compress the payload of non-control 
WebSocket messages using a specified compression algorithm.
One reserved bit RSV1 in the WebSocket frame header is allocated to 
control application of compression for each message. This document
also specifies one specific compression extension using DEFLATE.


2. Review and Consensus


The Compression extension has been discussed extensively within the HyBi 
almost since the beginning of the WebSocket standardization process,
however at the time the wg decided, in order to speed up the process and 
not increase even more the discussion, not to standardize any extension
in the main WebSocket spec but postpone all of them.
The initial version of the draft was based on per-frame compression, but 
then in IETF84 meeting, in Vancouver, the HyBi WG discussed the change
from per-frame to per-message compression 
(http://www.ietf.org/mail-archive/web/hybi/current/msg09729.html).
The chairs sensed the WG’s consensus in the room to go ahead with this 
change (http://www.ietf.org/mail-archive/web/hybi/current/msg09816.html)

The wg hasn't faced any significant point of difficulty or controversial.

Chrome supports the old perframe deflate draft. However they are going 
to update it to the latest one soon.
pywebsocket (http://code.google.com/p/pywebsocket/ ) supports 
permessage-compression-04 but needs some changes
on extension parameters parsing to be 05 compliant.

Jetty webserver has supports the permessage-compression draft but an 
older version of the draft.



3. Intellectual Property

The author has confirmed conformance with BCPs 78 and 79.


4. Other Points


The draft reference as Informative: RFC1951 "DEFLATE Compressed Data 
Format Specification version 1.3"
that appear in the DOWNREF registry.

There is no new IANA registry created by this document.




      

    

    

  


--------------040807040503020008020605--

From barryleiba.mailing.lists@gmail.com  Thu Feb 21 14:42:22 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4196E21E803F for ; Thu, 21 Feb 2013 14:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.954
X-Spam-Level: 
X-Spam-Status: No, score=-102.954 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koAlEWrdNYUp for ; Thu, 21 Feb 2013 14:42:21 -0800 (PST)
Received: from mail-ve0-f178.google.com (mail-ve0-f178.google.com [209.85.128.178]) by ietfa.amsl.com (Postfix) with ESMTP id 42C9F21E803D for ; Thu, 21 Feb 2013 14:42:21 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id db10so42678veb.9 for ; Thu, 21 Feb 2013 14:42:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=lDKC7rGMML7kUgzzqPPhTOr1qFFecUEQ2Y4/pF2wX1E=; b=tPAb6K8O9aump86/i2A0V0P670lq5GMzypgqqwWJDw10dkH/bczDscu/mAePvl4sM0 P7Rmqxct7j/0xJwNylRtdelZK0R2S74InMR2Qihj3kWF6+dCYdyedRi4wDZLbjobql6e tiZ0qzHXc8MRscdwVci2O+PVTjBKHzK18cQK2+SPMXvbUUZ02noso3zdT/BBChOdLa+e wpuaycuF5I5N6Bc3pKD1U/Ri0Y1FwD8Xa5PVJhHH6Y18PB6Ecv45Q2i+nSg2wgKLTxgk MFPRmc0j2R46SXUzZ32b8T1mKJXHUX9dFsysa62a26dvnAtnj1Hs9IViXKx+BsRuHS7T lDyQ==
MIME-Version: 1.0
X-Received: by 10.52.24.229 with SMTP id x5mr29330347vdf.84.1361486540534; Thu, 21 Feb 2013 14:42:20 -0800 (PST)
Sender: barryleiba.mailing.lists@gmail.com
Received: by 10.59.3.41 with HTTP; Thu, 21 Feb 2013 14:42:20 -0800 (PST)
In-Reply-To: <5124CF8E.2000406@ericsson.com>
References: <5124943C.4080503@ericsson.com> <5124CF8E.2000406@ericsson.com>
Date: Thu, 21 Feb 2013 17:42:20 -0500
X-Google-Sender-Auth: e65zQpbdXVKiEQuoIfuZmYi1Xf8
Message-ID: 
From: Barry Leiba 
To: Salvatore Loreto 
Content-Type: text/plain; charset=ISO-8859-1
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Fwd: publication request: draft-ietf-hybi-permessage-compression-05
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 22:42:22 -0000

> I have sent a publication request to the IESG for the permessage-compression draft.

And I'm afraid that I'm sending it back: I think it's not in
appropriate shape to ask the community and the IESG to review and
accept it.  What I've read has been unclear, and I'm very much
concerned that implementors won't be able to follow it well enough to
implement it correctly.  See my (partial) review below; I stopped
after Section 3.

I'm asking the working group to do some careful review to make sure
that it's clear, understandable, and ready for people outside the
working group to implement.  Make sure everything holds together and
that someone who is NOT already familiar with how this works can still
understand and correctly implement it.  If the working group needs
more help with this, it can ask for it on apps-discuss.

Barry

========================================
-- General --

   [in various places...}
   _This section is non-normative._

   2. Conformance Requirements
   Everything in this specification except for sections explicitly
   marked non-normative is normative.

I understand that all of this corresponds to the same text in the
WebSockets document.  I can't tell you how much I dislike this style,
and I ask (but not demand) that you please consider removing it.  I'm
happy to discuss this.

I believe you need to be clear from the language you use (and I don't
just mean MUST and SHOULD) when something is not normative.  Calling
things "examples" already conveys this.  Section titles such as
"Introduction" conveys this.  Most documents manage without this sort
of thing.  Why does WebSockets (and its successor documents, such as
this one) need it?

-- Introduction --

   The simplest "Sec-WebSocket-Extensions" header in the client's
   opening handshake to request permessage-deflate is the following:

       Sec-WebSocket-Extensions: permessage-deflate

   The simplest header from the server to accept this extension is the
   same.

Why is this in the Introduction?  It seems seriously out of place there.

-- Section 3 --

I find the organization of this to be awkward.  The first paragraph
doesn't make much sense to me, for one thing.  I suggest two things to
start with:

1. Change the overall document title:

OLD
WebSocket Per-message Compression

NEW
WebSocket Per-message Compression Extension Framework

That better explains what the document is specifying (the abbreviated
title can remain "WebSocket Per-message Compression"), and means that
the last sentence of the first paragraph of Section 3 can be removed.
For the rest of the paragraph, how about this (I'm also pulling up
something from the paragraphs below)?:

NEW
   Per-Message Compression Extensions (PMCEs) are individually
   defined, and are registered in the WebSocket Extension Name
   Registry.  One such extension is defined in Section 5 of this
   document and is registered in Section 7.1.  Other PMCEs may
   be defined in other documents.  Each PMCE defines the content
   of its extension token, including any applicable extension
   parameters.
END

Note that you now have an abbreviation (PMCE) that you can use freely.

Second paragraph:

   To request use of a Per-message Compression Extension, a client MUST
   include an element with its extension token in the
   "Sec-WebSocket-Extensions" header in its opening handshake.

You should avoid a lot of "it"s, unless the antecedent is quite clear.
 Here, the antecedents are not clear.  It looks like "its extension
token" means "the client's extension token," and it looks like "its
opening handshake" means "the S-WS-E header's opening handshake," or
perhaps "the token's opening handshake."

Also, is the client "requesting" use of one particular PMCE, or
"offering" a list of PMCEs?  It seems to me that it's the latter: the
client offers a list, and the server selects zero or one from the list
and sends it in the response.  Yes?

   The
   element contains extension parameters as specified by the
   specification of the extension.

This loops around in a circle, and is hard to make sense of.

   A client MAY list multiple Per-
   message Compression Extensions with the same name to offer use of the
   same algorithm with different configurations.

May a client also list multiple extensions with *different* names?

How about this for the whole paragraph?:

NEW
   To offer use of a PMCE, a client MUST include an element with the
   offered extension's token in the "Sec-WebSocket-Extensions" header
   in the opening handshake of the WebSocket connection.  A client
   offers multiple PMCE choices to the server by including multiple
   tokens, one for each PMCE offered.  The set of tokens MAY include
   multiple PMCEs with the same name to offer use of the same
   algorithm with different configurations.
END

Please look for other "it" occurrences, and make sure they're similarly clear.

Similarly, for the third paragraph, maybe this?:

NEW
   To accept use of a PMCE, a server MUST include an element with the
   accepted extension token in the "Sec-WebSocket-Extensions" header in
   the opening handshake of the WebSocket connection.  The accepted
   token MUST be one of those offered by the client during the opening
   handshake, and MUST represent a PMCE that is fully supported by the
   server.  The server rejects all offered PMCEs by not including any
   PMCE tokens, in which case the connection proceeds without
   per-message compression.
END

Fourth paragraph:

   If a client doesn't support the extension and its parameters replied
   from the server, the client MUST _Fail the WebSocket Connection_.
   Otherwise, once _the WebSocket Connection is established_, both
   endpoints MUST use the algorithm described in Section 4 to exchange
   messages.

Why would a server respond with an extension/parameters that the
client doesn't support?  The client already sent a list of what it's
willing to use.  In the re-writes I've done above, that's made clear,
and this paragraph is, if anything, just specifying how to handle a
server response that's in violation of the protocol.  You also refer
to the Section 4 algorithm, but say nothing about what compression
mechanism will be used.  So maybe this?:

NEW
   * If the server responds with no PMCE tokens, once _the WebSocket
   Connection is established_ it proceeds without per-message
   compression.

   * If the server gives an invalid response, such as accepting a
   PMCE that the client did not offer, the client MUST _Fail the
   WebSocket Connection_.

   * Otherwise, once _the WebSocket Connection is established_, both
   endpoints MUST use the algorithm described in Section 4 to exchange
   messages, using the PMCE returned by the server.
OLD

By my reckoning, this has just re-written the entire Section 3.  This
bothers me, because it makes me question the level of review and
editing that the document has gone through.  As I look at Section 3.1,
I see that it appears to be inadequate: it is *not* a "negotiation
example"; it is a series of out-of-context examples of isolated header
field values.  This actually *would* benefit from a full example of an
opening handshake that uses this, where a client offers a few PMCEs
(perhaps two with the same name and a third with another name), and
showing how the server responds.
========================================

From derhoermi@gmx.net  Thu Feb 21 15:36:31 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E40121E8039 for ; Thu, 21 Feb 2013 15:36:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.128
X-Spam-Level: 
X-Spam-Status: No, score=-3.128 tagged_above=-999 required=5 tests=[AWL=-0.529, 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 zIrc4xzcQLuX for ; Thu, 21 Feb 2013 15:36:29 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6721221E803D for ; Thu, 21 Feb 2013 15:36:29 -0800 (PST)
Received: from mailout-de.gmx.net ([10.1.76.24]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M9d2X-1U0e851ilb-00D0g7 for ; Fri, 22 Feb 2013 00:36:26 +0100
Received: (qmail invoked by alias); 21 Feb 2013 23:36:25 -0000
Received: from p5B2322BB.dip.t-dialin.net (EHLO netb.Speedport_W_700V) [91.35.34.187] by mail.gmx.net (mp024) with SMTP; 22 Feb 2013 00:36:25 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX19Qalt4bBRQnq4syOOV+EwU+mDmePEwzClCw25n8D 7NpUGoi6EFjXdf
From: Bjoern Hoehrmann 
To: Barry Leiba 
Date: Fri, 22 Feb 2013 00:36:28 +0100
Message-ID: 
References: <5124943C.4080503@ericsson.com> <5124CF8E.2000406@ericsson.com> 
In-Reply-To: 
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "hybi@ietf.org" 
Subject: Re: [hybi] Fwd: publication request: draft-ietf-hybi-permessage-compression-05
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 21 Feb 2013 23:36:31 -0000

* Barry Leiba wrote:
>========================================
>-- General --
>
>   [in various places...}
>   _This section is non-normative._
>
>   2. Conformance Requirements
>   Everything in this specification except for sections explicitly
>   marked non-normative is normative.
>
>I understand that all of this corresponds to the same text in the
>WebSockets document.  I can't tell you how much I dislike this style,
>and I ask (but not demand) that you please consider removing it.  I'm
>happy to discuss this.
>
>I believe you need to be clear from the language you use (and I don't
>just mean MUST and SHOULD) when something is not normative.  Calling
>things "examples" already conveys this.  Section titles such as
>"Introduction" conveys this.  Most documents manage without this sort
>of thing.  Why does WebSockets (and its successor documents, such as
>this one) need it?

It corresponds to Ian Hickson's stylistic preference and most likely was
kept and copied from the early protocol drafts that he edited. Since the
errata system we have in place seems to be working, it does not really
serve a useful purpose where it's used in the document under discussion.

(Sometimes such markers are the best editorial option available, I'm
just saying that none of the cases in the document strike me as such.)

>-- Introduction --
>
>   The simplest "Sec-WebSocket-Extensions" header in the client's
>   opening handshake to request permessage-deflate is the following:
>
>       Sec-WebSocket-Extensions: permessage-deflate
>
>   The simplest header from the server to accept this extension is the
>   same.
>
>Why is this in the Introduction?  It seems seriously out of place there.

I think pointing out something like "clients and servers negotiate use
of Per-message Compression using Sec-WebSocket-Extensions: ..." may well
belong in the Introduction, it just seems a bit oddly phrased and lacks
context as it appears above.

>-- Section 3 --
>
>I find the organization of this to be awkward.  The first paragraph
>doesn't make much sense to me, for one thing.  I suggest two things to
>start with:
>
>1. Change the overall document title:
>
>OLD
>WebSocket Per-message Compression
>
>NEW
>WebSocket Per-message Compression Extension Framework

I think "Extension Framework" is overdoing it, but the idea seems good.
Perhaps "WebSocket Per-message Compression Extensions" would be better.
-- 
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 sm@resistor.net  Sat Feb 23 19:10:28 2013
Return-Path: 
X-Original-To: hybi@ietfa.amsl.com
Delivered-To: hybi@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A9821F8ECA for ; Sat, 23 Feb 2013 19:10:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.279
X-Spam-Level: 
X-Spam-Status: No, score=-102.279 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_00=-2.599, J_CHICKENPOX_64=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQR0FVNpfI1v for ; Sat, 23 Feb 2013 19:10:26 -0800 (PST)
Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id BA3EF21F8E57 for ; Sat, 23 Feb 2013 19:10:26 -0800 (PST)
Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) (authenticated bits=0) by mx.elandsys.com (8.14.5/8.14.5) with ESMTP id r1O3AFlp010800; Sat, 23 Feb 2013 19:10:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1361675420; bh=CBUwnLnAyLf4C5R8FGhTdGPMLko348Q+e//KPY/axeA=; h=Date:To:From:Subject:Cc; b=JRoC80PZ9V7SsPhe8q58Bf3EQasFQzXa9B30RxG6k0Nw2tlKx+TDqLd2Z1Uyphc9K Aswets+jNyX0IlZfagZcM9eR19MLWwvX0MSiaCdh/2mz8lqY/PmZQTpFhdKdbTJ+3Y CgDpNuSNUmCpyr0wEDGxlEKwxYxTUtTVWlXkjPMg=
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1361675420; i=@resistor.net; bh=CBUwnLnAyLf4C5R8FGhTdGPMLko348Q+e//KPY/axeA=; h=Date:To:From:Subject:Cc; b=ypcq0bHtOgywQ5VbRmBGqUj+3+O2U0BmbQZGAZyR4w+NoyTYDH0+2Wigc+7hqkBac 50QzUD9t66u9IllVKZOFQhrfx1zBed83udfgSojpUFYyRB9DrP48AQZCPEVL3ZxzQq 26g3Ts+7Y9PnNzYEwDJ1EF67KL8+LreBlq1nhT6o=
Message-Id: <6.2.5.6.2.20130223175715.094d8508@elandnews.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6
Date: Sat, 23 Feb 2013 18:59:30 -0800
To: Takeshi Yoshino 
From: SM 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: hybi@ietf.org
Subject: [hybi] Comments on draft-ietf-hybi-permessage-compression-05
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Server-Initiated HTTP 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 24 Feb 2013 03:10:28 -0000

Hi Takeshi,

This is an individual comment on 
draft-ietf-hybi-permessage-compression-05.  I did not cover all the 
issues.  Sorry for not providing ample explanation.

In Section 1:

  "_This section is non-normative._"

This style is unusual for IETF Stream documents.  I suggest switching 
back to the usual style.

   "As well as other communication protocols, the WebSocket Protocol
    [RFC6455] can benefit from compression technology."

The sentence would benefit from a rewrite.  It could alternatively be dropped.

I suggest first specifying the framework and then go into the 
details.  I would look at the Introduction Section in terms of 
providing an introduction to the topic and after that a view of what 
to expect in the other sections so that there is a "logical" 
flow.  Sorry for not describing this in better terms.

In Section 3:

   'Extensions build based on this framework are collectively
    called "Per-message Compression Extensions".'

Where is there an explanation for the framework?

   'To request use of a Per-message Compression Extension, a client
    MUST include an element with its extension token in the
    "Sec-WebSocket-Extensions" header in its opening handshake.'

What is "element" and what is "extension token"?

   "A client MAY list multiple Per-message Compression Extensions
    with the same name to offer use of the same algorithm with
    different configurations."

Why is this a MAY?

   "The parameters MUST be derived from the parameters sent by the
    client and the server's capability."

What is the meaning of "the parameters must be derived"?

   'To reject use of a Per-message Compression Extension, a server MUST
    simply ignore the element in the "Sec-WebSocket-Extensions" header in
    the client's opening handshake.'

This is not clear.

   "If a client doesn't support the extension and its parameters replied
    from the server, the client MUST _Fail the WebSocket Connection_."

What is the meaning of "MUST _Fail"?

   "Otherwise, once _the WebSocket Connection is established_, both
    endpoints MUST use the algorithm described in Section 4 to exchange
    messages."

This comes out as IF requirement1 ELSE requirement2.

I suggest explaining how the protocol should work.  Error handling 
could be part of that.

In Section 4.1:

   "To send a compressed message, an endpoint MUST use the following
    algorithm."

I only need to know the format to use to send the compressed 
message.  I suggest looking at it from that angle instead of 
specifying an algorithm.

In Section 5.2.1:

   "The ABNF [RFC5234] for the value of this parameter is 1*DIGIT."

I suggest following the usual practices for ABNF (see existing RFCs 
for examples).

Each section seems like a standalone part of the draft.  In Section 5.3.2.1:

   "The first 2 octets are the WebSocket protocol's overhead (FIN=1,
    RSV1=1, RSV2=0, RSV3=0, opcode=text, MASK=0, Payload length=7)."

I suggest using ASCII art for illustration.

   "To send it after fragmentation, split the compressed payload and
    build frames for each of split data as well as fragmentation process
    done when the compression extension is not used."

I suggest avoiding the tutorial approach.  I would look at this as 
what goes on the wire.
In Section 6:

   "There are no security concerns for now."

This is going to flag this as an issue.  I suggest thinking about the 
security considerations.  There must be something which could go wrong.

The basic idea is there.  It is a matter of having text to explain 
that.  I suggest avoiding sentences like 'Then, a block containing 
"llo" follows.' as it will create more work for the RFC Editor.  The 
draft unfortunately has to be rewritten.  It is better not to make 
liberal use of RFC 2119 key words.  I suggest using them for 
interoperability.  RFC 6709 discusses about design considerations for 
extensions.  It could be used as guidance.  I suggest looking at some 
other RFCs discussing about extensions to get an idea of the possible 
styles and then choosing one.

Regards,
-sm