Subject:	The MessageBroker WebSocket Subprotocol
Date:	Sun, 2 Oct 2011 00:33:52 +0200
From:	Hapner mark <hapner.mark@huawei.com>
To:	hybi@ietf.org <hybi@ietf.org>
CC:	csuconic@redhat.com <csuconic@redhat.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>

Subject:	The MessageBroker WebSocket Subprotocol
Date:	Sun, 2 Oct 2011 00:33:52 +0200
From:	Hapner mark <hapner.mark@huawei.com>
To:	hybi@ietf.= org <hybi@ietf.or= g>
CC:	csuc= onic@redhat.com <csuconic@redhat.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>

It wouldn't have = to be a new version of WebSockets, just a separate standard defining it.

For it to be useful, you would have to expose contro= l frame handling in the API. =C2=A0While there certainly are non-browser WS= clients, WS exists because of them (the others could just use TCP directly= ) and has to deal with potentially hostile JS. =C2=A0Opening up control fra= me processing by that hostile JS would require very careful consideration.<= /div>

Also, since once a frame is sent, you can't interje= ct a control frame into it until it is done, I don't know how effective= it would be unless the WS implementation specifically limited frame sizes.=

I'm not sure exactly what the need is, but if it is= for out-of-band messaging, then maybe a better idea would be to expose tha= t concept in the API, and then define a control frame for carrying out-of-b= and messages.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd6ecae054c3b04ae7b4062-- From clebert.suconic@gmail.com Tue Oct 4 09:08:43 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5355521F8DAD for ; Tue, 4 Oct 2011 09:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J8uLTuM6eMMN for ; Tue, 4 Oct 2011 09:08:42 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id B40A821F8DAC for ; Tue, 4 Oct 2011 09:08:42 -0700 (PDT) Received: by qadb12 with SMTP id b12so620034qad.31 for ; Tue, 04 Oct 2011 09:11:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Cmq4I8DD/pONlq7ItBNrP/hYGgJWZhpwghqBo++iC8k=; b=EH7wOVYZe39Ew44+mIZwu+/fELZD0ekgNXbLPkNKVCRKTgx2OVXI8xjeRQajD7vCbw id+vsZh+2HrNyJn8/Z9xAUTIJQ4YOYW8Dyu0Q9qXJXjO6+NOtJXQQ5B5/1WUfJd/gnoF TuzSwxZ8EBk2apZ2qiBAeM9NZTp+LElH6IvUI= MIME-Version: 1.0 Received: by 10.68.19.137 with SMTP id f9mr5583585pbe.93.1317744707829; Tue, 04 Oct 2011 09:11:47 -0700 (PDT) Received: by 10.142.237.19 with HTTP; Tue, 4 Oct 2011 09:11:47 -0700 (PDT) In-Reply-To: References: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx>

Date: Tue, 4 Oct 2011 09:11:47 -0700 Message-ID: From: Clebert Suconic To: John Tamplin Content-Type: multipart/alternative; boundary=bcaec530465736ff6b04ae7b59cb Cc: "hybi@ietf.org" , Hapner mark Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 04 Oct 2011 16:08:43 -0000 --bcaec530465736ff6b04ae7b59cb Content-Type: text/plain; charset=ISO-8859-1 > > Also, since once a frame is sent, you can't interject a control frame into > it until it is done, I don't know how effective it would be unless the WS > implementation specifically limited frame sizes. > > I'm not sure exactly what the need is, but if it is for out-of-band > messaging, then maybe a better idea would be to expose that concept in the > API, and then define a control frame for carrying out-of-band messages. > > Having the control frame exposed through the API would be great. That's actually something I asked here before we opened the standard... you will probably see it. --bcaec530465736ff6b04ae7b59cb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Also, since= once a frame is sent, you can't interject a control frame into it unti= l it is done, I don't know how effective it would be unless the WS impl= ementation specifically limited frame sizes.

I'm not sure exactly what the need is, but if it is= for out-of-band messaging, then maybe a better idea would be to expose tha= t concept in the API, and then define a control frame for carrying out-of-b= and messages.

Having the cont= rol frame exposed through the API would be great.

= That's actually something I asked here before we opened the standard...= you will probably see it.=A0

--bcaec530465736ff6b04ae7b59cb-- From jat@google.com Tue Oct 4 09:17:59 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3261B21F8CE3 for ; Tue, 4 Oct 2011 09:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.899 X-Spam-Level: X-Spam-Status: No, score=-105.899 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4of0tUoXRDIl for ; Tue, 4 Oct 2011 09:17:58 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 96F5121F8B38 for ; Tue, 4 Oct 2011 09:17:58 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p94GL3Z7012247 for ; Tue, 4 Oct 2011 09:21:03 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317745264; bh=uZbSjR1i1cspiNGwg5+YG7mtORw=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Sjqrufz3KJYN/OJnDKPzH7hBx3AfIc0pfs//tPs+qdnbKGJrLjjMjXaRNfUax8sVl WsFkuWd567g6hx7bUYacA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=M8tkz5e0Pqt/y2BIIsAsmNrhYJnpp66lfHa/X+hI2RSpvfZdbYU9VTUr6IM12mdtl Sq6Fpwu7d8kX6ps+823Mw== Received: from ywm21 (ywm21.prod.google.com [10.192.13.21]) by wpaz5.hot.corp.google.com with ESMTP id p94GKOsD018110 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 09:21:02 -0700 Received: by ywm21 with SMTP id 21so934695ywm.16 for ; Tue, 04 Oct 2011 09:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=dfkhE7aqr5kjlAUxxVzERnReU8vH6tgTVOmqEL+iTf8=; b=o8rJpes5KJWVAfC0ixCgKg50Uo9+DIq0YP95WzVpDF9Crxq5AXMxmk64AbQVqNBi0s TuwuJ4P1P943BjKM0z9g== Received: by 10.151.144.7 with SMTP id w7mr1375881ybn.59.1317745262704; Tue, 04 Oct 2011 09:21:02 -0700 (PDT) Received: by 10.151.144.7 with SMTP id w7mr1375873ybn.59.1317745262572; Tue, 04 Oct 2011 09:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 4 Oct 2011 09:20:41 -0700 (PDT) In-Reply-To: References: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx>

From: John Tamplin Date: Tue, 4 Oct 2011 12:20:41 -0400 Message-ID: To: Clebert Suconic Content-Type: multipart/alternative; boundary=0015174bed0647b76004ae7b7a69 X-System-Of-Record: true Cc: "hybi@ietf.org" , Hapner mark Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 04 Oct 2011 16:17:59 -0000 --0015174bed0647b76004ae7b7a69 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 4, 2011 at 12:11 PM, Clebert Suconic wrote: > Having the control frame exposed through the API would be great. > As mentioned, doing so would seem to open a lot of possibilities for abuse since the JS code must be assumed to be hostile. It would take some effort to determine what level of access should be granted and what checks to be performed. It is much easier to add later if warranted than to try and remove it after you discover it has problems. > That's actually something I asked here before we opened the standard... you > will probably see it. > Note that the API is not the developed in this group -- this group is about defining the wire protocol. -- John A. Tamplin Software Engineer (GWT), Google --0015174bed0647b76004ae7b7a69 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 12:11 PM, Clebert Suconic= <clebert= .suconic@gmail.com> wrote:

Having the control frame = exposed through the API would be great.

As mentioned, doing so would seem to open a lot of possibili= ties for abuse since the JS code must be assumed to be hostile. =C2=A0It wo= uld take some effort to determine what level of access should be granted an= d what checks to be performed. =C2=A0It is much easier to add later if warr= anted than to try and remove it after you discover it has problems.

=C2=A0

That's actually something I asked here before we opened the stand= ard... you will probably see it.=C2=A0

Note that the API is not the developed in this group= -- this group is about defining the wire protocol.

<= br>

--
John A. Tamplin
Software Engineer (GWT), Google
--0015174bed0647b76004ae7b7a69-- From ferg@caucho.com Tue Oct 4 09:22:38 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EB621F8C80 for ; Tue, 4 Oct 2011 09:22:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.328 X-Spam-Level: X-Spam-Status: No, score=-2.328 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJkaVG2sYPML for ; Tue, 4 Oct 2011 09:22:37 -0700 (PDT) Received: from nm15-vm0.bullet.mail.sp2.yahoo.com (nm15-vm0.bullet.mail.sp2.yahoo.com [98.139.91.208]) by ietfa.amsl.com (Postfix) with SMTP id 9726B21F8C76 for ; Tue, 4 Oct 2011 09:22:37 -0700 (PDT) Received: from [98.139.91.68] by nm15.bullet.mail.sp2.yahoo.com with NNFMP; 04 Oct 2011 16:25:43 -0000 Received: from [98.139.91.49] by tm8.bullet.mail.sp2.yahoo.com with NNFMP; 04 Oct 2011 16:25:43 -0000 Received: from [127.0.0.1] by omp1049.mail.sp2.yahoo.com with NNFMP; 04 Oct 2011 16:25:43 -0000 X-Yahoo-Newman-Id: 212524.87612.bm@omp1049.mail.sp2.yahoo.com Received: (qmail 3049 invoked from network); 4 Oct 2011 16:25:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1317745543; bh=hzW32gYnOp5ihKQg4intTbzq62fkAZnpym/Gdnql2Wc=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type; b=b8v5YTau8PjVjMKKsjdaTljhN8LSCvosfq3KhmbATPpJMyjrMDULl+9UE2EBkRhh+D7teziDgx7OJAPtFdQt13xB+xKbrlrxTdCaAavEagwD9vkrnKth+7a52O9ktg9q6cIndXRoXwl3MkuKAz9yATzCF7l+OPJjGNRuMjSIHYY= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: PxLxyxoVM1l9B.2DQ6UHNjM_LqUqyYg0ST5L1chcb.6tt.Q QdjFpQumEZSWHCuR_IrqNAOZPTGhs1D9kTJ9g0A0zlTRiwLBCs9EK2X_iv_r U6ZXPPC4N2KQiFQmQa9go3pX31jBHfhJE2j_9obEYk3CYyNER8PSq0PXICAt 7vIssB93x1CS8KilH6WU2FJOGUDRT73lbI0gHyqSei1rKfNNRWuL8VwbX3qk kGsa9PzU72sgx6CaVnnW.EtzwvMatlnwNwIFAhrl9BJPXSlJ_PqGwq7epiSL XwgdjNikywhD25k60iQON3TbXXP9CS0xJ5O62k_.9RH1YYSNxKR.noIcRMqw ZXOA2EvPzzMjKv4C1be5srfPxa2Nd.w2rZXZ6hZk7oVodQ5EEGGGxVvb7jYT .HbNc7xz84DYnfsj8bjbB.odrPMoL X-Yahoo-SMTP: L1_TBRiswBB5.MuzAo8Yf89wczFo0A2C Received: from [192.168.1.11] (ferg@66.92.8.203 with plain) by smtp115.biz.mail.sp1.yahoo.com with SMTP; 04 Oct 2011 09:25:42 -0700 PDT Message-ID: <4E8B3380.1080204@caucho.com> Date: Tue, 04 Oct 2011 09:25:36 -0700 From: Scott Ferguson User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: hybi@ietf.org References: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx>

In-Reply-To: Content-Type: multipart/alternative; boundary="------------060600040204010903090907" Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 04 Oct 2011 16:22:38 -0000 This is a multi-part message in MIME format. --------------060600040204010903090907 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 10/04/2011 09:11 AM, Clebert Suconic wrote: > > Also, since once a frame is sent, you can't interject a control > frame into it until it is done, I don't know how effective it > would be unless the WS implementation specifically limited frame > sizes. > > I'm not sure exactly what the need is, but if it is for > out-of-band messaging, then maybe a better idea would be to expose > that concept in the API, and then define a control frame for > carrying out-of-band messages. > > > Having the control frame exposed through the API would be great. Remember, though, that your application protocol can define messages however it wants. Some of those messages can be control messages. And some of those messages can be fragments. As an example, you could build an entire muxing layer as a subprotocol, not an extension. That subprotocol's WebSocket messages might be fragments of a larger file. Or a streaming video service, where each WebSocket message is a chunk of a video stream, interlaced with streaming control messages. Neither of those control messages need to have anything to do with a WebSocket control frame. I'd think layering sub-protocols on top of WebSockets would be a better approach for now, instead of trying to make everything an extension. -- Scott > > That's actually something I asked here before we opened the > standard... you will probably see it. > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --------------060600040204010903090907 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 10/04/2011 09:11 AM, Clebert Suconic wrote:

Also, since once a frame is sent, you can't interject a control frame into it until it is done, I don't know how effective it would be unless the WS implementation specifically limited frame sizes.

I'm not sure exactly what the need is, but if it is for out-of-band messaging, then maybe a better idea would be to expose that concept in the API, and then define a control frame for carrying out-of-band messages.

Having the control frame exposed through the API would be great.

Remember, though, that your application protocol can define messages however it wants. Some of those messages can be control messages. And some of those messages can be fragments.

As an example, you could build an entire muxing layer as a subprotocol, not an extension. That subprotocol's WebSocket messages might be fragments of a larger file. Or a streaming video service, where each WebSocket message is a chunk of a video stream, interlaced with streaming control messages. Neither of those control messages need to have anything to do with a WebSocket control frame.

I'd think layering sub-protocols on top of WebSockets would be a better approach for now, instead of trying to make everything an extension.

-- Scott

That's actually something I asked here before we opened the standard... you will probably see it.
_______________________________________________
hybi mailing list
hybi@ietf.org
https://www.ietf.org/mailman/listinfo/hybi

--------------060600040204010903090907-- From clebert.suconic@gmail.com Tue Oct 4 09:29:39 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F6F121F8B76 for ; Tue, 4 Oct 2011 09:29:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+6mZVlbtUCv for ; Tue, 4 Oct 2011 09:29:38 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8693421F8B71 for ; Tue, 4 Oct 2011 09:29:38 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so684427vcb.31 for ; Tue, 04 Oct 2011 09:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=frf83Gpa+t8Q5E4Fhy4cWFMvKTOgEv6/bI3sUORO87A=; b=a2IccuzSZ+pBI1TEd4+OoawowmRX4DYD9MM/QK/puUBYYyARsJNjxsabDUCvLZKT2O KXt7v/ID/p79hZg4gse5sGm6E7M176qS4tI6a6jG4KIcX0Y5r6cvt4Em3gabNO8VZgzR 6eCHCjh8HzrcrGkcuEyCeqRk5eNRrKXaP4kJ0= MIME-Version: 1.0 Received: by 10.68.15.34 with SMTP id u2mr10787501pbc.59.1317745963315; Tue, 04 Oct 2011 09:32:43 -0700 (PDT) Received: by 10.142.237.19 with HTTP; Tue, 4 Oct 2011 09:32:43 -0700 (PDT) In-Reply-To: <4E8B3380.1080204@caucho.com> References: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx>

<4E8B3380.1080204@caucho.com> Date: Tue, 4 Oct 2011 09:32:43 -0700 Message-ID: From: Clebert Suconic To: Scott Ferguson Content-Type: multipart/alternative; boundary=bcaec520e5e30c313b04ae7ba483 Cc: hybi@ietf.org Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 04 Oct 2011 16:29:39 -0000 --bcaec520e5e30c313b04ae7ba483 Content-Type: text/plain; charset=ISO-8859-1 > > Remember, though, that your application protocol can define messages > however it wants. Some of those messages can be control messages. And some > of those messages can be fragments. > > As an example, you could build an entire muxing layer as a subprotocol, not > an extension. That subprotocol's WebSocket messages might be fragments of a > larger file. Or a streaming video service, where each WebSocket message is a > chunk of a video stream, interlaced with streaming control messages. Neither > of those control messages need to have anything to do with a WebSocket > control frame. > > I'd think layering sub-protocols on top of WebSockets would be a better > approach for now, instead of trying to make everything an extension. > > I don't think there's another option with the current state of the web socket API on the browser. but I'm not sure if that's the ideal (I will have to hear from Mark Hapner when he's back). I have heard from Mark that there is at least one WebSocket implementations that will expose the control frame but that's meant for a server's side. But the protocol has to take care of the Web Browser as well. --bcaec520e5e30c313b04ae7ba483 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Remember, though, that your application protocol = can define messages however it wants. Some of those messages can be control messages. And some of those messages can be fragments.

As an example, you could build an entire muxing layer as a subprotocol, not an extension. That subprotocol's WebSocket message= s might be fragments of a larger file. Or a streaming video service, where each WebSocket message is a chunk of a video stream, interlaced with streaming control messages. Neither of those control messages need to have anything to do with a WebSocket control frame.
I'd think layering sub-protocols on top of WebSockets would be a better approach for now, instead of trying to make everything an extension.

I don't th= ink there's another option with the current state of the web socket API= on the browser. but I'm not sure if that's the ideal (I will have = to hear from Mark Hapner when he's back).

I have heard from Mark that there is at least one WebSo= cket implementations that will expose the control frame but that's mean= t for a server's side. But the protocol has to take care of the Web Bro= wser as well.

--bcaec520e5e30c313b04ae7ba483-- From hapner.mark@huawei.com Tue Oct 4 13:20:14 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CD021F8DE8 for ; Tue, 4 Oct 2011 13:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.804 X-Spam-Level: X-Spam-Status: No, score=-6.804 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0XnGjwzWEqj for ; Tue, 4 Oct 2011 13:20:13 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id B354921F8DE2 for ; Tue, 4 Oct 2011 13:20:13 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK0025Y5YVI9@usaga04-in.huawei.com> for hybi@ietf.org; Tue, 04 Oct 2011 15:23:19 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00BP55YUO9@usaga04-in.huawei.com> for hybi@ietf.org; Tue, 04 Oct 2011 15:23:19 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 04 Oct 2011 13:23:19 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 04 Oct 2011 13:23:09 -0700 Date: Tue, 04 Oct 2011 20:23:08 +0000 From: Hapner mark X-Originating-IP: [172.18.9.109] To: "hybi@ietf.org" Message-id: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_2qXUji/0O6/Qzx2tDV2k8w)" Content-language: en-US Accept-Language: en-US Thread-topic: Subprotocol and Control Frames Thread-index: AcyCzo83r27v+PhnTw6E8yG0xmwZAA== X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:20:14 -0000 --Boundary_(ID_2qXUji/0O6/Qzx2tDV2k8w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT In my reading of draft 17, I do not find a definition of subprotocol that puts any restrictions on the WebSocket extensibility features a subprotocol may use. If the sense of the WG is that subprotocols are restricted to use only extension data and message format/schema restrictions, this is not apparent in the content of this draft. It is my observation that there will be a number of WebSocket usecases that could benefit from the ability to define usecase-specific control frames to mediate message flow. Telling developers to stuff this mediation protocol into extension data rather than in control frames does not appear to increase security; rather, it likely decreases security because it intermixes control with data which is a fundamentally bad thing for a protocol design to do. The two control frames defined by MBWS are fairly simple and are likely representative of what other subprotocols would need. It would be far better to allow MBWS to properly factor its control and data than force it to put control in its data. It is true that TCP does not support application control extension; however, HTTP clearly does support this with a very open-ended extension of the HTTP header. The WG needs to think carefully about this. I hope there is room to resolve this issue in this version of WebSocket. It is up to the W3C WebSocket API to insure it provides the functionality that both native users of WebSocket and implementors of WebSocket subprotocols require. In looking over what is currently defined, this API does not yet provide an API sufficient for the later. Possibly later it will. I don't believe that the design of WebSocket needs to be restricted by the current limitations of this API. --Boundary_(ID_2qXUji/0O6/Qzx2tDV2k8w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

In my reading of draft 17, I do not find a definition of subprotocol that puts any restrictions on the WebSocket extensibility features a subprotocol may use. If the sense of the WG is that subprotocols are restricted to use only extension data and message format/schema restrictions, this is not apparent in the content of this draft.

It is my observation that there will be a number of WebSocket usecases that could benefit from the ability to define usecase-specific control frames to mediate message flow. Telling developers to stuff this mediation protocol into extension data rather than in control frames does not appear to increase security; rather, it likely decreases security because it intermixes control with data which is a fundamentally bad thing for a protocol design to do.

The two control frames defined by MBWS are fairly simple and are likely representative of what other subprotocols would need. It would be far better to allow MBWS to properly factor its control and data than force it to put control in its data.

It is true that TCP does not support application control extension; however, HTTP clearly does support this with a very open-ended extension of the HTTP header. The WG needs to think carefully about this. I hope there is room to resolve this issue in this version of WebSocket.

It is up to the W3C WebSocket API to insure it provides the functionality that both native users of WebSocket and implementors of WebSocket subprotocols require. In looking over what is currently defined, this API does not yet provide an API sufficient for the later. Possibly later it will. I don't believe that the design of WebSocket needs to be restricted by the current limitations of this API.

--Boundary_(ID_2qXUji/0O6/Qzx2tDV2k8w)-- From jat@google.com Tue Oct 4 13:30:50 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79FA121F8F76 for ; Tue, 4 Oct 2011 13:30:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.901 X-Spam-Level: X-Spam-Status: No, score=-105.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_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRO8gaT7yYlE for ; Tue, 4 Oct 2011 13:30:49 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9D35621F8F75 for ; Tue, 4 Oct 2011 13:30:49 -0700 (PDT) Received: from hpaq13.eem.corp.google.com (hpaq13.eem.corp.google.com [172.25.149.13]) by smtp-out.google.com with ESMTP id p94KXspo000602 for ; Tue, 4 Oct 2011 13:33:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317760435; bh=7/5PXVGLvYhEcje/YCMpholV2nk=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=mI0FFXCyvDPviu34OU6ujzWEraxkUYObMylfR++UZ9fVfwt7H+g1zSWxb7jMAHNFr d2Ahi0LXSqvw3FsbcuiLw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=iWeGw2v/yrP+chyhwcxA3qx4sJg5cpYBRuax7Nxuoq4XF40F4c5MXMoIVxcjIALWr 6zu3ORWjTo0acIqjLXBJQ== Received: from yxi11 (yxi11.prod.google.com [10.190.3.11]) by hpaq13.eem.corp.google.com with ESMTP id p94KXVhA016846 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 4 Oct 2011 13:33:53 -0700 Received: by yxi11 with SMTP id 11so1290286yxi.22 for ; Tue, 04 Oct 2011 13:33:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=2AxiI+E38fCNZy/ViqjkGVV2tSJsSPFE11WgiLTN7ag=; b=gwgVUG/Avg4NG9X2PJVSaQ62DLgZepzkBpHTd5YI6zZFoyl5RrWwdXYl8XV3yFTgoh 6eDdzWbqaiqOXWw/n8SQ== Received: by 10.150.73.41 with SMTP id v41mr1610635yba.230.1317760433313; Tue, 04 Oct 2011 13:33:53 -0700 (PDT) Received: by 10.150.73.41 with SMTP id v41mr1610631yba.230.1317760433141; Tue, 04 Oct 2011 13:33:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 4 Oct 2011 13:33:33 -0700 (PDT) In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> From: John Tamplin Date: Tue, 4 Oct 2011 16:33:33 -0400 Message-ID: To: Hapner mark Content-Type: multipart/alternative; boundary=000e0cd5914684388604ae7f02eb X-System-Of-Record: true Cc: "hybi@ietf.org" Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 20:30:50 -0000 --000e0cd5914684388604ae7f02eb Content-Type: text/plain; charset=UTF-8 On Tue, Oct 4, 2011 at 4:23 PM, Hapner mark wrote: > > In my reading of draft 17, I do not find a definition of subprotocol that > puts any restrictions on the WebSocket extensibility features a subprotocol > may use. If the sense of the WG is that subprotocols are restricted to use > only extension data and message format/schema restrictions, this is not > apparent in the content of this draft. > So where do you see that a subprotocol may define new opcodes or change the framing? There are an infinite number of things the spec doesn't say can't be done. > It is my observation that there will be a number of WebSocket usecases > that could benefit from the ability to define usecase-specific control > frames to mediate message flow. Telling developers to stuff this mediation > protocol into extension data rather than in control frames does not appear > to increase security; rather, it likely decreases security because it > intermixes control with data which is a fundamentally bad thing for a > protocol design to do. > WS control frames are there for WS implementations, not for higher-level protocols. Similarly, you can't directly control ICMP frames from your UDP connection. If you want your own control frames, you layer them on top of the lower level protocols. > The two control frames defined by MBWS are fairly simple and are likely > representative of what other subprotocols would need. It would be far better > to allow MBWS to properly factor its control and data than force it to put > control in its data. > There are very few available opcodes. If every subprotocol allocates a couple that it needs, there won't be many subprotocols. > It is true that TCP does not support application control extension; > however, HTTP clearly does support this with a very open-ended extension of > the HTTP header. The WG needs to think carefully about this. I hope there is > room to resolve this issue in this version of WebSocket. > HTTP doesn't send a separate control frame, it is sent as a prefix to the higher-level payload, exactly as we are suggesting you do. > It is up to the W3C WebSocket API to insure it provides the functionality > that both native users of WebSocket and implementors of WebSocket > subprotocols require. In looking over what is currently defined, this API > does not yet provide an API sufficient for the later. Possibly later it > will. I don't believe that the design of WebSocket needs to be restricted by > the current limitations of this API. > There are many examples where the protocol is not restricted by the API -- for example, the JS API did not even support binary frames when they were present in the wire protocol. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd5914684388604ae7f02eb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 4:23 PM, Hapner mark <hapner.mark@hua= wei.com> wrote:

In my reading of draft 17, I do not find a definition of subprotocol t= hat puts any restrictions on the WebSocket extensibility features a subprot= ocol may use. If the sense of the WG is that subprotocols are restricted to= use only extension data and message format/schema restrictions, this is not apparent in the content of this dr= aft.

So where do you see = that a subprotocol may define new opcodes or change the framing? =C2=A0Ther= e are an infinite number of things the spec doesn't say can't be do= ne.

=C2=A0

It is my observation that there will be a number of WebSocket usecases= that could benefit from the ability to define usecase-specific control fra= mes to mediate message flow. Telling developers to stuff this mediation pro= tocol into extension data rather than in control frames does not appear to increase security; rather, it li= kely decreases security because it intermixes control with data which is a = fundamentally bad thing for a protocol design to do.

WS control frames are there for WS impleme= ntations, not for higher-level protocols. =C2=A0Similarly, you can't di= rectly control ICMP frames from your UDP connection. =C2=A0If you want your= own control frames, you layer them on top of the lower level protocols.

=C2=A0

The two control frames defined by MBWS are fairly simple and are likel= y representative of what other subprotocols would need. It would be far bet= ter to allow MBWS to properly factor its control and data than force it to = put control in its data.=C2=A0

There are very few available o= pcodes. =C2=A0If every subprotocol allocates a couple that it needs, there = won't be many subprotocols.

=C2=A0

It is true that TCP does not support application control extension; ho= wever, HTTP clearly does support this with a very open-ended extension of t= he HTTP header. The WG needs to think carefully about this. I hope there is= room to resolve this issue in this version of WebSocket.=C2=A0

<= div>HTTP doesn't send a separate control frame, it is sent as a prefix = to the higher-level payload, exactly as we are suggesting you do.

=C2=A0

It is up to the W3C WebSocket API to insure it provides the functional= ity that both native users of WebSocket and implementors of WebSocket subpr= otocols require. In looking over what is currently defined, this API does n= ot yet provide an API sufficient for the later. Possibly later it will. I don't believe that the design= of WebSocket needs to be restricted by the current limitations of this API= .

There are many examples= where the protocol is not restricted by the API -- for example, the JS API= did not even support binary frames when they were present in the wire prot= ocol.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd5914684388604ae7f02eb-- From gregw@intalio.com Tue Oct 4 15:16:32 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180ED21F8E97 for ; Tue, 4 Oct 2011 15:16:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.919 X-Spam-Level: X-Spam-Status: No, score=-2.919 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvB2EIF-befl for ; Tue, 4 Oct 2011 15:16:31 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 33A1B21F8E88 for ; Tue, 4 Oct 2011 15:16:30 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1067062vcb.31 for ; Tue, 04 Oct 2011 15:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.97.193 with SMTP id ec1mr1715245vdb.69.1317766776866; Tue, 04 Oct 2011 15:19:36 -0700 (PDT) Received: by 10.52.186.134 with HTTP; Tue, 4 Oct 2011 15:19:36 -0700 (PDT) In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> Date: Wed, 5 Oct 2011 09:19:36 +1100 Message-ID: From: Greg Wilkins To: Hapner mark Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Oct 2011 22:16:32 -0000 On 5 October 2011 07:23, Hapner mark wrote: > > In my reading of draft 17, I do not find a definition of subprotocol that > puts any restrictions on the WebSocket extensibility features a subprotocol > may use. Mark, in section 5.8 Extensibility: This specification provides opcodes 0x3 through 0x7 and 0xB through 0xF, the extension data field, and the frame-rsv1, frame- rsv2, and frame-rsv3 bits of the frame header for use by extensions. So while there is no explicit restriction on subprotocols using opcodes, the only allowance given is to extensions. > If the sense of the WG is that subprotocols are restricted to use > only extension data and message format/schema restrictions, this is not > apparent in the content of this draft. The specification also describes subprotocols in section 1.3 as ... used to indicate what subprotocols (application-level protocols layered over the WebSocket protocol) are acceptable to the client. > It is my observation that there will be a number of WebSocket usecases that > could benefit from the ability to define usecase-specific control frames to > mediate message flow. Telling developers to stuff this mediation protocol > into extension data rather than in control frames does not appear to > increase security; Firstly subprotocols can no more use extensions data than they can use extension opcodes. They can however use the payload and are free to define arbitrary message semantics within that payload that may include application control messages. The restriction of subprotocols to not use opcodes is not done for security. It is done for protocol layering reasons. The opcode is there to inform the WS implementation (and it's extensions) how to handle the message. There is no application semantics associated with any of the opcodes. For example the text vs binary opcodes instructs the implementation if UTF-8 decoding is required and to which part of the websocket API a message should be delivered. There is no semantic restriction imposed by a binary message, which may actually be a text message, but one for which the application or subprotocol has taken responsibility for character encoding. > rather, it likely decreases security because it > intermixes control with data which is a fundamentally bad thing for a > protocol design to do. The two control frames defined by MBWS are fairly simple and are likely > representative of what other subprotocols would need. It would be far better > to allow MBWS to properly factor its control and data than force it to put > control in its data. Indeed there is a limitation in the current protocol of providing only a single stream per connection, so there can be no separation of control/data on a single connection. However the solution is not to allow applications to put their control messages into the protocols control stream, but rather to better support multiple streams - ie MUX. For the protocol, it is clear that there are two streams of frames: data and control, but there is no reason why this taxonomy will apply generally to all applications and subprotocols. There may be use cases where applications/subprotocols need n streams or control frames larger than 125 bytes. The solution is to not see that the protocols control frame mechanism is somewhat like the applications need for control messages and thus to attempt to expose the protocols control channel to the application. The solution is to allow applications to efficiently create their own control channels - MUX! > It is true that TCP does not support application control extension; however, > HTTP clearly does support this with a very open-ended extension of the HTTP > header. The WG needs to think carefully about this. I hope there is room to > resolve this issue in this version of WebSocket. > It is up to the W3C WebSocket API to insure it provides the functionality > that both native users of WebSocket and implementors of WebSocket > subprotocols require. In looking over what is currently defined, this API > does not yet provide an API sufficient for the later. Possibly later it > will. I don't believe that the design of WebSocket needs to be restricted by > the current limitations of this API. This distinction between extensions and subprotocols has not been made because of any API limitations. It has been done for good protocol layering reasons. Consider if we open up the control channel to applications, then this will make the task of creating things like MUX extensions much more difficult. The mux solution would have to allow for extending control frames with extension data so that they may be correctly routed to the right application control channel. But if a 125 byte application control frame is sent, then there may not be sufficient room to add the channel identifier! Also if control frames are used to implement MUX flow control, will applications use their application control frames to attempt to get around this flow control? We may end up needing to put flow control on the control channel to limit the number of application control frames. Mixing application control frames with protocol control frames is a far worse "solution" than mixing application control messages with application data messages. regards From duerst@it.aoyama.ac.jp Tue Oct 4 18:11:40 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9C21F8D0D for ; Tue, 4 Oct 2011 18:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.738 X-Spam-Level: X-Spam-Status: No, score=-99.738 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yU8WHcFxLdGk for ; Tue, 4 Oct 2011 18:11:39 -0700 (PDT) Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8EE21F8D0C for ; Tue, 4 Oct 2011 18:11:38 -0700 (PDT) Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id p951EZJr027882 for ; Wed, 5 Oct 2011 10:14:35 +0900 Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 5b9f_2c4e_63941cc6_eeef_11e0_b296_001d096c5782; Wed, 05 Oct 2011 10:14:35 +0900 Received: from [IPv6:::1] ([133.2.210.1]:44098) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id for from ; Wed, 5 Oct 2011 10:14:39 +0900 Message-ID: <4E8BAF77.9060600@it.aoyama.ac.jp> Date: Wed, 05 Oct 2011 10:14:31 +0900 From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Organization: Aoyama Gakuin University User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4 MIME-Version: 1.0 To: Greg Wilkins References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , Hapner mark Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:11:40 -0000 Hello Mark, others, I think you are working on some great stuff, but I very much agree with John and Greg and the many others who have clearly explained that options are for extensions and not for subprotocols (and Greg even found the text in the spec that says so). It would be really great if you gave WebSockets a chance to be deployed and used as designed in the WG. This means that when you design a subprotocol, you just pretend that there are no more free option bits available (just the same as in TCP). If you really, really can't get things to work that way (which I highly doubt), please ask this WG for further advice. We can always change things in a future version of WebSockets if we see a really strong need to do so. But for the moment, we would really strongly prefer to get experience with WebSockets as designed and as described in the spec. Many thanks in advance! Regards, Martin. On 2011/10/05 7:19, Greg Wilkins wrote: > On 5 October 2011 07:23, Hapner mark wrote: >> >> In my reading of draft 17, I do not find a definition of subprotocol that >> puts any restrictions on the WebSocket extensibility features a subprotocol >> may use. > > Mark, > > in section 5.8 Extensibility: > > This specification provides opcodes 0x3 through 0x7 and > 0xB through 0xF, the extension data field, and the frame-rsv1, frame- > rsv2, and frame-rsv3 bits of the frame header for use by extensions. > > So while there is no explicit restriction on subprotocols using > opcodes, the only allowance given is to extensions. > >> If the sense of the WG is that subprotocols are restricted to use >> only extension data and message format/schema restrictions, this is not >> apparent in the content of this draft. > > The specification also describes subprotocols in section 1.3 as > > ... used to indicate what subprotocols (application-level protocols > layered over the WebSocket protocol) are acceptable to the client. > > >> It is my observation that there will be a number of WebSocket usecases that >> could benefit from the ability to define usecase-specific control frames to >> mediate message flow. Telling developers to stuff this mediation protocol >> into extension data rather than in control frames does not appear to >> increase security; > > Firstly subprotocols can no more use extensions data than they can use > extension opcodes. > They can however use the payload and are free to define arbitrary > message semantics within that payload that may include application > control messages. > > The restriction of subprotocols to not use opcodes is not done for > security. It is done for protocol layering reasons. > The opcode is there to inform the WS implementation (and it's > extensions) how to handle the message. There is no application > semantics associated with any of the opcodes. For example the text vs > binary opcodes instructs the implementation if UTF-8 decoding is > required and to which part of the websocket API a message should be > delivered. There is no semantic restriction imposed by a binary > message, which may actually be a text message, but one for which the > application or subprotocol has taken responsibility for character > encoding. > >> rather, it likely decreases security because it >> intermixes control with data which is a fundamentally bad thing for a >> protocol design to do. The two control frames defined by MBWS are fairly simple and are likely >> representative of what other subprotocols would need. It would be far better >> to allow MBWS to properly factor its control and data than force it to put >> control in its data. > > Indeed there is a limitation in the current protocol of providing only > a single stream per connection, so there can be no separation of > control/data on a single connection. However the solution is not to > allow applications to put their control messages into the protocols > control stream, but rather to better support multiple streams - ie > MUX. For the protocol, it is clear that there are two streams of > frames: data and control, but there is no reason why this taxonomy > will apply generally to all applications and subprotocols. There may > be use cases where applications/subprotocols need n streams or control > frames larger than 125 bytes. > > The solution is to not see that the protocols control frame mechanism > is somewhat like the applications need for control messages and thus > to attempt to expose the protocols control channel to the application. > The solution is to allow applications to efficiently create their own > control channels - MUX! > > >> It is true that TCP does not support application control extension; however, >> HTTP clearly does support this with a very open-ended extension of the HTTP >> header. The WG needs to think carefully about this. I hope there is room to >> resolve this issue in this version of WebSocket. >> It is up to the W3C WebSocket API to insure it provides the functionality >> that both native users of WebSocket and implementors of WebSocket >> subprotocols require. In looking over what is currently defined, this API >> does not yet provide an API sufficient for the later. Possibly later it >> will. I don't believe that the design of WebSocket needs to be restricted by >> the current limitations of this API. > > This distinction between extensions and subprotocols has not been made > because of any API limitations. It has been done for good protocol > layering reasons. > > Consider if we open up the control channel to applications, then this > will make the task of creating things like MUX extensions much more > difficult. The mux solution would have to allow for extending control > frames with extension data so that they may be correctly routed to the > right application control channel. But if a 125 byte application > control frame is sent, then there may not be sufficient room to add > the channel identifier! Also if control frames are used to > implement MUX flow control, will applications use their application > control frames to attempt to get around this flow control? We may end > up needing to put flow control on the control channel to limit the > number of application control frames. > > Mixing application control frames with protocol control frames is a > far worse "solution" than mixing application control messages with > application data messages. > > regards > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From hapner.mark@huawei.com Tue Oct 4 18:33:28 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8647621F8D44 for ; Tue, 4 Oct 2011 18:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.784 X-Spam-Level: X-Spam-Status: No, score=-6.784 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BnVbytbddeuy for ; Tue, 4 Oct 2011 18:33:27 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 6F66F21F8D22 for ; Tue, 4 Oct 2011 18:33:27 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00J14KGX41@usaga02-in.huawei.com> for hybi@ietf.org; Tue, 04 Oct 2011 20:36:33 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LSK00DHXKGW9K@usaga02-in.huawei.com> for hybi@ietf.org; Tue, 04 Oct 2011 20:36:33 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 04 Oct 2011 18:36:33 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Tue, 04 Oct 2011 18:36:27 -0700 Date: Wed, 05 Oct 2011 01:36:26 +0000 From: Hapner mark In-reply-to: X-Originating-IP: [172.18.9.109] To: Greg Wilkins Message-id: <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [hybi] Subprotocol and Control Frames Thread-index: AcyCzo83r27v+PhnTw6E8yG0xmwZAAAT9AwA//+gz2U= X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> Cc: "hybi@ietf.org" Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:33:28 -0000 Thanks for everyone's comments. Clebert and I are learning as we go ... Greg, Thanks for the clarifications ... I agree that MBWS could define its own framing protocol within the WebSocket message payload, i.e. MBWS could be defined as a WebSocket subprotocol. (Sorry for my original confabulation of subprotocol and extension) The option also exists to implement MBWS as it is currently defined as a WebSocket extension that adds extension data and extension control frame opcodes. WebSocket provides support for both subprotocols and extensions and I believe both are available for use by outside parties as long as the IANA registration mechanisms are followed. Is this correct? My primary concern is that implementing MBWS as a subprotocol will add complexity and overhead. The only rationale I can see for defining MBWS as a subprotocol would be if, for some reason, browsers/proxies/firewalls blocked WebSocket extensions, i.e. MBWS has to use a 'subprotocol tunnel' through them. The core point in favor of using an extension is that WebSocket already defines an excellent framing protocol. There is simply no need for MBWS to layer yet another framing protocol over it. It would be equivalent to a REST service defining a request-response framing protocol within the HTTP request-response body when all it needed was to add a few new header fields. Let me see, I think I remember this being done, it was called WS* :>) The point about control frame opcodes being 'scarce' is an issue; however, the spec already suggests the use of an extension bit to resolve this. The spec does not describe how the opcode space will be distributed across extensions. It does not say whether or not an extension opcode value can be 'redefined' by different extensions. Since a session can only be operating under one extension, there does not appear to be a technical reason why extensions could not redefine extension opcodes. If this is possible, then MBWS does not 'use up' any extension opcodes. Perhaps the fact that WebSocket itself does not reserve any of the opcode extension space for itself is an issue. There seems to be an implication in the comments so far that, in effect, they are all reserved and none are available for 'outside' use. I don't believe this is the case. I think subprotocols and extensions are both useful. For an application specific case, say the transport of Insurance Policies and Quotes, defining a subprotocol for transport of this Insurance Message Schema would be sensible. I believe that MBWS is case where the use of an extension is sensible. Again, I think this issue is worthy of some serious debate. I'm not ready to concede, as yet, that defining MBWS as a WebSocket extension is wrong. -- Mark >On 5 October 2011 07:23, Hapner mark wrote: >> >> In my reading of draft 17, I do not find a definition of subprotocol that >> puts any restrictions on the WebSocket extensibility features a subprotocol >> may use. > >Mark, > >in section 5.8 Extensibility: > > This specification provides opcodes 0x3 through 0x7 and > 0xB through 0xF, the extension data field, and the frame-rsv1, frame- > rsv2, and frame-rsv3 bits of the frame header for use by extensions. > >So while there is no explicit restriction on subprotocols using >opcodes, the only allowance given is to extensions. > >> If the sense of the WG is that subprotocols are restricted to use >> only extension data and message format/schema restrictions, this is not >> apparent in the content of this draft. > >The specification also describes subprotocols in section 1.3 as > > ... used to indicate what subprotocols (application-level protocols > layered over the WebSocket protocol) are acceptable to the client. > > >> It is my observation that there will be a number of WebSocket usecases that >> could benefit from the ability to define usecase-specific control frames to >> mediate message flow. Telling developers to stuff this mediation protocol >> into extension data rather than in control frames does not appear to >> increase security; > >Firstly subprotocols can no more use extensions data than they can use >extension opcodes. >They can however use the payload and are free to define arbitrary >message semantics within that payload that may include application >control messages. > >The restriction of subprotocols to not use opcodes is not done for >security. It is done for protocol layering reasons. >The opcode is there to inform the WS implementation (and it's >extensions) how to handle the message. There is no application >semantics associated with any of the opcodes. For example the text vs >binary opcodes instructs the implementation if UTF-8 decoding is >required and to which part of the websocket API a message should be >delivered. There is no semantic restriction imposed by a binary >message, which may actually be a text message, but one for which the >application or subprotocol has taken responsibility for character >encoding. > >> rather, it likely decreases security because it >> intermixes control with data which is a fundamentally bad thing for a >> protocol design to do. The two control frames defined by MBWS are fairly simple and are likely >> representative of what other subprotocols would need. It would be far better >> to allow MBWS to properly factor its control and data than force it to put >> control in its data. > >Indeed there is a limitation in the current protocol of providing only >a single stream per connection, so there can be no separation of >control/data on a single connection. However the solution is not to >allow applications to put their control messages into the protocols >control stream, but rather to better support multiple streams - ie >MUX. For the protocol, it is clear that there are two streams of >frames: data and control, but there is no reason why this taxonomy >will apply generally to all applications and subprotocols. There may >be use cases where applications/subprotocols need n streams or control >frames larger than 125 bytes. > >The solution is to not see that the protocols control frame mechanism >is somewhat like the applications need for control messages and thus >to attempt to expose the protocols control channel to the application. > The solution is to allow applications to efficiently create their own >control channels - MUX! > > >> It is true that TCP does not support application control extension; however, >> HTTP clearly does support this with a very open-ended extension of the HTTP >> header. The WG needs to think carefully about this. I hope there is room to >> resolve this issue in this version of WebSocket. >> It is up to the W3C WebSocket API to insure it provides the functionality >> that both native users of WebSocket and implementors of WebSocket >> subprotocols require. In looking over what is currently defined, this API >> does not yet provide an API sufficient for the later. Possibly later it >> will. I don't believe that the design of WebSocket needs to be restricted by >> the current limitations of this API. > >This distinction between extensions and subprotocols has not been made >because of any API limitations. It has been done for good protocol >layering reasons. > >Consider if we open up the control channel to applications, then this >will make the task of creating things like MUX extensions much more >difficult. The mux solution would have to allow for extending control >frames with extension data so that they may be correctly routed to the >right application control channel. But if a 125 byte application >control frame is sent, then there may not be sufficient room to add >the channel identifier! Also if control frames are used to >implement MUX flow control, will applications use their application >control frames to attempt to get around this flow control? We may end >up needing to put flow control on the control channel to limit the >number of application control frames. > >Mixing application control frames with protocol control frames is a >far worse "solution" than mixing application control messages with >application data messages. > >regards From jat@google.com Tue Oct 4 18:51:28 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBD721F8AD1 for ; Tue, 4 Oct 2011 18:51:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.911 X-Spam-Level: X-Spam-Status: No, score=-105.911 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+LSf22K2hMZ for ; Tue, 4 Oct 2011 18:51:27 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 5ED5C21F8ACA for ; Tue, 4 Oct 2011 18:51:27 -0700 (PDT) Received: from wpaz1.hot.corp.google.com (wpaz1.hot.corp.google.com [172.24.198.65]) by smtp-out.google.com with ESMTP id p951sWmb016923 for ; Tue, 4 Oct 2011 18:54:33 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317779673; bh=4snHxtJqGCmFR/C2TQ0GGm9ljHI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=EDMIcglKbpSqhpPrXWoEPc5Kq/MU68QZIlfJpkR34tpMJAyGLbTgozCPaEinyTcfx Gwf6I21dHmKHuHTtkfn7g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=jIBAvCbXB9eW2Wl66C0d5CbzkbLEYNEp1i92KlQbWswtIJfpyugDEQRUnY4P7YEZG 1IEmwbQRMfa7jZl/0oZCA== Received: from ggnq2 (ggnq2.prod.google.com [10.218.98.130]) by wpaz1.hot.corp.google.com with ESMTP id p951sUTh011340 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 18:54:30 -0700 Received: by ggnq2 with SMTP id q2so719765ggn.4 for ; Tue, 04 Oct 2011 18:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=f4m3W4PzA0ajoG4rILoENhJAonNL3dSsDnWB/DYMjQM=; b=aTMjtaGwZ8WRM9rdC2QtR4CiM8YoUO5tXyCO17hBpoAJcpLYKjY0Gmggfzs1Ud5Cl0 lQR+lRkUSRiasH3tCV5Q== Received: by 10.150.104.10 with SMTP id b10mr1746874ybc.116.1317779670330; Tue, 04 Oct 2011 18:54:30 -0700 (PDT) Received: by 10.150.104.10 with SMTP id b10mr1746869ybc.116.1317779670181; Tue, 04 Oct 2011 18:54:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 4 Oct 2011 18:54:10 -0700 (PDT) In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> From: John Tamplin Date: Tue, 4 Oct 2011 21:54:10 -0400 Message-ID: To: Hapner mark Content-Type: multipart/alternative; boundary=000e0cd489d622274004ae837dd7 X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 01:51:28 -0000 --000e0cd489d622274004ae837dd7 Content-Type: text/plain; charset=UTF-8 On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark wrote: > WebSocket provides support for both subprotocols and extensions and I > believe both are available for use by outside parties as long as the IANA > registration mechanisms are followed. Is this correct? > Yes, but there are very very few available, and they were intended for WS infrastructure needs. If the first WS subprotocol allocates two of them, do we tell people in a couple of months "sorry, we are all out", and not have any left for the purpose for which they are intended? This is notwithstanding the fact that current APIs make no provision for using other opcodes, and as we have explained, we don't think they should. > The core point in favor of using an extension is that WebSocket already > defines an excellent framing protocol. There is simply no need for MBWS to > layer yet another framing protocol over it. It would be equivalent to a REST > service defining a request-response framing protocol within the HTTP > request-response body when all it needed was to add a few new header fields. > Let me see, I think I remember this being done, it was called WS* :>) > In most cases, such services *do* define a framing layer on top of HTTP -- for example, JSON, which defines how the payload carried by HTTP should be interpreted. They even have things like an opcode or message type inside them. > The point about control frame opcodes being 'scarce' is an issue; however, > the spec already suggests the use of an extension bit to resolve this. > > The spec does not describe how the opcode space will be distributed across > extensions. It does not say whether or not an extension opcode value can be > 'redefined' by different extensions. Since a session can only be operating > under one extension, there does not appear to be a technical reason why > extensions could not redefine extension opcodes. If this is possible, then > MBWS does not 'use up' any extension opcodes. > No, arbitrary extensions can be supported at the same time -- there is only one subprotocol. > Perhaps the fact that WebSocket itself does not reserve any of the opcode > extension space for itself is an issue. There seems to be an implication in > the comments so far that, in effect, they are all reserved and none are > available for 'outside' use. I don't believe this is the case. > That was the intent of requiring registration of new opcodes and reserved bits -- to basically require standards action for them to be assigned, since they are so scarce. Again, I think this issue is worthy of some serious debate. I'm not ready to > concede, as yet, that defining MBWS as a WebSocket extension is wrong. Let's say you did define it as an extension. For it to be useful, the API would have to be modified to suit your need and the browsers would have to implement your extension. What are the odds that will happen in a short time period, vs. just using the facility already available via the subprotocol? @Ian - clearly, we need to add some text to the spec explaining the distinction between subprotocols and extensions so others don't get the same misconceptions. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd489d622274004ae837dd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark <hapner.mark@hua= wei.com> wrote:

WebSocket provides support for both subprotocols and extensions and I belie= ve both are available for use by outside parties as long as the IANA regist= ration mechanisms are followed. Is this correct?

Yes, but there are very very few available, and they were intend= ed for WS infrastructure needs. =C2=A0If the first WS subprotocol allocates= two of them, do we tell people in a couple of months "sorry, we are a= ll out", and not have any left for the purpose for which they are inte= nded? =C2=A0This is notwithstanding the fact that current APIs make no prov= ision for using other opcodes, and as we have explained, we don't think= they should.

=C2=A0

The core point in favor of= using an extension is that WebSocket already defines an excellent framing = protocol. There is simply no need for MBWS to layer yet another framing pro= tocol over it. It would be equivalent to a REST service defining a request-= response framing protocol within the HTTP request-response body when all it= needed was to add a few new header fields. Let me see, I think I remember = this being done, it was called WS* :>)

In most cases, such services *do* define a= framing layer on top of HTTP -- for example, JSON, which defines how the p= ayload carried by HTTP should be interpreted. =C2=A0They even have things l= ike an opcode or message type inside them.=C2=A0

=C2=A0

The point about control frame opcodes being 'scarce' is an issue; h= owever, the spec already suggests the use of an extension bit to resolve th= is.

The spec does not describe how the opcode space will be distributed across = extensions. It does not say whether or not an extension opcode value can be= 'redefined' by different extensions. Since a session can only be o= perating under one extension, there does not appear to be a technical reaso= n why extensions could not redefine extension opcodes. If this is possible,= then MBWS does not 'use up' any extension opcodes.

No, arbitrary extensions can be supported = at the same time -- there is only one subprotocol.

=C2=A0

Perhaps the fact that WebSocket itself does not reserve any of the opcode e= xtension space for itself is an issue. There seems to be an implication in = the comments so far that, in effect, they are all reserved and none are ava= ilable for 'outside' use. I don't believe this is the case.

That was the intent of requiring registrat= ion of new opcodes and reserved bits -- to basically require standards acti= on for them to be assigned, since they are so scarce.=C2=A0

<= /div>

Again, I think this issue is worthy of some= serious debate. I'm not ready to concede, as yet, that defining MBWS a= s a WebSocket extension is wrong.

Let's say you did define it as an extension. =C2=A0= For it to be useful, the API would have to be modified to suit your need an= d the browsers would have to implement your extension. =C2=A0What are the o= dds that will happen in a short time period, vs. just using the facility al= ready available via the subprotocol?=C2=A0

@Ian - clearly, we need to add some text to the s= pec explaining the distinction between subprotocols and extensions so other= s don't get the same misconceptions.

--
John A.= Tamplin
Software Engineer (GWT), Google
--000e0cd489d622274004ae837dd7-- From gregw@intalio.com Tue Oct 4 20:42:12 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3322521F848E for ; Tue, 4 Oct 2011 20:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4+IxihUuQ9NJ for ; Tue, 4 Oct 2011 20:42:11 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A332021F8498 for ; Tue, 4 Oct 2011 20:42:10 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1234657vcb.31 for ; Tue, 04 Oct 2011 20:45:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.97.200 with SMTP id ec8mr2022455vdb.203.1317786316988; Tue, 04 Oct 2011 20:45:16 -0700 (PDT) Received: by 10.52.186.134 with HTTP; Tue, 4 Oct 2011 20:45:16 -0700 (PDT) In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> Date: Wed, 5 Oct 2011 14:45:16 +1100 Message-ID: From: Greg Wilkins To: Hapner mark Content-Type: text/plain; charset=ISO-8859-1 Cc: "hybi@ietf.org" Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:42:12 -0000 Mark, I think MBWS could be considered either as a subprotocol or as an extension, depending somewhat on what your requirements for reliable delivery are. If it was done as a subprotocol without additional layer of framing, the major issue I see from lacking control frame semantics is that the timeliness of an ack may be poor if there is a large message being sent over the channel in the same direction as the ack. Your protocol would still be reliable and able to recover from connection loss, but it may have some undue latency when informing the application of a successful delivery. Conversely, reliable messaging with timely acknowledgement is a good candidate for a websocket extension, that could be of use to MBWS and other protocols. So it may be that the MBWS concept of a connection spanning multiple WS connections is something that should be implemented in a subprotocol, while the message sequencing and acknowledgement part could be implemented in an extension. cheers From hapner.mark@huawei.com Tue Oct 4 20:57:52 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505B721F8A35 for ; Tue, 4 Oct 2011 20:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.767 X-Spam-Level: X-Spam-Status: No, score=-6.767 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TIWPUCDFFiRW for ; Tue, 4 Oct 2011 20:57:51 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9F21F8888 for ; Tue, 4 Oct 2011 20:57:51 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00L09R5JCM@usaga04-in.huawei.com> for hybi@ietf.org; Tue, 04 Oct 2011 23:00:57 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00D66R5IBL@usaga04-in.huawei.com> for hybi@ietf.org; Tue, 04 Oct 2011 23:00:55 -0500 (CDT) Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 04 Oct 2011 21:00:50 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Tue, 04 Oct 2011 21:00:44 -0700 Date: Wed, 05 Oct 2011 04:00:44 +0000 From: Hapner mark In-reply-to: X-Originating-IP: [172.18.9.109] To: John Tamplin Message-id: <92457F4F764A5C4785FCDBDDDD76477A123C7F00@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_qkjBluocrA6u90wTG/+8fw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-topic: [hybi] Subprotocol and Control Frames Thread-index: AcyCzo83r27v+PhnTw6E8yG0xmwZAAAT9AwA//+gz2WAAJskAP//j0wV X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 03:57:52 -0000 --Boundary_(ID_qkjBluocrA6u90wTG/+8fw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT John, Thanks for the further clarifications/corrections ... So if I understand correctly, extension opcodes are globally defined and extensions are required to be defined such that they can be combined in adhoc combinations. I would disagree that most users of HTTP put a framing protocol in HTTP bodies. They put MIME types (i.e. content types) in bodies. Content types do not contain protocol control - only the HTTP header contains (should contain) protocol control. The MessageBroker use case is not an 'application' usecase; it is an extended element of the messaging infrastructure. Much like a firewall or proxy is an extended element of the HTTP infrastructure. Within the phone home restriction, I believe AJAX clients have free rein to construct HTTP headers as they require. WebSocket needs something equivalent to this. If extensions are not this mechanism perhaps subprotocols can be extended a bit to provide this level of flexibility. To be specific, providing one extension control frame opcode for overloaded use by a subprotocol, combined with allowing subprotocols to use extension data (or append 'subprotocol extension data' to the end of protocol extension data) would likely resolve this issue (MBWS would definitely use it). Also, the API would need to be extended to provide access to these subprotocol features so AJAX clients could access them. (As an aside, it isn't clear to me how different extensions that define different extension data can be composed.) I realize I'm a newbie to this WG so you are free to take my opinion with a grain of salt; however, I hope the WG will carefully consider extending subprotocol to allow MBWS to be defined without requiring it to define yet another message framing protocol. -- Mark ________________________________ From: John Tamplin [jat@google.com] Sent: Tuesday, October 04, 2011 6:54 PM To: Hapner mark Cc: Greg Wilkins; hybi@ietf.org Subject: Re: [hybi] Subprotocol and Control Frames On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark > wrote: WebSocket provides support for both subprotocols and extensions and I believe both are available for use by outside parties as long as the IANA registration mechanisms are followed. Is this correct? Yes, but there are very very few available, and they were intended for WS infrastructure needs. If the first WS subprotocol allocates two of them, do we tell people in a couple of months "sorry, we are all out", and not have any left for the purpose for which they are intended? This is notwithstanding the fact that current APIs make no provision for using other opcodes, and as we have explained, we don't think they should. The core point in favor of using an extension is that WebSocket already defines an excellent framing protocol. There is simply no need for MBWS to layer yet another framing protocol over it. It would be equivalent to a REST service defining a request-response framing protocol within the HTTP request-response body when all it needed was to add a few new header fields. Let me see, I think I remember this being done, it was called WS* :>) In most cases, such services *do* define a framing layer on top of HTTP -- for example, JSON, which defines how the payload carried by HTTP should be interpreted. They even have things like an opcode or message type inside them. The point about control frame opcodes being 'scarce' is an issue; however, the spec already suggests the use of an extension bit to resolve this. The spec does not describe how the opcode space will be distributed across extensions. It does not say whether or not an extension opcode value can be 'redefined' by different extensions. Since a session can only be operating under one extension, there does not appear to be a technical reason why extensions could not redefine extension opcodes. If this is possible, then MBWS does not 'use up' any extension opcodes. No, arbitrary extensions can be supported at the same time -- there is only one subprotocol. Perhaps the fact that WebSocket itself does not reserve any of the opcode extension space for itself is an issue. There seems to be an implication in the comments so far that, in effect, they are all reserved and none are available for 'outside' use. I don't believe this is the case. That was the intent of requiring registration of new opcodes and reserved bits -- to basically require standards action for them to be assigned, since they are so scarce. Again, I think this issue is worthy of some serious debate. I'm not ready to concede, as yet, that defining MBWS as a WebSocket extension is wrong. Let's say you did define it as an extension. For it to be useful, the API would have to be modified to suit your need and the browsers would have to implement your extension. What are the odds that will happen in a short time period, vs. just using the facility already available via the subprotocol? @Ian - clearly, we need to add some text to the spec explaining the distinction between subprotocols and extensions so others don't get the same misconceptions. -- John A. Tamplin Software Engineer (GWT), Google --Boundary_(ID_qkjBluocrA6u90wTG/+8fw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

John,

Thanks for the further clarifications/corrections ...

So if I understand correctly, extension opcodes are globally defined and extensions are required to be defined such that they can be combined in adhoc combinations.

I would disagree that most users of HTTP put a framing protocol in HTTP bodies. They put MIME types (i.e. content types) in bodies. Content types do not contain protocol control - only the HTTP header contains (should contain) protocol control.

The MessageBroker use case is not an 'application' usecase; it is an extended element of the messaging infrastructure. Much like a firewall or proxy is an extended element of the HTTP infrastructure.

Within the phone home restriction, I believe AJAX clients have free rein to construct HTTP headers as they require. WebSocket needs something equivalent to this. If extensions are not this mechanism perhaps subprotocols can be extended a bit to provide this level of flexibility.

To be specific, providing one extension control frame opcode for overloaded use by a subprotocol, combined with allowing subprotocols to use extension data (or append 'subprotocol extension data' to the end of protocol extension data) would likely resolve this issue (MBWS would definitely use it). Also, the API would need to be extended to provide access to these subprotocol features so AJAX clients could access them.

(As an aside, it isn't clear to me how different extensions that define different extension data can be composed.)

I realize I'm a newbie to this WG so you are free to take my opinion with a grain of salt; however, I hope the WG will carefully consider extending subprotocol to allow MBWS to be defined without requiring it to define yet another message framing protocol.

-- Mark

From: John Tamplin [jat@google.com]
Sent: Tuesday, October 04, 2011 6:54 PM
To: Hapner mark
Cc: Greg Wilkins; hybi@ietf.org
Subject: Re: [hybi] Subprotocol and Control Frames

On Tue, Oct 4, 2011 at 9:36 PM, Hapner mark <hapner.mark@huawei.com> wrote:

WebSocket provides support for both subprotocols and extensions and I believe both are available for use by outside parties as long as the IANA registration mechanisms are followed. Is this correct?

Yes, but there are very very few available, and they were intended for WS infrastructure needs. If the first WS subprotocol allocates two of them, do we tell people in a couple of months "sorry, we are all out", and not have any left for the purpose for which they are intended? This is notwithstanding the fact that current APIs make no provision for using other opcodes, and as we have explained, we don't think they should.

The core point in favor of using an extension is that WebSocket already defines an excellent framing protocol. There is simply no need for MBWS to layer yet another framing protocol over it. It would be equivalent to a REST service defining a request-response framing protocol within the HTTP request-response body when all it needed was to add a few new header fields. Let me see, I think I remember this being done, it was called WS* :>)

In most cases, such services *do* define a framing layer on top of HTTP -- for example, JSON, which defines how the payload carried by HTTP should be interpreted. They even have things like an opcode or message type inside them.

The point about control frame opcodes being 'scarce' is an issue; however, the spec already suggests the use of an extension bit to resolve this.

The spec does not describe how the opcode space will be distributed across extensions. It does not say whether or not an extension opcode value can be 'redefined' by different extensions. Since a session can only be operating under one extension, there does not appear to be a technical reason why extensions could not redefine extension opcodes. If this is possible, then MBWS does not 'use up' any extension opcodes.

No, arbitrary extensions can be supported at the same time -- there is only one subprotocol.

Perhaps the fact that WebSocket itself does not reserve any of the opcode extension space for itself is an issue. There seems to be an implication in the comments so far that, in effect, they are all reserved and none are available for 'outside' use. I don't believe this is the case.

That was the intent of requiring registration of new opcodes and reserved bits -- to basically require standards action for them to be assigned, since they are so scarce.

Again, I think this issue is worthy of some serious debate. I'm not ready to concede, as yet, that defining MBWS as a WebSocket extension is wrong.

Let's say you did define it as an extension. For it to be useful, the API would have to be modified to suit your need and the browsers would have to implement your extension. What are the odds that will happen in a short time period, vs. just using the facility already available via the subprotocol?

@Ian - clearly, we need to add some text to the spec explaining the distinction between subprotocols and extensions so others don't get the same misconceptions.

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

--Boundary_(ID_qkjBluocrA6u90wTG/+8fw)-- From jat@google.com Tue Oct 4 21:15:18 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8B21F8B94 for ; Tue, 4 Oct 2011 21:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.912 X-Spam-Level: X-Spam-Status: No, score=-105.912 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AX8U8eatr3J for ; Tue, 4 Oct 2011 21:15:17 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 0512521F8B1C for ; Tue, 4 Oct 2011 21:15:16 -0700 (PDT) Received: from hpaq7.eem.corp.google.com (hpaq7.eem.corp.google.com [172.25.149.7]) by smtp-out.google.com with ESMTP id p954INfw007544 for ; Tue, 4 Oct 2011 21:18:23 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317788303; bh=bnQC1GfuuC8T5eltR3l0Gg50D2k=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=WN0qLH2qP6c8hYqibNVC0ABnTLnDoy+BB26ewVKoh8Pt5KMrBC4BhBZ9gelJuViik 65onvuuCRA9u/j4JL5ERw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=PbfDUT2n2ealao+pkFNJZJhgbW2CZvmKQYFidzGweqemzBswK1kdtNxXqsX4Yrx/R /DcUiLnDL8PDX55wIP4kw== Received: from gyg4 (gyg4.prod.google.com [10.243.50.132]) by hpaq7.eem.corp.google.com with ESMTP id p954Hgfm020303 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 21:18:21 -0700 Received: by gyg4 with SMTP id 4so1557956gyg.5 for ; Tue, 04 Oct 2011 21:18:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=pU7ecuwiotmzjoeAXD5eN3rI3PK5EYDzDHoY9ovQT/Q=; b=OaZk6g2wV9JSJnIlDU9l7pP+PxnZj60J2DOBh1RgZqm/ALs9nsxZRw0UTEuxhzBNg0 PM/UMHlNEYkbcLzC08zw== Received: by 10.151.144.7 with SMTP id w7mr1872764ybn.59.1317788301495; Tue, 04 Oct 2011 21:18:21 -0700 (PDT) Received: by 10.151.144.7 with SMTP id w7mr1872757ybn.59.1317788301308; Tue, 04 Oct 2011 21:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 4 Oct 2011 21:18:01 -0700 (PDT) In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C7F00@dfweml506-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C7F00@dfweml506-mbx> From: John Tamplin Date: Wed, 5 Oct 2011 00:18:01 -0400 Message-ID: To: Hapner mark Content-Type: multipart/alternative; boundary=0015174bed0696b2b304ae857f04 X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 04:15:18 -0000 --0015174bed0696b2b304ae857f04 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark wrote: > Thanks for the further clarifications/corrections ... > > So if I understand correctly, extension opcodes are globally defined and > extensions are required to be defined such that they can be combined in > adhoc combinations. > They are globally defined, but it is yet to be determined whether they can be allocated in overlapping fashion or dynamically. We couldn't reach agreement on those, so we left it the way it is now, which basically means they can't be used without getting some agreement on them. For example, one proposal was that each extension specify how many opcodes and reserved bits it needs, and those are allocated as needed per connection. If we go with that approach, we could create a spec that defines the mechanism for dynamically allocating these resources, and then extension specs that want to make use of this could simply refer to that spec. Basically, the intent is to cross that bridge when we get there, and hopefully we will have real use cases to consider to guide that decision. > I would disagree that most users of HTTP put a framing protocol in HTTP > bodies. They put MIME types (i.e. content types) in bodies. Content types do > not contain protocol control - only the HTTP header contains (should > contain) protocol control. > Most JSON or SOAP-based services I have used do in fact have some sort of message type in the payload, but YMMV. > To be specific, providing one extension control frame opcode for > overloaded use by a subprotocol, combined with allowing subprotocols to use > extension data (or append 'subprotocol extension data' to the end of > protocol extension data) would likely resolve this issue (MBWS would > definitely use it). Also, the API would need to be extended to provide > access to these subprotocol features so AJAX clients could access them. > I really don't see the difference -- if MBWS were to say "I want 20 bytes of extension data", how is that any different than just using the first 20 bytes of the WS payload as its extension data, and the remainder of the WS payload as the upper-level payload? > (As an aside, it isn't clear to me how different extensions that define > different extension data can be composed.) > In the order they are declared. > I realize I'm a newbie to this WG so you are free to take my opinion with > a grain of salt; however, I hope the WG will carefully consider extending > subprotocol to allow MBWS to be defined without requiring it to define yet > another message framing protocol. > Multiple layers of framing is the norm -- Ethernet has its own framing, IP on top of that, TCP or UDP on top of that, HTTP on top of that, etc. Each layer peels off their part and passes the rest on to the next layer -- that is the way the network stack works. I am not sure why you are resisting this. -- John A. Tamplin Software Engineer (GWT), Google --0015174bed0696b2b304ae857f04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark <hapner.mark@hu= awei.com> wrote:

Thanks for the further clarifications/corrections ...

So if I understand correctly, extension opcodes are globally defined a= nd extensions are required to be defined such that they can be combined in = adhoc combinations.

They are globally defined, but it is yet to be determined whether they can = be allocated in overlapping fashion or dynamically. =C2=A0We couldn't r= each agreement on those, so we left it the way it is now, which basically m= eans they can't be used without getting some agreement on them. =C2=A0F= or example, one proposal was that each extension specify how many opcodes a= nd reserved bits it needs, and those are allocated as needed per connection= . =C2=A0If we go with that approach, we could create a spec that defines th= e mechanism for=C2=A0dynamically=C2=A0allocating these resources, and then = extension specs that want to make use of this could simply refer to that sp= ec.

Basically, the intent is to cross that bridge when we g= et there, and hopefully we will have real use cases to consider to guide th= at decision.

=C2=A0

I would disagree that most users of HTTP put a framing protocol in HTT= P bodies. They put MIME types (i.e. content types) in bodies. Content types= do not contain protocol control - only the HTTP header contains=C2=A0(shou= ld contain)=C2=A0protocol control.

Most JSON or SOAP-based servic= es I have used do in fact have some sort of message type in the payload, bu= t YMMV.

=C2=A0

To be specific, providing one extension control frame opcode for overl= oaded use by a subprotocol, combined with allowing subprotocols to use exte= nsion data (or append 'subprotocol extension data' to the end of pr= otocol extension data) would likely resolve this issue (MBWS would definitely use it).=C2=A0Also, the API would need t= o be extended to provide access to these subprotocol features so AJAX clien= ts could access them.

I r= eally don't see the difference -- if MBWS were to say "I want 20 b= ytes of extension data", how is that any different than just using the= first 20 bytes of the WS payload as its extension data, and the remainder = of the WS payload as the upper-level payload?

=C2=A0

(As an aside, it isn't clear to me how different extensions that d= efine different extension data can be composed.)

In the order they are declared.
=C2=A0

I realize I'm a newbie to this WG so you are free to take my opini= on with a grain of salt; however, I hope the WG will carefully consider ext= ending subprotocol to allow MBWS to be defined without requiring it to defi= ne yet another message framing protocol.

Multiple layers of framing is = the norm -- Ethernet has its own framing, IP on top of that, TCP or UDP on = top of that, HTTP on top of that, etc. =C2=A0Each layer peels off their par= t and passes the rest on to the next layer -- that is the way the network s= tack works. =C2=A0I am not sure why you are resisting this.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--0015174bed0696b2b304ae857f04-- From hapner.mark@huawei.com Tue Oct 4 22:33:43 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21FC21F8B44 for ; Tue, 4 Oct 2011 22:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.753 X-Spam-Level: X-Spam-Status: No, score=-6.753 tagged_above=-999 required=5 tests=[AWL=-0.154, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tinmwd8UGEll for ; Tue, 4 Oct 2011 22:33:42 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id A5ABF21F8B28 for ; Tue, 4 Oct 2011 22:33:42 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00LJDVLDCM@usaga04-in.huawei.com> for hybi@ietf.org; Wed, 05 Oct 2011 00:36:49 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSK00DWPVLCBL@usaga04-in.huawei.com> for hybi@ietf.org; Wed, 05 Oct 2011 00:36:49 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 04 Oct 2011 22:36:44 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Tue, 04 Oct 2011 22:36:38 -0700 Date: Wed, 05 Oct 2011 05:36:37 +0000 From: Hapner mark In-reply-to: X-Originating-IP: [172.18.9.109] To: John Tamplin Message-id: <92457F4F764A5C4785FCDBDDDD76477A123C8F43@dfweml506-mbx> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [hybi] Subprotocol and Control Frames Thread-index: AcyCzo83r27v+PhnTw6E8yG0xmwZAAAT9AwA//+gz2WAAJskAP//j0wVgACY5ID//4up7Q== X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C7F00@dfweml506-mbx> Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2011 05:33:43 -0000 >From: John Tamplin [jat@google.com] >Sent: Tuesday, October 04, 2011 9:18 PM >To: Hapner mark >Cc: Greg Wilkins; hybi@ietf.org >Subject: Re: [hybi] Subprotocol and Control Frames > >On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark wrote: >Thanks for the further clarifications/corrections ... > >So if I understand correctly, extension opcodes are globally defined and extensions are required to be defined such that they can be combined in adhoc combinations. > >They are globally defined, but it is yet to be determined whether they can be allocated in overlapping fashion or dynamically. We couldn't reach agreement on those, so we left it the way it is now, which basically means they can't be used without getting some agreement on them. For example, one proposal was that each extension specify how many opcodes and reserved bits it needs, and those are allocated as needed per connection. If we go with that approach, we could create a spec that defines the mechanism for dynamically allocating these resources, and then extension specs that want to make use of this could simply refer to that spec. > >Basically, the intent is to cross that bridge when we get there, and hopefully we will have real use cases to consider to guide that decision. > >I would disagree that most users of HTTP put a framing protocol in HTTP bodies. They put MIME types (i.e. content types) in bodies. Content types do not contain protocol control - only the HTTP header contains (should contain) protocol control. > >Most JSON or SOAP-based services I have used do in fact have some sort of message type in the payload, but YMMV. > >To be specific, providing one extension control frame opcode for overloaded use by a subprotocol, combined with allowing subprotocols to use extension data (or append 'subprotocol extension data' to the end of protocol extension data) would likely resolve this issue (MBWS would definitely use it). Also, the API would need to be extended to provide access to these subprotocol features so AJAX clients could access them. > >I really don't see the difference -- if MBWS were to say "I want 20 bytes of extension data", how is that any different than just using the first 20 bytes of the WS payload as its extension data, and the remainder of the WS payload as the upper-level payload? My main issue is with putting MBWS control frames into WebSocket message payloads. Putting MBWS message metadata into its associated message payload is a lesser issue. It requires the definition of an extension data mechanism within text message payloads and binary message payloads that mirrors what already exists in WebSocket. You equate WebSocket with TCP. I equate it with HTTP. Possibly neither of us is fully correct. HTTP added a framing protocol over TCP so does WebSocket. If all extended use of WebSocket has to treat it like TCP, then Clebert and I should get on with implementing our MBWS message framing protocol and stop annoying the WG. On the other hand, there is great potential to reuse/extend the WebSocket protocol in much the same way that the web community has with HTTP. If the community had treated HTTP like it was TCP it would be worse off (as WS* did and is). Possibly the TCP analogy with WebSocket is not the most productive mental model of WebSocket's role in web architecture. What would be the harm in considering extending the functionality of WebSocket subprotocol in the way I'm suggesting? Wouldn't having one less layer be a useful result. > >(As an aside, it isn't clear to me how different extensions that define different extension data can be composed.) > >In the order they are declared. > >I realize I'm a newbie to this WG so you are free to take my opinion with a grain of salt; however, I hope the WG will carefully consider extending subprotocol to allow MBWS to be defined without requiring it to define yet another message framing protocol. > >Multiple layers of framing is the norm -- Ethernet has its own framing, IP on top of that, TCP or UDP on top of that, HTTP on top of that, etc. Each layer peels off their part and passes the rest on to the next layer -- that is the way the network stack works. I am not sure why you are resisting this. > >-- >John A. Tamplin >Software Engineer (GWT), Google From ifette@google.com Tue Oct 4 23:01:54 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB1621F849C for ; Tue, 4 Oct 2011 23:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLZcjGzR+Mlx for ; Tue, 4 Oct 2011 23:01:53 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 614E921F846D for ; Tue, 4 Oct 2011 23:01:53 -0700 (PDT) Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p9564xCX019494 for ; Tue, 4 Oct 2011 23:04:59 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1317794700; bh=drHn+/4U05TgPYTeE8KIb3+g76g=; h=MIME-Version:Reply-To:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type; b=oZLzXoG3VZDva8VYKNAyooecDIY21Xb8akZ31JxZGi2lvV3KklIT6zwjjm+EOq+Zn FNmBWJNcLI9n22/0EVZiA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:reply-to:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=DgyD/9gbnODxtkQ75oCREcoPegB1O5fApz93LuoMs6XlHhm2bbEfKVOnTyG35AGAy bk+CAKapyF9ropAid3+uQ== Received: from iadj38 (iadj38.prod.google.com [10.12.136.38]) by hpaq14.eem.corp.google.com with ESMTP id p9564X2i012786 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 4 Oct 2011 23:04:58 -0700 Received: by iadj38 with SMTP id j38so2481448iad.1 for ; Tue, 04 Oct 2011 23:04:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7Y/Chb1QV76EFVN90krgXEfa+Cm7obwr438Z0SbVpA4=; b=S5m/Wacf98z3gmSpAPw67LaH7t+NoiOsrJ25xVi/aD7SNPimBIViGj5DSGzlx5OJA0 xIpOLsV4FzgAs/uLHBjQ== Received: by 10.231.0.140 with SMTP id 12mr3603655ibb.98.1317794697996; Tue, 04 Oct 2011 23:04:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.0.140 with SMTP id 12mr3603644ibb.98.1317794697818; Tue, 04 Oct 2011 23:04:57 -0700 (PDT) Received: by 10.231.35.10 with HTTP; Tue, 4 Oct 2011 23:04:57 -0700 (PDT) In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C8F43@dfweml506-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C7F00@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C8F43@dfweml506-mbx> Date: Tue, 4 Oct 2011 23:04:57 -0700 Message-ID: From: =?UTF-8?B?SWFuIEZldHRlICjjgqTjgqLjg7Pjg5Xjgqfjg4Pjg4bjgqMp?= To: Hapner mark Content-Type: multipart/alternative; boundary=0015177409c0d9b4e504ae86fcda X-System-Of-Record: true Cc: "hybi@ietf.org" , Greg Wilkins Subject: Re: [hybi] Subprotocol and Control Frames 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: Wed, 05 Oct 2011 06:01:55 -0000 --0015177409c0d9b4e504ae86fcda Content-Type: text/plain; charset=UTF-8 On Tue, Oct 4, 2011 at 10:36 PM, Hapner mark wrote: > >From: John Tamplin [jat@google.com] > >Sent: Tuesday, October 04, 2011 9:18 PM > >To: Hapner mark > >Cc: Greg Wilkins; hybi@ietf.org > >Subject: Re: [hybi] Subprotocol and Control Frames > > > >On Wed, Oct 5, 2011 at 12:00 AM, Hapner mark > wrote: > >Thanks for the further clarifications/corrections ... > > > >So if I understand correctly, extension opcodes are globally defined and > extensions are required to be defined such that they can be combined in > adhoc combinations. > > > >They are globally defined, but it is yet to be determined whether they > can be allocated in overlapping fashion or dynamically. We couldn't reach > agreement on those, so we left it the way it is now, which basically means > they can't be used without getting some agreement on them. For example, one > proposal was that each extension specify how many opcodes and reserved bits > it needs, and those are allocated as needed per connection. If we go with > that approach, we could create a spec that defines the mechanism for > dynamically allocating these resources, and then extension specs that want > to make use of this could simply refer to that spec. > > > >Basically, the intent is to cross that bridge when we get there, and > hopefully we will have real use cases to consider to guide that decision. > > > >I would disagree that most users of HTTP put a framing protocol in HTTP > bodies. They put MIME types (i.e. content types) in bodies. Content types do > not contain protocol control - only the HTTP header contains (should > contain) protocol control. > > > >Most JSON or SOAP-based services I have used do in fact have some sort of > message type in the payload, but YMMV. > > > >To be specific, providing one extension control frame opcode for > overloaded use by a subprotocol, combined with allowing subprotocols to use > extension data (or append 'subprotocol extension data' to the end of > protocol extension data) would likely resolve this issue (MBWS would > definitely use it). Also, the API would need to be extended to provide > access to these subprotocol features so AJAX clients could access them. > > > >I really don't see the difference -- if MBWS were to say "I want 20 bytes > of extension data", how is that any different than just using the first 20 > bytes of the WS payload as its extension data, and the remainder of the WS > payload as the upper-level payload? > > My main issue is with putting MBWS control frames into WebSocket message > payloads. > > Putting MBWS message metadata into its associated message payload is a > lesser issue. It requires the definition of an extension data mechanism > within text message payloads and binary message payloads that mirrors what > already exists in WebSocket. > > You equate WebSocket with TCP. I equate it with HTTP. Possibly neither of > us is fully correct. > > HTTP added a framing protocol over TCP so does WebSocket. If all extended > use of WebSocket has to treat it like TCP, then Clebert and I should get on > with implementing our MBWS message framing protocol and stop annoying the > WG. > > On the other hand, there is great potential to reuse/extend the WebSocket > protocol in much the same way that the web community has with HTTP. If the > community had treated HTTP like it was TCP it would be worse off (as WS* did > and is). Possibly the TCP analogy with WebSocket is not the most productive > mental model of WebSocket's role in web architecture. > > What would be the harm in considering extending the functionality of > WebSocket subprotocol in the way I'm suggesting? Wouldn't having one less > layer be a useful result. At the end of the day, the way I think of it is that extensions are for protocol level things that the client and server software must support. subprotocols are contracts between the application software running in the client and server, but the client and server are blissfully unaware of any of these semantics. It would be hell if you had to recompile Apache to understand the semantics of each website you wanted to serve. If you're changing the framing in a meaningful way (e.g. changing message opcodes), then servers and intermediaries need to be altered and recompiled to deal with those changes. At that point, you've defined an extension. If you're not meaningfully changing the framing, but you're simply instructing the other endpoint "Here's how to interpret the data contained in the payload of the message", the servers and intermediaries don't need to be recompiled and you are defining a subprotocol. I suspect that what you are trying to do, like many things, could be written as either an extension or a subprotocol. We could define an extension for google search - send a search opcode and the search terms and get back a results opcode with the search results. Yes, it's a bit of a facetious example, but I'm merely trying to illustrate a point. The mere fact that something can be done that way doesn't make it necessarily appropriate or desirable. It's not clear to me as a browser vendor why I would want to implement either a google search extension or an MBWS extension, for example, nor why I would want to agree to opcodes and reserved bits being allocated for its use. -Ian --0015177409c0d9b4e504ae86fcda Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Oct 4, 2011 at 10:36 PM, Hapner mark <hapner.mark@hu= awei.com> wrote:
=C2=A0>From: John Tamplin [jat@google.= com]
=C2=A0>Sent: Tuesday, October 04, 2011 9:18 PM

=C2=A0>To: Hapner mark
=C2=A0>Cc: Greg Wilkins; hybi@ietf.org<= /a>
=C2=A0>Subject: Re: [hybi] Subprotocol and Control Frames
=C2=A0>

=C2=A0>On Wed, Oct 5, 2011 at 12:00 AM, Hapner m= ark <hapner.mark@huawei.com> wrote:
=C2=A0>Thanks for the further clarifications/corrections ...
=C2=A0>
=C2=A0>So if I understand correctly, extension opcodes are globally defi= ned and extensions are required to be defined such that they can be combine= d in adhoc combinations.
=C2=A0>
=C2=A0>They are globally defined, but it is yet to be determined whether= they can be allocated in overlapping fashion or dynamically. =C2=A0We coul= dn't reach agreement on those, so we left it the way it is now, which b= asically means they can't be used without getting some agreement on the= m. =C2=A0For example, one proposal was that each extension specify how many= opcodes and reserved bits it needs, and those are allocated as needed per = connection. =C2=A0If we go with that approach, we could create a spec that = defines the mechanism for dynamically allocating these resources, and then = extension specs that want to make use of this could simply refer to that sp= ec.
=C2=A0>
=C2=A0>Basically, the intent is to cross that bridge when we get there, = and hopefully we will have real use cases to consider to guide that decisio= n.
=C2=A0>
=C2=A0>I would disagree that most users of HTTP put a framing protocol i= n HTTP bodies. They put MIME types (i.e. content types) in bodies. Content = types do not contain protocol control - only the HTTP header contains (shou= ld contain) protocol control.
=C2=A0>
=C2=A0>Most JSON or SOAP-based services I have used do in fact have some= sort of message type in the payload, but YMMV.
=C2=A0>
=C2=A0>To be specific, providing one extension control frame opcode for = overloaded use by a subprotocol, combined with allowing subprotocols to use= extension data (or append 'subprotocol extension data' to the end = of protocol extension data) would likely resolve this issue (MBWS would def= initely use it). Also, the API would need to be extended to provide access = to these subprotocol features so AJAX clients could access them.
=C2=A0>
=C2=A0>I really don't see the difference -- if MBWS were to say &quo= t;I want 20 bytes of extension data", how is that any different than j= ust using the first 20 bytes of the WS payload as its extension data, and t= he remainder of the WS payload as the upper-level payload?

My main issue is with putting MBWS control frames into WebSocket mess= age payloads.

Putting MBWS message metadata into its associated message payload is a less= er issue. It requires the definition of an extension data mechanism within = text message payloads and binary message payloads that mirrors what already= exists in WebSocket.

You equate WebSocket with TCP. I equate it with HTTP. Possibly neither of u= s is fully correct.

HTTP added a framing protocol over TCP so does WebSocket. If all extended u= se of WebSocket has to treat it like TCP, then Clebert and I should get on = with implementing our MBWS message framing protocol and stop annoying the W= G.

On the other hand, there is great potential to reuse/extend the WebSocket p= rotocol in much the same way that the web community has with HTTP. If the c= ommunity had treated HTTP like it was TCP it would be worse off (as WS* did= and is). Possibly the TCP analogy with WebSocket is not the most productiv= e mental model of WebSocket's role in web architecture.

What would be the harm in considering extending the functionality of WebSoc= ket subprotocol in the way I'm suggesting? Wouldn't having one less= layer be a useful result.

At the end of th= e day, the way I think of it is that extensions are for protocol level thin= gs that the client and server software must support. subprotocols are contr= acts between the application software running in the client and server, but= the client and server are blissfully unaware of any of these semantics. It= would be hell if you had to recompile Apache to understand the semantics o= f each website you wanted to serve.

If you're changing the framing in a meaningful way = (e.g. changing message opcodes), then servers and intermediaries need to be= altered and recompiled to deal with those changes. At that point, you'= ve defined an extension. If you're not meaningfully changing the framin= g, but you're simply instructing the other endpoint "Here's ho= w to interpret the data contained in the payload of the message", the = servers and intermediaries don't need to be recompiled and you are defi= ning a subprotocol.

I suspect that what you are trying to do, like many thi= ngs, could be written as either an extension or a subprotocol. We could def= ine an extension for google search - send a search opcode and the search te= rms and get back a results opcode with the search results. Yes, it's a = bit of a facetious example, but I'm merely trying to illustrate a point= . The mere fact that something can be done that way doesn't make it nec= essarily appropriate or desirable. It's not clear to me as a browser ve= ndor why I would want to implement either a google search extension or an M= BWS extension, for example, nor why I would want to agree to opcodes and re= served bits being allocated for its use.

-Ian
--0015177409c0d9b4e504ae86fcda-- From julian.reschke@gmx.de Wed Oct 5 00:13:04 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E6E721F8B10 for ; Wed, 5 Oct 2011 00:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.106 X-Spam-Level: X-Spam-Status: No, score=-103.106 tagged_above=-999 required=5 tests=[AWL=-0.507, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EisDjyS-dIrP for ; Wed, 5 Oct 2011 00:13:03 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DB2E421F85D1 for ; Wed, 5 Oct 2011 00:12:59 -0700 (PDT) Received: (qmail invoked by alias); 05 Oct 2011 07:16:03 -0000 Received: from p5DCC39D6.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.57.214] by mail.gmx.net (mp052) with SMTP; 05 Oct 2011 09:16:03 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1//W3BV7pP/j+isfc8s/cc7Z82ozbJn9Kt4JytQQU X2zkfCK6ZvCweT Message-ID: <4E8C0421.80109@gmx.de> Date: Wed, 05 Oct 2011 09:15:45 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Arthur Barstow References: <4E849CAD.8090204@nokia.com> In-Reply-To: <4E849CAD.8090204@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: public-webapps , "hybi@ietf.org" Subject: Re: [hybi] RfC: LCWD of Web Socket API; comment deadline October 21 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 05 Oct 2011 07:13:04 -0000 On 2011-09-29 18:28, Arthur Barstow wrote: > On September 29, aLCWD of Web Sockets API was published: > > http://www.w3.org/TR/2011/WD-websockets-20110929/ > > Please send all comments to public-webapps@w3.org by October 21. I just noted that as of yesterday, the API spec contains the custom URI parsing algorithm that we removed from the protocol spec a long time ago. This was a post-LC change. What's the Webapps WG's procedure to manage changes during LC? Best regards, Julian From sustrik@250bpm.com Wed Oct 5 01:36:58 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA8221F84CD for ; Wed, 5 Oct 2011 01:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.524 X-Spam-Level: X-Spam-Status: No, score=-0.524 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tytsRWjza7zS for ; Wed, 5 Oct 2011 01:36:58 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id A86FC21F84C1 for ; Wed, 5 Oct 2011 01:36:57 -0700 (PDT) Received: from [10.9.1.2] (chello089173046084.chello.sk [89.173.46.84]) by mail.moloch.sk (Postfix) with ESMTPSA id DA93C182D0BB; Wed, 5 Oct 2011 10:40:02 +0200 (CEST) Message-ID: <4E8C17B0.7030003@250bpm.com> Date: Wed, 05 Oct 2011 10:39:12 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hapner mark References: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx> In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 05 Oct 2011 08:36:58 -0000 Hi Mark, >> 1. Given the explicit focus on reliability, it's strange that the >> proposal deals with message metadata, which have to do with broker >> or even application behaviour and have absolutely nothing to do >> with reliability. What ensues is a spec where metadata are defined >> as opaque syntactic placeholders with no associated semantics. The >> semantics are meant to be defined on the broker or application >> level. The question is whether it doesn't follow that the syntax >> should be defined on those layers as well. >> > > Both the reliability and message metadata are defined with the > expectation that they are generic for a broad class of MessageBroker > services. The majority of those I'm familiar with could easily make > do with this metadata. The semantics of messages having a text > address, an optional content type, and an optional property list > covers a very broad set of MessageBroker scenarios. On the other > hand, without this additional message metadata, the protocol would > not be usable by any MessageBrokers I'm aware of. I think the argument goes rather like this: If the metadata is to be used by the protocol, the semantics of the usage should be defined. If it's not defined, there's no interoperability. If there's no interoperability, there's no point in having a standard in the first place. >> 2. AFAICS there's nothing in the spec that presumes existence of >> the broker. It can be as well used for direct communication >> between applications. Thus, I would suggest replacing messaging >> broker/messaging client terminology with WebSocket server and >> WebSocket client wording. >> > Yes, while the protocol has been defined for the MessageBroker > usecase, nothing prevents its use in other contexts. On the other > hand, if it were called 'foobar' instead of 'MessageBroker' it would > be hard to explain why it contains the specific elements it does. What I meant was that there are messaging solutions out there with no broker (Tibco RV, LBM, 0MQ). There's nothing expect the "broker" wording in the protocol to prevent these solutions to use the protocol. Btw, I've heard something about Kaazing providing access to Tibco through the web on top of websockets... >> 3. As for reliability itself, it should be clear what kind of >> error conditions is the protocol meant to handle. Possible >> options: >> >> a. Network failure. If so, how does it differ from simply turning >> off TCP keepalives? >> >> b. Client failure and restart? >> >> c. Server failure and restart? >> > > The reliability elements of MBWS are just the protocol elements that > client and MessageBroker use to jointly create and maintain a > connection abstraction. This shared abstraction exists independent of > MBWS. This allows a connection to be 'carried' over an open-ended > sequence of MBWS sessions. Since connections exist independent of the > network, they survive any form of network failure. This is interesting. Can you give an example of such network failure? > The degree to which a connection will or won't survive a > client/MessageBroker failure depends entirely on the ability of the > client/MessageBroker to retain the state needed for it to maintain > the connection across its failure. MBWS does not define how this is > to be done; however, there are many practical ways of doing it. A > client or MessageBroker could fully implement MBWS and only recover > from failed MBWS sessions (i.e. not support connection recovery > across program failures). Ack. The failures of server/client are not addressed in the protocol. You can handle them on top of it though. Martin From gregl.msp@gmail.com Wed Oct 5 05:45:57 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAFFD21F8CC6 for ; Wed, 5 Oct 2011 05:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZ4lU6WMzG3z for ; Wed, 5 Oct 2011 05:45:57 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D1E1621F8D2C for ; Wed, 5 Oct 2011 05:45:56 -0700 (PDT) Received: by ywm3 with SMTP id 3so1857138ywm.31 for ; Wed, 05 Oct 2011 05:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=72vqUnBpXcbsJVosr96ZAzP+HXK5iUzDu0q3rbVGtXU=; b=l9B4mJ1wHeV7QLZnnzlUTnH6Cy4g1BOJQKJfNuFYKH2sOuqciYOsXaNF7efUqP73qO lwc9YGvEVu8rSHoPdtwBbOFVmwk4n684JY74ZUca3PVOFHp9cEI+gnF/gM7yVpjd337G j6Ohhd2oNWqVpqMdMQyhMct6tCaFT/EYxuZKg= Received: by 10.101.178.20 with SMTP id f20mr2007639anp.154.1317818941908; Wed, 05 Oct 2011 05:49:01 -0700 (PDT) Received: from GJL8710w (184-97-191-56.mpls.qwest.net. [184.97.191.56]) by mx.google.com with ESMTPS id u13sm4531411anf.14.2011.10.05.05.49.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Oct 2011 05:49:01 -0700 (PDT) From: Greg Longtin To: "hybi" References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C7F00@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C8F43@dfweml506-mbx> In-Reply-To: Date: Wed, 5 Oct 2011 07:48:59 -0500 Message-ID: <4e8c523d.0dc5640a.57e0.591d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyDJLoH2ZvWSYTtR0qmWIRnG3GxmgANKLPw Content-Language: en-us Subject: [hybi] Subprotocols, extensions, LC, 17 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 05 Oct 2011 12:45:58 -0000 To all, On Wed, Oct 5, 2011 at 1:05 AM, Ian Fette wrote: At the end of the day, the way I think of it is that extensions are for = protocol level things that the client and server software must support. = subprotocols are contracts between the application software running in = the client and server, but the client and server are blissfully unaware = of any of these semantics. It would be hell if you had to recompile = Apache to understand the semantics of each website you wanted to serve. Having followed the progress of WS, my understanding of the distinction = between subprotocols and extensions was as Ian has stated very well. Conversely, the discussions about MBWS may show that the spec is not = clear enough on the distinction. When 17 was released, I tried to read the spec from the perspective of = someone 'new' to WS, and felt there could a better description of the = distinction. This issue is also affected by the wording in the W3C 'The = WebSocket API' document, which mentions both subprotocols and = extensions. To add to it, I speak English natively. Not being familiar with changing/amending a 'Proposed Standard', I'm not = sure if this can be addressed... Thanks, Greg Longtin From clebert.suconic@gmail.com Wed Oct 5 09:33:05 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B5CD21F8B7C for ; Wed, 5 Oct 2011 09:33:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NwOPHQznr3HW for ; Wed, 5 Oct 2011 09:33:05 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC721F8B8E for ; Wed, 5 Oct 2011 09:33:04 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so1867833vcb.31 for ; Wed, 05 Oct 2011 09:36:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=16llFan5voFdXmqXfF1HwX3UAm1tIFKJ7K2n03V/RT4=; b=uuPFqX80IX3SHJNpPjXtqNKGrl00AZi7I1SGAoNe7WzHvV0KQTb/xpVUBgQcI1gAIM dzN6cXp4dvkNlNa+hKYo3OsU8JbA3YWM4HfSTOBJKNOdU8mXLEfAgsxkYv0VtxpuBqc4 U1i121Z91bF3VKJ5eN6u+j2Y/gNnlZRR72lis= MIME-Version: 1.0 Received: by 10.68.39.229 with SMTP id s5mr19566030pbk.76.1317832572576; Wed, 05 Oct 2011 09:36:12 -0700 (PDT) Received: by 10.142.237.19 with HTTP; Wed, 5 Oct 2011 09:36:12 -0700 (PDT) In-Reply-To: <4E8C17B0.7030003@250bpm.com> References: <92457F4F764A5C4785FCDBDDDD76477A123C5D31@dfweml506-mbx> <4E8C17B0.7030003@250bpm.com> Date: Wed, 5 Oct 2011 09:36:12 -0700 Message-ID: From: Clebert Suconic To: Martin Sustrik Content-Type: multipart/alternative; boundary=bcaec520f3fb5ca21f04ae8fce78 Cc: "hybi@ietf.org" , Hapner mark Subject: Re: [hybi] The MessageBroker WebSocket Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 05 Oct 2011 16:33:05 -0000 --bcaec520f3fb5ca21f04ae8fce78 Content-Type: text/plain; charset=ISO-8859-1 > > I think the argument goes rather like this: If the metadata is to be used > by the protocol, the semantics of the usage should be defined. If it's not > defined, there's no interoperability. If there's no interoperability, > there's no point in having a standard in the first place. > > > Any message implementation will need some context to perform reconnections. That shouldn't be a problem for any message-like systems. It should be a simple solution that just works.. and I believe this would bring a lot of advantages over other over-complex standards that are defined on the message-world. This can actually be used for other communications where some context needs to be defined as well. I'm sure Mark will have more to say on top of this. --bcaec520f3fb5ca21f04ae8fce78 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I think the argu= ment goes rather like this: If the metadata is to be used by the protocol, = the semantics of the usage should be defined. If it's not defined, ther= e's no interoperability. If there's no interoperability, there'= s no point in having a standard in the first place.

Any message implementation w= ill need some context to perform reconnections. That shouldn't be a pro= blem for any message-like systems.

It should be a = simple solution that just works.. and I believe this would bring a lot of a= dvantages over other over-complex standards that are defined on the message= -world.

This can actually be used for other communications wher= e some context needs to be defined as well.

I'= m sure Mark will have more to say on top of this.
--bcaec520f3fb5ca21f04ae8fce78-- From hapner.mark@huawei.com Wed Oct 5 14:14:16 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB7541F0C5F for ; Wed, 5 Oct 2011 14:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.86 X-Spam-Level: X-Spam-Status: No, score=-5.86 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DeVqYxfpOZbR for ; Wed, 5 Oct 2011 14:14:15 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 9F04E1F0C46 for ; Wed, 5 Oct 2011 14:14:15 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSM009WV34Y1D@usaga04-in.huawei.com> for hybi@ietf.org; Wed, 05 Oct 2011 16:17:23 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSM00IGG34X6N@usaga04-in.huawei.com> for hybi@ietf.org; Wed, 05 Oct 2011 16:17:22 -0500 (CDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 05 Oct 2011 14:17:23 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Wed, 05 Oct 2011 14:17:11 -0700 Date: Wed, 05 Oct 2011 21:17:10 +0000 From: Hapner mark X-Originating-IP: [172.18.9.109] To: Martin Sustrik Message-id: <92457F4F764A5C4785FCDBDDDD76477A123CA06E@dfweml506-mbx> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_IpblXUIJcEgxeTYmvFpoBw)" Content-language: en-US Accept-Language: en-US, zh-CN Thread-index: AcyDl0nVbhTiuaS9SoeDkPmBh4oJQQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: Cc: "hybi@ietf.org" , "csuconic@redhat.com" Subject: [hybi] (no subject) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 05 Oct 2011 21:14:16 -0000 --Boundary_(ID_IpblXUIJcEgxeTYmvFpoBw) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi Martin, Thanks for the feedback, See comments below ... -- Mark >Hi Mark, > >>> 1. Given the explicit focus on reliability, it's strange that the >>> proposal deals with message metadata, which have to do with broker >>> or even application behaviour and have absolutely nothing to do >>> with reliability. What ensues is a spec where metadata are defined >>> as opaque syntactic placeholders with no associated semantics. The >>> semantics are meant to be defined on the broker or application >>> level. The question is whether it doesn't follow that the syntax >>> should be defined on those layers as well. >>> >> >> Both the reliability and message metadata are defined with the >> expectation that they are generic for a broad class of MessageBroker >> services. The majority of those I'm familiar with could easily make >> do with this metadata. The semantics of messages having a text >> address, an optional content type, and an optional property list >> covers a very broad set of MessageBroker scenarios. On the other >> hand, without this additional message metadata, the protocol would >> not be usable by any MessageBrokers I'm aware of. > >I think the argument goes rather like this: If the metadata is to be >used by the protocol, the semantics of the usage should be defined. If >it's not defined, there's no interoperability. If there's no >interoperability, there's no point in having a standard in the first place. > >>> 2. AFAICS there's nothing in the spec that presumes existence of >>> the broker. It can be as well used for direct communication >>> between applications. Thus, I would suggest replacing messaging >>> broker/messaging client terminology with WebSocket server and >>> WebSocket client wording. >>> >> Yes, while the protocol has been defined for the MessageBroker >> usecase, nothing prevents its use in other contexts. On the other >> hand, if it were called 'foobar' instead of 'MessageBroker' it would >> be hard to explain why it contains the specific elements it does. > >What I meant was that there are messaging solutions out there with no >broker (Tibco RV, LBM, 0MQ). There's nothing expect the "broker" wording >in the protocol to prevent these solutions to use the protocol. > I was using the term 'MessageBroker' to represent the abstract messaging service the client is using for message transport/distribution. You are right that nothing prevents an endpoint taking on the roles of both client and 'broker'. Possibly there is a better term for capturing the messaging role of the endpoint a client is connecting to. Please send suggestions ... >Btw, I've heard something about Kaazing providing access to Tibco >through the web on top of websockets... > >>> 3. As for reliability itself, it should be clear what kind of >>> error conditions is the protocol meant to handle. Possible >>> options: >>> >>> a. Network failure. If so, how does it differ from simply turning >>> off TCP keepalives? >>> >>> b. Client failure and restart? >>> >>> c. Server failure and restart? >>> >> >> The reliability elements of MBWS are just the protocol elements that >> client and MessageBroker use to jointly create and maintain a >> connection abstraction. This shared abstraction exists independent of >> MBWS. This allows a connection to be 'carried' over an open-ended >> sequence of MBWS sessions. Since connections exist independent of the >> network, they survive any form of network failure. > >This is interesting. Can you give an example of such network failure? Any failure that abnormally terminates a WebSocket session will require resynchronization of the duplex messaging stream for a connection. The session failure could be due to a wide range of issues from hardware problems to TCP timeouts caused by congestion, etc. In Enterprise messaging, reliable message transport requires what amounts to transport transactions. This adds complexity and overhead. For WebSocket, a stream oriented, message window based resynchronization technique is a better fit. Unlike Enterprise messaging, this distributes the responsibility for reliability equally between client and broker. > >> The degree to which a connection will or won't survive a >> client/MessageBroker failure depends entirely on the ability of the >> client/MessageBroker to retain the state needed for it to maintain >> the connection across its failure. MBWS does not define how this is >> to be done; however, there are many practical ways of doing it. A >> client or MessageBroker could fully implement MBWS and only recover >> from failed MBWS sessions (i.e. not support connection recovery >> across program failures). > >Ack. The failures of server/client are not addressed in the protocol. >You can handle them on top of it though. > >Martin --Boundary_(ID_IpblXUIJcEgxeTYmvFpoBw) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT

Hi Martin,

Thanks for the feedback, See comments below ...

-- Mark

>Hi Mark,

>

>>> 1. Given the explicit focus on reliability, it's strange that the

>>> proposal deals with message metadata, which have to do with broker

>>> or even application behaviour and have absolutely nothing to do

>>> with reliability. What ensues is a spec where metadata are defined

>>> as opaque syntactic placeholders with no associated semantics. The

>>> semantics are meant to be defined on the broker or application

>>> level. The question is whether it doesn't follow that the syntax

>>> should be defined on those layers as well.

>>>

>>

>> Both the reliability and message metadata are defined with the

>> expectation that they are generic for a broad class of MessageBroker

>> services. The majority of those I'm familiar with could easily make

>> do with this metadata. The semantics of messages having a text

>> address, an optional content type, and an optional property list

>> covers a very broad set of MessageBroker scenarios. On the other

>> hand, without this additional message metadata, the protocol would

>> not be usable by any MessageBrokers I'm aware of.

>

>I think the argument goes rather like this: If the metadata is to be

>used by the protocol, the semantics of the usage should be defined. If

>it's not defined, there's no interoperability. If there's no

>interoperability, there's no point in having a standard in the first place.

>

>>> 2. AFAICS there's nothing in the spec that presumes existence of

>>> the broker. It can be as well used for direct communication

>>> between applications. Thus, I would suggest replacing messaging

>>> broker/messaging client terminology with WebSocket server and

>>> WebSocket client wording.

>>>

>> Yes, while the protocol has been defined for the MessageBroker

>> usecase, nothing prevents its use in other contexts. On the other

>> hand, if it were called 'foobar' instead of 'MessageBroker' it would

>> be hard to explain why it contains the specific elements it does.

>

>What I meant was that there are messaging solutions out there with no

>broker (Tibco RV, LBM, 0MQ). There's nothing expect the "broker" wording

>in the protocol to prevent these solutions to use the protocol.

>

I was using the term 'MessageBroker' to represent the abstract messaging service the client is using for message transport/distribution. You are right that nothing prevents an endpoint taking on the roles of both client and 'broker'.

Possibly there is a better term for capturing the messaging role of the endpoint a client is connecting to. Please send suggestions ...

>Btw, I've heard something about Kaazing providing access to Tibco

>through the web on top of websockets...

>

>>> 3. As for reliability itself, it should be clear what kind of

>>> error conditions is the protocol meant to handle. Possible

>>> options:

>>>

>>> a. Network failure. If so, how does it differ from simply turning

>>> off TCP keepalives?

>>>

>>> b. Client failure and restart?

>>>

>>> c. Server failure and restart?

>>>

>>

>> The reliability elements of MBWS are just the protocol elements that

>> client and MessageBroker use to jointly create and maintain a

>> connection abstraction. This shared abstraction exists independent of

>> MBWS. This allows a connection to be 'carried' over an open-ended

>> sequence of MBWS sessions. Since connections exist independent of the

>> network, they survive any form of network failure.

>

>This is interesting. Can you give an example of such network failure?

Any failure that abnormally terminates a WebSocket session will require resynchronization of the duplex messaging stream for a connection. The session failure could be due to a wide range of issues from hardware problems to TCP timeouts caused by congestion, etc.

In Enterprise messaging, reliable message transport requires what amounts to transport transactions. This adds complexity and overhead. For WebSocket, a stream oriented, message window based resynchronization technique is a better fit. Unlike Enterprise messaging, this distributes the responsibility for reliability equally between client and broker.

>

>> The degree to which a connection will or won't survive a

>> client/MessageBroker failure depends entirely on the ability of the

>> client/MessageBroker to retain the state needed for it to maintain

>> the connection across its failure. MBWS does not define how this is

>> to be done; however, there are many practical ways of doing it. A

>> client or MessageBroker could fully implement MBWS and only recover

>> from failed MBWS sessions (i.e. not support connection recovery

>> across program failures).

>

>Ack. The failures of server/client are not addressed in the protocol.

>You can handle them on top of it though.

>

>Martin

--Boundary_(ID_IpblXUIJcEgxeTYmvFpoBw)-- From sustrik@250bpm.com Thu Oct 6 02:39:17 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B001C21F8B61 for ; Thu, 6 Oct 2011 02:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.543 X-Spam-Level: X-Spam-Status: No, score=-0.543 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR6tMopNQPmz for ; Thu, 6 Oct 2011 02:39:16 -0700 (PDT) Received: from mail.moloch.sk (chrocht.moloch.sk [62.176.169.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B8E621F8B54 for ; Thu, 6 Oct 2011 02:39:15 -0700 (PDT) Received: from [10.9.1.2] (chello089173046084.chello.sk [89.173.46.84]) by mail.moloch.sk (Postfix) with ESMTPSA id BDE36180113D; Thu, 6 Oct 2011 11:42:23 +0200 (CEST) Message-ID: <4E8D7805.4050405@250bpm.com> Date: Thu, 06 Oct 2011 11:42:29 +0200 From: Martin Sustrik User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Hapner mark References: <92457F4F764A5C4785FCDBDDDD76477A123CA06E@dfweml506-mbx> In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123CA06E@dfweml506-mbx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , "csuconic@redhat.com" Subject: Re: [hybi] (no subject) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 09:39:17 -0000 Hi Mark, > >I think the argument goes rather like this: If the metadata is to be > >used by the protocol, the semantics of the usage should be defined. If > >it's not defined, there's no interoperability. If there's no > >interoperability, there's no point in having a standard in the first > place. The great thing about JMS was that it actually defined the canonical semantics of a messaging system. (Kudos, btw!) If it was just function signatures without an explanation what the individual calls are meant to do, it won't be pretty much useless. I think the same principle applies to wire protocols: Don't add anything to the protocol unless you are explicit about how it should be used. > >What I meant was that there are messaging solutions out there with no > >broker (Tibco RV, LBM, 0MQ). There's nothing expect the "broker" wording > >in the protocol to prevent these solutions to use the protocol. > > > > I was using the term 'MessageBroker' to represent the abstract messaging > service the client is using for message transport/distribution. You are > right that nothing prevents an endpoint taking on the roles of both > client and 'broker'. > > Possibly there is a better term for capturing the messaging role of the > endpoint a client is connecting to. Please send suggestions ... I would apply Occam's razor and go for "WebSocket server" and "WebSocket client". In traditional broker-based setting "WebSocket server" pretty straightforwardly translates to "messaging broker" and "WebSocket client" to "messaging client". Brokerless solutions are free to interpret the roles as they see fit. Btw, getting rid of broker/client terminology allow for using the protocol for broker-to-broker federation as well. > >This is interesting. Can you give an example of such network failure? > > Any failure that abnormally terminates a WebSocket session will require > resynchronization of the duplex messaging stream for a connection. The > session failure could be due to a wide range of issues from hardware > problems to TCP timeouts caused by congestion, etc. What's interesting here is that that's exactly what TCP is supposed to do. Obviously, there are issues with TCP reliability algorithm. It would be nice to identify those deficiencies and enumerate them in the introduction. (Are they deficiencies of TCP as such? Or maybe just problems with TCP implementations? etc.) > In Enterprise messaging, reliable message transport requires what > amounts to transport transactions. This adds complexity and overhead. > For WebSocket, a stream oriented, message window based resynchronization > technique is a better fit. Unlike Enterprise messaging, this distributes > the responsibility for reliability equally between client and broker. Definitely. Dealing with transactions is a mess. Martin From webmaster@zaphoyd.com Fri Oct 7 05:47:33 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBEF221F8997 for ; Fri, 7 Oct 2011 05:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.067 X-Spam-Level: X-Spam-Status: No, score=-1.067 tagged_above=-999 required=5 tests=[AWL=-0.882, BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YJoOadEWvJA for ; Fri, 7 Oct 2011 05:47:33 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 4522A21F8A6C for ; Fri, 7 Oct 2011 05:47:33 -0700 (PDT) Received: from c-68-51-77-246.hsd1.il.comcast.net ([68.51.77.246]:46271 helo=[10.0.1.82]) by sh78.surpasshosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1RC9sv-0004HU-M4 for hybi@ietf.org; Fri, 07 Oct 2011 08:50:43 -0400 From: Peter Thorson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 7 Oct 2011 07:50:39 -0500 Message-Id: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> To: hybi@ietf.org Mime-Version: 1.0 (Apple Message framework v1244.3) X-Mailer: Apple Mail (2.1244.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Subject: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 12:47:33 -0000 This issue came up while polishing up the error handling code for my WS = implementation. There doesn't seem to be a websocket close code = equivalent to HTTP 500/Internal server error. I would like to handle situations where my endpoint catches an internal = logic error and knows that continuing the connection will probably = result in bad/unknown behavior but knows that it is safe enough to close = the connection cleanly.=20 Example: I am a server and my handler for processing websocket messages = is interpreted code and that code has a syntax error. The websocket = server itself is fine and can safely close the connection but clearly = cannot process messages until someone fixes the missing semicolon = somewhere. In an HTTP server I would return 500/Internal Server error to = indicate that something on the server end screwed up and that there is = probably more information in the server log files to diagnose further. None of the current close codes (except 1006/abnormal closure - which = isn't allowed on the wire) really fit. I'd rather not just drop the = connection uncleanly/send back empty close frame since that provides no = information about what happened and makes figuring out whose logs I = should be looking at as an end application developer difficult. Browsers = only report the status code itself and not the reason so sending a = normal/going away error code with a more specific reason is less = helpful. What are other implementations doing in this case? Would = another close code for internal server error make sense? From arman@noemax.com Fri Oct 7 06:32:49 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8922E21F893C for ; Fri, 7 Oct 2011 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+HTi1Q0JsI7 for ; Fri, 7 Oct 2011 06:32:48 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E521F84FD for ; Fri, 7 Oct 2011 06:32:48 -0700 (PDT) Received: from ArmanLaptop by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id QXQ56055; Fri, 07 Oct 2011 16:35:55 +0300 From: "Arman Djusupov" To: "'Hapner mark'" , "'Greg Wilkins'" References: <92457F4F764A5C4785FCDBDDDD76477A123C6E12@dfweml506-mbx> <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A123C6EA7@dfweml506-mbx> Date: Fri, 7 Oct 2011 16:35:51 +0300 Message-ID: <001201cc84f6$0c3d0a90$24b71fb0$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIvPDy6D7yKeOTtjVlL/HbBCtGu0AIq681mAbh8CBGUjFKe0A== Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Subprotocol and Control Frames X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 13:32:49 -0000 I believe that this sub-protocol is needed, as it can provide a common = way of message dispatching and connection recovery for various = application=F3 irrespective of what format they use for the message. For example there are various JSON RPC or Protobuff RPC in development = and most of them are not interoperable with each other due to incompatible message metadata format. Having a common message metadata format would = be very beneficial. Message Extension Data Fields =20 | Address | base 128 varint | UTF-8 character string | | Content-Type | base 128 varint | UTF-8 character string | | Property List | base 128 varint | Sequence of Property | =20 In addition to the implicit sequence number, a MessageID/ReleatesTo = field could also be added to the message header. Most applications would need = this to associate the messages they receive with the messages they send. This property can obviously be added to the property list or even be part of = the Address field but this would add additional overhead when processing the message. For example, multiple outbound requests were sent by one side and = received by the remote side in correct order, but processing each request took different amounts of time so the responses may arrive in a different = order. In such cases the application that sent the requests would have to use a Property list and search for e.g. "RelatesTo" in message properties. = This would definitely be slower than if there would be some sort of fixed "Topic/ID" field in the message header that would associate requests = with responses. This field could be a variant integer number for faster processing. With best regards, Arman > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf = Of > Hapner mark > Sent: Wednesday, October 05, 2011 4:36 AM > To: Greg Wilkins > Cc: hybi@ietf.org > Subject: Re: [hybi] Subprotocol and Control Frames >=20 > Thanks for everyone's comments. Clebert and I are learning as we go = ... >=20 > Greg, >=20 > Thanks for the clarifications ... >=20 > I agree that MBWS could define its own framing protocol within the > WebSocket message payload, i.e. MBWS could be defined as a WebSocket > subprotocol. (Sorry for my original confabulation of subprotocol and > extension) >=20 > The option also exists to implement MBWS as it is currently defined as = a > WebSocket extension that adds extension data and extension control = frame > opcodes. >=20 > WebSocket provides support for both subprotocols and extensions and I > believe both are available for use by outside parties as long as the = IANA > registration mechanisms are followed. Is this correct? >=20 > My primary concern is that implementing MBWS as a subprotocol will add > complexity and overhead. The only rationale I can see for defining = MBWS as > a subprotocol would be if, for some reason, browsers/proxies/firewalls > blocked WebSocket extensions, i.e. MBWS has to use a 'subprotocol = tunnel' > through them. >=20 > The core point in favor of using an extension is that WebSocket = already > defines an excellent framing protocol. There is simply no need for = MBWS to > layer yet another framing protocol over it. It would be equivalent to = a REST > service defining a request-response framing protocol within the HTTP > request-response body when all it needed was to add a few new header > fields. Let me see, I think I remember this being done, it was called = WS* :>) >=20 > The point about control frame opcodes being 'scarce' is an issue; = however, > the spec already suggests the use of an extension bit to resolve this. >=20 > The spec does not describe how the opcode space will be distributed = across > extensions. It does not say whether or not an extension opcode value = can be > 'redefined' by different extensions. Since a session can only be = operating > under one extension, there does not appear to be a technical reason = why > extensions could not redefine extension opcodes. If this is possible, = then > MBWS does not 'use up' any extension opcodes. >=20 > Perhaps the fact that WebSocket itself does not reserve any of the = opcode > extension space for itself is an issue. There seems to be an = implication in the > comments so far that, in effect, they are all reserved and none are available > for 'outside' use. I don't believe this is the case. >=20 > I think subprotocols and extensions are both useful. For an = application > specific case, say the transport of Insurance Policies and Quotes, defining a > subprotocol for transport of this Insurance Message Schema would be > sensible. I believe that MBWS is case where the use of an extension is > sensible. >=20 > Again, I think this issue is worthy of some serious debate. I'm not = ready to > concede, as yet, that defining MBWS as a WebSocket extension is wrong. >=20 > -- Mark >=20 > >On 5 October 2011 07:23, Hapner mark > wrote: > >> > >> In my reading of draft 17, I do not find a definition of = subprotocol that >> > puts any restrictions on the WebSocket extensibility features a subprotocol > >> may use. > > > >Mark, > > > >in section 5.8 Extensibility: > > > > This specification provides opcodes 0x3 through 0x7 and > > 0xB through 0xF, the extension data field, and the frame-rsv1, = frame- > > rsv2, and frame-rsv3 bits of the frame header for use by = extensions. > > > >So while there is no explicit restriction on subprotocols using >opcodes, > the only allowance given is to extensions. > > > >> If the sense of the WG is that subprotocols are restricted to use = >> only > extension data and message format/schema restrictions, this is not >> > apparent in the content of this draft. > > > >The specification also describes subprotocols in section 1.3 as > > > ... used to indicate what subprotocols (application-level = protocols > > layered over the WebSocket protocol) are acceptable to the = client. > > > > > >> It is my observation that there will be a number of WebSocket = usecases > that >> could benefit from the ability to define usecase-specific = control > frames to >> mediate message flow. Telling developers to stuff this > mediation protocol >> into extension data rather than in control = frames does > not appear to >> increase security; > >Firstly subprotocols can no = more use > extensions data than they can use >extension opcodes. > >They can however use the payload and are free to define arbitrary > >message semantics within that payload that may include application > >control messages. > > > >The restriction of subprotocols to not use opcodes is not done for > >security. It is done for protocol layering reasons. > >The opcode is there to inform the WS implementation (and it's > >extensions) how to handle the message. There is no application > >semantics associated with any of the opcodes. For example the text = vs > >binary opcodes instructs the implementation if UTF-8 decoding is >required > and to which part of the websocket API a message should be = >delivered. > There is no semantic restriction imposed by a binary >message, which = may > actually be a text message, but one for which the >application or > subprotocol has taken responsibility for character >encoding. > > > >> rather, it likely decreases security because it >> intermixes = control with > data which is a fundamentally bad thing for a >> protocol design to = do. The > two control frames defined by MBWS are fairly simple and are likely = >> > representative of what other subprotocols would need. It would be far > better >> to allow MBWS to properly factor its control and data than force it > to put >> control in its data. > > > >Indeed there is a limitation in the current protocol of providing = only >a > single stream per connection, so there can be no separation of > >control/data on a single connection. However the solution is not = to > >allow applications to put their control messages into the protocols >control > stream, but rather to better support multiple streams - ie >MUX. For = the > protocol, it is clear that there are two streams of > >frames: data and control, but there is no reason why this taxonomy >will > apply generally to all applications and subprotocols. There may >be = use > cases where applications/subprotocols need n streams or control = >frames > larger than 125 bytes. > > > >The solution is to not see that the protocols control frame = mechanism >is > somewhat like the applications need for control messages and thus >to > attempt to expose the protocols control channel to the application. > > The solution is to allow applications to efficiently create their = own >control > channels - MUX! > > > > > >> It is true that TCP does not support application control = extension; > however, >> HTTP clearly does support this with a very open-ended > extension of the HTTP >> header. The WG needs to think carefully = about > this. I hope there is room to >> resolve this issue in this version = of > WebSocket. > >> It is up to the W3C WebSocket API to insure it provides the functionality > >> that both native users of WebSocket and implementors of WebSocket = >> > subprotocols require. In looking over what is currently defined, this = API >> > does not yet provide an API sufficient for the later. Possibly later = it >> will. I > don't believe that the design of WebSocket needs to be restricted by = >> the > current limitations of this API. > > > >This distinction between extensions and subprotocols has not been = made > >because of any API limitations. It has been done for good protocol > >layering reasons. > > > >Consider if we open up the control channel to applications, then = this >will > make the task of creating things like MUX extensions much more >difficult. > The mux solution would have to allow for extending control >frames = with > extension data so that they may be correctly routed to the >right application > control channel. But if a 125 byte application >control frame is = sent, then > there may not be sufficient room to add > >the channel identifier! Also if control frames are used to > >implement MUX flow control, will applications use their application > >control frames to attempt to get around this flow control? We may = end > >up needing to put flow control on the control channel to limit the >number > of application control frames. > > > >Mixing application control frames with protocol control frames is a >far > worse "solution" than mixing application control messages with >application > data messages. > > > >regards > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From julian.reschke@gmx.de Fri Oct 7 09:07:27 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C70421F8BD3 for ; Fri, 7 Oct 2011 09:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.287 X-Spam-Level: X-Spam-Status: No, score=-104.287 tagged_above=-999 required=5 tests=[AWL=-1.688, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cm2k5vAUR99l for ; Fri, 7 Oct 2011 09:07:25 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id A8B5621F8BDB for ; Fri, 7 Oct 2011 09:07:24 -0700 (PDT) Received: (qmail invoked by alias); 07 Oct 2011 16:10:36 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp011) with SMTP; 07 Oct 2011 18:10:36 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+Q8Ys/iwOQIf8TbHhhrsLNmLFD2bwzrBw2NBk5uq EpjOplaKjQrXba Message-ID: <4E8F247B.5010907@gmx.de> Date: Fri, 07 Oct 2011 18:10:35 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: "Hybi (hybi@ietf.org)" References: <4DCB8D70.4010509@gmx.de> In-Reply-To: <4DCB8D70.4010509@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Oct 2011 16:07:27 -0000 On 2011-05-12 09:34, Julian Reschke wrote: > ... > What we should make clear is that although fragment identifiers > currently do not make sense with websockets URIs, this does *not* affect > the syntax. So if you need a literal "#" in a WS URI, you will have to > percent-escape it. > ... The text that ended up in the spec () is: > Fragment identifiers are meaningless in the context of WebSocket > URIs, and MUST NOT be used on these URIs. The character "#" in URIs > MUST be escaped as %23 if used as part of the query component. That's a bit misleading as it needs to be escaped not only in the query component. Maybe this can be fixed in AUTH48? Best regards, Julian From art.barstow@nokia.com Fri Oct 7 06:25:42 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 339F821F8B2A for ; Fri, 7 Oct 2011 06:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htvzemICTxrI for ; Fri, 7 Oct 2011 06:25:41 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 570F821F8B29 for ; Fri, 7 Oct 2011 06:25:41 -0700 (PDT) Received: from bsdhcp175155.americas.nokia.com (bsdhcp175155.americas.nokia.com [172.19.175.155]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p97DSrMM000671 for ; Fri, 7 Oct 2011 16:28:53 +0300 Message-ID: <4E8EFE94.8090504@nokia.com> Date: Fri, 07 Oct 2011 09:28:52 -0400 From: Arthur Barstow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: "hybi@ietf.org" References: <4E8EE89C.3060204@nokia.com> In-Reply-To: <4E8EE89C.3060204@nokia.com> X-Forwarded-Message-Id: <4E8EE89C.3060204@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 07 Oct 2011 11:20:50 -0700 Subject: [hybi] Fwd: Spec changes for LCs and later maturity levels [Was: Re: RfC: LCWD of Web Socket API; comment deadline October 21] X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 13:25:42 -0000 [ I meant to Cc the hybi list on the e-mail below which is my response to Julian's email archived at ] -------- Original Message -------- Subject: Spec changes for LCs and later maturity levels [Was: Re: RfC: LCWD of Web Socket API; comment deadline October 21] Resent-Date: Fri, 7 Oct 2011 11:55:51 +0000 Resent-From: Date: Fri, 7 Oct 2011 07:55:08 -0400 From: ext Arthur Barstow To: Julian Reschke , public-webapps On 10/5/11 3:15 AM, ext Julian Reschke wrote: > On 2011-09-29 18:28, Arthur Barstow wrote: >> On September 29, aLCWD of Web Sockets API was published: >> >> http://www.w3.org/TR/2011/WD-websockets-20110929/ >> >> Please send all comments to public-webapps@w3.org by October 21. > > I just noted that as of yesterday, the API spec contains the custom > URI parsing algorithm that we removed from the protocol spec a long > time ago. > > This was a post-LC change. > > What's the Webapps WG's procedure to manage changes during LC? Hi Julian, All - I changed the subject to reflect the general process-related issue here. I will respond separately to the WebSocket specifics ... WebApps has always used the Edit First, Review Second process, as documented in our [WorkMode] document. Overall, I think the process has worked reasonably well, yet it can create some challenges, especially as a spec enters the later maturity levels i.e. LC and later. For specs in LC or later, I think the Editor(s) should feel free to make minor changes e.g. editorial changes and bug fixes that would not invalidate an implementation, without any explicit notification to the group. However, for major changes e.g. a new feature or a bug fix that would affect an implementation, I think it is reasonable to expect the Editor(s) to make some type of explicit notification and that could be done via an e-mail, bug report, new issue (e.g. Tracker), etc. Some groups have defined relatively detailed processes for handling changes to specs at LC and later. My expectation is that everyone is participating with the best of intentions, and as such, I would prefer to not be overly prescriptive with the group's change process. If others have additional or contrary thoughts about how the group should handle spec changes for specs at LC or later, please speak up. -Art Barstow [WorkMode] http://www.w3.org/2008/webapps/wiki/WorkMode From art.barstow@nokia.com Fri Oct 7 06:27:36 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE94921F85B8 for ; Fri, 7 Oct 2011 06:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbcnoyuvSwN3 for ; Fri, 7 Oct 2011 06:27:36 -0700 (PDT) Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4F521F8B0D for ; Fri, 7 Oct 2011 06:27:36 -0700 (PDT) Received: from bsdhcp175155.americas.nokia.com (bsdhcp175155.americas.nokia.com [172.19.175.155]) by mgw-da02.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p97DUhnB008196; Fri, 7 Oct 2011 16:30:43 +0300 Message-ID: <4E8EFF03.2070103@nokia.com> Date: Fri, 07 Oct 2011 09:30:43 -0400 From: Arthur Barstow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: ext Julian Reschke , Ian Hickson References: <4E849CAD.8090204@nokia.com> <4E8C0421.80109@gmx.de> In-Reply-To: <4E8C0421.80109@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 07 Oct 2011 11:21:09 -0700 Cc: public-webapps , "hybi@ietf.org" Subject: Re: [hybi] RfC: LCWD of Web Socket API; comment deadline October 21 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 13:27:37 -0000 Hi Hixie, In [1], Julian asks about Web Socket API rev 1.247 [2], the change that adds the Parsing WebSocket URLs section (CVS comment "Revert the part of r5409 that removed the URL parsing algorithms, since it's no longer defined in the protocol spec. (whatwg r6632)"). Would you please elaborate on this change? -AB [1] http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0125.html [2] http://dev.w3.org/cvsweb/html5/websockets/Overview.html.diff?r1=1.246;r2=1.247;f=h On 10/5/11 3:15 AM, ext Julian Reschke wrote: > On 2011-09-29 18:28, Arthur Barstow wrote: >> On September 29, aLCWD of Web Sockets API was published: >> >> http://www.w3.org/TR/2011/WD-websockets-20110929/ >> >> Please send all comments to public-webapps@w3.org by October 21. > > I just noted that as of yesterday, the API spec contains the custom > URI parsing algorithm that we removed from the protocol spec a long > time ago. > > This was a post-LC change. > > What's the Webapps WG's procedure to manage changes during LC? > > Best regards, Julian From ibc@aliax.net Sat Oct 8 13:46:38 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA9F21F8B32 for ; Sat, 8 Oct 2011 13:46:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.633 X-Spam-Level: X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlS5U2tQ6g4E for ; Sat, 8 Oct 2011 13:46:37 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9680621F87FA for ; Sat, 8 Oct 2011 13:46:37 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4795708vcb.31 for ; Sat, 08 Oct 2011 13:49:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.120.12 with SMTP id b12mr971772vcr.111.1318106993545; Sat, 08 Oct 2011 13:49:53 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Sat, 8 Oct 2011 13:49:53 -0700 (PDT) In-Reply-To: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> Date: Sat, 8 Oct 2011 22:49:53 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Peter Thorson Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: hybi@ietf.org Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 08 Oct 2011 20:46:38 -0000 2011/10/7 Peter Thorson : > Browsers only report the status code itself and not the reason The WS API tells you the status code and the reason (when present) of the closure. > so sending a normal/going away error code with a more specific reason is = less helpful. What are other implementations doing in this case? Would anot= her close code for internal server error make sense? Good question :) --=20 I=C3=B1aki Baz Castillo From gregw@intalio.com Sat Oct 8 15:03:41 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE2D821F8B20 for ; Sat, 8 Oct 2011 15:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.92 X-Spam-Level: X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TucV+Gv9+l0u for ; Sat, 8 Oct 2011 15:03:41 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 37C9B21F8AE9 for ; Sat, 8 Oct 2011 15:03:41 -0700 (PDT) Received: by vcbfo11 with SMTP id fo11so4816143vcb.31 for ; Sat, 08 Oct 2011 15:06:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.37.44 with SMTP id v12mr7980059vdj.53.1318111617954; Sat, 08 Oct 2011 15:06:57 -0700 (PDT) Received: by 10.52.186.134 with HTTP; Sat, 8 Oct 2011 15:06:57 -0700 (PDT) In-Reply-To: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> References: <02F41063-6221-4EB8-A4E4-2E396A6B946C@zaphoyd.com> Date: Sun, 9 Oct 2011 09:06:57 +1100 Message-ID: From: Greg Wilkins To: Peter Thorson Content-Type: text/plain; charset=ISO-8859-1 Cc: hybi@ietf.org Subject: Re: [hybi] WS close code equivalent to HTTP 500/Internal Server Error X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 08 Oct 2011 22:03:41 -0000 On 7 October 2011 23:50, Peter Thorson wrote: > This issue came up while polishing up the error handling code for my WS implementation. There doesn't seem to be a websocket close code equivalent to HTTP 500/Internal server error. I've noted before that we don't have such a general close code and I think the addition of one would be good... even at this very late stage. Currently in Jetty if the message handling code throws and exception, I'm sending 1007 bad payload. ie blaming the other end, when it is just as likely there is a local problem that has caused the issue. This is obviously going to wrong sometimes, but I can't see a better option with the spec as it is. cheers From tyoshino@google.com Wed Oct 12 00:50:06 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61A8C21F8C70 for ; Wed, 12 Oct 2011 00:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGQTb3TF+q7A for ; Wed, 12 Oct 2011 00:50:05 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7821F8C66 for ; Wed, 12 Oct 2011 00:50:05 -0700 (PDT) Received: from hpaq5.eem.corp.google.com (hpaq5.eem.corp.google.com [172.25.149.5]) by smtp-out.google.com with ESMTP id p9C7IB8p029602 for ; Wed, 12 Oct 2011 00:18:12 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1318403892; bh=FdowrWROaWstTI6eLkU/TdYiKeE=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=dM5NrN+23JBdwYWX8jMYTAzWVI1ppdvznRkXxwt3x2gHfgsM0WJoUMs4GdTLdzre1 SWDuqkZwmt23ZllJUhsPg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:content-type:x-system-of-record; b=hV3TM/TJYL+NX4LCgnHD34Mt86L3k7G6ZlBB8/ql90c1coj91RA775TgLJRTSC26B 6VyxkXez/be1EgQ6SqfoQ== Received: from iaqq3 (iaqq3.prod.google.com [10.12.43.3]) by hpaq5.eem.corp.google.com with ESMTP id p9C7I9EN009129 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 12 Oct 2011 00:18:10 -0700 Received: by iaqq3 with SMTP id q3so1229388iaq.11 for ; Wed, 12 Oct 2011 00:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=J+nHtFMiBtFIU8MBz+hCQNlxJEM0gFIKF7SopccAQGk=; b=rJF/9VeryWcMFddFGbXKaiCZ8FNn/7AUUKNCF3Su7za+IUtQqKpHiQ3cgtvdaJmx6i M0rxtG+JeGJzn/8A6V8g== Received: by 10.231.83.211 with SMTP id g19mr11743879ibl.26.1318403889359; Wed, 12 Oct 2011 00:18:09 -0700 (PDT) Received: by 10.231.83.211 with SMTP id g19mr11743839ibl.26.1318403888123; Wed, 12 Oct 2011 00:18:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.31.205 with HTTP; Wed, 12 Oct 2011 00:17:48 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Wed, 12 Oct 2011 16:17:48 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=000e0cd72ad26c0f8804af14d32d X-System-Of-Record: true Subject: Re: [hybi] Per-frame compression extension proposal X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Oct 2011 07:50:06 -0000 --000e0cd72ad26c0f8804af14d32d Content-Type: text/plain; charset=ISO-8859-1 Hi all, As the main spec is almost done, shall we resume work on compression? Here's the latest draft of per-frame deflate compression extension. http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-04 Based on input from the list, this spec includes - inter frame compression context sharing - COMP bit -- so that we can turn off compression for data that doesn't compress well e.g. small frames - LZ77 window size option -- so that endpoints with memory limited can ask the other peer not to use big window size - frame-by-frame compression option -- for intermediaries that just cut and dispatch frames to backends but don't want to do much work e.g. load balancer - overhead elimination proposed in RFC1979 Thanks Takeshi --000e0cd72ad26c0f8804af14d32d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

As the main spec is almost done, shall we resume= work on compression?

Here's the latest draft = of per-frame deflate compression extension.
http://= tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-04

Based on input from the list, this spec includes
<= div>- inter frame compression context sharing
- COMP bit
-- so that we can turn off compression for data that doesn't compress= well e.g. small frames

- LZ77 window size option

-- so that endpoints with memory l= imited can ask the other peer not to use big window size

- frame-= by-frame compression option

-- for intermediaries that just cut a= nd dispatch frames to backends but don't want to do much work e.g. load= balancer

- overhead elimination proposed in RFC1979

Th= anks

Takeshi

--000e0cd72ad26c0f8804af14d32d-- From art.barstow@nokia.com Fri Oct 14 04:39:30 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F67D21F8B1A for ; Fri, 14 Oct 2011 04:39:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oawpSeTMdGsk for ; Fri, 14 Oct 2011 04:39:30 -0700 (PDT) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id CBA3A21F8B16 for ; Fri, 14 Oct 2011 04:39:29 -0700 (PDT) Received: from bsdhcp175155.americas.nokia.com (bsdhcp175155.americas.nokia.com [172.19.175.155]) by mgw-da01.nokia.com (Switch-3.4.4/Switch-3.4.3) with ESMTP id p9EBdRKt002652; Fri, 14 Oct 2011 14:39:27 +0300 Message-ID: <4E981F7D.7030700@nokia.com> Date: Fri, 14 Oct 2011 07:39:41 -0400 From: Arthur Barstow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: public-webapps , "hybi@ietf.org" References: <4E849CAD.8090204@nokia.com> In-Reply-To: <4E849CAD.8090204@nokia.com> X-Forwarded-Message-Id: <4E849CAD.8090204@nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean X-Mailman-Approved-At: Fri, 14 Oct 2011 07:42:36 -0700 Subject: [hybi] Reminder: RfC: LCWD of Web Socket API; comment deadline October 21 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 14 Oct 2011 11:39:30 -0000 -------- Original Message -------- Subject: RfC: LCWD of Web Socket API; comment deadline October 21 Resent-Date: Thu, 29 Sep 2011 16:29:15 +0000 Resent-From: Date: Thu, 29 Sep 2011 12:28:29 -0400 From: ext Arthur Barstow To: public-webapps On September 29, aLCWD of Web Sockets API was published: http://www.w3.org/TR/2011/WD-websockets-20110929/ Please send all comments to public-webapps@w3.org by October 21. From stpeter@stpeter.im Mon Oct 17 08:26:53 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E71521F8C1C for ; Mon, 17 Oct 2011 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfSPDLEURnqq for ; Mon, 17 Oct 2011 08:26:52 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CE28621F8C15 for ; Mon, 17 Oct 2011 08:26:52 -0700 (PDT) Received: from dhcp-64-101-72-193.cisco.com (unknown [64.101.72.193]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id BCD8A41ECE; Mon, 17 Oct 2011 09:31:42 -0600 (MDT) Message-ID: <4E9C493B.90500@stpeter.im> Date: Mon, 17 Oct 2011 09:26:51 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Julian Reschke References: <4DCB8D70.4010509@gmx.de> <4E8F247B.5010907@gmx.de> In-Reply-To: <4E8F247B.5010907@gmx.de> X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "Hybi $hybi@ietf.org$" Subject: Re: [hybi] Editorial issue: Ignoring rather than failing on URI fragments X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:26:53 -0000 On 10/7/11 10:10 AM, Julian Reschke wrote: > On 2011-05-12 09:34, Julian Reschke wrote: >> ... >> What we should make clear is that although fragment identifiers >> currently do not make sense with websockets URIs, this does *not* affect >> the syntax. So if you need a literal "#" in a WS URI, you will have to >> percent-escape it. >> ... > > The text that ended up in the spec > () > is: > >> Fragment identifiers are meaningless in the context of WebSocket >> URIs, and MUST NOT be used on these URIs. The character "#" in URIs >> MUST be escaped as %23 if used as part of the query component. > > That's a bit misleading as it needs to be escaped not only in the query > component. Maybe this can be fixed in AUTH48? Yes, fixing this in AUTH48 seems appropriate. For those unfamiliar with IETF processes and lingo, the "AUTH48" state is described at http://www.rfc-editor.org/pubprocess.html#auth48 ... Peter -- Peter Saint-Andre https://stpeter.im/ From jduell.mcbugs@gmail.com Tue Oct 18 15:02:00 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6156121F8B9E for ; Tue, 18 Oct 2011 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQ0LlslABZSd for ; Tue, 18 Oct 2011 15:02:00 -0700 (PDT) Received: from dm-mail01.mozilla.org (dm-mail01.mozilla.org [63.245.208.150]) by ietfa.amsl.com (Postfix) with ESMTP id 071C621F8B3A for ; Tue, 18 Oct 2011 15:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at mozilla.org Received: from [192.168.1.190] (v74-nslb.mozilla.org [10.2.74.4]) (Authenticated sender: jduell@mozilla.com) by dm-mail01.mozilla.org (Postfix) with ESMTP id 1374DB801D for ; Tue, 18 Oct 2011 15:01:59 -0700 (PDT) Message-ID: <4E9DF756.1070108@gmail.com> Date: Tue, 18 Oct 2011 15:01:58 -0700 From: Jason Duell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [hybi] Clarification: only one onerror call per websocket? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:02:00 -0000 Implementation detail: Am I reading the spec correctly when I say that it implies that at most one "error" event should be dispatched per websocket? I.e. if a user does something that requires the "fail the websocket connection" algorithm (like calling close() before the ws connection has been established), and the server *also* replies with a non-101 status code, we should only call onerror once. My read is that both of these actions "fail" the ws, but that the "close the ws" algorithm only sends out one error msg (if the ws failed or was closed w/prejudice). Jason Duell Mozilla From derhoermi@gmx.net Tue Oct 18 15:37:08 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A51F0C36 for ; Tue, 18 Oct 2011 15:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs1KyzAZfzzu for ; Tue, 18 Oct 2011 15:37:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id C3C0D21F8AF8 for ; Tue, 18 Oct 2011 15:37:07 -0700 (PDT) Received: (qmail invoked by alias); 18 Oct 2011 22:37:05 -0000 Received: from dslb-094-223-193-217.pools.arcor-ip.net (EHLO HIVE) [94.223.193.217] by mail.gmx.net (mp013) with SMTP; 19 Oct 2011 00:37:05 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX181pqgEZFU1jkoyR+JPQKP/nzKDWO5sBvAH/xIFEi fsS67fdP06vdyE From: Bjoern Hoehrmann To: Jason Duell Date: Wed, 19 Oct 2011 00:37:13 +0200 Message-ID: References: <4E9DF756.1070108@gmail.com> In-Reply-To: <4E9DF756.1070108@gmail.com> 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] Clarification: only one onerror call per websocket? X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 22:37:09 -0000 * Jason Duell wrote: >Am I reading the spec correctly when I say that it implies that at most >one "error" event should be dispatched per websocket? I.e. if a user >does something that requires the "fail the websocket connection" >algorithm (like calling close() before the ws connection has been >established), and the server *also* replies with a non-101 status code, >we should only call onerror once. This seems to be a question for the W3C API specification, comments on which should be sent to . It seems there is only one point from where error events might be dispatched in the algorithm, you just have to check that "the WebSocket connection is closed" happens only once. This happens "When the underlying TCP connection is closed" and "If the WebSocket connection could not be established". I'd think it is obvious that you can determine either only once without additional attempts to establish a new connection and it seems fair to assume they are mutually exclusive, but I have not tried to debug all the relevant specifications in their entirety to reverse-engineer a complete answer. I note in passing that the API proposal says "decoded as UTF-8, with error handling" without defining what that means as far as I could find. This may mean that clients should recover from errors in the "reason" phrase, which might go against the Working Group's decision to treat encoding errors as fatal errors. I also note the "review period" ends this week. While that has no formal consequences, people might want to make sure they submit their comments very soon if they have any. -- 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 tyoshino@google.com Thu Oct 20 00:40:52 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CE021F84F9 for ; Thu, 20 Oct 2011 00:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.375 X-Spam-Level: X-Spam-Status: No, score=-103.375 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=2.601, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ6JxU32FBVl for ; Thu, 20 Oct 2011 00:40:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D743D21F85AA for ; Thu, 20 Oct 2011 00:40:51 -0700 (PDT) Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p9K7eoOM013656 for ; Thu, 20 Oct 2011 00:40:50 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319096450; bh=2a344A7WyFDWnW9Q0+ZPahd0rVA=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=bTBnFKQ5UAOqTfUn+ijqmk2WzJLw5UnLJQdObBTnl75gHBhaUKea5CMfiiMPtJ2wb V6495zb+SjHx2KgXze9sA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:from:date:message-id:subject:to: content-type:x-system-of-record; b=a94hbUhsN6rdDs5xW/0PXsK9Upb1WDMbWCOc4xbUvZQ/tfc/v2rmesXQeO9lHdc00 ckMZ0/VBsaY0apFW5rD1A== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by wpaz5.hot.corp.google.com with ESMTP id p9K7ZdvA008215 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Thu, 20 Oct 2011 00:40:49 -0700 Received: by gyf1 with SMTP id 1so3615174gyf.0 for ; Thu, 20 Oct 2011 00:40:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=oUKSokxJwtzTVwwzVmY+8gPETARfsxLprH+ix28rDUw=; b=TuxzrHjujGcIcxSpd/S3oJKdulXi++/b3vp4i+6FZzEuXkEFfNdsKptBIxnO7IFraW LsBJZ4zgzD7lxToxxBbg== Received: by 10.150.135.19 with SMTP id i19mr7586123ybd.99.1319096449369; Thu, 20 Oct 2011 00:40:49 -0700 (PDT) Received: by 10.150.135.19 with SMTP id i19mr7586114ybd.99.1319096449177; Thu, 20 Oct 2011 00:40:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.57.10 with HTTP; Thu, 20 Oct 2011 00:40:29 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 20 Oct 2011 16:40:29 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=000e0cd59cd2471adc04afb613d5 X-System-Of-Record: true Subject: [hybi] Rule for multiple Sec-WebSocket-Extensions headers X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 20 Oct 2011 07:40:52 -0000 --000e0cd59cd2471adc04afb613d5 Content-Type: text/plain; charset=ISO-8859-1 Hi, The last paragraph of draft 17 11.3.2. says use of multiple Sec-WebSocket-Extensions is allowed in request but NOT in response. It contradicts with 4.2.2. step 6. Maybe just a bug on 13->14 (seems c&p-ed text for Sec-WebSocket-Protocol but wasn't edited properly)? --000e0cd59cd2471adc04afb613d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

The last paragraph of=A0draft = 17=A011.3.2. says use of multiple=A0Sec-WebSocket-Extensions is allowed= in request but NOT in response. It contradicts with=A04.2.2. step 6.

Maybe just a bug on=A013->14=A0(s= eems=A0c&p-ed text for Sec-WebSocket-Protocol but wasn't edited pro= perly)?

--000e0cd59cd2471adc04afb613d5-- From stpeter@stpeter.im Thu Oct 20 10:11:14 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF2621F8B92 for ; Thu, 20 Oct 2011 10:11:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.73 X-Spam-Level: X-Spam-Status: No, score=-102.73 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMgy4Wvab1eU for ; Thu, 20 Oct 2011 10:11:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id CB38B21F8B3A for ; Thu, 20 Oct 2011 10:11:13 -0700 (PDT) Received: from dhcp-64-101-72-202.cisco.com (unknown [64.101.72.202]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3847441E49; Thu, 20 Oct 2011 11:16:12 -0600 (MDT) Message-ID: <4EA05630.8020107@stpeter.im> Date: Thu, 20 Oct 2011 11:11:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Takeshi Yoshino References: In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: hybi@ietf.org Subject: Re: [hybi] Rule for multiple Sec-WebSocket-Extensions headers X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 20 Oct 2011 17:11:14 -0000 I think this is something that the editors can fix during AUTH48. On 10/20/11 1:40 AM, Takeshi Yoshino wrote: > Hi, > > The last paragraph of draft 17 > 11.3.2. > says use of multiple Sec-WebSocket-Extensions is allowed in request but > NOT in response. It contradicts with 4.2.2. step 6. > > Maybe just a bug on 13->14 > (seems c&p-ed > text for Sec-WebSocket-Protocol but wasn't edited properly)? From jat@google.com Fri Oct 21 13:20:35 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A902E1F0C49 for ; Fri, 21 Oct 2011 13:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGhXu4NzCMkY for ; Fri, 21 Oct 2011 13:20:34 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 8458B1F0C35 for ; Fri, 21 Oct 2011 13:20:33 -0700 (PDT) Received: from wpaz17.hot.corp.google.com (wpaz17.hot.corp.google.com [172.24.198.81]) by smtp-out.google.com with ESMTP id p9LKKVrS015627 for ; Fri, 21 Oct 2011 13:20:31 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319228431; bh=rtSMzpn4Xvut9ayaA2mBnAuS9ZA=; h=MIME-Version:From:Date:Message-ID:Subject:To:Content-Type; b=cqtYK35jbru7UfL+Gl6j/LNVnMjVH3b0i3cR5iqr8oQTbm9KAKdGmLu5jbJ9FpaLG 1wheq1hwRLessfIZAqQbQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:from:date:message-id:subject:to: content-type:x-system-of-record; b=QqDKX4ZmnfHE+7G8oeIODtJWMAga0VCkx60nIIVj/LNpp6tRmBwK7JZKdHmv8z3Zi DyPMGAnLSFdZIiYVQd2/A== Received: from qabj40 (qabj40.prod.google.com [10.224.21.168]) by wpaz17.hot.corp.google.com with ESMTP id p9LKJxAr015955 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 21 Oct 2011 13:20:30 -0700 Received: by qabj40 with SMTP id j40so8072334qab.10 for ; Fri, 21 Oct 2011 13:20:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record; bh=sCFUYkHCrA4MKfevE+hCVHT2F8t0kFlDdIsSiNKdL00=; b=jlhFa2dyCiN5vbEHuWcmYgr+UExw6qa1S++dXdIr+ZeyXFL+Vvm/1Gj/xYI6DZWyL4 OZd4jIPQ27zb0snfXacA== Received: by 10.150.139.9 with SMTP id m9mr2948999ybd.104.1319228430274; Fri, 21 Oct 2011 13:20:30 -0700 (PDT) Received: by 10.150.139.9 with SMTP id m9mr2948992ybd.104.1319228430107; Fri, 21 Oct 2011 13:20:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 21 Oct 2011 13:20:10 -0700 (PDT) From: John Tamplin Date: Fri, 21 Oct 2011 13:20:10 -0700 Message-ID: To: Hybi Content-Type: multipart/alternative; boundary=000e0cd56b1cf4436004afd4cd83 X-System-Of-Record: true Subject: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 20:20:35 -0000 --000e0cd56b1cf4436004afd4cd83 Content-Type: text/plain; charset=UTF-8 I have modified the original mux proposal (apologies to those of you who didn't see it) based on feedback from early reviewers and implementation experience (and also a late change to the WS spec which allowed simplification of the framing), and now I think it is ready for wider review. I have uploaded it, and it is currently available at http://www.ietf.org/staging/draft-ietf-hybi-google-mux-00.txt -- John A. Tamplin Software Engineer (GWT), Google --000e0cd56b1cf4436004afd4cd83 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I have modified the original mux proposal (apologies to those of you w= ho didn't see it) based on feedback from early reviewers and implementa= tion experience (and also a late change to the WS spec which allowed simpli= fication of the framing), and now I think it is ready for wider review.

I have uploaded it, and it is currently available at=C2=A0htt= p://www.ietf.org/staging/draft-ietf-hybi-google-mux-00.txt

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd56b1cf4436004afd4cd83-- From ibc@aliax.net Fri Oct 21 14:31:58 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A4021F86DD for ; Fri, 21 Oct 2011 14:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kn0oteO+ARAB for ; Fri, 21 Oct 2011 14:31:57 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6047121F86D0 for ; Fri, 21 Oct 2011 14:31:57 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4449098vcb.31 for ; Fri, 21 Oct 2011 14:31:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.184.103 with SMTP id et7mr15851752vdc.35.1319232715204; Fri, 21 Oct 2011 14:31:55 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 14:31:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 21 Oct 2011 23:31:55 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 21:31:58 -0000 2011/10/21 John Tamplin : > I have uploaded it, and it is currently available > at=C2=A0http://www.ietf.org/staging/draft-ietf-hybi-google-mux-00.txt Hi, I get I 404: 404: Page Not Found The page you have requested could not be found. You requested: http://www.ietf.org/staging/draft-ietf-hybi-google-mux-00.tx= t That URL does not currently exist on the IETF website. We have recently rearranged and redesigned our website, so things have changed. --=20 I=C3=B1aki Baz Castillo From jat@google.com Fri Oct 21 14:41:41 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D281F0C44 for ; Fri, 21 Oct 2011 14:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.676 X-Spam-Level: X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mKVl5FyC5WQf for ; Fri, 21 Oct 2011 14:41:40 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id BA7651F0C35 for ; Fri, 21 Oct 2011 14:41:35 -0700 (PDT) Received: from hpaq2.eem.corp.google.com (hpaq2.eem.corp.google.com [172.25.149.2]) by smtp-out.google.com with ESMTP id p9LLfY7v008863 for ; Fri, 21 Oct 2011 14:41:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319233294; bh=DW0l81IXg2iIkoX48jBITES7g5U=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=Iv2uFry1WwBYK8TX1XAt1dez/tinA+5mRSnMzaNY6S8ZRZG4r10l/W/sAo/WV6Vkk X1SzNmkqUP/9j8CsyVDkA== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=CcMLYYbLsURPMbiXknbNlqrzpnFVfw7Xpfc5zqMW9NWnRy7Sk9RZqZgo5IxuitYX7 tzRzM33m8ffGoBShy/BBw== Received: from qadb10 (qadb10.prod.google.com [10.224.32.74]) by hpaq2.eem.corp.google.com with ESMTP id p9LLdJZe023445 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Fri, 21 Oct 2011 14:41:33 -0700 Received: by qadb10 with SMTP id b10so3886959qad.9 for ; Fri, 21 Oct 2011 14:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=14yzKCa+dfmPB5YAcI5G2rzGdD1kJl9F2Hi9y6dZpxQ=; b=NZQ7FYZVRZSahPEdMsXlhMj8msu/NKhppSw4uKtetX9nl6JYetnppeAJo1nzpeb9Ll 9R5jvGAteqf7Bo+rDUzw== Received: by 10.151.122.14 with SMTP id z14mr14815181ybm.59.1319233293395; Fri, 21 Oct 2011 14:41:33 -0700 (PDT) Received: by 10.151.122.14 with SMTP id z14mr14815160ybm.59.1319233293083; Fri, 21 Oct 2011 14:41:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Fri, 21 Oct 2011 14:41:13 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Fri, 21 Oct 2011 14:41:13 -0700 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd4c1d6cf631b04afd5ef58 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 21:41:41 -0000 --000e0cd4c1d6cf631b04afd5ef58 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2011 at 2:31 PM, I=C3=B1aki Baz Castillo wr= ote: > Hi, I get I 404: > I used the wrong name and had to cancel it and resubmit. It is now available at http://www.ietf.org/id/draft-tamplin-hybi-google-mux-00.txt --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd4c1d6cf631b04afd5ef58 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 21, 2011 at 2:31 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:

Hi, I get I 404:

I used the wrong name = and had to cancel it and resubmit. =C2=A0It is now available at

<= br>

http://www.ietf.org/id/draft-tamplin-hybi-google-mux-00.txt= =C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd4c1d6cf631b04afd5ef58-- From Gabriel.Montenegro@microsoft.com Fri Oct 21 14:50:39 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FE7E21F8A70 for ; Fri, 21 Oct 2011 14:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niHHzb4rVBbh for ; Fri, 21 Oct 2011 14:50:38 -0700 (PDT) Received: from smtp.microsoft.com (smtp.microsoft.com [131.107.115.214]) by ietfa.amsl.com (Postfix) with ESMTP id ABD2C21F8A6C for ; Fri, 21 Oct 2011 14:50:38 -0700 (PDT) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 21 Oct 2011 14:50:37 -0700 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.1.339.2; Fri, 21 Oct 2011 14:50:37 -0700 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.160]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.01.0339.002; Fri, 21 Oct 2011 14:50:37 -0700 From: Gabriel Montenegro To: John Tamplin , =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= Thread-Topic: [hybi] first draft of WS mux extension Thread-Index: AQHMkC70fU9Gqo05v0mztnh1ln3otJWHxrCAgAACmYD//40VgA== Date: Fri, 21 Oct 2011 21:50:36 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C114490F707TK5EX14MBXW602w_" MIME-Version: 1.0 Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 21:50:39 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C114490F707TK5EX14MBXW602w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEpvaG4gYW5kIFRha2VzaGkgc2FuIQ0KDQpGb3IgdGhvc2UgdGhhdCBwcmVmZXIgaHRt bCwgdGhlIGRyYWZ0IGlzIGFsc28gYXZhaWxhYmxlIGF0Og0KaHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtdGFtcGxpbi1oeWJpLWdvb2dsZS1tdXgtMDANCg0KR2FicmllbA0KDQpGcm9t OiBoeWJpLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpoeWJpLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBKb2huIFRhbXBsaW4NClNlbnQ6IDIxIE9jdG9iZXIsIDIwMTEgMTQ6NDENClRv OiBJw7Fha2kgQmF6IENhc3RpbGxvDQpDYzogSHliaQ0KU3ViamVjdDogUmU6IFtoeWJpXSBmaXJz dCBkcmFmdCBvZiBXUyBtdXggZXh0ZW5zaW9uDQoNCk9uIEZyaSwgT2N0IDIxLCAyMDExIGF0IDI6 MzEgUE0sIEnDsWFraSBCYXogQ2FzdGlsbG8gPGliY0BhbGlheC5uZXQ8bWFpbHRvOmliY0BhbGlh eC5uZXQ+PiB3cm90ZToNCkhpLCBJIGdldCBJIDQwNDoNCg0KSSB1c2VkIHRoZSB3cm9uZyBuYW1l IGFuZCBoYWQgdG8gY2FuY2VsIGl0IGFuZCByZXN1Ym1pdC4gIEl0IGlzIG5vdyBhdmFpbGFibGUg YXQNCg0KaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC10YW1wbGluLWh5YmktZ29vZ2xlLW11 eC0wMC50eHQNCg0KLS0NCkpvaG4gQS4gVGFtcGxpbg0KU29mdHdhcmUgRW5naW5lZXIgKEdXVCks IEdvb2dsZQ0K --_000_CA566BAEAD6B3F4E8B5C5C4F61710C114490F707TK5EX14MBXW602w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIE1pbmNobyI7 DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNUyBNaW5jaG8iOw0KCXBhbm9zZS0xOjIgMiA2IDkgNCAyIDUgOCAzIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMgTWluY2hv IjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgSm9obiBhbmQgVGFrZXNoaSBzYW4hPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5Gb3IgdGhvc2UgdGhhdCBwcmVmZXIgaHRtbCwgdGhlIGRyYWZ0IGlzIGFsc28gYXZhaWxh YmxlIGF0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48YSBocmVmPSJodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC10YW1wbGluLWh5YmktZ29vZ2xlLW11eC0wMCI+aHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGFtcGxpbi1oeWJpLWdvb2dsZS1tdXgtMDA8L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj5HYWJyaWVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IGh5YmktYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmh5YmktYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+Sm9obiBUYW1wbGluPGJyPg0KPGI+U2VudDo8L2I+IDIx IE9jdG9iZXIsIDIwMTEgMTQ6NDE8YnI+DQo8Yj5Ubzo8L2I+IEnDsWFraSBCYXogQ2FzdGlsbG88 YnI+DQo8Yj5DYzo8L2I+IEh5Ymk8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtoeWJpXSBmaXJz dCBkcmFmdCBvZiBXUyBtdXggZXh0ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDIxLCAyMDExIGF0IDI6MzEgUE0s IEnDsWFraSBCYXogQ2FzdGlsbG8gJmx0OzxhIGhyZWY9Im1haWx0bzppYmNAYWxpYXgubmV0Ij5p YmNAYWxpYXgubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IaSwgSSBnZXQgSSA0MDQ6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHVzZWQgdGhlIHdyb25nIG5hbWUgYW5kIGhhZCB0byBjYW5jZWwgaXQg YW5kIHJlc3VibWl0LiAmbmJzcDtJdCBpcyBub3cgYXZhaWxhYmxlIGF0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvaWQvZHJhZnQtdGFtcGxpbi1oeWJpLWdvb2dsZS1tdXgtMDAudHh0Ij5odHRw Oi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LXRhbXBsaW4taHliaS1nb29nbGUtbXV4LTAwLnR4dDwv YT4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tIDxicj4NCkpvaG4gQS4gVGFtcGxpbjxicj4NClNvZnR3YXJlIEVuZ2luZWVyIChH V1QpLCBHb29nbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CA566BAEAD6B3F4E8B5C5C4F61710C114490F707TK5EX14MBXW602w_-- From gregw@intalio.com Fri Oct 21 15:26:03 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A5B21F8A4E for ; Fri, 21 Oct 2011 15:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEI1NuJz6VGI for ; Fri, 21 Oct 2011 15:26:02 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B85A821F8A35 for ; Fri, 21 Oct 2011 15:26:02 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4475846vcb.31 for ; Fri, 21 Oct 2011 15:26:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.69 with SMTP id q5mr15621336vdh.110.1319235961363; Fri, 21 Oct 2011 15:26:01 -0700 (PDT) Received: by 10.52.180.161 with HTTP; Fri, 21 Oct 2011 15:26:01 -0700 (PDT) In-Reply-To: References:

Date: Sat, 22 Oct 2011 09:26:01 +1100 Message-ID: From: Greg Wilkins To: Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 22:26:03 -0000 FYI, I just noticed that this -00 draft is significantly different to the other -00 draft for MUX that I have seen (I guess the earlier one had not been submitted, so no increment in the draft number). So for anybody else like me that had not looked at this for a while thinking it had not changed, have a look at the new draft. It has been updated to support interleaved WS frames and looks really clean and simple - Good work guys! cheers On 22 October 2011 08:50, Gabriel Montenegro wrote: > Thanks John and Takeshi san! > > > > For those that prefer html, the draft is also available at: > > http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-00 > > > > Gabriel > > > > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of J= ohn > Tamplin > Sent: 21 October, 2011 14:41 > To: I=F1aki Baz Castillo > Cc: Hybi > Subject: Re: [hybi] first draft of WS mux extension > > > > On Fri, Oct 21, 2011 at 2:31 PM, I=F1aki Baz Castillo wro= te: > > Hi, I get I 404: > > > > I used the wrong name and had to cancel it and resubmit. =A0It is now > available at > > > > http://www.ietf.org/id/draft-tamplin-hybi-google-mux-00.txt > > > > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > From ibc@aliax.net Fri Oct 21 15:29:53 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9552521F8AF6 for ; Fri, 21 Oct 2011 15:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.636 X-Spam-Level: X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvxYW2bStt-I for ; Fri, 21 Oct 2011 15:29:53 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1122F21F8AF5 for ; Fri, 21 Oct 2011 15:29:52 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4477572vcb.31 for ; Fri, 21 Oct 2011 15:29:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.25.75 with SMTP id a11mr15899072vdg.1.1319236186160; Fri, 21 Oct 2011 15:29:46 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 15:29:46 -0700 (PDT) In-Reply-To: References:

Date: Sat, 22 Oct 2011 00:29:46 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 22:29:53 -0000 2011/10/21 John Tamplin : > http://www.ietf.org/id/draft-tamplin-hybi-google-mux-00.txt The Overview says: -------------- Initially, it will be identified by the private-use token "x-google-mux". -------------- Please, don't use "x-" for a private extension, or we will end with lot of clients and servers implementing the "x-" private name and the standarized name forever. Check http://tools.ietf.org/html/draft-saintandre-xdash-considered-harmful-01 I strongly propose to rename it to "mux". --=20 I=C3=B1aki Baz Castillo From ibc@aliax.net Fri Oct 21 15:33:52 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 128701F0C4E for ; Fri, 21 Oct 2011 15:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.637 X-Spam-Level: X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TNmZqQ0Crhb for ; Fri, 21 Oct 2011 15:33:51 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 852181F0C35 for ; Fri, 21 Oct 2011 15:33:51 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so4479289vcb.31 for ; Fri, 21 Oct 2011 15:33:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.184.11 with SMTP id ci11mr1258988vcb.76.1319236430921; Fri, 21 Oct 2011 15:33:50 -0700 (PDT) Received: by 10.220.118.143 with HTTP; Fri, 21 Oct 2011 15:33:50 -0700 (PDT) In-Reply-To: References:

Date: Sat, 22 Oct 2011 00:33:50 +0200 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: John Tamplin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe:

From: John Tamplin Date: Fri, 21 Oct 2011 18:51:59 -0400 Message-ID: To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Content-Type: multipart/alternative; boundary=000e0cd5d026e4be0404afd6ec8e X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 22:52:22 -0000 --000e0cd5d026e4be0404afd6ec8e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Oct 21, 2011 at 6:33 PM, I=C3=B1aki Baz Castillo wr= ote: > 2011/10/22 I=C3=B1aki Baz Castillo : > > I strongly propose to rename it to "mux". > > I mean right now, without waiting for it to be an approved RFC. Until there is feedback that others besides Google are interested in implementing it, it seems presumptuous to take the name "mux". I am aware of the article you reference, but since non-private use names have to be registered before use, it isn't clear the alternative is any better. WS has already shown that you can have early deployments of a work in progress, make breaking changes, and have implementations adapt to the new version fairly quickly. So, I would much rather have some implementations use x-google-mux first and have to change them later after it is standardized, than to use the name "mux" now and then find out we really want a different mux protocol for that name. There are only a few browsers, so if they all update the servers will have no choice but to update to match. --=20 John A. Tamplin Software Engineer (GWT), Google --000e0cd5d026e4be0404afd6ec8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, Oct 21, 2011 at 6:33 PM, I=C3=B1aki Baz = Castillo <ibc@aliax.n= et> wrote:

2011/10/22 I=C3=B1aki Baz Castillo <ibc= @aliax.net>:

> I strongly propose to rename it to "mux".<= br>

I mean right now, without waiting for it to be an approved RFC.

Until there is feedback that others besides Goo= gle are interested in implementing it, it seems presumptuous to take the na= me "mux".

I am aware of the article you reference, but since non-= private use names have to be registered before use, it isn't clear the = alternative is any better. =C2=A0WS has already shown that you can have ear= ly deployments of a work in progress, make breaking changes, and have imple= mentations adapt to the new version fairly quickly. So, I would much rather= have some implementations use x-google-mux first and have to change them l= ater after it is standardized, than to use the name "mux" now and= then find out we really want a different mux protocol for that name. =C2= =A0There are only a few browsers, so if they all update the servers will ha= ve no choice but to update to match.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd5d026e4be0404afd6ec8e-- From tobias.oberstein@tavendo.de Sat Oct 22 14:40:24 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD7021F86EC for ; Sat, 22 Oct 2011 14:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HNowORhWXTR for ; Sat, 22 Oct 2011 14:40:23 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id A47FA21F86A6 for ; Sat, 22 Oct 2011 14:40:23 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Sat, 22 Oct 2011 14:40:22 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Sat, 22 Oct 2011 14:40:20 -0700 Thread-Topic: WS URLs Thread-Index: AcyRAfMcynScsoopThG4iaBqB+cA5Q== Message-ID: <634914A010D0B943A035D226786325D42D0B036D37@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] WS URLs X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 21:40:24 -0000 2 short questions .. first one is part of http://bugs.python.org/issue13244 Which of the following URLs are valid WS URLs? 1. ws://example.com/something#somewhere 2. ws://example.com/something#somewhere/ 3. ws://example.com/something#somewhere/foo 4. ws://example.com/something?query=3Dfoo#bar 5. ws://example.com/something%23somewhere 6. ws://example.com/something%23somewhere/ 7. ws://example.com/something%23somewhere/foo 8. ws://example.com/something?query=3Dfoo%23bar %23 =3D # "percentage escaped" Hybi-17 spec: "Fragment identifiers are meaningless in the context of WebSocket URIs, and MUST NOT be used on these URIs. The character "#" in URIs MUST be escaped as %23 if used as part of the query component." "path =3D " http://tools.ietf.org/html/rfc3986: "The path is terminated by the first question mark ("?") or number sign ("#= ") character, or by the end of the URI." =3D=3D When an invalid WS URLs is received in the client request during opening ha= ndshake, how is the server supposed to react? Fail the handshake (i.e. http 400 Bad request), or "ignore" invalid parts (= like fragment component)? From tobias.oberstein@tavendo.de Sat Oct 22 14:57:08 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260E421F84D3 for ; Sat, 22 Oct 2011 14:57:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w5V8lCE7St7B for ; Sat, 22 Oct 2011 14:57:07 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB5821F891D for ; Sat, 22 Oct 2011 14:57:07 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Sat, 22 Oct 2011 14:57:06 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Sat, 22 Oct 2011 14:57:04 -0700 Thread-Topic: WS URLs Thread-Index: AcyRAfMcynScsoopThG4iaBqB+cA5QAAwnxA Message-ID: <634914A010D0B943A035D226786325D42D0B036D38@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D37@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D42D0B036D37@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [hybi] WS URLs X-BeenThere: hybi@ietf.org X-Mailman-Version: 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 Oct 2011 21:57:08 -0000 sorry, I missed the posts by Peter and Julian http://www.ietf.org/mail-archive/web/hybi/current/msg09243.html So 1. - 4. are invalid, and 5. - 8. are valid? What about failing the handshake vs ignoring a fragment component (introduc= ed via non-escaped #)? > -----Urspr=FCngliche Nachricht----- > Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von > Tobias Oberstein > Gesendet: Samstag, 22. Oktober 2011 23:40 > An: hybi@ietf.org > Betreff: [hybi] WS URLs >=20 > 2 short questions .. first one is part of http://bugs.python.org/issue132= 44 >=20 > Which of the following URLs are valid WS URLs? >=20 > 1. ws://example.com/something#somewhere > 2. ws://example.com/something#somewhere/ > 3. ws://example.com/something#somewhere/foo > 4. ws://example.com/something?query=3Dfoo#bar > 5. ws://example.com/something%23somewhere > 6. ws://example.com/something%23somewhere/ > 7. ws://example.com/something%23somewhere/foo > 8. ws://example.com/something?query=3Dfoo%23bar >=20 > %23 =3D # "percentage escaped" >=20 > Hybi-17 spec: >=20 > "Fragment identifiers are meaningless in the context of WebSocket URIs, a= nd > MUST NOT be used on these URIs. The character "#" in URIs MUST be > escaped as %23 if used as part of the query component." >=20 > "path =3D " >=20 > http://tools.ietf.org/html/rfc3986: >=20 > "The path is terminated by the first question mark ("?") or number sign (= "#") > character, or by the end of the URI." >=20 > =3D=3D >=20 > When an invalid WS URLs is received in the client request during opening > handshake, how is the server supposed to react? >=20 > Fail the handshake (i.e. http 400 Bad request), or "ignore" invalid parts= (like > fragment component)? > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From len.holgate@gmail.com Mon Oct 24 00:37:04 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723A221F8B98 for ; Mon, 24 Oct 2011 00:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nE2vNn-iF7g3 for ; Mon, 24 Oct 2011 00:37:03 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 66AC821F8B9C for ; Mon, 24 Oct 2011 00:37:03 -0700 (PDT) Received: by wyh22 with SMTP id 22so6548969wyh.31 for ; Mon, 24 Oct 2011 00:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=CTLRQRG5uwS8svi5/1ujaDd9LVmmVhrvMglxbABfnP0=; b=G9RU0jpC/rYxyLtRl/AD6nZTKw986DeGN84NpcVW5WP+ze9u6i5rIiTlNF+SsW2P+m 56OBhluPJfLLIj6MarhpHKRUqhx+AuOwtutnglyUhlntBra2NIbAkGM5+UbIhtmbhkTy vpgbnVt/q56h2su65VfXYGAHS0JNF/CL0jkDQ= Received: by 10.216.138.29 with SMTP id z29mr2961949wei.4.1319441822442; Mon, 24 Oct 2011 00:37:02 -0700 (PDT) Received: from Venus (cpc8-glfd6-2-0-cust3.6-2.cable.virginmedia.com. [86.27.228.4]) by mx.google.com with ESMTPS id 11sm37322421wby.15.2011.10.24.00.36.59 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 00:37:00 -0700 (PDT) From: "Len Holgate" To: "'John Tamplin'" References:

Date: Mon, 24 Oct 2011 08:37:05 +0100 Message-ID: <21c201cc921f$bbd76a00$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcyQRCYzkXgqUGlpR9GdGj+9hN1aowB2waWA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 07:37:04 -0000 John, This seems nice and clean and pretty easy to implement.=20 Have you considered removing the "relaxation" of the fragmented frame = rules from the base protocol (ie the changes that permit the example shown in = 7). I would have thought that if all fragments on mux channels were sent as complete messages you could include the actual message's fin bit in the extension data of the mux frame and so not change the base protocol at = all. This would mean that mux could be implemented on existing websocket implementations without changing the underlying implementation at all. = The layer "above" could deal with all aspects of the muxing. Len=20 > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On=20 > Behalf Of John Tamplin > Sent: 21 October 2011 23:52 > To: I=F1aki Baz Castillo > Cc: Hybi > Subject: Re: [hybi] first draft of WS mux extension >=20 > On Fri, Oct 21, 2011 at 6:33 PM, I=F1aki Baz Castillo=20 > wrote: >=20 >=20 > 2011/10/22 I=F1aki Baz Castillo : > =09 > > I strongly propose to rename it to "mux". > =09 > =09 > I mean right now, without waiting for it to be an approved RFC. >=20 >=20 > Until there is feedback that others besides Google are=20 > interested in implementing it, it seems presumptuous to take=20 > the name "mux". >=20 >=20 > I am aware of the article you reference, but since=20 > non-private use names have to be registered before use, it=20 > isn't clear the alternative is any better. WS has already=20 > shown that you can have early deployments of a work in=20 > progress, make breaking changes, and have implementations=20 > adapt to the new version fairly quickly. So, I would much=20 > rather have some implementations use x-google-mux first and=20 > have to change them later after it is standardized, than to=20 > use the name "mux" now and then find out we really want a=20 > different mux protocol for that name. There are only a few=20 > browsers, so if they all update the servers will have no=20 > choice but to update to match. >=20 > --=20 > John A. Tamplin > Software Engineer (GWT), Google >=20 >=20 From jat@google.com Mon Oct 24 00:52:52 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B534321F8C1B for ; Mon, 24 Oct 2011 00:52:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8xxEYU7YxpM for ; Mon, 24 Oct 2011 00:52:52 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 102D321F8C1A for ; Mon, 24 Oct 2011 00:52:51 -0700 (PDT) Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id p9O7qpaT019755 for ; Mon, 24 Oct 2011 00:52:51 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319442771; bh=orSIW7rmRFbwUQAVyP+T8fzKB68=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=aC3oBH9XWodLcxCPmCITSatojVDYZhZxucYenHrJL9Dw8pUbReww1PEn+U8nikvyA HH2XFiWmSQw4CGfHIRBbg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=LXPM07lI6XDwoIXyffLCxkS42lh5TzxFZ9GCinGLeaR9oocZhbLOIJS1iCzkAdl+S 48+U6NY9xuxsKzFPTyf7A== Received: from ywm14 (ywm14.prod.google.com [10.192.13.14]) by wpaz13.hot.corp.google.com with ESMTP id p9O7pHmW002640 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 00:52:50 -0700 Received: by ywm14 with SMTP id 14so3819152ywm.7 for ; Mon, 24 Oct 2011 00:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=fkzbBseH19IcPM6T4scY4OO6CB1CsTUkD8YYo8IQKxQ=; b=qnELXW83vIkjYNLq4kwkXQkk9lS0msfbU392t9KAkgcTViUlzs6aAcNftbAeOONCEp OrxeKcOjqBrvfpKspdhQ== Received: by 10.229.37.207 with SMTP id y15mr4728244qcd.151.1319442770353; Mon, 24 Oct 2011 00:52:50 -0700 (PDT) Received: by 10.229.37.207 with SMTP id y15mr4728235qcd.151.1319442770099; Mon, 24 Oct 2011 00:52:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.1 with HTTP; Mon, 24 Oct 2011 00:52:30 -0700 (PDT) In-Reply-To: <21c201cc921f$bbd76a00$0a00a8c0@Venus> References:

<21c201cc921f$bbd76a00$0a00a8c0@Venus> From: John Tamplin Date: Mon, 24 Oct 2011 03:52:30 -0400 Message-ID: To: Len Holgate Content-Type: multipart/alternative; boundary=0016369fa10a9cfebc04b006b579 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 07:52:52 -0000 --0016369fa10a9cfebc04b006b579 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2011 at 3:37 AM, Len Holgate wrote: > This seems nice and clean and pretty easy to implement. > > Have you considered removing the "relaxation" of the fragmented frame rules > from the base protocol (ie the changes that permit the example shown in 7). > > I would have thought that if all fragments on mux channels were sent as > complete messages you could include the actual message's fin bit in the > extension data of the mux frame and so not change the base protocol at all. > This would mean that mux could be implemented on existing websocket > implementations without changing the underlying implementation at all. The > layer "above" could deal with all aspects of the muxing. > That would require an additional framing layer to allow that, and objections to that is what led to the support in the base spec allowing extensions to define interleaving behavior. -- John A. Tamplin Software Engineer (GWT), Google --0016369fa10a9cfebc04b006b579 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 24, 2011 at 3:37 AM, Len Holgate <len.holgate@gma= il.com> wrote:

This seems nice and clean and pretty easy to implement.

Have you considered removing the "relaxation" of the fragmented f= rame rules
from the base protocol (ie the changes that permit the example shown in 7).=

I would have thought that if all fragments on mux channels were sent as
complete messages you could include the actual message's fin bit in the=
extension data of the mux frame and so not change the base protocol at all.=
This would mean that mux could be implemented on existing websocket
implementations without changing the underlying implementation at all. The<= br> layer "above" could deal with all aspects of the muxing.

That would require an additional framing layer = to allow that, and objections to that is what led to the support in the bas= e spec allowing extensions to define interleaving behavior.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--0016369fa10a9cfebc04b006b579-- From tobias.oberstein@tavendo.de Mon Oct 24 00:58:16 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC9E21F8C6A for ; Mon, 24 Oct 2011 00:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBt8pOZ7IOOJ for ; Mon, 24 Oct 2011 00:58:16 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id EEAC821F8C69 for ; Mon, 24 Oct 2011 00:58:15 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 24 Oct 2011 00:58:15 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Mon, 24 Oct 2011 00:58:13 -0700 Thread-Topic: failed TLS handshake: which close code? Thread-Index: AcySIbAvR1mTC2mWQr2hZwnuI/+Ivg== Message-ID: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 07:58:16 -0000 Hybi-17: """ 4. Opening Handshake ... 4.1. Client Requirements ... 5. If /secure/ is true, the client MUST perform a TLS handshake over the connection after opening the connection and before sending the handshake data [RFC2818]. If this fails (e.g. the server's certificate could not be verified), then the client MUST _Fail the WebSocket Connection_ and abort the connection. Otherwise, all further communication on this channel MUST run through the encrypted tunnel. [RFC5246] """ When the client fails the TLS handshake (i.e. because of invalid server cer= tificate), which close status code would be appropriate to use for signaling that spec= ific reason to the caller? Is it supposed to use a close status code from the following range? """ 3000-3999 Status codes in the range 3000-3999 are reserved for use by libraries, frameworks and application. These status codes are registered directly with IANA. The interpretation of these codes is undefined by this protocol. """ Or are those only for "use on wire" not for signaling the caller? For example, Firefox currently provides the calling JavaScript with a "1006= Abnormal Connection Close": """ 1006 1006 is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint. It is designated for use in applications expecting a status code to indicate that the connection was closed abnormally, e.g. without sending or receiving a Close control frame. """ However, this could be multiple things and is not giving the real reason to= the JS. The JS thus can't react specifically .. From len.holgate@gmail.com Mon Oct 24 01:30:08 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4CA721F8C8B for ; Mon, 24 Oct 2011 01:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SgriRixHHYZl for ; Mon, 24 Oct 2011 01:30:07 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A92421F8C8D for ; Mon, 24 Oct 2011 01:30:07 -0700 (PDT) Received: by wyh22 with SMTP id 22so6604141wyh.31 for ; Mon, 24 Oct 2011 01:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=c2ThiD6tXqVaGR+XtPAiIVNYWlwzN9jr2Rv6xR1Xxe8=; b=FXn9x3dg4z3MrxdRYb+t8tZDgv5jt11T02YDLFhngN2+XcgLc2aQe30VmjzAk7zSMn 425bYNlOgb0TZj5llYlSqp9ps7fSyOL4efTpmxb4W9ISocBb+qzdN4YMe1M4NV/GxxAE Z4CDUjwIYmaDyzrN+V7U5Me4HMVr+as+ypuwo= Received: by 10.227.23.210 with SMTP id s18mr586541wbb.9.1319445006649; Mon, 24 Oct 2011 01:30:06 -0700 (PDT) Received: from Venus (cpc8-glfd6-2-0-cust3.6-2.cable.virginmedia.com. [86.27.228.4]) by mx.google.com with ESMTPS id ek13sm37601672wbb.3.2011.10.24.01.30.04 (version=SSLv3 cipher=OTHER); Mon, 24 Oct 2011 01:30:05 -0700 (PDT) From: "Len Holgate" To: "'John Tamplin'" References:

<21c201cc921f$bbd76a00$0a00a8c0@Venus> Date: Mon, 24 Oct 2011 09:30:12 +0100 Message-ID: <21d301cc9227$26c55c30$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcySIe6CQklQxcJMRZ+wbmfjUn0Y1AABMbwg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 08:30:08 -0000 No, you'd just use the existing framing in the base protocol and all fragments would have the FIN bit set. Thus any channel can interleave without changing any rules from the base protocol. You'd then have a single FIN bit in the extension data, before the channel id, which acts as the fin bit for this channel's data. Your example in 7 becomes 81 06 [FIN BIT HERE = 0]01 "Hello" 81 04 [FIN BIT HERE = 1]02 "bye" 81 07 [FIN BIT HERE = 1]01 " world" Len > -----Original Message----- > From: John Tamplin [mailto:jat@google.com] > Sent: 24 October 2011 08:53 > To: Len Holgate > Cc: Hybi > Subject: Re: [hybi] first draft of WS mux extension > > On Mon, Oct 24, 2011 at 3:37 AM, Len Holgate > wrote: > > > This seems nice and clean and pretty easy to implement. > > Have you considered removing the "relaxation" of the > fragmented frame rules > from the base protocol (ie the changes that permit the > example shown in 7). > > I would have thought that if all fragments on mux > channels were sent as > complete messages you could include the actual > message's fin bit in the > extension data of the mux frame and so not change the > base protocol at all. > This would mean that mux could be implemented on > existing websocket > implementations without changing the underlying > implementation at all. The > layer "above" could deal with all aspects of the muxing. > > > > That would require an additional framing layer to allow that, > and objections to that is what led to the support in the base > spec allowing extensions to define interleaving behavior. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > From jat@google.com Mon Oct 24 02:00:23 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6F821F8CB0 for ; Mon, 24 Oct 2011 02:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.811 X-Spam-Level: X-Spam-Status: No, score=-105.811 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB18=0.131, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1TzhHFrIU-IG for ; Mon, 24 Oct 2011 02:00:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2433E21F8CAB for ; Mon, 24 Oct 2011 02:00:22 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p9O90LE2025059 for ; Mon, 24 Oct 2011 02:00:21 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319446821; bh=Scd64cmABEOChbKblSmyEHZobwI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ABo7gthxxyRC6F57bwr+9TUB6zJHzUqXGOTYe/Jyaxw+w2PO4vuPiXk6oY9k5xejy 62b08m6bH5l9T98A5UZkQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=Q4a2Kz0hLk3P+LcaFdEGLIZpu52wPOoZ0VTd9HwjQH1N/DqoOtM+xWAmgsOjViAAD tqVuRaTdGEnB/igyV4DWw== Received: from vcbfl15 (vcbfl15.prod.google.com [10.220.204.79]) by wpaz24.hot.corp.google.com with ESMTP id p9O8xQ5r004314 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 02:00:20 -0700 Received: by vcbfl15 with SMTP id fl15so8434263vcb.5 for ; Mon, 24 Oct 2011 02:00:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=23bEgKBtEKWtm8InnoSv/6ft9RxBPnkXNNOLbIS6xos=; b=hn6SxU2tFqoBMNuN5RhHkQOdHdDLRQmzCt1npOmkLpwm2e3BZTUuEfJUAjdG4TOtWd WxU+zPPQ81MwkJwwJAgg== Received: by 10.229.219.20 with SMTP id hs20mr525904qcb.37.1319446820252; Mon, 24 Oct 2011 02:00:20 -0700 (PDT) Received: by 10.229.219.20 with SMTP id hs20mr525898qcb.37.1319446820115; Mon, 24 Oct 2011 02:00:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.1 with HTTP; Mon, 24 Oct 2011 02:00:00 -0700 (PDT) In-Reply-To: <21d301cc9227$26c55c30$0a00a8c0@Venus> References:

<21c201cc921f$bbd76a00$0a00a8c0@Venus>

--90e6ba6e827a8fc13704b00b23cd-- From webmaster@zaphoyd.com Mon Oct 24 06:10:51 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78AB221F8C8A for ; Mon, 24 Oct 2011 06:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BK+MpEOSkMVg for ; Mon, 24 Oct 2011 06:10:34 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id 1B17721F8C16 for ; Mon, 24 Oct 2011 06:10:26 -0700 (PDT) Received: from c-68-51-77-246.hsd1.il.comcast.net ([68.51.77.246]:36917 helo=[10.0.1.82]) by sh78.surpasshosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1RIKHr-0006m7-Jo; Mon, 24 Oct 2011 09:09:55 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=iso-8859-1 From: Peter Thorson In-Reply-To: Date: Mon, 24 Oct 2011 08:09:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

To: Alexey Melnikov X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: hybi@ietf.org Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:10:52 -0000 On Oct 24, 2011, at 8:04 , Alexey Melnikov wrote: > That was supposed to be sent to the mailing list. The WG should = consider adding multiple codes if needed. >=20 > TLS handshake probably deserves a separate 1XXX close code. What is the procedure right now for adding more 1XXX close codes? In = addition to TLS stuff, I still think (and a few here have agreed) that = we also need a 1XXX code similar in meaning to HTTP 500/"internal server = error"= From tobias.oberstein@tavendo.de Mon Oct 24 06:16:39 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4011F21F8D80 for ; Mon, 24 Oct 2011 06:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b9nrS9CLygI2 for ; Mon, 24 Oct 2011 06:16:38 -0700 (PDT) Received: from EXHUB020-2.exch020.serverdata.net (exhub020-2.exch020.serverdata.net [206.225.164.29]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7E521F8D7E for ; Mon, 24 Oct 2011 06:16:38 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-2.exch020.serverdata.net ([206.225.164.29]) with mapi; Mon, 24 Oct 2011 06:16:38 -0700 From: Tobias Oberstein To: Alexey Melnikov Date: Mon, 24 Oct 2011 06:16:36 -0700 Thread-Topic: [hybi] WS URLs Thread-Index: AcySTTai31p+TV62S12LJI/WTtwtDgAAJVvg Message-ID: <634914A010D0B943A035D226786325D42D0B036DC0@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D37@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] WS URLs X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:16:39 -0000 Hello Alexey, > >=20 > > Which of the following URLs are valid WS URLs? > > > > 1. ws://example.com/something#somewhere > > 2. ws://example.com/something#somewhere/ > > 3. ws://example.com/something#somewhere/foo > > 4. ws://example.com/something?query=3Dfoo#bar > I think all of these are invalid.=A0 Ok. > > When an invalid WS URLs is received in the client request during openin= g handshake, > > how is the server supposed to react? > As far as I remember WS/WSS URLs are not sent during the opening handshak= e. They can only be used to initiate one. Sorry, what I meant with sending was not the complete WS URL, but the /reso= urce/ component of the WS URL. That is, what if a WS client starts the handshake with a GET /something#somewhere/foo HTTP/1.1 Host: example.com .. Now, what should the server do? Go on with /resource/ =3D=3D "/something" ignoring the fragment component, or fail the handshake with 400? From lunohod.baikonur@googlemail.com Mon Oct 24 06:19:40 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AC021F8D88 for ; Mon, 24 Oct 2011 06:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfuyXv5QWwEq for ; Mon, 24 Oct 2011 06:19:39 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id AD21B21F8D7E for ; Mon, 24 Oct 2011 06:19:39 -0700 (PDT) Received: by iabn5 with SMTP id n5so9081709iab.31 for ; Mon, 24 Oct 2011 06:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Sxo8Rul4FeoarZXnhKcOn3oP/O7TgH/UMUbbQGBLxto=; b=bgEAAIWFg8pGXWPlL/xKs7P115wg9TQ6X1XAN9tafQKJyiLBqZ5etMdJte95K1Up6r Vzo2/798lnQSbZrZTQ3E6kDWgkVn8BxADy3VYRf++uZBe7Ylsrk/AFzRgUw9qr4rxkLQ cLp+7DCmmqaaPFSMpOSBzk3c0pf+yc+i91wkc= MIME-Version: 1.0 Received: by 10.42.152.201 with SMTP id j9mr30423023icw.55.1319462378267; Mon, 24 Oct 2011 06:19:38 -0700 (PDT) Sender: lunohod.baikonur@googlemail.com Received: by 10.42.247.199 with HTTP; Mon, 24 Oct 2011 06:19:38 -0700 (PDT) In-Reply-To: <0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> Date: Mon, 24 Oct 2011 14:19:38 +0100 X-Google-Sender-Auth: bDJj9Y8Dd0ETweu2JSbltEE-mQI Message-ID: From: Alexey Melnikov To: Peter Thorson Content-Type: multipart/alternative; boundary=90e6ba6e889c59e26a04b00b4682 Cc: hybi@ietf.org Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:19:40 -0000 --90e6ba6e889c59e26a04b00b4682 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 24, 2011 at 2:09 PM, Peter Thorson wrote: > > On Oct 24, 2011, at 8:04 , Alexey Melnikov wrote: > > > That was supposed to be sent to the mailing list. The WG should consider > adding multiple codes if needed. > > > > TLS handshake probably deserves a separate 1XXX close code. > > What is the procedure right now for adding more 1XXX close codes? People should suggest specific close codes on the mailing list and, ideally, suggest their description. For codes recommended this week or next (basically before the final RFC is published), there is a good chance that they can be included directly into the RFC-to-be. Close codes suggested later can still be added to the registry (they will need a review by a yet-to-be-appointed Expert Reviewer -- IESG will take care of this), but they will not appear in the RFC. All of the codes will be seen in the IANA registry (< http://www.iana.org/assignments/websocket/websocket.xml>) > In addition to TLS stuff, I still think (and a few here have agreed) that > we also need a 1XXX code similar in meaning to HTTP 500/"internal server > error" Agreed. --90e6ba6e889c59e26a04b00b4682 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Oct 24, 2011 at 2:09 PM, Peter Thorson <webmaster@zaphoyd.com> wro= te:

On Oct 24, 2011, at 8:04 , Alexey Melnikov wrote:

> That was supposed to be sent to the mailing list. The WG should consid= er adding multiple codes if needed.
>

> TLS handshake probably deserves a separate 1XX= X close code.

What is the procedure right now for adding more 1XXX close codes?

People should suggest specific close codes on = the mailing list and, ideally, suggest their description.

For codes recommended this week or next (basically before the fi= nal RFC is published), there is a good chance that they can be included dir= ectly into the RFC-to-be.

Close codes suggested la= ter can still be added to the registry (they will need a review by a yet-to= -be-appointed Expert Reviewer -- IESG will take care of this), but they wil= l not appear in the RFC.

All of the codes will be seen in the IANA registry (<= ;http:/= /www.iana.org/assignments/websocket/websocket.xml>)
=A0=A0=

In addition to TLS stuff, I still think (an= d a few here have agreed) that we also need a 1XXX code similar in meaning = to HTTP 500/"internal server error"

Agreed.

--90e6ba6e889c59e26a04b00b4682-- From rbarnes@bbn.com Mon Oct 24 06:22:16 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE2D21F8D98 for ; Mon, 24 Oct 2011 06:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doSXa2+9T5AI for ; Mon, 24 Oct 2011 06:22:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7B97221F8D96 for ; Mon, 24 Oct 2011 06:22:15 -0700 (PDT) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:55347) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RIKTl-0000xY-QV; Mon, 24 Oct 2011 09:22:13 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 24 Oct 2011 09:22:13 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: hybi@ietf.org Subject: Re: [hybi] failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:22:16 -0000 +1 It's silly to require the WS implementation to send a close frame in = plaintext after the TLS connection fails. I don't even think this sort = of thing would be supported by standard TLS libraries. --Richard On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote: > On a second thought: TLS fails before WebSocket connection is = established, so (unless I am missing something) TLS related close codes = will never be sent on the wire. However reserving some WebSocket codes = is still a good idea. >=20 > On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov = wrotetL > That was supposed to be sent to the mailing list. The WG should = consider adding multiple codes if needed. >=20 >=20 > ---------- Forwarded message ---------- > From: Alexey Melnikov > Date: Mon, Oct 24, 2011 at 1:34 PM > Subject: Re: [hybi] failed TLS handshake: which close code? > To: Tobias Oberstein >=20 >=20 > Hi Tobias, >=20 > On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein = wrote: > Hybi-17: >=20 > """ > 4. Opening Handshake > ... > 4.1. Client Requirements > ... > 5. If /secure/ is true, the client MUST perform a TLS handshake = over > the connection after opening the connection and before sending > the handshake data [RFC2818]. If this fails (e.g. the server's > certificate could not be verified), then the client MUST _Fail > the WebSocket Connection_ and abort the connection. Otherwise, > all further communication on this channel MUST run through the > encrypted tunnel. [RFC5246] > """ >=20 > When the client fails the TLS handshake (i.e. because of invalid = server certificate), > which close status code would be appropriate to use for signaling that = specific > reason to the caller? >=20 > Is it supposed to use a close status code from the following range? >=20 > """ > 3000-3999 >=20 > Status codes in the range 3000-3999 are reserved for use by > libraries, frameworks and application. These status codes are > registered directly with IANA. The interpretation of these codes > is undefined by this protocol. > """ >=20 > Or are those only for "use on wire" not for signaling the caller? >=20 > For example, Firefox currently provides the calling JavaScript with a = "1006 Abnormal Connection Close": >=20 > """ > 1006 >=20 > 1006 is a reserved value and MUST NOT be set as a status code in = a > Close control frame by an endpoint. It is designated for use in > applications expecting a status code to indicate that the > connection was closed abnormally, e.g. without sending or > receiving a Close control frame. > """ >=20 > However, this could be multiple things and is not giving the real = reason to the JS. > The JS thus can't react specifically .. >=20 > TLS handshake probably deserves a separate 1XXX close code. >=20 >=20 >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From julian.reschke@gmx.de Mon Oct 24 06:28:31 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22DC21F8C60 for ; Mon, 24 Oct 2011 06:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.969 X-Spam-Level: X-Spam-Status: No, score=-102.969 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNAKyriMYYGG for ; Mon, 24 Oct 2011 06:28:30 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id E9E2A21F8C22 for ; Mon, 24 Oct 2011 06:28:22 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 13:28:21 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp059) with SMTP; 24 Oct 2011 15:28:21 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/vHIVpGJTv/FA2x15L0aUQlNE3bT+C3UK/Ww7cQK NNq1f8tPVSdSyP Message-ID: <4EA567F1.4050702@gmx.de> Date: Mon, 24 Oct 2011 15:28:17 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tobias Oberstein References: <634914A010D0B943A035D226786325D42D0B036D37@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D42D0B036DC0@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D42D0B036DC0@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] WS URLs X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:28:31 -0000 On 2011-10-24 15:16, Tobias Oberstein wrote: > Hello Alexey, > >>> >>> Which of the following URLs are valid WS URLs? >>> >>> 1. ws://example.com/something#somewhere >>> 2. ws://example.com/something#somewhere/ >>> 3. ws://example.com/something#somewhere/foo >>> 4. ws://example.com/something?query=foo#bar >> I think all of these are invalid. > > Ok. > >>> When an invalid WS URLs is received in the client request during opening handshake, >>> how is the server supposed to react? >> As far as I remember WS/WSS URLs are not sent during the opening handshake. They can only be used to initiate one. > > Sorry, what I meant with sending was not the complete WS URL, but the /resource/ component of the WS URL. > > That is, what if a WS client starts the handshake with a > > GET /something#somewhere/foo HTTP/1.1 > Host: example.com > .. > > Now, what should the server do? > > Go on with > > /resource/ == "/something" > > ignoring the fragment component, or fail the handshake with 400? > ... That's an HTTP question; as the /something#somewhere/foo is not a valid rquest-target according to , the server should reject the request with a 400 status. Best regards, Julian From lunohod.baikonur@googlemail.com Mon Oct 24 06:29:25 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08CA21F8C5C for ; Mon, 24 Oct 2011 06:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.972 X-Spam-Level: X-Spam-Status: No, score=-102.972 tagged_above=-999 required=5 tests=[AWL=0.004, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BzVNloWm8D1z for ; Mon, 24 Oct 2011 06:29:25 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0E85121F8C22 for ; Mon, 24 Oct 2011 06:29:24 -0700 (PDT) Received: by iabn5 with SMTP id n5so9092391iab.31 for ; Mon, 24 Oct 2011 06:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=zsYZYXPpfywVZqIEdPO5oUwpomfe4Pv1wJQ2xq1OjDs=; b=E0IZrkGMYQObfyLe4S5YqpKmbusuu+N/Kc+yvaz8jhSOAJVHsaN9gOvuju+Wxdl+/8 FwY0C9HYEz89ZXAvNbPMNhG+ePS6/IsgJcJlGyY45pO09iZ7+AVjmEz6BRC+/ESQ5owS AMWS+rzLaxTwq3pwnONXW+YqtfLHgYSPZ4Ptg= MIME-Version: 1.0 Received: by 10.42.197.197 with SMTP id el5mr40374707icb.23.1319462964420; Mon, 24 Oct 2011 06:29:24 -0700 (PDT) Sender: lunohod.baikonur@googlemail.com Received: by 10.42.247.199 with HTTP; Mon, 24 Oct 2011 06:29:24 -0700 (PDT) In-Reply-To: <7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> Date: Mon, 24 Oct 2011 14:29:24 +0100 X-Google-Sender-Auth: Ajzyx5zwz85eadMJ6wTcE4Y2EG0 Message-ID: From: Alexey Melnikov To: "Richard L. Barnes" Content-Type: multipart/alternative; boundary=20cf303bfbde49e0f304b00b6978 Cc: hybi@ietf.org Subject: Re: [hybi] failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:29:26 -0000 --20cf303bfbde49e0f304b00b6978 Content-Type: text/plain; charset=ISO-8859-1 Hi Richard, On Mon, Oct 24, 2011 at 2:22 PM, Richard L. Barnes wrote: > +1 > > It's silly to require the WS implementation to send a close frame in > plaintext after the TLS connection fails. I don't even think this sort of > thing would be supported by standard TLS libraries. > Right. But the TLS-related code(s) might have to be allocated for use in the WebSocket API. > > --Richard > > > > On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote: > > > On a second thought: TLS fails before WebSocket connection is > established, so (unless I am missing something) TLS related close codes will > never be sent on the wire. However reserving some WebSocket codes is still a > good idea. > > > > On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov < > alexey.melnikov@isode.com> wrotetL > > That was supposed to be sent to the mailing list. The WG should consider > adding multiple codes if needed. > > > > > > ---------- Forwarded message ---------- > > From: Alexey Melnikov > > Date: Mon, Oct 24, 2011 at 1:34 PM > > Subject: Re: [hybi] failed TLS handshake: which close code? > > To: Tobias Oberstein > > > > > > Hi Tobias, > > > > On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein < > tobias.oberstein@tavendo.de> wrote: > > Hybi-17: > > > > """ > > 4. Opening Handshake > > ... > > 4.1. Client Requirements > > ... > > 5. If /secure/ is true, the client MUST perform a TLS handshake over > > the connection after opening the connection and before sending > > the handshake data [RFC2818]. If this fails (e.g. the server's > > certificate could not be verified), then the client MUST _Fail > > the WebSocket Connection_ and abort the connection. Otherwise, > > all further communication on this channel MUST run through the > > encrypted tunnel. [RFC5246] > > """ > > > > When the client fails the TLS handshake (i.e. because of invalid server > certificate), > > which close status code would be appropriate to use for signaling that > specific > > reason to the caller? > > > > Is it supposed to use a close status code from the following range? > > > > """ > > 3000-3999 > > > > Status codes in the range 3000-3999 are reserved for use by > > libraries, frameworks and application. These status codes are > > registered directly with IANA. The interpretation of these codes > > is undefined by this protocol. > > """ > > > > Or are those only for "use on wire" not for signaling the caller? > > > > For example, Firefox currently provides the calling JavaScript with a > "1006 Abnormal Connection Close": > > > > """ > > 1006 > > > > 1006 is a reserved value and MUST NOT be set as a status code in a > > Close control frame by an endpoint. It is designated for use in > > applications expecting a status code to indicate that the > > connection was closed abnormally, e.g. without sending or > > receiving a Close control frame. > > """ > > > > However, this could be multiple things and is not giving the real reason > to the JS. > > The JS thus can't react specifically .. > > > > TLS handshake probably deserves a separate 1XXX close code. > > > > > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi > > --20cf303bfbde49e0f304b00b6978 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Richard,

On Mon, Oct 24, 2011 at 2:22 = PM, Richard L. Barnes <rbarnes@bbn.com> wrote:

--Richard

On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote:

> On a second thought: TLS fails before WebSocket connection is establis= hed, so (unless I am missing something) TLS related close codes will never = be sent on the wire. However reserving some WebSocket codes is still a good= idea.
>
> On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrotetL
> That was supposed to be sent to the mailing list. The WG should consid= er adding multiple codes if needed.
>
>
> ---------- Forwarded message ----------
> From: Alexey Melnikov <alexey.melnikov@isode.com>
> Date: Mon, Oct 24, 2011 at 1:34 PM
> Subject: Re: [hybi] failed TLS handshake: which close code?
> To: Tobias Oberstein <tobias.oberstein@tavendo.de>
>
>
> Hi Tobias,
>
> On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote: > Hybi-17:
>
> """
> 4. Opening Handshake
> ...
> 4.1. Client Requirements
> ...
> =A0 5. =A0If /secure/ is true, the client MUST perform a TLS handshake= over
> =A0 =A0 =A0 the connection after opening the connection and before sen= ding
> =A0 =A0 =A0 the handshake data [RFC2818]. =A0If this fails (e.g. the s= erver's
> =A0 =A0 =A0 certificate could not be verified), then the client MUST _= Fail
> =A0 =A0 =A0 the WebSocket Connection_ and abort the connection. =A0Oth= erwise,
> =A0 =A0 =A0 all further communication on this channel MUST run through= the
> =A0 =A0 =A0 encrypted tunnel. =A0[RFC5246]
> """
>
> When the client fails the TLS handshake (i.e. because of invalid serve= r certificate),
> which close status code would be appropriate to use for signaling that= specific
> reason to the caller?
>
> Is it supposed to use a close status code from the following range? >
> """
> =A0 3000-3999
>
> =A0 =A0 =A0Status codes in the range 3000-3999 are reserved for use by=
> =A0 =A0 =A0libraries, frameworks and application. =A0These status code= s are
> =A0 =A0 =A0registered directly with IANA. =A0The interpretation of the= se codes
> =A0 =A0 =A0is undefined by this protocol.
> """
>
> Or are those only for "use on wire" not for signaling the ca= ller?
>
> For example, Firefox currently provides the calling JavaScript with a = "1006 Abnormal Connection Close":
>
> """
> =A01006
>
> =A0 =A0 =A01006 is a reserved value and MUST NOT be set as a status co= de in a
> =A0 =A0 =A0Close control frame by an endpoint. =A0It is designated for= use in
> =A0 =A0 =A0applications expecting a status code to indicate that the > =A0 =A0 =A0connection was closed abnormally, e.g. without sending or > =A0 =A0 =A0receiving a Close control frame.
> """
>
> However, this could be multiple things and is not giving the real reas= on to the JS.
> The JS thus can't react specifically ..
>
> TLS handshake probably deserves a separate 1XXX close code.
>
>
>

> ________________________= _______________________
> hybi mailing list
> hybi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

--20cf303bfbde49e0f304b00b6978-- From rbarnes@bbn.com Mon Oct 24 06:53:30 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A949221F8D9E for ; Mon, 24 Oct 2011 06:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9gfWdZ1Ny8u for ; Mon, 24 Oct 2011 06:53:30 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by ietfa.amsl.com (Postfix) with ESMTP id F08D721F8D9D for ; Mon, 24 Oct 2011 06:53:29 -0700 (PDT) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:55580) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RIKy1-0001kk-Ap; Mon, 24 Oct 2011 09:53:29 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 24 Oct 2011 09:53:28 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <363A8979-63BA-489F-A1A0-A8A3287891C6@bbn.com> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1084) Cc: hybi@ietf.org Subject: Re: [hybi] failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 13:53:30 -0000 To quote the WebSocket API: " If the user agent was required to fail the websocket connection or the = WebSocket connection is closed with prejudice, fire a simple event named = error at the WebSocket object. " So if TLS fails and the client has to _Fail the WebSocket Connection_, = then the API only reports an error; it does not provide a close code. = Which is appropriate, because the existence of a close code presumes the = existence of an established WS connection, which does not exist in this = case. --Richard On Oct 24, 2011, at 9:29 AM, Alexey Melnikov wrote: > Hi Richard, >=20 > On Mon, Oct 24, 2011 at 2:22 PM, Richard L. Barnes = wrote: > +1 >=20 > It's silly to require the WS implementation to send a close frame in = plaintext after the TLS connection fails. I don't even think this sort = of thing would be supported by standard TLS libraries. > Right. But the TLS-related code(s) might have to be allocated for use = in the WebSocket API.=20 >=20 > --Richard >=20 >=20 >=20 > On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote: >=20 > > On a second thought: TLS fails before WebSocket connection is = established, so (unless I am missing something) TLS related close codes = will never be sent on the wire. However reserving some WebSocket codes = is still a good idea. > > > > On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov = wrotetL > > That was supposed to be sent to the mailing list. The WG should = consider adding multiple codes if needed. > > > > > > ---------- Forwarded message ---------- > > From: Alexey Melnikov > > Date: Mon, Oct 24, 2011 at 1:34 PM > > Subject: Re: [hybi] failed TLS handshake: which close code? > > To: Tobias Oberstein > > > > > > Hi Tobias, > > > > On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein = wrote: > > Hybi-17: > > > > """ > > 4. Opening Handshake > > ... > > 4.1. Client Requirements > > ... > > 5. If /secure/ is true, the client MUST perform a TLS handshake = over > > the connection after opening the connection and before sending > > the handshake data [RFC2818]. If this fails (e.g. the = server's > > certificate could not be verified), then the client MUST _Fail > > the WebSocket Connection_ and abort the connection. = Otherwise, > > all further communication on this channel MUST run through the > > encrypted tunnel. [RFC5246] > > """ > > > > When the client fails the TLS handshake (i.e. because of invalid = server certificate), > > which close status code would be appropriate to use for signaling = that specific > > reason to the caller? > > > > Is it supposed to use a close status code from the following range? > > > > """ > > 3000-3999 > > > > Status codes in the range 3000-3999 are reserved for use by > > libraries, frameworks and application. These status codes are > > registered directly with IANA. The interpretation of these = codes > > is undefined by this protocol. > > """ > > > > Or are those only for "use on wire" not for signaling the caller? > > > > For example, Firefox currently provides the calling JavaScript with = a "1006 Abnormal Connection Close": > > > > """ > > 1006 > > > > 1006 is a reserved value and MUST NOT be set as a status code = in a > > Close control frame by an endpoint. It is designated for use = in > > applications expecting a status code to indicate that the > > connection was closed abnormally, e.g. without sending or > > receiving a Close control frame. > > """ > > > > However, this could be multiple things and is not giving the real = reason to the JS. > > The JS thus can't react specifically .. > > > > TLS handshake probably deserves a separate 1XXX close code. > > > > > > > > _______________________________________________ > > hybi mailing list > > hybi@ietf.org > > https://www.ietf.org/mailman/listinfo/hybi >=20 >=20 From webmaster@zaphoyd.com Mon Oct 24 07:02:47 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD0121F8D8D for ; Mon, 24 Oct 2011 07:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RClosh6cIV5F for ; Mon, 24 Oct 2011 07:02:47 -0700 (PDT) Received: from sh78.surpasshosting.com (sh78.surpasshosting.com [72.29.64.142]) by ietfa.amsl.com (Postfix) with ESMTP id E6CB921F8C4A for ; Mon, 24 Oct 2011 07:02:46 -0700 (PDT) Received: from c-68-51-77-246.hsd1.il.comcast.net ([68.51.77.246]:33207 helo=[10.0.1.82]) by sh78.surpasshosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1RIL6x-0001X6-Jx; Mon, 24 Oct 2011 10:02:44 -0400 Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: multipart/alternative; boundary="Apple-Mail=_3DBC1076-8285-4810-ACED-89828EB6D849" From: Peter Thorson In-Reply-To: Date: Mon, 24 Oct 2011 09:02:42 -0500 Message-Id: References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> To: Alexey Melnikov X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - sh78.surpasshosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - zaphoyd.com X-Source: X-Source-Args: X-Source-Dir: Cc: hybi@ietf.org Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 14:02:48 -0000 --Apple-Mail=_3DBC1076-8285-4810-ACED-89828EB6D849 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Oct 24, 2011, at 8:19 , Alexey Melnikov wrote: > On Mon, Oct 24, 2011 at 2:09 PM, Peter Thorson = wrote: >=20 > On Oct 24, 2011, at 8:04 , Alexey Melnikov wrote: >=20 > > That was supposed to be sent to the mailing list. The WG should = consider adding multiple codes if needed. > > > > TLS handshake probably deserves a separate 1XXX close code. >=20 > What is the procedure right now for adding more 1XXX close codes? >=20 > People should suggest specific close codes on the mailing list and, = ideally, suggest their description. >=20 > For codes recommended this week or next (basically before the final = RFC is published), there is a good chance that they can be included = directly into the RFC-to-be. >=20 > Close codes suggested later can still be added to the registry (they = will need a review by a yet-to-be-appointed Expert Reviewer -- IESG will = take care of this), but they will not appear in the RFC. >=20 > All of the codes will be seen in the IANA registry = () > =20 > In addition to TLS stuff, I still think (and a few here have agreed) = that we also need a 1XXX code similar in meaning to HTTP 500/"internal = server error" > Agreed. I that case like to propose the following code: 1011/Internal Endpoint Error 1011 indicates that an endpoint is terminating the connection due to an = unexpected condition that prevents it from safely continuing. The = condition is the result of an internal logic error and not the fault of = the remote peer except tangentially (i.e. in cases where the remote peer = sent a valid frame that the terminating endpoint could not understand). = More information about the error may be available in the terminating = endpoint's log files.= --Apple-Mail=_3DBC1076-8285-4810-ACED-89828EB6D849 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

On Mon, Oct 24, 2011 at 2:09 PM, Peter Thorson <webmaster@zaphoyd.com>= wrote:

On Oct 24, 2011, at 8:04 , Alexey Melnikov wrote:

> That was supposed to be sent to the mailing list. The WG should = consider adding multiple codes if needed.
>

> TLS handshake probably deserves a separate = 1XXX close code.

What is the procedure right now for adding more 1XXX close = codes?

People should suggest specific = close codes on the mailing list and, ideally, suggest their = description.

For codes recommended this week or next (basically before the = final RFC is published), there is a good chance that they can be = included directly into the RFC-to-be.

Close = codes suggested later can still be added to the registry (they will need = a review by a yet-to-be-appointed Expert Reviewer -- IESG will take care = of this), but they will not appear in the RFC.

All of the codes will be seen in the IANA registry = (<http://ww= w.iana.org/assignments/websocket/websocket.xml>)
&n= bsp;

In addition to TLS = stuff, I still think (and a few here have agreed) that we also need a = 1XXX code similar in meaning to HTTP 500/"internal server = error"

Agreed.

Date: Mon, 24 Oct 2011 07:55:24 -0700 Thread-Topic: [hybi] failed TLS handshake: which close code? Thread-Index: AcySUPfuAQDulTv5S/GqcmdGUkmQwQAC2sWg Message-ID: <634914A010D0B943A035D226786325D42D0B036E63@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: multipart/alternative; boundary="_000_634914A010D0B943A035D226786325D42D0B036E63EXVMBX02012ex_" MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 14:55:39 -0000 --_000_634914A010D0B943A035D226786325D42D0B036E63EXVMBX02012ex_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yep, its not about _sending_ a close frame (which would be silly). Its abou= t signaling the application. There are already two close code which must not be used on the wire and are only there for signaling errors to the application: 1005 and 1006. The spec says they must not be used on wire, the spec does not speak about whether the codes must only be used when a WS connection previsously existe= d .. Von: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] Im Auftrag von Al= exey Melnikov Gesendet: Montag, 24. Oktober 2011 15:29 An: Richard L. Barnes Cc: hybi@ietf.org Betreff: Re: [hybi] failed TLS handshake: which close code? Hi Richard, On Mon, Oct 24, 2011 at 2:22 PM, Richard L. Barnes > wrote: +1 It's silly to require the WS implementation to send a close frame in plaint= ext after the TLS connection fails. I don't even think this sort of thing = would be supported by standard TLS libraries. Right. But the TLS-related code(s) might have to be allocated for use in th= e WebSocket API. --Richard On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote: > On a second thought: TLS fails before WebSocket connection is established= , so (unless I am missing something) TLS related close codes will never be = sent on the wire. However reserving some WebSocket codes is still a good id= ea. > > On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov > wrotetL > That was supposed to be sent to the mailing list. The WG should consider = adding multiple codes if needed. > > > ---------- Forwarded message ---------- > From: Alexey Melnikov > > Date: Mon, Oct 24, 2011 at 1:34 PM > Subject: Re: [hybi] failed TLS handshake: which close code? > To: Tobias Oberstein > > > > Hi Tobias, > > On Mon, Oct 24, 2011 at 3:58 AM, Tobias Oberstein > wrote: > Hybi-17: > > """ > 4. Opening Handshake > ... > 4.1. Client Requirements > ... > 5. If /secure/ is true, the client MUST perform a TLS handshake over > the connection after opening the connection and before sending > the handshake data [RFC2818]. If this fails (e.g. the server's > certificate could not be verified), then the client MUST _Fail > the WebSocket Connection_ and abort the connection. Otherwise, > all further communication on this channel MUST run through the > encrypted tunnel. [RFC5246] > """ > > When the client fails the TLS handshake (i.e. because of invalid server c= ertificate), > which close status code would be appropriate to use for signaling that sp= ecific > reason to the caller? > > Is it supposed to use a close status code from the following range? > > """ > 3000-3999 > > Status codes in the range 3000-3999 are reserved for use by > libraries, frameworks and application. These status codes are > registered directly with IANA. The interpretation of these codes > is undefined by this protocol. > """ > > Or are those only for "use on wire" not for signaling the caller? > > For example, Firefox currently provides the calling JavaScript with a "10= 06 Abnormal Connection Close": > > """ > 1006 > > 1006 is a reserved value and MUST NOT be set as a status code in a > Close control frame by an endpoint. It is designated for use in > applications expecting a status code to indicate that the > connection was closed abnormally, e.g. without sending or > receiving a Close control frame. > """ > > However, this could be multiple things and is not giving the real reason = to the JS. > The JS thus can't react specifically .. > > TLS handshake probably deserves a separate 1XXX close code. > > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi --_000_634914A010D0B943A035D226786325D42D0B036E63EXVMBX02012ex_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yep, its no= t about _sending_ a close frame (which would be silly). Its about signaling= the application.

&nb= sp;

There are already two close= code which must not be used on the wire and are

only there for signaling errors to the application: = 1005 and 1006.

The spec says they must not be= used on wire, the spec does not speak about

whether the codes must only be used when a WS connectio= n previsously existed ..

<= o:p>

Von: hybi-bounces@ietf.org = [mailto:hybi-bounces@ietf.org] Im Auftrag von Alexey Melnikov
= Gesendet: Montag, 24. Oktober 2011 15:29
An: Richard L. Barne= s
Cc: hybi@ietf.org
Betreff: Re: [hybi] failed TLS hand= shake: which close code?

Hi Richard,

On Mon, Oct 24, 2011 = at 2:22 PM, Richard L. Barnes <rbarne= s@bbn.com> wrote:

+1

It's = silly to require the WS implementation to send a close frame in plaintext a= fter the TLS connection fails. I don't even think this sort of thing = would be supported by standard TLS libraries.

Right. But the TLS-related code(s) might have to be allocated = for use in the WebSocket API.

--Richard

On Oct 24, 2011, at 9:09 AM, Alexey Melnikov wrote:

&g= t; On a second thought: TLS fails before WebSocket connection is establishe= d, so (unless I am missing something) TLS related close codes will never be= sent on the wire. However reserving some WebSocket codes is still a good i= dea.
>
> On Mon, Oct 24, 2011 at 2:04 PM, Alexey Melnikov <<= a href=3D"mailto:alexey.melnikov@isode.com">alexey.melnikov@isode.com&g= t; wrotetL
> That was supposed to be sent to the mailing list. The WG= should consider adding multiple codes if needed.
>
>
> -= --------- Forwarded message ----------
> From: Alexey Melnikov <alexey.melnikov@isode.com>= ;
> Date: Mon, Oct 24, 2011 at 1:34 PM
> Subject: Re: [hybi] fa= iled TLS handshake: which close code?
> To: Tobias Oberstein <tobias.oberstein@tavendo.de&= gt;
>
>
> Hi Tobias,
>
> On Mon, Oct 24, 2011= at 3:58 AM, Tobias Oberstein <tobias.oberstein@tavendo.de> wrote:
> Hybi-17:
>> """
> 4. Opening Handshake
> ...
> = 4.1. Client Requirements
> ...
> 5. If /secure/ is= true, the client MUST perform a TLS handshake over
> &= nbsp; the connection after opening the connection and before sending
>= ; the handshake data [RFC2818]. If this fails (e= .g. the server's
> certificate could not be veri= fied), then the client MUST _Fail
> the WebSocke= t Connection_ and abort the connection. Otherwise,
> &nb= sp; all further communication on this channel MUST run through the> encrypted tunnel. [RFC5246]
> "= ;""
>
> When the client fails the TLS handshake (i.e.= because of invalid server certificate),
> which close status code wo= uld be appropriate to use for signaling that specific
> reason to the= caller?
>
> Is it supposed to use a close status code from the= following range?
>
> """
> 3000-39= 99
>
> Status codes in the range 3000-3999 = are reserved for use by
> libraries, frameworks a= nd application. These status codes are
> re= gistered directly with IANA. The interpretation of these codes
>= ; is undefined by this protocol.
> ""&q= uot;
>
> Or are those only for "use on wire" not for = signaling the caller?
>
> For example, Firefox currently provid= es the calling JavaScript with a "1006 Abnormal Connection Close"= :
>
> """
> 1006
>
> &nb= sp; 1006 is a reserved value and MUST NOT be set as a status c= ode in a
> Close control frame by an endpoint. &n= bsp;It is designated for use in
> applications ex= pecting a status code to indicate that the
> conn= ection was closed abnormally, e.g. without sending or
> = receiving a Close control frame.
> """
><= br>> However, this could be multiple things and is not giving the real r= eason to the JS.
> The JS thus can't react specifically ..
>> TLS handshake probably deserves a separate 1XXX close code.
>>
>
> __________________________________________= _____
> hybi mailing list
> hy= bi@ietf.org
> https://www.ietf.org/mailman/listinfo/hybi

= --_000_634914A010D0B943A035D226786325D42D0B036E63EXVMBX02012ex_-- From tobias.oberstein@tavendo.de Mon Oct 24 07:57:13 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB721F8C85 for ; Mon, 24 Oct 2011 07:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q-6qYESoHD+e for ; Mon, 24 Oct 2011 07:57:12 -0700 (PDT) Received: from EXHUB020-5.exch020.serverdata.net (exhub020-5.exch020.serverdata.net [206.225.164.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0FB21F8C69 for ; Mon, 24 Oct 2011 07:57:12 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-5.exch020.serverdata.net ([206.225.164.32]) with mapi; Mon, 24 Oct 2011 07:57:11 -0700 From: Tobias Oberstein To: "Richard L. Barnes" , Alexey Melnikov Date: Mon, 24 Oct 2011 07:57:11 -0700 Thread-Topic: [hybi] failed TLS handshake: which close code? Thread-Index: AcySVFSqZxa3N/K/Rd+2XzLkoHI9KAAByt7w Message-ID: <634914A010D0B943A035D226786325D42D0B036E6B@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<7ECB103B-4C75-49B2-A29B-ABCF91B3DB36@bbn.com> <363A8979-63BA-489F-A1A0-A8A3287891C6@bbn.com> In-Reply-To: <363A8979-63BA-489F-A1A0-A8A3287891C6@bbn.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 14:57:13 -0000 > To quote the WebSocket API: > " > If the user agent was required to fail the websocket connection or the > WebSocket connection is closed with prejudice, fire a simple event named > error at the WebSocket object. > " >=20 > So if TLS fails and the client has to _Fail the WebSocket Connection_, th= en > the API only reports an error; it does not provide a close code. Which i= s > appropriate, because the existence of a close code presumes the existence > of an established WS connection, which does not exist in this case. >=20 But the text of above (step 2) spec continues (with step 3): " Create an event that uses the CloseEvent interface, with the event name clo= se, which does not bubble, is not cancelable, has no default action, whose = wasClean attribute is initialized to true if the connection closed cleanly = and false otherwise, whose code attribute is initialized to the WebSocket c= onnection close code, and whose reason attribute is initialized to the WebS= ocket connection close reason decoded as UTF-8, with error handling, and di= spatch the event at the WebSocket object. " I'm not sure: does step 2 prevent doing step 3? In any case: a) Firefox currently fires "close" with 1006 "Abormal Close" on TLS invalid= cert. failure b) If no WS close code will be reserved for "TLS invalid cert", then what a= lternative is there to signal that specific error condition to the app? c) Why is it so bad to have a code never used on wire, but used to signal a= n error that happened before a WS connection was established? =20 From jat@google.com Mon Oct 24 08:05:41 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A2E421F8E4A for ; Mon, 24 Oct 2011 08:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86Cb2UQqQ0i9 for ; Mon, 24 Oct 2011 08:05:41 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id DE82421F8E46 for ; Mon, 24 Oct 2011 08:05:40 -0700 (PDT) Received: from hpaq6.eem.corp.google.com (hpaq6.eem.corp.google.com [172.25.149.6]) by smtp-out.google.com with ESMTP id p9OF5XsQ005238 for ; Mon, 24 Oct 2011 08:05:34 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319468734; bh=YyWBamlaFRM7hF1IqplCyBlJkiM=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=YTaquEL87myRi0FSm27aM/5R9D1Kr8iexDIboFatUn4u5P/5NNbGu54+MnlKpjWrg uEd+dKCI72uX4lkOIbq1g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=mVHbIWjU7X8sS/TKVaAZphtLiUSVoTZpQB33lNRmr1bODVZ3nzjzlorbhiVdBzAy3 fUMEUZiMAvLDboL8O6Sqg== Received: from vws15 (vws15.prod.google.com [10.241.21.143]) by hpaq6.eem.corp.google.com with ESMTP id p9OF50q8004103 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 08:05:32 -0700 Received: by vws15 with SMTP id 15so8827895vws.6 for ; Mon, 24 Oct 2011 08:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=hiz5U4dfheOKSQvz/pchaAx16dvdS546cEPBSAcjAI0=; b=IYdqeEpWwwE/Vvk7jR/lqmonEIqJoOP4m1xZ4CM3UFqiJC3BuFsJtGw73Ka0Lrgfzx KwjaZnbCfbK5DvrbNe6g== Received: by 10.150.135.2 with SMTP id i2mr21242284ybd.44.1319468732303; Mon, 24 Oct 2011 08:05:32 -0700 (PDT) Received: by 10.150.135.2 with SMTP id i2mr21242269ybd.44.1319468732139; Mon, 24 Oct 2011 08:05:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 24 Oct 2011 08:05:12 -0700 (PDT) In-Reply-To: <21fe01cc9237$b08dc780$0a00a8c0@Venus> References:

On Mon, Oct 24, 2011 at 6:28 AM, Len Holgate <len.holgate@gma= il.com> wrote:

Ok, sorry, it must fail to enable the extension.

<= /div>

While the intermediary could conceivably alter the handshake, in = most cases they are simply observers of the traffic. =C2=A0If they actually= terminate one connection and create another, they are more properly tw WS = endpoints rather than an intermediary.

=C2=A0

If we don't change the base protocol and the intermediary doesn't c= are about
payload data then it could allow the extension to be enabled and simply dea= l
with the normal websocket framing rules and ignore the content of the frame= s
and any mux specific stuff that's going on.

We aren't changing the base protocol -- the base protocol already = allows extensions to define the meaning of such things. =C2=A0If existing i= ntermediaries violate this, then perhaps it is good to get an extension out= early that will break them, so they properly implement the spec.

The whole point of having MUX in the first place is tha= t it can be done without changing the endpoints. =C2=A0In a typical scenari= o, the user agent automatically reuses existing connections and sends to a = mux-aware server, with application code on both ends neither knowing or car= ing that this is taking place.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd5d02612490404b00cc117-- From tobias.oberstein@tavendo.de Mon Oct 24 08:06:44 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2652721F8C87 for ; Mon, 24 Oct 2011 08:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id muWk858FDG6g for ; Mon, 24 Oct 2011 08:06:43 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC7821F8C78 for ; Mon, 24 Oct 2011 08:06:43 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 24 Oct 2011 08:06:42 -0700 From: Tobias Oberstein To: Peter Thorson , Alexey Melnikov Date: Mon, 24 Oct 2011 08:06:41 -0700 Thread-Topic: [hybi] Fwd: failed TLS handshake: which close code? Thread-Index: AcySVaHNvvVsYFhlT5CLM5HUgEh1mgAB8xwg Message-ID: <634914A010D0B943A035D226786325D42D0B036E7D@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com>

In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 15:06:44 -0000 > 1011/Internal Endpoint Error > > 1011 indicates that an endpoint is terminating the connection due to an u= nexpected condition that prevents it from safely continuing. The condition = is the result of an internal logic error and not the fault of the remote pe= er except tangentially (i.e. in cases where the > > remote peer sent a vali= d frame that the terminating endpoint could not understand). More informati= on about the error may be available in the terminating endpoint's log files= . +1 1012/Service Restart 1012 indicates that the service is restarted. a client may reconnect, and i= f it choses to do, should reconnect using a randomized delay of 5 - 30s. Use case: restart a service with 100k clients connected clients present an informative user notification ("service restarting .. re= connecting in N secs)=20 clients should not reconnect all at exactly the same time .. thus the rando= mized delay 1013/Service Overload 1013 indicates that the service is experiencing overload. a client should o= nly connect to a different IP (when there are multiple for the target) or r= econnect to the same IP upon user action. Use case: clients present an informative user notification ("service overload .. try = later or try different IP) From jat@google.com Mon Oct 24 08:08:24 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1463A21F8D0B for ; Mon, 24 Oct 2011 08:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpzmU2bUi5jq for ; Mon, 24 Oct 2011 08:08:23 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 7F55D21F8C5B for ; Mon, 24 Oct 2011 08:08:16 -0700 (PDT) Received: from hpaq1.eem.corp.google.com (hpaq1.eem.corp.google.com [172.25.149.1]) by smtp-out.google.com with ESMTP id p9OF8Fhh014734 for ; Mon, 24 Oct 2011 08:08:15 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319468896; bh=ST4RCWZOTnszdBW3uidduvOPncA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=iul3T76QqUK/21xBUjxghN3jYSZD8e1d1/yffk337ftuuhGt8+f7ksXVzhKvhAb9r 1KfQ5pnvuXrPNhi2hb5Uw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=LJie8om/O41TL1r4mCjxWJTC8CgBp3r2YarU2VnDj91ov2IXaoIKiJ9ZDvOY1PvY/ zNiBfQf2uWiAHRVhxryYA== Received: from ywt32 (ywt32.prod.google.com [10.192.20.32]) by hpaq1.eem.corp.google.com with ESMTP id p9OF43s6021357 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 08:08:14 -0700 Received: by ywt32 with SMTP id 32so3244651ywt.0 for ; Mon, 24 Oct 2011 08:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vTnXsrlBrZO0qMUleQNlwfzYWLoIYiF0VY53TOGQ3NI=; b=pLskzLZTuZcVntkFUWKOh0Z3FDWJRHE9449Vv0uEyZyJtz8Lv2FtbXX3zQruLkp178 ljrTsWB/dgVv5Q3jYHGg== Received: by 10.150.214.14 with SMTP id m14mr21854016ybg.74.1319468894277; Mon, 24 Oct 2011 08:08:14 -0700 (PDT) Received: by 10.150.214.14 with SMTP id m14mr21853999ybg.74.1319468894089; Mon, 24 Oct 2011 08:08:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 24 Oct 2011 08:07:54 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D42D0B036D71@EXVMBX020-12.exch020.serverdata.net> References:

On Mon, Oct 24, 2011 at 6:47 AM, Tobias Oberstei= n <tobi= as.oberstein@tavendo.de> wrote:

there might be extensions which don't change the base= WS framing rules, where an
intermediary not understanding the extension might nevertheless safely chan= ge
the fragmentation

i.e. "per-frame compression" when intermediary does not understan= d

No, if you move one byte from one fr= agment to another, you will have to alter both that byte (and possibly subs= titute a different ending byte for the first frame) and the succeeding byte= s in a hypothetical per-frame-compression extension. =C2=A0Since an interme= diary that doesn't understand an extension doesn't even know if the= re are any extension data bytes at the beginning of the payload or not, or = whether these are per-message or per-frame, it cannot change fragmentation = at all if it does not understand any negotiated extension.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd352a8b9730504b00cca63-- From tobias.oberstein@tavendo.de Mon Oct 24 08:24:45 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87FBD21F8EB2 for ; Mon, 24 Oct 2011 08:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id To9DLBuPxATO for ; Mon, 24 Oct 2011 08:24:45 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 9486C21F8EB1 for ; Mon, 24 Oct 2011 08:24:44 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 24 Oct 2011 08:24:44 -0700 From: Tobias Oberstein To: Alexey Melnikov , Peter Thorson Date: Mon, 24 Oct 2011 08:24:42 -0700 Thread-Topic: [hybi] Fwd: failed TLS handshake: which close code? Thread-Index: AcyST5tpCCU5wmykQI+wo/5Vbug1wwAEJdnw Message-ID: <634914A010D0B943A035D226786325D42D0B036E9D@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 15:24:45 -0000 TLS handshake failure codes proposal: 1014/ TLS Handshake Failed By Client : The TLS handshake was failed by the = client (unspecific). 1015/TLS Handshake Failed By Server : The TLS handshake was failed by the s= erver (unspecific). 1016/TLS Handshake Failed By Client - Invalid Server Certificate : The TLS= handshake was failed by the client due to the server certificate being inv= alid or not accepted. 1017/TLS Handshake Failed By Server - Invalid Client Certificate : The TLS = handshake, where the server requested a client certificate, was failed by t= he client due to the client certificate being invalid or not accepted. From rbarnes@bbn.com Mon Oct 24 09:07:38 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96CDF21F8CA4 for ; Mon, 24 Oct 2011 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zEQLRn7W23e for ; Mon, 24 Oct 2011 09:07:37 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 92A3421F8876 for ; Mon, 24 Oct 2011 09:07:37 -0700 (PDT) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:57354) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RIN3m-0003KU-7P; Mon, 24 Oct 2011 12:07:34 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <634914A010D0B943A035D226786325D42D0B036E9D@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 24 Oct 2011 12:07:33 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> <634914A010D0B943A035D226786325D42D0B036E9D@EXVMBX020-12.exch020.serverdata.net> To: Tobias Oberstein X-Mailer: Apple Mail (2.1084) Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 16:07:38 -0000 This is pointless. These codes are not needed by the WS API, since a = TLS failure does not provide a close code. These codes are not needed = by the WS protocol, since neither party will send a close frame (since = there's no TLS channel). =20 --Richard On Oct 24, 2011, at 11:24 AM, Tobias Oberstein wrote: > TLS handshake failure codes proposal: >=20 > 1014/ TLS Handshake Failed By Client : The TLS handshake was failed by = the client (unspecific). >=20 > 1015/TLS Handshake Failed By Server : The TLS handshake was failed by = the server (unspecific). >=20 > 1016/TLS Handshake Failed By Client - Invalid Server Certificate : = The TLS handshake was failed by the client due to the server certificate = being invalid or not accepted. >=20 > 1017/TLS Handshake Failed By Server - Invalid Client Certificate : The = TLS handshake, where the server requested a client certificate, was = failed by the client due to the client certificate being invalid or not = accepted. >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From tobias.oberstein@tavendo.de Mon Oct 24 09:25:46 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9BA21F0C58 for ; Mon, 24 Oct 2011 09:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5yn6XI4U+9u8 for ; Mon, 24 Oct 2011 09:25:46 -0700 (PDT) Received: from EXHUB020-3.exch020.serverdata.net (exhub020-3.exch020.serverdata.net [206.225.164.30]) by ietfa.amsl.com (Postfix) with ESMTP id BDB601F0C5D for ; Mon, 24 Oct 2011 09:25:43 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-3.exch020.serverdata.net ([206.225.164.30]) with mapi; Mon, 24 Oct 2011 09:25:43 -0700 From: Tobias Oberstein To: "Richard L. Barnes" Date: Mon, 24 Oct 2011 09:25:41 -0700 Thread-Topic: [hybi] Fwd: failed TLS handshake: which close code? Thread-Index: AcySZxQRHSKClYs0RfOxI68Zr9wpAwAAdZMg Message-ID: <634914A010D0B943A035D226786325D42D0B036EF5@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> <634914A010D0B943A035D226786325D42D0B036E9D@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 16:25:47 -0000 > This is pointless. These codes are not needed by the WS API, since a TLS > failure does not provide a close code.=20 Well, both Chrome (16.0.912.10 canary) and Firefox (10.0a1 (2011-10-24)) _do_ fire the onclose() event handler with 1006 when the WS connection cann= ot even be established (host unreachable). Firefox fires the onclose() with 1006 also for WSS when the server cert is = invalid. Chrome currently does not check WSS server cert (unrelated beh./bug). So both browsers are wrong? Anyway: what is your recommendation for WS API for _apps_ (JavaScript) to r= ecognize "invalid server cert"? From jat@google.com Mon Oct 24 09:28:38 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A984011E808C for ; Mon, 24 Oct 2011 09:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.885 X-Spam-Level: X-Spam-Status: No, score=-105.885 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV8n-ezbQUTW for ; Mon, 24 Oct 2011 09:28:38 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id D24FB11E8083 for ; Mon, 24 Oct 2011 09:28:37 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p9OGSW4C031684 for ; Mon, 24 Oct 2011 09:28:32 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319473712; bh=DqRUcMM4MqwZFUGeufnKfG9xvTI=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=uZodc9LbL2c8S6rIRR48eLlmdY1kUvRlR9B/PTIqbNqc2UW7Seeqqgtx29LxkyQVo uyTk608I5sVj/NXv9sCeQ== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=vPmC3duaFSsl2QsuOccc4phlDiSXalpJjDO97EfXi82s1Itk1KrSfY0RIwyv8gRxq 2gsCxJilKZeDu3HpmkY6Q== Received: from yxn16 (yxn16.prod.google.com [10.190.4.80]) by hpaq12.eem.corp.google.com with ESMTP id p9OGLmmc018517 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Mon, 24 Oct 2011 09:28:31 -0700 Received: by yxn16 with SMTP id 16so2856472yxn.4 for ; Mon, 24 Oct 2011 09:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=U2qKBIfuqh5pscjJVmKTjRcjQQc4qNKf8eQAic2hkFk=; b=pVmAUFQbSRMYq5OB1dwZ0sqBtHw5PRIcAzbTgNREVORXNtvMsJigunCIXl3xWcPUD0 iZCc9pE56hxH92Ca1++A== Received: by 10.150.214.1 with SMTP id m1mr11728099ybg.89.1319473711605; Mon, 24 Oct 2011 09:28:31 -0700 (PDT) Received: by 10.150.214.1 with SMTP id m1mr11728080ybg.89.1319473711464; Mon, 24 Oct 2011 09:28:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Mon, 24 Oct 2011 09:28:11 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D42D0B036EF5@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> <634914A010D0B943A035D226786325D42D0B036E9D@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D42D0B036EF5@EXVMBX020-12.exch020.serverdata.net> From: John Tamplin Date: Mon, 24 Oct 2011 12:28:11 -0400 Message-ID: To: Tobias Oberstein Content-Type: multipart/alternative; boundary=000e0cd355f0dcc20d04b00de9f1 X-System-Of-Record: true Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 16:28:38 -0000 --000e0cd355f0dcc20d04b00de9f1 Content-Type: text/plain; charset=UTF-8 On Mon, Oct 24, 2011 at 12:25 PM, Tobias Oberstein < tobias.oberstein@tavendo.de> wrote: > Anyway: what is your recommendation for WS API for _apps_ (JavaScript) to > recognize "invalid server cert"? > As this doesn't have anything to do with the wire protocol, that question would be better asked on the WHATWG list for the WS API. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd355f0dcc20d04b00de9f1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Mon, Oct 24, 2011 at 12:25 PM, Tobias Oberste= in <tob= ias.oberstein@tavendo.de> wrote:

Anyway: what is your recommendation for WS API for _apps_= (JavaScript) to recognize "invalid server cert"?

As this doesn't have anything to do with the wi= re protocol, that question would be better asked on the WHATWG list for the= WS API.

--
John A. Tamplin
Software Engineer (GWT), Google --000e0cd355f0dcc20d04b00de9f1-- From rbarnes@bbn.com Mon Oct 24 09:29:34 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D16E11E8086 for ; Mon, 24 Oct 2011 09:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvYwb6YP2pxw for ; Mon, 24 Oct 2011 09:29:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 0B12411E8083 for ; Mon, 24 Oct 2011 09:29:34 -0700 (PDT) Received: from ros-dhcp192-1-51-60.bbn.com ([192.1.51.60]:58924) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1RINP2-0003cz-HM; Mon, 24 Oct 2011 12:29:32 -0400 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: Date: Mon, 24 Oct 2011 12:29:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <634914A010D0B943A035D226786325D42D0B036D6D@EXVMBX020-12.exch020.serverdata.net>

<0ED03DDD-1AF9-41F9-B5F0-2968BF16E378@zaphoyd.com> <634914A010D0B943A035D226786325D42D0B036E9D@EXVMBX020-12.exch020.serverdata.net> <634914A010D0B943A035D226786325D42D0B036EF5@EXVMBX020-12.exch020.serverdata.net> To: Tobias Oberstein X-Mailer: Apple Mail (2.1084) Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 16:31:01 -0000 Quoting the same part of the WS API spec as I did earlier: " If the user agent was required to fail the websocket connection or the = WebSocket connection is closed with prejudice, fire a simple event named = error at the WebSocket object. " A TLS failure requires the UA to fail the websocket connection, and = should result in an error event, not a close event. So it seems that = Chrome and Firefox are not following the spec in this regard. --Richard On Oct 24, 2011, at 12:25 PM, Tobias Oberstein wrote: >> This is pointless. These codes are not needed by the WS API, since a = TLS >> failure does not provide a close code.=20 >=20 > Well, both Chrome (16.0.912.10 canary) and Firefox (10.0a1 = (2011-10-24)) > _do_ fire the onclose() event handler with 1006 when the WS connection = cannot > even be established (host unreachable). >=20 > Firefox fires the onclose() with 1006 also for WSS when the server = cert is invalid. > Chrome currently does not check WSS server cert (unrelated beh./bug). >=20 > So both browsers are wrong? >=20 > Anyway: what is your recommendation for WS API for _apps_ (JavaScript) = to recognize "invalid server cert"? >=20 From derhoermi@gmx.net Mon Oct 24 14:17:19 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFAB11E80E7 for ; Mon, 24 Oct 2011 14:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO+d1mcuwgei for ; Mon, 24 Oct 2011 14:17:19 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id AA2CA11E809B for ; Mon, 24 Oct 2011 14:17:18 -0700 (PDT) Received: (qmail invoked by alias); 24 Oct 2011 21:17:17 -0000 Received: from dslb-094-223-152-226.pools.arcor-ip.net (EHLO HIVE) [94.223.152.226] by mail.gmx.net (mp025) with SMTP; 24 Oct 2011 23:17:17 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX187hDEbIKk7+KJ3GBWvZgKGBduZfm0AWXpH9Ekwjw DP+wNEmF5VjkfM From: Bjoern Hoehrmann To: Alexey Melnikov Date: Mon, 24 Oct 2011 23:17:22 +0200 Message-ID: References: <634914A010D0B943A035D226786325D42D0B036D37@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: X-Mailer: Forte Agent 3.3/32.846 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] WS URLs X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 21:17:19 -0000 * Alexey Melnikov wrote: >On Sat, Oct 22, 2011 at 5:40 PM, Tobias Oberstein < >tobias.oberstein@tavendo.de> wrote: >> Which of the following URLs are valid WS URLs? >> >> 1. ws://example.com/something#somewhere >> 2. ws://example.com/something#somewhere/ >> 3. ws://example.com/something#somewhere/foo >> 4. ws://example.com/something?query=foo#bar > >I think all of these are invalid. That is what the draft suggests. It seems incorrect to me for the draft to prohibit using fragment identifiers. Fragment identifiers are not a scheme-specific feature. -- Bj�rn H�hrmann � mailto:bjoern@hoehrmann.de � http://bjoern.hoehrmann.de Am Badedeich 7 � Telefon: +49(0)160/4415681 � http://www.bjoernsworld.de 25899 Dageb�ll � PGP Pub. KeyID: 0xA4357E78 � http://www.websitedev.de/ From gregw@intalio.com Mon Oct 24 14:59:28 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FFEF21F8C78 for ; Mon, 24 Oct 2011 14:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ek2KXZZKE5Um for ; Mon, 24 Oct 2011 14:59:28 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DFE9021F8BBA for ; Mon, 24 Oct 2011 14:59:27 -0700 (PDT) Received: by vws5 with SMTP id 5so5926286vws.31 for ; Mon, 24 Oct 2011 14:59:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.33.50 with SMTP id o18mr16987206vdi.42.1319493567169; Mon, 24 Oct 2011 14:59:27 -0700 (PDT) Received: by 10.52.180.161 with HTTP; Mon, 24 Oct 2011 14:59:27 -0700 (PDT) In-Reply-To: <220e01cc9239$bcf425d0$0a00a8c0@Venus> References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "hybi@ietf.org" , Peter Thorson Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Oct 2011 23:40:22 -0000 I believe the discussion on WS API is held at the W3C webapps WG: http://www.w3.org/2008/webapps/ > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of > Richard L. Barnes > Sent: Monday, October 24, 2011 09:30 > To: John Tamplin > Cc: hybi@ietf.org; Peter Thorson > Subject: Re: [hybi] Fwd: failed TLS handshake: which close code? >=20 > +1, I was about to say the same thing. > --Richard >=20 > On Oct 24, 2011, at 12:28 PM, John Tamplin wrote: >=20 > > On Mon, Oct 24, 2011 at 12:25 PM, Tobias Oberstein > wrote: > > Anyway: what is your recommendation for WS API for _apps_ (JavaScript) = to > recognize "invalid server cert"? > > > > As this doesn't have anything to do with the wire protocol, that questi= on > would be better asked on the WHATWG list for the WS API. > > > > -- > > John A. Tamplin > > Software Engineer (GWT), Google >=20 > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From len.holgate@gmail.com Tue Oct 25 04:03:00 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BE221F8B08 for ; Tue, 25 Oct 2011 04:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WHL8zW2L5440 for ; Tue, 25 Oct 2011 04:02:59 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id D088121F8B27 for ; Tue, 25 Oct 2011 04:02:58 -0700 (PDT) Received: by wwe6 with SMTP id 6so388799wwe.13 for ; Tue, 25 Oct 2011 04:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=JUOAb+GXlXGG+gM+c6IaGv2hTwuzMdDS/HqZ7FTH0Ok=; b=mMNTORZjEziotAWRlX5PjJ7wI4Anah0olGhl11mTTbiAEgZl1BaJFcKfbRR2e1BSfn RQmt0gQlZLJAGFtyowtWSrNTQ3pXvOu59ED9K5qxvqK8+ghadcnRtEvzMLi388otmPky wqjUpPhqbPCzMfoG5vmzNdNTyf7UQ0AGDA//I= Received: by 10.227.204.135 with SMTP id fm7mr3020061wbb.2.1319540578021; Tue, 25 Oct 2011 04:02:58 -0700 (PDT) Received: from Venus (cpc8-glfd6-2-0-cust3.6-2.cable.virginmedia.com. [86.27.228.4]) by mx.google.com with ESMTPS id eu16sm44365262wbb.7.2011.10.25.04.02.54 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 04:02:55 -0700 (PDT) From: "Len Holgate" To: "'Greg Wilkins'" References:

<21c201cc921f$bbd76a00$0a00a8c0@Venus><21d301cc9227$26c55c30$0a00a8c0@Venus><21e801cc922c$99b712b0$0a00a8c0@Venus><634914A010D0B943A035D226786325D42D0B036D6F@EXVMBX020-12.exch020.serverdata.net><220e01cc9239$bcf425d0$0a00a8c0@Venus> Date: Tue, 25 Oct 2011 12:03:17 +0100 Message-ID: <236d01cc9305$b415aa20$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: Thread-Index: AcySmDKwB7s0yBqKR2ukdzEp7n+wzAAbKpfg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 25 Oct 2011 11:03:00 -0000 Greg, I doubt I have to change my code either. I just think that in general it would be better to avoid flexing the base protocol in extension designs unless absolutely necessary. Len > -----Original Message----- > From: Greg Wilkins [mailto:gregw@intalio.com] > Sent: 24 October 2011 22:59 > To: Len Holgate > Cc: Tobias Oberstein; John Tamplin; Hybi > Subject: Re: [hybi] first draft of WS mux extension > > On 24 October 2011 21:43, Len Holgate wrote: > > I still think it would be good to avoid changing the base > protocol for every > > extension. > > Len, > > While I have not yet implemented MUX yet, I do not expect that I will > have to change the base jetty implementation to support it. > > The enforcement of non-interleaved fragments is done in a layer above > the frame parsing and below the message delivery API. It is into this > layer that extensions will be plugged, thus the MUX extension will > intercept frames and redirect them to multiple message aggregation and > delivery APIs. Thus the same code that checks for no interleaved > messages will still execute, but after the mux layer and it will check > that the demuxed streams contain legal frame sequences. > > > regards > From jat@google.com Tue Oct 25 07:40:55 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3D21F8549 for ; Tue, 25 Oct 2011 07:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JrZ7ljIf18Wb for ; Tue, 25 Oct 2011 07:40:55 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 257C421F8512 for ; Tue, 25 Oct 2011 07:40:55 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p9PEem6J019294 for ; Tue, 25 Oct 2011 07:40:48 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319553648; bh=8Eiod1Kmo6dqV4jFsBzZgAJHWkU=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=BqImvDPWAqyH1/p63OQbK41mULPflaAewSJ+VVHJOH9C3iFin6yoD+aUUF/kDd4p7 LnjSPsnGyq88sqfPd8b3g== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=ep973zju9vRLEVLkdeyWCbW4pgw+SaoOeaqg3qprR5BLXXzPYm1LEVg5K7T9+4Kkt ijXPrjPtsx9i+TOFONfBw== Received: from vws18 (vws18.prod.google.com [10.241.21.146]) by wpaz24.hot.corp.google.com with ESMTP id p9PEcRKf000768 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Tue, 25 Oct 2011 07:40:47 -0700 Received: by vws18 with SMTP id 18so781614vws.9 for ; Tue, 25 Oct 2011 07:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=l5YVtJbYJ0oN6XbgqYBGdAPGuOogzI7EgxjXr9BSFHM=; b=eNohq0tbaFBiKxmNWgyPTzJBRjF4hTSBozDQph7v4FXb98+gRohSRkkP97BXVhOMP+ tiMboMVVrNXm3JzddGmg== Received: by 10.150.135.2 with SMTP id i2mr25148634ybd.44.1319553647275; Tue, 25 Oct 2011 07:40:47 -0700 (PDT) Received: by 10.150.135.2 with SMTP id i2mr25148613ybd.44.1319553647102; Tue, 25 Oct 2011 07:40:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Tue, 25 Oct 2011 07:40:27 -0700 (PDT) In-Reply-To: <236d01cc9305$b415aa20$0a00a8c0@Venus> References:

On Tue, Oct 25, 2011 at 7:03 AM, Len Holgate <len.holgate@gma= il.com> wrote:

I doubt I have to change my code either.

I just think that in general it would be better to avoid flexing the base protocol in extension designs unless absolutely necessary.

It sounds like what you want is a subprotocol, which does n= ot meet the needs this extension was designed for. Doing some crude hack li= ke making the FIN bit set in every frame so you can interleave them arbitra= rily, then putting the real FIN bit in extension data seems far worse than = using the extensibility hooks that were designed into the base protocol spe= cifically to support extensions like this.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd5d02665cb3104b02086ae-- From len.holgate@gmail.com Tue Oct 25 09:04:27 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8887321F8C87 for ; Tue, 25 Oct 2011 09:04:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP-vqtQbB7ja for ; Tue, 25 Oct 2011 09:04:27 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C826E21F8C82 for ; Tue, 25 Oct 2011 09:04:26 -0700 (PDT) Received: by wyh22 with SMTP id 22so836923wyh.31 for ; Tue, 25 Oct 2011 09:04:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:in-reply-to :thread-index:x-mimeole; bh=o3Xz44BLrAqllQwda8abh6J5hWa/T10EMsRTIjZbu+g=; b=YlJ24R0QVilsnalfdBn1IRHX9cxttxuHh4e/xvQ/Dx89zJFeUnnLdmKwjUNeG85tD/ Gl+i7qStgSaFPMokqDccohXz2AZ1AycZUq40uezQm2mqIKWF8zEVAp1lnnDz2wQBzC33 zvGivglh+x16WNqaWn7n6J27qGXv+BNXIn7+E= Received: by 10.216.72.145 with SMTP id t17mr4978337wed.88.1319558665738; Tue, 25 Oct 2011 09:04:25 -0700 (PDT) Received: from Venus (cpc8-glfd6-2-0-cust3.6-2.cable.virginmedia.com. [86.27.228.4]) by mx.google.com with ESMTPS id fr4sm17249248wbb.0.2011.10.25.09.04.23 (version=SSLv3 cipher=OTHER); Tue, 25 Oct 2011 09:04:24 -0700 (PDT) From: "Len Holgate" To: "'John Tamplin'" References:

In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Oct 2011 22:27:39 -0000 On 10/21/11 4:51 PM, John Tamplin wrote: > On Fri, Oct 21, 2011 at 6:33 PM, Iñaki Baz Castillo > wrote: > > 2011/10/22 Iñaki Baz Castillo >: > > I strongly propose to rename it to "mux". > > I mean right now, without waiting for it to be an approved RFC. > > > Until there is feedback that others besides Google are interested in > implementing it, it seems presumptuous to take the name "mux". There is nothing presumptuous about it, IMHO. > I am aware of the article you reference, but since non-private use names > have to be registered before use, it isn't clear the alternative is any > better. Says who? > WS has already shown that you can have early deployments of a > work in progress, make breaking changes, and have implementations adapt > to the new version fairly quickly. In the case of this community, that's true. > So, I would much rather have some > implementations use x-google-mux first and have to change them later > after it is standardized, than to use the name "mux" now and then find > out we really want a different mux protocol for that name. There are > only a few browsers, so if they all update the servers will have no > choice but to update to match. http://tools.ietf.org/html/draft-ietf-appsawg-xdash has suggestions about naming things without the "x-" prefix. Please have a look, because it's been changed since it became a WG draft. Peter -- Peter Saint-Andre https://stpeter.im/ From jat@google.com Wed Oct 26 16:20:01 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A162121F8573 for ; Wed, 26 Oct 2011 16:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpQE+uUIqrXV for ; Wed, 26 Oct 2011 16:20:01 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id 08F9621F8558 for ; Wed, 26 Oct 2011 16:20:00 -0700 (PDT) Received: from wpaz24.hot.corp.google.com (wpaz24.hot.corp.google.com [172.24.198.88]) by smtp-out.google.com with ESMTP id p9QNJtk5029719 for ; Wed, 26 Oct 2011 16:19:55 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319671195; bh=LGan46I4JxVTosYO0634FaYtYVY=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=sR+dzUmigKuAbjfGT+TY3k/q8Bh/iD2XQ3elfujIKOBFnao7elnR7p9Wijifi5jQq Qn7HXGcehdugAuTkgtIww== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=jdXo4xsG0bru1vahDnz3ic9zh90BMcUvknwl/PkQ85Nrci3pg/RcZKlZ9Q66IqDev iMi4/NCu8+wckLbTW74bA== Received: from gyf1 (gyf1.prod.google.com [10.243.50.65]) by wpaz24.hot.corp.google.com with ESMTP id p9QNGlec014672 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 16:19:54 -0700 Received: by gyf1 with SMTP id 1so3069501gyf.0 for ; Wed, 26 Oct 2011 16:19:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=HHxUN8yo5sJoHkZGxO55Bn7XX4yknEM1k0JhH0uUk4o=; b=iTbT+xsQwIrkvnyc+pktT95oEAuHcCKpiAR0mn9rBFiig5QkoG+TNEC5/UXjQqsuH3 jXEjTeU67Bud4AutBaAA== Received: by 10.150.214.1 with SMTP id m1mr20281084ybg.89.1319671194254; Wed, 26 Oct 2011 16:19:54 -0700 (PDT) Received: by 10.150.214.1 with SMTP id m1mr20281073ybg.89.1319671194094; Wed, 26 Oct 2011 16:19:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Wed, 26 Oct 2011 16:19:34 -0700 (PDT) In-Reply-To: <4EA88957.2090903@stpeter.im> References:

<4EA88957.2090903@stpeter.im> From: John Tamplin Date: Wed, 26 Oct 2011 19:19:34 -0400 Message-ID: To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd355f0be8d4904b03be4e4 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Oct 2011 23:20:01 -0000 --000e0cd355f0be8d4904b03be4e4 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 26, 2011 at 6:27 PM, Peter Saint-Andre wrote: > > Until there is feedback that others besides Google are interested in > > implementing it, it seems presumptuous to take the name "mux". > > There is nothing presumptuous about it, IMHO. Ok, I have no problem changing the name to mux. Even though there hasn't been much feedback, what little there has been seems to have been positive, so I want to go ahead and finish it up. What is the recommended way to write up the IANA considerations section, about registering a value for the WS Sec-WebSockets-Extension header? http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-11.4 establishes a registry, but I don't see details of what should be included in the MUX document. The closest I could find was http://tools.ietf.org/html/rfc4169#section-5.1 -- can you recommend how this should be written up? -- John A. Tamplin Software Engineer (GWT), Google --000e0cd355f0be8d4904b03be4e4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 26, 2011 at 6:27 PM, Peter Saint-And= re <stpeter@stpe= ter.im> wrote:

> Until there is feedback that others besides Google a= re interested in
> implementing it, it seems presumptuous to take the name "mux"= ;.

There is nothing presumptuous about it, IMHO.

Ok, I have no problem changing the name to mux.

Even though there hasn't been much feedback, what little there h= as been seems to have been positive, so I want to go ahead and finish it up= .

What is the recommended way to write up the IANA consid= erations section, about registering a value for the WS Sec-WebSockets-Exten= sion header? =C2=A0http://tools.ietf.org/html/draft-ietf-h= ybi-thewebsocketprotocol-17#section-11.4=C2=A0 establishes a registry, = but I don't see details of what should be included in the MUX document.= =C2=A0The closest I could find was=C2=A0http://tools.ietf.org/html/rfc4169#section-5.1= =C2=A0-- can you recommend how this should be written up?

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--000e0cd355f0be8d4904b03be4e4-- From stpeter@stpeter.im Wed Oct 26 16:28:13 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DA5721F8A58 for ; Wed, 26 Oct 2011 16:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWHeHreaaARH for ; Wed, 26 Oct 2011 16:28:13 -0700 (PDT) Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id F1A9521F8A4B for ; Wed, 26 Oct 2011 16:28:12 -0700 (PDT) Received: from leavealone.cisco.com (unknown [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 621AF404FF; Wed, 26 Oct 2011 17:33:29 -0600 (MDT) Message-ID: <4EA8978B.8090408@stpeter.im> Date: Wed, 26 Oct 2011 17:28:11 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: John Tamplin References:

<4EA88957.2090903@stpeter.im> In-Reply-To: X-Enigmail-Version: 1.3.2 OpenPGP: url=https://stpeter.im/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Oct 2011 23:28:13 -0000 On 10/26/11 5:19 PM, John Tamplin wrote: > On Wed, Oct 26, 2011 at 6:27 PM, Peter Saint-Andre > wrote: > > > Until there is feedback that others besides Google are interested in > > implementing it, it seems presumptuous to take the name "mux". > > There is nothing presumptuous about it, IMHO. > > > Ok, I have no problem changing the name to mux. > > Even though there hasn't been much feedback, what little there has been > seems to have been positive, so I want to go ahead and finish it up. > > What is the recommended way to write up the IANA considerations section, > about registering a value for the WS Sec-WebSockets-Extension header? > http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-17#section-11.4 > establishes a registry, but I don't see details of what should be > included in the MUX document. The closest I could find > was http://tools.ietf.org/html/rfc4169#section-5.1 -- can you recommend > how this should be written up? I think you would include an IANA Considerations section that says it is registering a value for the Sec-WebSocket-Extension header field in accordance with Section 11.4 of draft-ietf-hybi-thewebsocketprotocol, and specify the information mentioned there: Extension Identifier Extension Common Name Extension Definition Known Incompatible Extensions Feel free to post what you come up with to the list here and we'll help you with wordsmithing. In fact the registration policy is "First Come First Served" so you don't need to wait on publication of your RFC to complete the registration, but given that you're working on an Internet-Draft there's no harm in including the IANA registration in that document. Peter -- Peter Saint-Andre https://stpeter.im/ From theturtle32@gmail.com Wed Oct 26 16:57:10 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEEA321F854E for ; Wed, 26 Oct 2011 16:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDBp0Go2sctF for ; Wed, 26 Oct 2011 16:57:10 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2348721F854D for ; Wed, 26 Oct 2011 16:57:09 -0700 (PDT) Received: by wyh22 with SMTP id 22so2621552wyh.31 for ; Wed, 26 Oct 2011 16:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0CfMxrHzjVYT4ErfmKG3rGltbjzc80W/L7+KtCr0aHE=; b=h++l64gPwgT8ZrPXU/Ox6hW4BGJU9AqiiOmx+1hPNP1UKrCc93R2ic3eIikgglrApm +DRkPORKhYwXyWZfUuevibrm+arKkKpApozlb/6Pvl+zsgtOdDPbCAWx+cOimT3ZpKYG ldMtvG62dSO8ZqK0k05LTOfe7S9w85/3IUUeY= MIME-Version: 1.0 Received: by 10.227.59.204 with SMTP id m12mr14180355wbh.14.1319673429204; Wed, 26 Oct 2011 16:57:09 -0700 (PDT) Received: by 10.180.102.193 with HTTP; Wed, 26 Oct 2011 16:57:08 -0700 (PDT) In-Reply-To: References:

<4EA88957.2090903@stpeter.im> Date: Wed, 26 Oct 2011 16:57:08 -0700 Message-ID: From: Brian To: John Tamplin Content-Type: multipart/alternative; boundary=0015174be496f79f4a04b03c694d Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Oct 2011 23:57:10 -0000 --0015174be496f79f4a04b03c694d Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 26, 2011 at 4:19 PM, John Tamplin wrote: > On Wed, Oct 26, 2011 at 6:27 PM, Peter Saint-Andre wrote: > >> Even though there hasn't been much feedback, what little there has been >> seems to have been positive, so I want to go ahead and finish it up. >> > > Awesome! I look forward to following its progress. I might have an opportunity to take a stab at an implementation some time in the coming weeks. Do you have a prototype implementation against which I could test? Cheers, Brian --0015174be496f79f4a04b03c694d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 26, 2011 at 4:19 PM, John Tamplin <jat@google.com>= ; wrote:

On Wed, Oct 26, 2011 at 6:27 P= M, Peter Saint-Andre <stpeter@stpeter.im> wrote:

Even though there hasn't been much feedback, what little there has= been seems to have been positive, so I want to go ahead and finish it up.<= /div>

Awesome! =A0I look fo= rward to following its progress. =A0I might have an opportunity to take a s= tab at an implementation some time in the coming weeks. =A0Do you have a pr= ototype implementation against which I could test?

Cheers,

Brian=A0

--0015174be496f79f4a04b03c694d-- From jat@google.com Wed Oct 26 18:17:58 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4896321F8AF6 for ; Wed, 26 Oct 2011 18:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lt9-c+LhaCSt for ; Wed, 26 Oct 2011 18:17:57 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id B6EAC21F8AF4 for ; Wed, 26 Oct 2011 18:17:57 -0700 (PDT) Received: from hpaq12.eem.corp.google.com (hpaq12.eem.corp.google.com [172.25.149.12]) by smtp-out.google.com with ESMTP id p9R1HsrE019638 for ; Wed, 26 Oct 2011 18:17:54 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319678275; bh=TUu1oVs85WpuUYSBKTdwLsTJ9do=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=ek42BmWbyK8F2HSc7BhblxjSaRkkiwE2kWeKt5eA7hASD6noZBBlw2Oz32O+gPOck zru8Lraei30wBBSVYgpZw== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:cc:content-type:x-system-of-record; b=igeVoayX6DxBexpqXsCdUGc/4VeOSk48tmVNwPSmT2l7MdYHbEHC0MajJNb+JTeXf bFK/Mpnjf/z5vpP4caVww== Received: from vcbfk14 (vcbfk14.prod.google.com [10.220.204.14]) by hpaq12.eem.corp.google.com with ESMTP id p9R1HkxJ028176 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 18:17:53 -0700 Received: by vcbfk14 with SMTP id fk14so3421293vcb.6 for ; Wed, 26 Oct 2011 18:17:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=1BUaOozRHpDsrMwffokzoWh1zjt2QJKmZDp33Ym7gnw=; b=Zo61mDSfmrPhrYyk3YIAmycB/ZQ5WJpxj5P2X1Ws5mg4rfA3zdXunCaHOoUdjMrXDy /HC96kMMA9ohWa4m+wlQ== Received: by 10.150.214.14 with SMTP id m14mr31242951ybg.74.1319678273227; Wed, 26 Oct 2011 18:17:53 -0700 (PDT) Received: by 10.150.214.14 with SMTP id m14mr31242939ybg.74.1319678273084; Wed, 26 Oct 2011 18:17:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.150.96.7 with HTTP; Wed, 26 Oct 2011 18:17:33 -0700 (PDT) In-Reply-To: References:

<4EA88957.2090903@stpeter.im>

From: John Tamplin Date: Wed, 26 Oct 2011 21:17:33 -0400 Message-ID: To: Brian Content-Type: multipart/alternative; boundary=000e0cd352a8af5db004b03d8a44 X-System-Of-Record: true Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 27 Oct 2011 01:17:58 -0000 --000e0cd352a8af5db004b03d8a44 Content-Type: text/plain; charset=UTF-8 On Wed, Oct 26, 2011 at 7:57 PM, Brian wrote: > Awesome! I look forward to following its progress. I might have an > opportunity to take a stab at an implementation some time in the coming > weeks. Do you have a prototype implementation against which I could test? > Not currently -- Andy and Greg both had implementations of the earlier version, so presumably it wouldn't be too hard to adapt those implementations. -- John A. Tamplin Software Engineer (GWT), Google --000e0cd352a8af5db004b03d8a44 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 26, 2011 at 7:57 PM, Brian <theturtle32@gmail.com= > wrote:

Awesome! =C2=A0I look forward = to following its progress. =C2=A0I might have an opportunity to take a stab= at an implementation some time in the coming weeks. =C2=A0Do you have a pr= ototype implementation against which I could test?

Not currently -- Andy and Greg both = had implementations of the earlier version, so presumably it wouldn't b= e too hard to adapt those implementations.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Google
--000e0cd352a8af5db004b03d8a44-- From jat@google.com Wed Oct 26 21:16:48 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6EE21F858D for ; Wed, 26 Oct 2011 21:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.976 X-Spam-Level: X-Spam-Status: No, score=-105.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mFM-Sye3PyZt for ; Wed, 26 Oct 2011 21:16:48 -0700 (PDT) Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id F31DF21F8487 for ; Wed, 26 Oct 2011 21:16:47 -0700 (PDT) Received: from wpaz9.hot.corp.google.com (wpaz9.hot.corp.google.com [172.24.198.73]) by smtp-out.google.com with ESMTP id p9R4Ghad020516 for ; Wed, 26 Oct 2011 21:16:43 -0700 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1319689003; bh=iI6Ssycta7O945gwO/i1YcHUEVA=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Content-Type; b=I9KKW54AwouXBxkeVZ/3c91JMg/FC5O9nyokbEfQ8dicFnDIyRRqmesvn5TbjlrCI GE+U5lZ19txaLeqkxiNYg== DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:from:date: message-id:subject:to:content-type:x-system-of-record; b=SAvxQ3Bmsl+e2p2TLe4CGY8aLFP7kNd28egxtlfipgCp5m6FH4BGTNZiIKdh22+Y7 LZ7HUnAQRoYR7kU784NkQ== Received: from gyd8 (gyd8.prod.google.com [10.243.49.200]) by wpaz9.hot.corp.google.com with ESMTP id p9R4Ggsx026873 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Wed, 26 Oct 2011 21:16:42 -0700 Received: by gyd8 with SMTP id 8so3412180gyd.10 for ; Wed, 26 Oct 2011 21:16:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:x-system-of-record; bh=V/LgAFQnZRLNSRwKmgx/9Ku0Fij75YncuOJVyD1PtzE=; b=xZ5qCP79nU4l4J5iLuGM029qMCn+3chbj0s0gmg1rF6YdW2XQyFqNZcOlczl81Pxb3 cmcryevVFKVFEcet7UrA== Received: by 10.229.64.222 with SMTP id f30mr7130550qci.227.1319689002404; Wed, 26 Oct 2011 21:16:42 -0700 (PDT) Received: by 10.229.64.222 with SMTP id f30mr7130532qci.227.1319689000764; Wed, 26 Oct 2011 21:16:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.134.1 with HTTP; Wed, 26 Oct 2011 21:16:20 -0700 (PDT) In-Reply-To: References:

<4EA88957.2090903@stpeter.im>

From: John Tamplin Date: Wed, 26 Oct 2011 21:16:20 -0700 Message-ID: To: Hybi Content-Type: multipart/alternative; boundary=0016e64f81da1ac70a04b0400a8e X-System-Of-Record: true Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 27 Oct 2011 04:16:48 -0000 --0016e64f81da1ac70a04b0400a8e Content-Type: text/plain; charset=UTF-8 Updated version, mostly cleaning up I-D nits and adding an IANA section to register the extension name. http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-01 -- John A. Tamplin Software Engineer (GWT), Google --0016e64f81da1ac70a04b0400a8e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Updated version, mostly cleaning up I-D nits and adding an IANA sectio= n to register the extension name.

http://tools.ietf.org/ht= ml/draft-tamplin-hybi-google-mux-01

--
John A. Tamplin
Software Enginee= r (GWT), Google
--0016e64f81da1ac70a04b0400a8e-- From len.holgate@gmail.com Wed Oct 26 22:39:35 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A02021F8ADE for ; Wed, 26 Oct 2011 22:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zvLXy7y1lTs for ; Wed, 26 Oct 2011 22:39:35 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id C958621F8AD9 for ; Wed, 26 Oct 2011 22:39:34 -0700 (PDT) Received: by wyh22 with SMTP id 22so2835393wyh.31 for ; Wed, 26 Oct 2011 22:39:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:references:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :in-reply-to:x-mimeole; bh=XcherdDJQW5BcIYNEsMBPsR5edK6R3X9iD+noD4B4SU=; b=BGx4ULgtsOgSyQOOM+kXaTPgKueq0BptJoxhuDzdUkk9PnRoVfZPk5ZluutawrNq0a xwSn9MjEuMbARDxKpOdWmzWoxEZQqL4jNIxdNuxmrH4nZIcO7+YuSRljVVebUult6lpU JEI64rfyBQXkseXk1IqxOXk+1jqZ6hRu8sc48= Received: by 10.227.205.213 with SMTP id fr21mr14072866wbb.16.1319693973907; Wed, 26 Oct 2011 22:39:33 -0700 (PDT) Received: from Venus (cpc8-glfd6-2-0-cust3.6-2.cable.virginmedia.com. [86.27.228.4]) by mx.google.com with ESMTPS id fw16sm7113647wbb.13.2011.10.26.22.39.31 (version=SSLv3 cipher=OTHER); Wed, 26 Oct 2011 22:39:32 -0700 (PDT) From: "Len Holgate" To: "'Brian'" , "'John Tamplin'" References:

<4EA88957.2090903@stpeter.im>

Date: Thu, 27 Oct 2011 06:39:25 +0100 Message-ID: <005601cc946a$ca86d520$0a00a8c0@Venus> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcyUOvxe3PnovhNyS26R6/tmGjJh7AAL7cSw In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 Cc: 'Hybi' Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 27 Oct 2011 05:39:35 -0000 John, Brian, I was just going to ask the same thing, something that I haven't written to test against would be very useful. Len > -----Original Message----- > From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On > Behalf Of Brian > Sent: 27 October 2011 00:57 > To: John Tamplin > Cc: Hybi > Subject: Re: [hybi] first draft of WS mux extension > > On Wed, Oct 26, 2011 at 4:19 PM, John Tamplin wrote: > > > On Wed, Oct 26, 2011 at 6:27 PM, Peter Saint-Andre > wrote: > > > Even though there hasn't been much feedback, > what little there has been seems to have been positive, so I > want to go ahead and finish it up. > > > > Awesome! I look forward to following its progress. I might > have an opportunity to take a stab at an implementation some > time in the coming weeks. Do you have a prototype > implementation against which I could test? > > Cheers, > Brian > > From gregw@intalio.com Thu Oct 27 17:26:59 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E1811E8099 for ; Thu, 27 Oct 2011 17:26:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mM83OmMKv4Il for ; Thu, 27 Oct 2011 17:26:58 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 58AF011E808F for ; Thu, 27 Oct 2011 17:26:58 -0700 (PDT) Received: by vws5 with SMTP id 5so3594444vws.31 for ; Thu, 27 Oct 2011 17:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.69 with SMTP id q5mr67351vdh.110.1319761617612; Thu, 27 Oct 2011 17:26:57 -0700 (PDT) Received: by 10.52.180.161 with HTTP; Thu, 27 Oct 2011 17:26:57 -0700 (PDT) In-Reply-To: References:

Date: Fri, 28 Oct 2011 11:26:57 +1100 Message-ID: From: Greg Wilkins To: John Tamplin , Hybi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 28 Oct 2011 00:26:59 -0000 On 22 October 2011 09:51, John Tamplin wrote: > On Fri, Oct 21, 2011 at 6:33 PM, I=F1aki Baz Castillo wro= te: >> >> 2011/10/22 I=F1aki Baz Castillo : >> > I strongly propose to rename it to "mux". >> >> I mean right now, without waiting for it to be an approved RFC. > > Until there is feedback that others besides Google are interested in > implementing it, it seems presumptuous to take the name "mux". If you could somehow convince gmail that all postings from jat@google.com to hybi are not spam, then that would greatly assist in giving you feedback! Do any other readers using gmail have this problem with Johns postings? We in the Jetty project are keen to implement it. We'll be even keener once we know there will be a browser implementation available. perhaps the name x-mux might be a compromise while it is in draft status. cheers From gregw@intalio.com Thu Oct 27 17:29:19 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0643111E80A2 for ; Thu, 27 Oct 2011 17:29:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nPjG0358cr+q for ; Thu, 27 Oct 2011 17:29:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0A311E8099 for ; Thu, 27 Oct 2011 17:29:18 -0700 (PDT) Received: by vws5 with SMTP id 5so3595390vws.31 for ; Thu, 27 Oct 2011 17:29:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.98.227 with SMTP id el3mr101398vdb.8.1319761757892; Thu, 27 Oct 2011 17:29:17 -0700 (PDT) Received: by 10.52.180.161 with HTTP; Thu, 27 Oct 2011 17:29:17 -0700 (PDT) In-Reply-To: References:

<4EA88957.2090903@stpeter.im> Date: Fri, 28 Oct 2011 11:29:17 +1100 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 28 Oct 2011 00:29:19 -0000 On 27 October 2011 10:19, John Tamplin wrote: > Ok, I have no problem changing the name to mux. Ah - another spam'ed post from John. As you are happy with mux, ignore my previous x-mux suggestion. cheers From theturtle32@gmail.com Thu Oct 27 17:31:05 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F79D21F853A for ; Thu, 27 Oct 2011 17:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGNX4z1Bc8zy for ; Thu, 27 Oct 2011 17:31:04 -0700 (PDT) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id C74F521F852E for ; Thu, 27 Oct 2011 17:31:04 -0700 (PDT) Received: by pzk34 with SMTP id 34so8621276pzk.9 for ; Thu, 27 Oct 2011 17:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=IgsEdpAy/lpChPnkpmTIA6lcjonikgjX0DEwndoySAo=; b=m4I1LeqaxGZ0uaomCyFtrN1YvAEc2uhRYeol+pOosKzauLUpczGE02lrXI9yfdN+cq VZiaW6ynJnhAlKhnCT2mL6sDmk5w2AeI7pJmvp2hhNpdtt+vE/a1ea45xN0QSMximsIv HcWTD+SoWzhbXxf+h82TcUUWPMpD8WYoIZXjI= Received: by 10.68.73.232 with SMTP id o8mr1214791pbv.82.1319761864541; Thu, 27 Oct 2011 17:31:04 -0700 (PDT) Received: from [192.168.1.78] (cpe-98-148-224-102.socal.res.rr.com. [98.148.224.102]) by mx.google.com with ESMTPS id d8sm18878316pbb.6.2011.10.27.17.31.02 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 27 Oct 2011 17:31:03 -0700 (PDT) References:

In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9A334) From: Brian McKelvey Date: Thu, 27 Oct 2011 17:30:59 -0700 To: Greg Wilkins Cc: Hybi Subject: Re: [hybi] first draft of WS mux extension X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 28 Oct 2011 00:31:05 -0000 I use gmail and johns postings never end up in my spam box to my knowledge. Sent from my iPhone On Oct 27, 2011, at 5:26 PM, Greg Wilkins wrote: > On 22 October 2011 09:51, John Tamplin wrote: >> On Fri, Oct 21, 2011 at 6:33 PM, I=C3=B1aki Baz Castillo w= rote: >>>=20 >>> 2011/10/22 I=C3=B1aki Baz Castillo : >>>> I strongly propose to rename it to "mux". >>>=20 >>> I mean right now, without waiting for it to be an approved RFC. >>=20 >> Until there is feedback that others besides Google are interested in >> implementing it, it seems presumptuous to take the name "mux". >=20 > If you could somehow convince gmail that all postings from > jat@google.com to hybi are not spam, then that would greatly assist in > giving you feedback! > Do any other readers using gmail have this problem with Johns postings? >=20 > We in the Jetty project are keen to implement it. We'll be even > keener once we know there will be a browser implementation available. >=20 > perhaps the name x-mux might be a compromise while it is in draft status= . >=20 > cheers > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi From tobias.oberstein@tavendo.de Sat Oct 29 05:27:43 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B6D21F8753 for ; Sat, 29 Oct 2011 05:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Z7Et76TUmaC for ; Sat, 29 Oct 2011 05:27:43 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2A821F86D0 for ; Sat, 29 Oct 2011 05:27:42 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Sat, 29 Oct 2011 05:27:42 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Sat, 29 Oct 2011 05:27:41 -0700 Thread-Topic: opening headers: multiplicity / port in host Thread-Index: AcyWNajsoM/4C50qRjabcC/IvLSoRg== Message-ID: <634914A010D0B943A035D226786325D42D0B0D8372@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] opening headers: multiplicity / port in host X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 29 Oct 2011 12:27:43 -0000 Polishing up our WS handshake code, I have 3 short questions regarding head= ers: 1) The spec is explicit about the allowed header multiplicity in opening hands= hake requests and responses for the headers: sec-websocket-key sec-websocket-accept sec-websocket-protocol sec-websocket-extensions sec-websocket-version I couldn't find text mentioning multiplicity wrt: origin (was: sec-websocket-origin) host connection upgrade Is the following right? Host header MUST appear exactly once in request (by HTTP spec). Origin header MUST NOT appear more than once in request (exactly once for b= rowser clients). Upgrade/Connection: may contain multiple (comma separated) values, may appe= ar more than once (by HTTP spec). 2) Upgrade header multiplicity =20 Hybi-17: """ 5. The request MUST contain an "Upgrade" header field whose value is equal to "websocket". 6. The request MUST contain a "Connection" header field whose value MUST include the "Upgrade" token. """ The HTTP spec seems to allow multiple values (and presumably also multiple = headers) Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 So is it allowed for a WS client to send i.e. Upgrade: WebSocket, RTA/x11 and the server accepts WS only, sending back Upgrade: WebSocket ? Note that the "Connection" header description in the spec has "extra langua= ge" "MUST include the ... token", which seems to allow multiple values in a sin= gle Connection header as well as multiple Connection headers. Should the Upgrade header be treated the same? 3) Host header port? Hybi-17: """ 4. The request MUST contain a "Host" header field whose value is equal to /host/. """ It does not say "equal to /host/[:/port/]". However, i.e. both Firefox and Chrome will send i.e. Host: 127.0.0.1:9001 Are both forms allowed? Host: /host/ Host: /host/:/port/ And if the client uses the 2nd, validate that /port/ is the one the server = is listening on? From julian.reschke@gmx.de Sat Oct 29 05:55:18 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5614821F87C5 for ; Sat, 29 Oct 2011 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.268 X-Spam-Level: X-Spam-Status: No, score=-104.268 tagged_above=-999 required=5 tests=[AWL=-1.669, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb8gMNYhMH3k for ; Sat, 29 Oct 2011 05:55:17 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 5080321F8797 for ; Sat, 29 Oct 2011 05:55:10 -0700 (PDT) Received: (qmail invoked by alias); 29 Oct 2011 12:55:08 -0000 Received: from p5DCCBD17.dip.t-dialin.net (EHLO [192.168.178.36]) [93.204.189.23] by mail.gmx.net (mp060) with SMTP; 29 Oct 2011 14:55:08 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX19463h7e5R4f1c7rQvdaFDqEMr2eKoqqFMSv6z9yq FQGH10ONir0tLD Message-ID: <4EABF7A7.6050900@gmx.de> Date: Sat, 29 Oct 2011 14:55:03 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Tobias Oberstein References: <634914A010D0B943A035D226786325D42D0B0D8372@EXVMBX020-12.exch020.serverdata.net> In-Reply-To: <634914A010D0B943A035D226786325D42D0B0D8372@EXVMBX020-12.exch020.serverdata.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] opening headers: multiplicity / port in host X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 29 Oct 2011 12:55:18 -0000 On 2011-10-29 14:27, Tobias Oberstein wrote: > Polishing up our WS handshake code, I have 3 short questions regarding headers: > > 1) > The spec is explicit about the allowed header multiplicity in opening handshake requests and responses for the headers: > > sec-websocket-key > sec-websocket-accept > sec-websocket-protocol > sec-websocket-extensions > sec-websocket-version > > I couldn't find text mentioning multiplicity wrt: > > origin (was: sec-websocket-origin) > host > connection > upgrade > > Is the following right? > > Host header MUST appear exactly once in request (by HTTP spec). Yes. (well, unless it's HTTP/1.0) > Origin header MUST NOT appear more than once in request (exactly once for browser clients). > > Upgrade/Connection: may contain multiple (comma separated) values, may appear more than once (by HTTP spec). Yes. > 2) Upgrade header multiplicity > > Hybi-17: > """ > 5. The request MUST contain an "Upgrade" header field whose value > is equal to "websocket". > > 6. The request MUST contain a "Connection" header field whose value > MUST include the "Upgrade" token. > """ > > The HTTP spec seems to allow multiple values (and presumably also multiple headers) > > Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 > > So is it allowed for a WS client to send i.e. > > Upgrade: WebSocket, RTA/x11 > > and the server accepts WS only, sending back > > Upgrade: WebSocket > > ? Yes. > Note that the "Connection" header description in the spec has "extra language" > "MUST include the ... token", which seems to allow multiple values in a single > Connection header as well as multiple Connection headers. > > Should the Upgrade header be treated the same? Yes, and this should be fixed during AUTH48. > > 3) Host header port? > > Hybi-17: > """ > 4. The request MUST contain a "Host" header field whose value is > equal to /host/. > """ > > It does not say "equal to /host/[:/port/]". > > However, i.e. both Firefox and Chrome will send i.e. > > Host: 127.0.0.1:9001 > > Are both forms allowed? No, the port is required unless it's the default. > Host: /host/ > Host: /host/:/port/ > > And if the client uses the 2nd, validate that /port/ is the one the server is listening on? Yes. That's another thing that should be fixed AUTH48. Also, it's what we deserve for trying to rephrase normative requirements from HTTP, instead of just referring to them. Best regards, Julian From jmason@rim.com Mon Oct 31 06:30:42 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 844F521F8C8B for ; Mon, 31 Oct 2011 06:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTl+KEj7-1XF for ; Mon, 31 Oct 2011 06:30:42 -0700 (PDT) Received: from mhs060cnc.rim.net (mhs060cnc.rim.net [208.65.73.34]) by ietfa.amsl.com (Postfix) with ESMTP id D178221F8C7E for ; Mon, 31 Oct 2011 06:30:41 -0700 (PDT) X-AuditID: 0a41282f-b7b05ae00000799c-7f-4eaea300b8b8 Received: from XHT102CNC.rim.net (xht102cnc.rim.net [10.65.12.215]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mhs060cnc.rim.net (SBG) with SMTP id B8.E2.31132.003AEAE4; Mon, 31 Oct 2011 13:30:41 +0000 (GMT) Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT102CNC.rim.net ([fe80::24bd:c715:2b6b:8f7d%11]) with mapi; Mon, 31 Oct 2011 09:30:40 -0400 From: Joe Mason To: Julian Reschke , Tobias Oberstein Date: Mon, 31 Oct 2011 09:30:48 -0400 Thread-Topic: [hybi] opening headers: multiplicity / port in host Thread-Index: AcyWOgXe2SX8QZt/TbKCu/fHUCpMmABlqWvw Message-ID: References: <634914A010D0B943A035D226786325D42D0B0D8372@EXVMBX020-12.exch020.serverdata.net> <4EABF7A7.6050900@gmx.de> In-Reply-To: <4EABF7A7.6050900@gmx.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrAKsWRmVeSWpSXmKPExsXC5chzXZdx8To/gymTmS3ev9zGZLH54RtW i3mLelgcmD0+fIzzWLLkJ5PHlakTWAKYoxoYbRLz8vJLEktSFVJSi5NtlXxS0xNzFAKKMssS kysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5y fkpmXrqtkmewv66FhamlrqGSnS4SSPjHnTG7N77gMnfF/94rzA2MTzm6GDk5JARMJN6/2sUM YYtJXLi3nq2LkYtDSKCXSeL93ImMIAkhgcWMEi8awYrYBBQkPh9+wARiiwjESDz41AMWZxZQ lrh6bAVLFyMHB4uAqsT5ixUgYWEBB4kZq/YxQpQ7SpzdcoAFwjaSmHdwISuIzSvgIbH7N8he kFUVEn3bZ7GD2JwCahI3Xs0A62UEuu37qTVMEKvEJW49mc8EcbOAxJI956HuF5V4+fgfK0S9 qMSd9vWMEPU6Egt2f2KDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxSiY m1FsYGaQnJesV5SZq5eXWrKJEZw0NPR3MPbt1TrEKMDBqMTDa9uxzk+INbGsuDL3EKMEB7OS CO91baAQb0piZVVqUX58UWlOavEhRgtgwE1kluJOzgcmtLySeGMDAxSOkjgv76UMPyGBdGAy yk5NLUgtgmll4uCUamCcNe3l2a5NbjziG3S4tmyXMj92mMsruPDV57bp1eaXeH9crtZq33FE 4f+eYx5yhqu3SlyyPBMUOfnQ/f2CBQIMO3JuXrC/6X/T/P1Et8+s7z1+Nr+sf/ak0fjgLfvC A/WsT2WXXvKwW6R/aV/H3weLH+pIxb88r+4RzbmXX3rH2UVN17xLZFuqlViKMxINtZiLihMB ZIgxTTMDAAA= Cc: "hybi@ietf.org" Subject: Re: [hybi] opening headers: multiplicity / port in host X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 31 Oct 2011 13:30:42 -0000 > -----Original Message----- > > 2) Upgrade header multiplicity > > > > Hybi-17: > > """ > > 5. The request MUST contain an "Upgrade" header field whose > value > > is equal to "websocket". > > > > 6. The request MUST contain a "Connection" header field whose > value > > MUST include the "Upgrade" token. > > """ > > > > The HTTP spec seems to allow multiple values (and presumably also > multiple headers) > > > > Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 > > > > So is it allowed for a WS client to send i.e. > > > > Upgrade: WebSocket, RTA/x11 > > > > and the server accepts WS only, sending back > > > > Upgrade: WebSocket > > > > ? > > Yes. Are you sure? The spec seems quite clear that "Upgrade" must exactly equal= "websocket". No multiple values allowed... > > Note that the "Connection" header description in the spec has "extra > language" > > "MUST include the ... token", which seems to allow multiple values in > a single > > Connection header as well as multiple Connection headers. > > > > Should the Upgrade header be treated the same? > > Yes, and this should be fixed during AUTH48. Oh. Well, the server I wrote is wrong, then. I think this change is big enough to need a version bump. Anyone advertisin= g itself as accepting WebSockets version 13 might only be able to handle exa= ctly one upgrade value, since that's what the spec said for several versions= . Joe --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From julian.reschke@gmx.de Mon Oct 31 06:39:09 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7454521F8B4B for ; Mon, 31 Oct 2011 06:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.252 X-Spam-Level: X-Spam-Status: No, score=-104.252 tagged_above=-999 required=5 tests=[AWL=-1.653, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id On4yOQjCIBLA for ; Mon, 31 Oct 2011 06:39:08 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id DB33321F8B9E for ; Mon, 31 Oct 2011 06:39:03 -0700 (PDT) Received: (qmail invoked by alias); 31 Oct 2011 13:39:00 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp004) with SMTP; 31 Oct 2011 14:39:00 +0100 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1/FgGx1Y/jFFJ/VJw4pByM6D8XG70N466xhPBu28z 8wDRPyIs1bxUef Message-ID: <4EAEA4F3.8030906@gmx.de> Date: Mon, 31 Oct 2011 14:38:59 +0100 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Joe Mason References: <634914A010D0B943A035D226786325D42D0B0D8372@EXVMBX020-12.exch020.serverdata.net> <4EABF7A7.6050900@gmx.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: "hybi@ietf.org" Subject: Re: [hybi] opening headers: multiplicity / port in host X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 31 Oct 2011 13:39:09 -0000 On 2011-10-31 14:30, Joe Mason wrote: >> -----Original Message----- >>> 2) Upgrade header multiplicity >>> >>> Hybi-17: >>> """ >>> 5. The request MUST contain an "Upgrade" header field whose >> value >>> is equal to "websocket". >>> >>> 6. The request MUST contain a "Connection" header field whose >> value >>> MUST include the "Upgrade" token. >>> """ >>> >>> The HTTP spec seems to allow multiple values (and presumably also >> multiple headers) >>> >>> Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11 >>> >>> So is it allowed for a WS client to send i.e. >>> >>> Upgrade: WebSocket, RTA/x11 >>> >>> and the server accepts WS only, sending back >>> >>> Upgrade: WebSocket >>> >>> ? >> >> Yes. > > Are you sure? The spec seems quite clear that "Upgrade" must exactly equal "websocket". No multiple values allowed... Yes, I am sure. This is defined by HTTP, not by the Hybi spec. > ... Best regards, Julian From tobias.oberstein@tavendo.de Mon Oct 31 08:05:53 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0616121F8DD8 for ; Mon, 31 Oct 2011 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTSTBbq8kFE6 for ; Mon, 31 Oct 2011 08:05:52 -0700 (PDT) Received: from EXHUB020-4.exch020.serverdata.net (exhub020-4.exch020.serverdata.net [206.225.164.31]) by ietfa.amsl.com (Postfix) with ESMTP id 272F521F8AFE for ; Mon, 31 Oct 2011 08:05:51 -0700 (PDT) Received: from EXVMBX020-12.exch020.serverdata.net ([169.254.3.230]) by EXHUB020-4.exch020.serverdata.net ([206.225.164.31]) with mapi; Mon, 31 Oct 2011 08:05:51 -0700 From: Tobias Oberstein To: "hybi@ietf.org" Date: Mon, 31 Oct 2011 08:05:49 -0700 Thread-Topic: Testsuite update Thread-Index: AcyX3bb8E8mdvb2FSJOyYHXV8gmPWw== Message-ID: <634914A010D0B943A035D226786325D42D0B0D84F7@EXVMBX020-12.exch020.serverdata.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: de-DE, en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [hybi] Testsuite update X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 31 Oct 2011 15:05:53 -0000 New release 0.4.3 of Autobahn WebSockets including updates to test suite: + supports Hybi-17 + detailed tracking of close behavior + initial set of 30 cases for close handshake + various test suite and protocol options Special thanks to Peter Thorson for significant code contributions and fruitful discussions! Peter works on a C++/ASIO-based WebSocket client/server framework you may checkout here https://github.com/zaphoyd/websocketpp Updated reports are available under http://www.tavendo.de/autobahn/testsuite.html including mobile clients and servers. Updated Python package is here: http://pypi.python.org/pypi/autobahn Since "close behavior" is new coverage for the test suite, there will likely be questions/issues .. feel free to give feedback on http://groups.google.com/group/autobahnws Cheers, Tobias From ibc@aliax.net Mon Oct 31 08:42:41 2011 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C77921F8E12 for ; Mon, 31 Oct 2011 08:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vF7BzZ7ywnLE for ; Mon, 31 Oct 2011 08:42:40 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4113C21F8E0F for ; Mon, 31 Oct 2011 08:42:40 -0700 (PDT) Received: by vws5 with SMTP id 5so5913111vws.31 for ; Mon, 31 Oct 2011 08:42:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.70.98 with SMTP id l2mr4694444vdu.101.1320075759709; Mon, 31 Oct 2011 08:42:39 -0700 (PDT) Received: by 10.220.184.6 with HTTP; Mon, 31 Oct 2011 08:42:39 -0700 (PDT) In-Reply-To: <634914A010D0B943A035D226786325D42D0B0D84F7@EXVMBX020-12.exch020.serverdata.net> References: <634914A010D0B943A035D226786325D42D0B0D84F7@EXVMBX020-12.exch020.serverdata.net> Date: Mon, 31 Oct 2011 16:42:39 +0100 Message-ID: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= To: Tobias Oberstein