From tyoshino@google.com Wed Dec 5 23:35:11 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0BED21F8D77 for ; Wed, 5 Dec 2012 23:35:11 -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=[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 K8RLTxxlKNbJ for ; Wed, 5 Dec 2012 23:35:11 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id D620021F8D74 for ; Wed, 5 Dec 2012 23:35:10 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so8642659vba.27 for ; Wed, 05 Dec 2012 23:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=/eGU1o5ISj95SGMwrjrfXQR7+eiIuiLjPNFJpzgLlh8=; b=o63aIniKiz1nCFmuF1n60UX6NP3NCmHRiHQbY37O1ng+Wlf/HHZCkq2442Ttimyt53 eb69U3SwOvE78gCNI/fOmottQxDNcofEWLF1UB6dcYyejEkP34ezADIK4fqJ6p3TRySO S8CokFxDHrWqlnnlrL82uUPHGGkzqjihHhKGmCqp6ysK3G21TNQ6GV+XNDi6qPtoqFk2 EDRvyaoa4efZtBqteOK5TVo2ku4B8wKUiMvlViBhKAdIwmN7QDjM2ZXPb6atzcq5p1ws NyJlvxK9/vE27rg5nOppXDkwGkXU425IFe77a6kCh0SywHndycYEvpzbznQRIhZABJ2s VEwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=/eGU1o5ISj95SGMwrjrfXQR7+eiIuiLjPNFJpzgLlh8=; b=XjLjqU6IaLHv5x0L5EMmgUZmi3m8pH14D+wj75SrwZl6DJkMB9obgIZtJxFGun2hqC 8SFM4tLRDUbqYqfNVUBm3wg3CZysIokblxigyS6c3CfStp82/EBxo9pvEZAoF7YbYwQr l2CGugB575VhVOOCqNa3LsBPArRQgmYUy7y/p9bvrYsVKkHVJBej86RKstU5pJs6UrKq bZXVW5/te0Qa+r1CfKcDW34OQ9OphHh77vRSMfXX02C8XViy5YS/LazTBCPEjXvG3h8/ FZ4WgHw/6KMFlYHIHQnIrIg8ooDBxEXf7LeHphynlTU3/kkwVG48lYtOdGgK4xtn+Wud NAoA== Received: by 10.58.221.228 with SMTP id qh4mr335742vec.49.1354779310067; Wed, 05 Dec 2012 23:35:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.248.228 with HTTP; Wed, 5 Dec 2012 23:34:49 -0800 (PST) In-Reply-To: References: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> <20121129101102.GA17793@jl-vm1.vm.bytemark.co.uk> From: Takeshi Yoshino Date: Thu, 6 Dec 2012 16:34:49 +0900 Message-ID: To: Roberto Peon Content-Type: multipart/alternative; boundary=047d7bdc7a9a868f2904d02a2304 X-Gm-Message-State: ALoCoQlcB7V55d6qwzzjUJ040gwQ11hVMUpWetYYGrcaRAk9QQmknd6dcr3+jOxAe66SvEC0+0aWXTurPvmBYlvrnU28pJguhebYaOLbRhl96gtZROTGmkMJCtQRrrZH2iFykQn2+VvtxAJyvJ+U2ijNrcZIWRAdoGCiJzR7vi23ssTxME8BjwR1p0pkKTPJsW4x/vjx6On1 Cc: hybi@ietf.org Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 06 Dec 2012 07:35:11 -0000 --047d7bdc7a9a868f2904d02a2304 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 30, 2012 at 3:42 AM, Roberto Peon wrote: > ++ > On Nov 29, 2012 2:11 AM, "Jamie Lokier" wrote: > snip > It might make sense if TLS could transmit its own, much shorter, >> keepalive messages, which are for the sole purpose of keeping the link >> alive. I would guess, since they have no other effect, that they >> wouldn't be exploitable in the same way. Is that right? >> >> There might be some nop available at TLS level, but I'm not sure. I heard that old attempt (0/n record splitting) to address ancestor of the BEAST attack faced a problem that some of existing NWs can't handle empty record correctly. How about allowing the API to invoke TCP layer keepalive (null TCP packet) instead of nop TLS record? I found similar discussion in these threads for http://tools.ietf.org/html/rfc6520. - http://www.ietf.org/mail-archive/web/tls/current/msg07986.html - http://www.ietf.org/mail-archive/web/tls/current/msg07987.html > It would be best if they could be invoked from the higher layer rather >> than generated in TLS itself (because the higher layer will have a >> better idea of the keepalive patterns that it needs), and if they were >> one-way keepalives rather than PING/PONG to avoid amplification >> attacks, and because PING/PONG is not the most efficient keepalive >> pattern. >> >> Is there provision in TLS for that sort of thing now? >> >> (Of course over mobile links, it would make much more sense for power >> efficiency to have a single, aggregated keepalive stream for all >> sockets rather than one per active websocket, or some other way of >> taking advantage of the phone's existing mobile link-level keepalives >> which it already does and are designed for efficiency.) >> >> --047d7bdc7a9a868f2904d02a2304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 30, 2012 at 3:42 AM, Roberto Peon <fenix@g= oogle.com> wrote:

++

On Nov 29, 2012 2:11 AM, = "Jamie Lokier" <jamie@shareable.org> wrote:
snip=A0
It might make sense if TLS could transmit its own, much shorter,
keepalive messages, which are for the sole purpose of keeping the link
alive. =A0I would guess, since they have no other effect, that they
wouldn't be exploitable in the same way. =A0Is that right?


There m= ight be some nop available at TLS level, but I'm not sure. I heard that= old attempt (0/n record splitting) to address ancestor of the BEAST attack= faced a problem that some of existing NWs can't handle empty record co= rrectly.

How about allowing the API to invoke TCP layer keepaliv= e (null TCP packet) instead of nop TLS record?

I f= ound similar discussion in these threads for=A0http://tools.ietf.org/html/rfc6520.
=A0
It would be best if they could be invoked from the higher layer rather
than generated in TLS itself (because the higher layer will have a
better idea of the keepalive patterns that it needs), and if they were
one-way keepalives rather than PING/PONG to avoid amplification
attacks, and because PING/PONG is not the most efficient keepalive
pattern.

Is there provision in TLS for that sort of thing now?

(Of course over mobile links, it would make much more sense for power
efficiency to have a single, aggregated keepalive stream for all
sockets rather than one per active websocket, or some other way of
taking advantage of the phone's existing mobile link-level keepalives which it already does and are designed for efficiency.)

=
--047d7bdc7a9a868f2904d02a2304-- From Markus.Isomaki@nokia.com Fri Dec 7 01:40:43 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DE021F890D for ; Fri, 7 Dec 2012 01:40:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6jtmer2r2ZT for ; Fri, 7 Dec 2012 01:40:43 -0800 (PST) Received: from mgw-sa01.nokia.com (smtp.nokia.com [147.243.1.47]) by ietfa.amsl.com (Postfix) with ESMTP id 9A77621F8906 for ; Fri, 7 Dec 2012 01:40:42 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (in-mx.nokia.com [10.160.244.32]) by mgw-sa01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id qB79ea8c009040; Fri, 7 Dec 2012 11:40:37 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.23]) by vaebh106.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Fri, 7 Dec 2012 11:40:36 +0200 Received: from 008-AM1MPN1-041.mgdnok.nokia.com ([169.254.1.185]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.02.0318.003; Fri, 7 Dec 2012 09:40:35 +0000 From: To: , Thread-Topic: [hybi] Websocket over TLS keep-alive overhead Thread-Index: Ac3JZhTrqgN5+FAiRC2vlGrsEjKGjQACz0aQASIn74AAB/kDAAGQDuNA Date: Fri, 7 Dec 2012 09:40:34 +0000 Message-ID: References: <634914A010D0B943A035D226786325D4339290CD54@EXVMBX020-12.exch020.serverdata.net> <20121129101102.GA17793@jl-vm1.vm.bytemark.co.uk> In-Reply-To: <20121129101102.GA17793@jl-vm1.vm.bytemark.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.21.81.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 07 Dec 2012 09:40:36.0681 (UTC) FILETIME=[E91FEB90:01CDD45E] X-Nokia-AV: Clean Cc: hybi@ietf.org Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 07 Dec 2012 09:40:43 -0000 Hi, Yes, these are all very good points. Just one comment. Jamie Lokier wrote: > >(Of course over mobile links, it would make much more sense for power >efficiency to have a single, aggregated keepalive stream for all sockets r= ather >than one per active websocket, or some other way of taking advantage of th= e >phone's existing mobile link-level keepalives which it already does and ar= e >designed for efficiency.) Yes, aggregation is very important. If the keep-alive streams are independe= nt, power consumption is typically also multiplied. But I'm not sure what t= ype of "link-level" keep-alives you are thinking about. In both cellular an= d Wi-Fi links there is some messaging/paging going on, but that is typicall= y in the timescale of hundreds of milliseconds. So, it's not relevant to TC= P or websocket level keep-alives. However, synchronizing keep-alives with a= ny other IP traffic the device sends/receives is useful. Markus >-----Original Message----- >From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of >ext Jamie Lokier >Sent: 29 November, 2012 12:11 >To: Takeshi Yoshino >Cc: hybi@ietf.org >Subject: Re: [hybi] Websocket over TLS keep-alive overhead > >Takeshi Yoshino wrote: >> Hi, >> Chromium is using 1/n-1 record splitting for TLS 1.0 connection w/ CB= C >> mode cipher to work around BEAST exploit. So, even a WebSocket frame >> with 1 octet payload (client -> server, 7 octets in total. AES block >> size (16) * 2 - SHA1 HMAC size (20) - padding length field size (1) > >> 7, so 1 application data record with 32 octets payload is enough) wil= l >> be packed into two TLS records with big padding. >> re: TLS compression, it's disabled on Chromium to address another >> exploit called CRIME. > >It might make sense if TLS could transmit its own, much shorter, keepalive >messages, which are for the sole purpose of keeping the link alive. I wou= ld >guess, since they have no other effect, that they wouldn't be exploitable = in >the same way. Is that right? > >It would be best if they could be invoked from the higher layer rather tha= n >generated in TLS itself (because the higher layer will have a better idea = of the >keepalive patterns that it needs), and if they were one-way keepalives rat= her >than PING/PONG to avoid amplification attacks, and because PING/PONG is >not the most efficient keepalive pattern. > >Is there provision in TLS for that sort of thing now? > >(Of course over mobile links, it would make much more sense for power >efficiency to have a single, aggregated keepalive stream for all sockets r= ather >than one per active websocket, or some other way of taking advantage of th= e >phone's existing mobile link-level keepalives which it already does and ar= e >designed for efficiency.) > >-- Jamie >_______________________________________________ >hybi mailing list >hybi@ietf.org >https://www.ietf.org/mailman/listinfo/hybi From jamie@shareable.org Mon Dec 10 01:52:20 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2745F21F8E2B for ; Mon, 10 Dec 2012 01:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=-2.967, BAYES_00=-2.599, FAKE_REPLY_C=2.012] 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 CuFIR4AXcEtE for ; Mon, 10 Dec 2012 01:52:19 -0800 (PST) Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by ietfa.amsl.com (Postfix) with ESMTP id 7CC2F21F8E23 for ; Mon, 10 Dec 2012 01:52:19 -0800 (PST) Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1Ti023-00066Y-DW; Mon, 10 Dec 2012 09:52:15 +0000 Date: Mon, 10 Dec 2012 09:52:15 +0000 From: Jamie Lokier To: Markus.Isomaki@nokia.com Message-ID: <20121210095215.GO26936@jl-vm1.vm.bytemark.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: hybi@ietf.org Subject: Re: [hybi] Websocket over TLS keep-alive overhead X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 10 Dec 2012 09:52:20 -0000 Markus.Isomaki@nokia.com wrote: > Hi, > > Yes, these are all very good points. Just one comment. > > Jamie Lokier wrote: > > > >(Of course over mobile links, it would make much more sense for power > >efficiency to have a single, aggregated keepalive stream for all sockets rather > >than one per active websocket, or some other way of taking advantage of the > >phone's existing mobile link-level keepalives which it already does and are > >designed for efficiency.) > > Yes, aggregation is very important. If the keep-alive streams are > independent, power consumption is typically also multiplied. But I'm > not sure what type of "link-level" keep-alives you are thinking > about. In both cellular and Wi-Fi links there is some > messaging/paging going on, but that is typically in the timescale of > hundreds of milliseconds. So, it's not relevant to TCP or websocket > level keep-alives. Hi Markus, It's the difference in timescale which makes it work. A longer keepalive at a higher layer in the stack can be piggybacked efficiently ("free") on a shorter keepalive at a lower layer in the stack. (It can also make the keepalive even more effective than the usual "1 per minute" approach at application level, guaranteeing more rapid notification to the application of when the link is lost, or more up to date confirmation the link is still live so synchronised state is still valid.) This works for mobile, wireless, and wired links. I don't know details but suspect it's particularly effective in terms of mobile power usage. WebSocket/TLS level keepalive power can be *eliminated entirely* (saving maximum possible power) if a protocol extension allows the handset and mobile network to recognise them and, using an intermediary-permitted transformation to the message stream, the mobile network sends keepalives to the WS server as long as the network has link-level confirmation of the handset presence, and the handset sends keepalives to the WS client application as long as the handset has link-level confirmation of the network's presence. That can't happen as long as the keepalives are generated by the applications in an application-specific way. And it isn't safe to do it on the existing ping/pong messages, because it does change the nature of the end-to-end guarantees, suitable for some applications but not all, so it needs to be opt in by application. And it can't be done with WS over TLS, unless there is a recognisable TLS-level message the intermediary is able to transform. Aside from link-level power savings, a very similar possibility applies aggregating multiple keepalive streams from different Javascript applications within a single browser, and different keepalive streams from different non-browser applications; and even from different machines behind any bandwidth-limited link. Again it needs to be opt-in because it changes the nature of the end-to-end guarantees, and it needs messages that are recognisable and safe to change by an intermediary. > However, synchronizing keep-alives with any other > IP traffic the device sends/receives is useful. Typically there are many applications where the keepalives are 90% or more of the total traffic, because they are just to stay "present", while very little is really happening. For example an application simply checking for short messages, which you don't receive often, but are expected to show on the client when they do. It needs a keepalive - or repeated connections - just to receive a message from the server when something changes. Especially if you want fast notification. Yet, that might only happen once a day, and transfer just a few bytes - about 3 packets per day. Whereas 1 keepalive per minute over TCP is 4320 packets per day. In such applications, using the above figures keepalive is >99.9% of the traffic. That overhead can be mostly eliminated, with a protocol extension that allows smart interaction with intermediaries, and this is useful for saving handset power, and reducing bandwidth use in all applications where you have a lot of applications per client with similar behaviour - few data updates, lots of presence. Mobile handsets tend to have both of these at the same time, increasingly as more apps want to subscribe to notifications from their own services. (This whole idea can be developed further by ideas such as named liveness subscriptions, which would provide stronger end-to-end guarantees and so be suitable for more applications.) Best, -- Jamie From tyoshino@google.com Sun Dec 16 20:28:51 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5168F21F8597 for ; Sun, 16 Dec 2012 20:28:51 -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=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 7o7eRYa-+QZ3 for ; Sun, 16 Dec 2012 20:28:50 -0800 (PST) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0F74F21F8464 for ; Sun, 16 Dec 2012 20:28:48 -0800 (PST) Received: by mail-vc0-f172.google.com with SMTP id fw7so6643170vcb.31 for ; Sun, 16 Dec 2012 20:28:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=3zr33AzyaDO+um3jXRZPglkVlRFGg+uEeMhkaBhsc0U=; b=jtSTs3FtW42USl0P91ymcFgO60onXas7BgGmgIVPAuqEB1NnaIooJfKOt1wv3GyME/ iqolngi83ieQ6fR7QOdKqk+MbA+JtsavdURNOpoWEoaIuoszYRK6IfReGczWQ1JQsB8i LntCLCXHVMCEgLlub583rUXnLpjTnOnLslzcsfQ1YO538q+VXEygCz9c63EtwWQdKpWG Qa4WMXPUG0eu4YHPJLofg+BaUelheHINLeWcB2GMVZTv0Mry8omd/BLx+YR1CtyxI2td xHaKliMqFyE0y+bTCayOkGUtRk2nAcvN2isuMtSeP7Q5u35F/QEvbbdcp9kOmkMCnNs3 n+Sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-gm-message-state; bh=3zr33AzyaDO+um3jXRZPglkVlRFGg+uEeMhkaBhsc0U=; b=HltR8q/inA55C+GAEDdgIuXiQLoScxmXyRsOLl7ogejhV/tFN44LxnrOnHh7UIeifC EenqI2xkDh3BYaSIao4ttxd1dLsKawAS9PYxVarin8a+BfUdQSSVytSiwtkz63n/W/yZ ZYQtQA9FHFsKRQLsHOqz6ye+GV6acG8RDZCw2EAOJoWZLhFgBdr2V2q1xt1yyeW2mw5I igPxnVB27l2w62AyiS9vuOUNBThbBvbcx7nADGNiUrX/PNybB3OApouDI+wCNJrBK3SZ 3WN3eA2wuKikKsRWKn0BbGT2qhbdIuIb5Tr4AragvdoQ9QYwAjIB/xsY4kYQNL5wrs2p meqQ== Received: by 10.52.175.163 with SMTP id cb3mr17309671vdc.76.1355718528364; Sun, 16 Dec 2012 20:28:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.212.137 with HTTP; Sun, 16 Dec 2012 20:28:27 -0800 (PST) From: Takeshi Yoshino Date: Mon, 17 Dec 2012 13:28:27 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=bcaec517a9c24c70c404d104d124 X-Gm-Message-State: ALoCoQkM0B38HohS2+0eTDE3Laj6/E0FTIHDwcVrYaMAy71eXwG8QbpDh+LqnkpjG7u5R81szwuIUiNoPkDHCZeOO2msYvKIY7LUeeKbWZQhDNLpdUnSkyLV2dxwglWN5hnxfX15sFP2xULWOwd+Gqp/A6+saLfG9I57KIIjRh/cULoWnWQjtVM6p8ALwdr5i3HqjNHphqor Subject: [hybi] Resolutions for the issues of the compression spec reported during WGLC X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 17 Dec 2012 04:28:51 -0000 --bcaec517a9c24c70c404d104d124 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Thanks for review. Issues reported during WGLC (ended 2012/Nov/14) except for the ABNF conflict issue are already addressed and there's -05 staged (not posted yet. http://www.ietf.org/staging/draft-ietf-hybi-permessage-compression-05.txt). ==== Resolved issues ==== - Syntax/rules defined in RFC 2616 are used but not referenced -- http://www.ietf.org/mail-archive/web/hybi/current/msg09902.html -- FIXED: Added references - How endpoints should handle bad values (ABNF violation, etc.) is unspecified -- http://www.ietf.org/mail-archive/web/hybi/current/msg09912.html -- FIXED: Specified (ABNF violation -> ignore, wrong extension parameter -> ignore) - English grammar issues -- http://www.ietf.org/mail-archive/web/hybi/current/msg09902.html -- FIXED - Add an option to suppress compression on client-to-server data -- http://www.ietf.org/mail-archive/web/hybi/current/msg09922.html -- WONT FIX: Didn't receive much support/justification. - Clarified that the condition list defining bad method descriptions is OR list (any of them is true then bad) ==== Open issue ==== - Conflict between "method" extension parameter spec and RFC 6455 -- http://www.ietf.org/mail-archive/web/hybi/current/msg09904.html Possible solutions are: a) revise RFC 6455 by replacing constraint on quoted-string from "token" to CHAR - CTL pros: - human readable cons: - needs very strong justification to change 6455 -- existing implementations strictly conform to 6455 will "Fail" when method parameter including space, semicolon, etc. instead of just rejecting the extension -- there might be any private-use extension that manipulates extensions header assuming extension parameters conform to token after unquote b) move the method parameter into a new separate handshake header entry pros: - human readable cons: - introduces a new header not defined in 6455 c) use hex-encoding to token-ize the method parameter string (for compatibility, use method_hex as the extension parameter name) pros: - just addition of well-known simple encoding. no change outside of Sec-WebSocket-Extensions header cons: - not human readable My thought: I think it can be considered to be a bug that the token constraint is making extension header hard to carry structured data. But as listed above, there're difficulties to adopt (a). (c) sounds like the most feasible interim solution. Thanks Takeshi --bcaec517a9c24c70c404d104d124 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
H= i all,

Thanks for review.

Issues reported during WGLC (ended 2012/Nov/14) except for the ABNF confli= ct issue are already addressed and there's -05 staged (not posted yet.= =A0http://www.ietf.org/staging/draft-ietf-hybi-permessage-compre= ssion-05.txt).

=3D=3D=3D=3D=A0Resolved issues =3D=3D=3D=3D
<= br>
- Syntax/rules defined in RFC 2616 are used but not refe= renced
-- FIXED: Added references
- How endpoints should handle bad= values (ABNF violation, etc.) is unspecified
-- FIXED: Specified (ABNF violation -> ignore, wrong extension para= meter -> ignore)
- English grammar issues
-- FIXED
- Add an option to suppress compression on client-t= o-server data
-- WONT FIX: Didn't receive much support/justification.
=
- Clarified that the condition list defining bad method desc= riptions is OR list (any of them is true then bad)

=3D=3D=3D=3D Open issue =3D=3D=3D=3D

- = Conflict between "method" extension parameter spec and RFC 6455

Possible solutions are:

a) rev= ise=A0RFC 6455 by replacing constraint on quoted-string from "token&qu= ot; to CHAR - CTL
pros:
- human readable
cons= :
- needs very strong justification to change 6455
-- existing= implementations strictly conform to 6455 will "Fail" when method= parameter including space, semicolon, etc. instead of just rejecting the e= xtension
-- there might be any private-use extension that manipulates extension= s header assuming extension parameters conform to token after unquote
=

b) move the method parameter into a new separate handshake h= eader entry
pros:
- human readable
cons:
- introduce= s a new header not defined in 6455

c) use hex-enco= ding to token-ize the method parameter string (for compatibility, use metho= d_hex as the extension parameter name)
pros:
- just addition of well-known simple encoding. no chan= ge outside of Sec-WebSocket-Extensions header
cons:
- n= ot human readable

My thought:

I think it can be considered to be a bug that the token constraint is = making extension header hard to carry structured data. But as listed above,= there're difficulties to adopt (a).

(c) sound= s like the most feasible interim solution.

Thanks
Takeshi

--bcaec517a9c24c70c404d104d124-- From wwwrun@rfc-editor.org Tue Dec 18 10:10:15 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0681721F8AA5 for ; Tue, 18 Dec 2012 10:10:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.125 X-Spam-Level: X-Spam-Status: No, score=-102.125 tagged_above=-999 required=5 tests=[AWL=0.475, BAYES_00=-2.599, 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 IQFbVJH8L-qQ for ; Tue, 18 Dec 2012 10:10:14 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 5A7EB21F8A94 for ; Tue, 18 Dec 2012 10:10:13 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 4CB96B1E002; Tue, 18 Dec 2012 10:01:00 -0800 (PST) To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, presnick@qti.qualcomm.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com From: RFC Errata System Message-Id: <20121218180105.4CB96B1E002@rfc-editor.org> Date: Tue, 18 Dec 2012 10:01:00 -0800 (PST) Cc: e_lawrence@hotmail.com, hybi@ietf.org, rfc-editor@rfc-editor.org Subject: [hybi] [Technical Errata Reported] RFC6455 (3432) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 18 Dec 2012 18:10:15 -0000 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=6455&eid=3432 -------------------------------------- Type: Technical Reported by: Eric Lawrence Section: 5.7 Original Text ------------- o Unmasked Ping request and masked Ping response * 0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", but the contents of the body are arbitrary) * 0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 (contains a body of "Hello", matching the body of the ping) Corrected Text -------------- o Unmasked Ping request and masked Pong response * 0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", but the contents of the body are arbitrary) * 0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 (contains a body of "Hello", matching the body of the ping) Notes ----- The response isn't a Ping, it's a Pong. 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 From wwwrun@rfc-editor.org Thu Dec 20 16:11:48 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB97F21F8AA3 for ; Thu, 20 Dec 2012 16:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.187 X-Spam-Level: X-Spam-Status: No, score=-102.187 tagged_above=-999 required=5 tests=[AWL=0.413, BAYES_00=-2.599, 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 FXiu36TkgG2t for ; Thu, 20 Dec 2012 16:11:48 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDB321F8A9B for ; Thu, 20 Dec 2012 16:11:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 0EC14B1E002; Thu, 20 Dec 2012 16:02:31 -0800 (PST) To: ifette+ietf@google.com, Alexey.Melnikov@isode.com, barryleiba@computer.org, presnick@qti.qualcomm.com, Salvatore.Loreto@ericsson.com, Gabriel.Montenegro@microsoft.com From: RFC Errata System Message-Id: <20121221000236.0EC14B1E002@rfc-editor.org> Date: Thu, 20 Dec 2012 16:02:31 -0800 (PST) Cc: e_lawrence@hotmail.com, hybi@ietf.org, rfc-editor@rfc-editor.org Subject: [hybi] [Technical Errata Reported] RFC6455 (3433) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 21 Dec 2012 00:11:49 -0000 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=6455&eid=3433 -------------------------------------- Type: Technical Reported by: Eric Lawrence Section: 11.3.2 Original Text ------------- However, the |Sec-WebSocket-Extensions| header field MUST NOT appear more than once in an HTTP response. Corrected Text -------------- The |Sec-WebSocket-Extensions| header field MAY appear multiple times in an HTTP response (which is logically the same as a single |Sec-WebSocket-Extensions| header field that contains all values). Notes ----- Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains that this header field may appear multiple times in the server's response: "If multiple extensions are to be used, they can all be listed in a single |Sec-WebSocket-Extensions| header field or split between multiple instances of the |Sec-WebSocket-Extensions| header field. This completes the server's handshake..." 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 From tyoshino@google.com Thu Dec 20 20:41:36 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD1B21E8042 for ; Thu, 20 Dec 2012 20:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, 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 0yEGjq-36-pW for ; Thu, 20 Dec 2012 20:41:35 -0800 (PST) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7421E803F for ; Thu, 20 Dec 2012 20:41:35 -0800 (PST) Received: by mail-vb0-f54.google.com with SMTP id l1so4640525vba.41 for ; Thu, 20 Dec 2012 20:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=U9ZKFPpDjKtsSVewrxT89n3MtXEb5fUA9xiNtfG/6eI=; b=LH/K2Ln1WbvOizm/8UKnC8f9z7C79mq9ZTNyjPzy9wmEC/rytBUbr/SHXlx+T+IPih RSEHMfk5IajskerE5p/Mj+k0SfDTZDkipWcFMZfNLuVvLbyO7VW+j9qDen92uwM+byRE UueR0pB8ZS32TaX8NohvmINlxBkew3P9lrZnZ3UcaQ0ye8OUuFnmys2BbEwnO3Sog97l r/F1PgtumgH6ZGVP4TaNDHgXY9BRu9BfdGt+e86T6njnLcNnwhptW0e8iSZ0Indf33cQ Kl1rle3VWfY/9lu/v7W87hW8/J+A3Y3QtC6CxYAkXumWWfE/XSAcdDghJl9Myqk3U76j VSvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=U9ZKFPpDjKtsSVewrxT89n3MtXEb5fUA9xiNtfG/6eI=; b=DGXlLMgr+7goV6w10YKndz7Q2yyP3HLPAVdjF0UFGjItYFTiHG/u5X6zIMedNT4vjf dx7TettmiQT6qEZN/ccQeMOJUtjkNHGHBf8XkscvdY65XEtx4VqbqCCfXOXWwxEuKuCN uv0O5DPDj420f3GBrR85SqkEDdzQUhzj3xMRsxo68qkuYJxS95kGq64laqmIygapAiLT FOfugAp1RwvObmmJ2dzAifDosgGxW2bU7SKrGPXugmxwipZpcutzdHaZB8wgDMwm6uQo 3RCxEDLk/EgftUt6PHpHFZFq/SG7wF+BqJxU3Wwh/q5MPi48uaZpThrdelt2JROUadRr /r7w== Received: by 10.58.200.39 with SMTP id jp7mr18681129vec.26.1356064894860; Thu, 20 Dec 2012 20:41:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.212.137 with HTTP; Thu, 20 Dec 2012 20:41:14 -0800 (PST) In-Reply-To: <20121221000236.0EC14B1E002@rfc-editor.org> References: <20121221000236.0EC14B1E002@rfc-editor.org> From: Takeshi Yoshino Date: Fri, 21 Dec 2012 13:41:14 +0900 Message-ID: To: RFC Errata System Content-Type: multipart/alternative; boundary=047d7bdc06aa59bd1404d15576b0 X-Gm-Message-State: ALoCoQmAbrjaloYqxh7nf7LyxgSA1BhHjqKUIBzSyBOPLcVSVSry4B4AGZMMiWLJviWKlXsQk0MmgQ/H75C+udpn2ADwyRYHLGqN+Nj+wPsYgG0trGEtYSsl3R9Shi28RWCTQvEop7Sgf52NUtkb/YTGdh9gfH9+07T0Tvw4nF9kLGZg7OUVhlJiY6ctIrIxAO0A9RcOXhHW Cc: e_lawrence@hotmail.com, "hybi@ietf.org" , presnick@qti.qualcomm.com, "ifette+ietf@google.com" , Gabriel Montenegro , barryleiba@computer.org Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3433) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 21 Dec 2012 04:41:36 -0000 --047d7bdc06aa59bd1404d15576b0 Content-Type: text/plain; charset=ISO-8859-1 +1 Both "If multiple ..." and "However, the ..." were added from https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14. In the release note by Alexey ( http://www.ietf.org/mail-archive/web/hybi/current/msg08863.html), it's said > Clarified that some header fields can appear multiple times. (per WG discussion) This is the thread where the decision was made (multiple headers are allowed) http://www.ietf.org/mail-archive/web/hybi/current/msg08690.html I think it was just cut n' pasted but left not updated. IIRC, we didn't have any discussion to add asymmetric constraints like this. There were similar bug which was fixed on -15 release. http://www.ietf.org/mail-archive/web/hybi/current/msg09057.html Takeshi On Fri, Dec 21, 2012 at 9:02 AM, RFC Errata System < rfc-editor@rfc-editor.org> wrote: > > 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=6455&eid=3433 > > -------------------------------------- > Type: Technical > Reported by: Eric Lawrence > > Section: 11.3.2 > > Original Text > ------------- > However, the |Sec-WebSocket-Extensions| header field MUST NOT appear more > than once in an HTTP response. > > > Corrected Text > -------------- > The |Sec-WebSocket-Extensions| header field MAY appear multiple times in > an HTTP response (which is logically the same as a single > |Sec-WebSocket-Extensions| header field that contains all values). > > > Notes > ----- > Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains that this > header field may appear multiple times in the server's response: "If > multiple extensions are to be used, they can all be listed in a single > |Sec-WebSocket-Extensions| header field or split between multiple instances > of the |Sec-WebSocket-Extensions| header field. This completes the server's > handshake..." > > 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 > --047d7bdc06aa59bd1404d15576b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1

Both "If mu= ltiple ..." and "However, the ..." were added from=A0ht= tps://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14.

In the release note by Alexey (http://www.ietf.org/mail-archive= /web/hybi/current/msg08863.html),=A0it's said
> Clarif= ied that some header fields can appear multiple times. (per WG discussion)<= br>

This = is the thread where the decision was made (multiple headers are allowed)
http://www.ietf.org/mail-archive/web/hybi/cur= rent/msg08690.html=A0

I think it was just cut n' pasted but left not updated. IIRC, we didn&#= 39;t have any discussion to add asymmetric constraints like this.

There were simila= r bug which was fixed on -15 release.
http://www.ietf.org/mail-archive/web/hy= bi/current/msg09057.html=A0


Takeshi


On Fri, Dec 21, 2012 at 9:02 AM, RFC Err= ata System <rfc-editor@rfc-editor.org> wrote:

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=3D3433

--------------------------------------
Type: Technical
Reported by: Eric Lawrence <e_= lawrence@hotmail.com>

Section: 11.3.2

Original Text
-------------
However, the |Sec-WebSocket-Extensions| header field MUST NOT appear more t= han once in an HTTP response.


Corrected Text
--------------
The |Sec-WebSocket-Extensions| header field MAY appear multiple times in an= HTTP response (which is logically the same as a single |Sec-WebSocket-Exte= nsions| header field that contains all values).


Notes
-----
Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains that this = header field may appear multiple times in the server's response: "= If multiple extensions are to be used, they can all be listed in a single |= Sec-WebSocket-Extensions| header field or split between multiple instances = of the |Sec-WebSocket-Extensions| header field. This completes the server&#= 39;s handshake..."

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, plea= se
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 =A0 =A0 =A0 =A0 =A0 =A0 =A0 : The WebSocket Protocol
Publication Date =A0 =A0: December 2011
Author(s) =A0 =A0 =A0 =A0 =A0 : I. Fette, A. Melnikov
Category =A0 =A0 =A0 =A0 =A0 =A0: PROPOSED STANDARD
Source =A0 =A0 =A0 =A0 =A0 =A0 =A0: BiDirectional or Server-Initiated HTTP<= br> Area =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0: Applications
Stream =A0 =A0 =A0 =A0 =A0 =A0 =A0: IETF
Verifying Party =A0 =A0 : IESG
_______________________________________________
hybi mailing list
hybi@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/hybi

--047d7bdc06aa59bd1404d15576b0-- From alexey.melnikov@isode.com Sat Dec 22 01:56:34 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D2321F8B2B for ; Sat, 22 Dec 2012 01:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 dFVZQCDnLIIn for ; Sat, 22 Dec 2012 01:56:33 -0800 (PST) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 275E821F8B28 for ; Sat, 22 Dec 2012 01:56:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1356170185; d=isode.com; s=selector; i=@isode.com; bh=KXaY3NrTR4v4/b3vIn/Xt7YrJ0gLG9mtsm1nwQD02FA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fW0fIBvPy0wv8Dcfuw6mxez7a2TnpOIfji7EbTyOktdvl352zOkghjWiz/LfU8dLzfT2W5 k9VEHQnLnsPHYJYYvIy6HK+3uWb7kQN5bA8X937NEbW8J6QoouXlKsmS/tkBMreIYTCaFI YAoIyFVPK08cb/cE19zxDMPn4fDc8IM=; Received: from [192.168.1.4] (ppp95-165-96-64.pppoe.spdop.ru [95.165.96.64]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Sat, 22 Dec 2012 09:56:24 +0000 Message-ID: <50D583DC.9040003@isode.com> Date: Sat, 22 Dec 2012 09:56:44 +0000 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 To: Takeshi Yoshino , barryleiba@computer.org References: <20121221000236.0EC14B1E002@rfc-editor.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000108050104090902060601" Cc: e_lawrence@hotmail.com, "hybi@ietf.org" , presnick@qti.qualcomm.com, "ifette+ietf@google.com" , Gabriel Montenegro , RFC Errata System Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3433) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 22 Dec 2012 09:56:34 -0000 This is a multi-part message in MIME format. --------------000108050104090902060601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 21/12/2012 04:41, Takeshi Yoshino wrote: > +1 > > Both "If multiple ..." and "However, the ..." were added from > https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14. > > In the release note by Alexey > (http://www.ietf.org/mail-archive/web/hybi/current/msg08863.html), it's said > > Clarified that some header fields can appear multiple times. (per WG > discussion) > > This is the thread where the decision was made (multiple headers are > allowed) > http://www.ietf.org/mail-archive/web/hybi/current/msg08690.html > > I think it was just cut n' pasted but left not updated. IIRC, we > didn't have any discussion to add asymmetric constraints like this. > > There were similar bug which was fixed on -15 release. > http://www.ietf.org/mail-archive/web/hybi/current/msg09057.html Thanks, Takeshi. I agree that the erratum should be approved. > Takeshi > > > On Fri, Dec 21, 2012 at 9:02 AM, RFC Errata System > > wrote: > > > 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=6455&eid=3433 > > -------------------------------------- > Type: Technical > Reported by: Eric Lawrence > > > Section: 11.3.2 > > Original Text > ------------- > However, the |Sec-WebSocket-Extensions| header field MUST NOT > appear more than once in an HTTP response. > > > Corrected Text > -------------- > The |Sec-WebSocket-Extensions| header field MAY appear multiple > times in an HTTP response (which is logically the same as a single > |Sec-WebSocket-Extensions| header field that contains all values). > > > Notes > ----- > Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains > that this header field may appear multiple times in the server's > response: "If multiple extensions are to be used, they can all be > listed in a single |Sec-WebSocket-Extensions| header field or > split between multiple instances of the |Sec-WebSocket-Extensions| > header field. This completes the server's handshake..." > > 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 > > --------------000108050104090902060601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 21/12/2012 04:41, Takeshi Yoshino wrote:
+1

Both "If multiple ..." and "However, the ..." were added from https://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-14.

In the release note by Alexey (http://www.ietf.org/mail-archive/web/hybi/current/msg08863.html), it's said
> Clarified that some header fields can appear multiple times. (per WG discussion)

This is the thread where the decision was made (multiple headers are allowed)
http://www.ietf.org/mail-archive/web/hybi/current/msg08690.html 

I think it was just cut n' pasted but left not updated. IIRC, we didn't have any discussion to add asymmetric constraints like this.

There were similar bug which was fixed on -15 release.
http://www.ietf.org/mail-archive/web/hybi/current/msg09057.html

Thanks, Takeshi. I agree that the erratum should be approved.

Takeshi


On Fri, Dec 21, 2012 at 9:02 AM, RFC Errata System <rfc-editor@rfc-editor.org> wrote:

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=6455&eid=3433

--------------------------------------
Type: Technical
Reported by: Eric Lawrence <e_lawrence@hotmail.com>

Section: 11.3.2

Original Text
-------------
However, the |Sec-WebSocket-Extensions| header field MUST NOT appear more than once in an HTTP response.


Corrected Text
--------------
The |Sec-WebSocket-Extensions| header field MAY appear multiple times in an HTTP response (which is logically the same as a single |Sec-WebSocket-Extensions| header field that contains all values).


Notes
-----
Section 4.2.2 Step 5 subpart 6 (top of page 25) clearly explains that this header field may appear multiple times in the server's response: "If multiple extensions are to be used, they can all be listed in a single |Sec-WebSocket-Extensions| header field or split between multiple instances of the |Sec-WebSocket-Extensions| header field. This completes the server's handshake..."

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



--------------000108050104090902060601-- From barryleiba.mailing.lists@gmail.com Sat Dec 22 08:20:02 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A305121F8B11 for ; Sat, 22 Dec 2012 08:20:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.019 X-Spam-Level: X-Spam-Status: No, score=-103.019 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 fzMryK48jSaX for ; Sat, 22 Dec 2012 08:20:02 -0800 (PST) Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ietfa.amsl.com (Postfix) with ESMTP id B556821F8B03 for ; Sat, 22 Dec 2012 08:20:01 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id e4so6629049lag.24 for ; Sat, 22 Dec 2012 08:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=cqyLqBn+39igQcFdtOtPitWrmvDbvFlNpRDaPgYT1Dg=; b=Ej8BuvuJW2j/rZsDu6VNk21Nizarcof7WYzmpHavPjCEDm9SPQ1w0r3+guYbLb0eUO I/o8fsc19pF66Gg9mMzdiTSaipC0SeSFezUpbSDJQzGR9GvG//eq37bikjl7/OH1Zyxe a6FyU1mx1wN7IdAM6Vs0ol1+F2nDYNFKAqd1BLJ+AtsutUKPsFCs+tvx7xr5vqNMhjfc HV8zZ44Lie+Lhn5FPsZL7ECEP9Nrkfc4j0Cy3sY6yAWf6dqQofByRTqJBdYdJvv79lUS JCfuNDmTEDDxi/qgHQ70jtiP/ptf7DUGrY/59lMD7nKGyK4FG7G3JiApmedgvazGMd/B WuTg== MIME-Version: 1.0 Received: by 10.112.100.195 with SMTP id fa3mr6859149lbb.38.1356193200536; Sat, 22 Dec 2012 08:20:00 -0800 (PST) Sender: barryleiba.mailing.lists@gmail.com Received: by 10.112.12.166 with HTTP; Sat, 22 Dec 2012 08:20:00 -0800 (PST) In-Reply-To: <50D583DC.9040003@isode.com> References: <20121221000236.0EC14B1E002@rfc-editor.org> <50D583DC.9040003@isode.com> Date: Sat, 22 Dec 2012 11:20:00 -0500 X-Google-Sender-Auth: B9GYThiTaoMHMS4CORx7BAh5r7M Message-ID: From: Barry Leiba To: Alexey Melnikov Content-Type: text/plain; charset=ISO-8859-1 Cc: e_lawrence@hotmail.com, "hybi@ietf.org" , Pete Resnick , "ifette+ietf@google.com" , Gabriel Montenegro , RFC Errata System Subject: Re: [hybi] [Technical Errata Reported] RFC6455 (3433) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 22 Dec 2012 16:20:02 -0000 > Thanks, Takeshi. I agree that the erratum should be approved. And now it has been. Barry, responsible AD