From tyoshino@google.com Wed Aug 1 10:20:46 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECA0311E81F5 for ; Wed, 1 Aug 2012 10:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.010, 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 vfKTGpEFR6rg for ; Wed, 1 Aug 2012 10:20:45 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20611E8168 for ; Wed, 1 Aug 2012 10:20:39 -0700 (PDT) Received: by ggnc4 with SMTP id c4so8164324ggn.31 for ; Wed, 01 Aug 2012 10:20:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=vJhwhgUn9nMruPrtcr9umWcdLuQPq/lpByg2KMxGplQ=; b=NSQuCA10x6I247bzJghgdTX91rxNVeQ8OFo5zL1oGSmKvXLyexXVSNW6mMexfA3y8O 0ht14pEIyFODtfgKnmX/Cj2RjNePdwp9fllCmznb6dVFxFcwszbpqBlWbjoc3eeqBZba jnz2+XriTmQ4XGUpGcB8UWimyJRbVGiT/UAN7T0Mkr//+bjkdQj9zj0E9nPmI4IrsslA quVCtCNME4YoNyXAK/83CjHCc2u0GzW7pIgr0e8Z2LoLJ8RbaVg+LJuxRdeT0eqAAGEV jg+LzGGu0PCX0OfqsOFxiRCGDiVhmf2Mx/Z76vhPbWV5T+VUUBV0TF1jDdSxogG4PR53 vArg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=vJhwhgUn9nMruPrtcr9umWcdLuQPq/lpByg2KMxGplQ=; b=GkpuNsGnncHmlHIjDRb2cZ3fsaA1LNK7ymkpJ7HkWzRXvlDrXDzXdcOc7/CmTduWYV vMy9xCfSZWGeOKIqmVV2BwvgTo0Kpz3eLRge38n4YFzQEZSrjfkqG8mWc+tfvKxgAhJG Kog4X5jAgAH4cn+oGXVHY6C0lHhsevs2LllPQjPfveeo4C6QO1N8yxwr/Nw5Tzdv6ezS ocHFvXH3t5dX9W6NpHPONpBN8wyc6LzLL8vnmE4w5BnOUafuDpQUedW0wU+Vl4w8bgPZ +8CVCPxLzOym0TBJQ8ZmHd9J56JxKC8k8Ny/M9qroVblOT+aovlfGBNUngoFO4Og7MKd CXaw== Received: by 10.50.17.169 with SMTP id p9mr6134740igd.60.1343841638302; Wed, 01 Aug 2012 10:20:38 -0700 (PDT) Received: by 10.50.17.169 with SMTP id p9mr6134727igd.60.1343841638103; Wed, 01 Aug 2012 10:20:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.7.228 with HTTP; Wed, 1 Aug 2012 10:20:17 -0700 (PDT) In-Reply-To: <5017E2E8.5090005@callenish.com> References: <5010B103.70809@callenish.com> <5017E2E8.5090005@callenish.com> From: Takeshi Yoshino Date: Thu, 2 Aug 2012 02:20:17 +0900 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=14dae93410e7793bb004c6378322 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlahcHJRXc8IzBC4j/rdwH1tggfQMn125cmU6NIMZxzgpL0aDHm+XqihelVmymrWrdzWpdGWsKCN2pfujvRK1AsImN05UNUfoDKmoNDE0ez73bT70PqQl0P+Z5+flysQjh8KgNDiv7+Owcnc3OLgMQMv9sfRNSeSN1+NrGRcNZ1b+3HVkI= Cc: hybi@ietf.org Subject: Re: [hybi] HTTP/2.0 framing and WebSocket multiplexing X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:20:46 -0000 --14dae93410e7793bb004c6378322 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 31, 2012 at 10:51 PM, Bruce Atherton wrote: > > On 7/26/2012 4:01 AM, Takeshi Yoshino wrote: > >> >> Separating the stream identifier space into two for each direction is >> necessary since each end may initiate stream asynchronously. I don't come >> up with any other attribute with a risk of collision. >> >> > Not with the two protocols currently proposed, but what of the future? > Will other protocols be carried on this common framing layer? If a peer to > peer protocol is added then the number of endpoints that could initiate the > stream is unlimited. > I see. But we don't have to use the channel ID space for addressing peers. It's fine that the client establishes a client-initiated stream with the destination peer ID, and then the server establishes a server-initiated stream to the peer and notifies the ID of the origin peer. The routing table on the server remembers the destination channel ID in addition to the destination peer. It's not so painful. > > Why can there not be a separate field to identify the endpoint that > initiated the connection? > > > I feel that reserving ID number space is over killing. >> >> > I'm not sure what you mean by "over killing". Are you agreeing that all > the bits in the ID space should serve the single purpose of defining the > ID, and not be overloaded to mean other things as well? > Yes. It looks using LSB for direction and the others for ID is sufficient for me. Protocol differentiation and source peer identification can be done by exchanging some token on AddChannelRequest rather than reserving precious bits in channel ID field. --14dae93410e7793bb004c6378322 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2012 at 10:51 PM, Bruce Atherton <bruce@callenish.com> wrote:

On 7/26/2012 4:01 AM, Takeshi Yoshino wrote:

Separating the stream identifier space into two for each direction is neces= sary since each end may initiate stream asynchronously. I don't come up= with any other attribute with a risk of collision.


Not with the two protocols currently proposed, but what of the future? Will= other protocols be carried on this common framing layer? If a peer to peer= protocol is added then the number of endpoints that could initiate the str= eam is unlimited.

I see. But we don't have to use the ch= annel ID space for addressing peers. It's fine that the client establis= hes a client-initiated stream with the destination peer ID, and then the se= rver establishes a server-initiated stream to the peer and notifies the ID = of the origin peer.

The routing table on the server remembers the destinati= on channel ID in addition to the destination peer. It's not so painful.=
=A0

Why can there not be a separate field to identify the endpoint that initiat= ed the connection?


I feel that reserving ID number space is over killing.


I'm not sure what you mean by "over killing". Are you agreein= g that all the bits in the ID space should serve the single purpose of defi= ning the ID, and not be overloaded to mean other things as well?

Yes. It looks using LSB for direction and the o= thers for ID is sufficient for me. Protocol differentiation and source peer= identification can be done by exchanging some token on AddChannelRequest r= ather than reserving precious bits in channel ID field.

--14dae93410e7793bb004c6378322-- From tyoshino@google.com Wed Aug 1 10:42:28 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4686F11E82F7 for ; Wed, 1 Aug 2012 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.966 X-Spam-Level: X-Spam-Status: No, score=-102.966 tagged_above=-999 required=5 tests=[AWL=0.010, 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 TS-MH5ArGgeu for ; Wed, 1 Aug 2012 10:42:24 -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 8FCC211E817B for ; Wed, 1 Aug 2012 10:42:24 -0700 (PDT) Received: by yhq56 with SMTP id 56so8193357yhq.31 for ; Wed, 01 Aug 2012 10:42:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=L2syCz4TfIcD6ErJWfgctZ/OYo4nl6XRm6hbS91lC6Q=; b=Og8ZPtEi8FumX+sufBGkGDvxSYjpO52r61t1duOkM4Vi1XcW56DkX+rxFL5GvZssh1 bZFWKXmpm6IUNd9aN7XtbgbdAmYvjEBaeBCA61zEmLB8ujjI7xtMfYX5wAg2ZNu1Urdj jJ/qP+AjfBtmBthl3oyRRD2aXmxzimTIcARqdRTEVdLnZvoIj7R2S4PqhGN3aoh9qBiR x9EF7I+6Q0F+e1pQ8uvjsdsFthpb3x/g4q/CzKi1AXvut9SSfTpREXgen2j7ptt3aNex JOJwrHsJgxJr0DUNI7T7oPcXKtSZXGOwWXc0EQeA9e4Emr+mBOmY2Afn049+PbBfIykW WInw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=L2syCz4TfIcD6ErJWfgctZ/OYo4nl6XRm6hbS91lC6Q=; b=NNnY+4Rcxnhv1Oj8EqCJmUIz5n/J6DI6ODbILFy8qDvUBS6mXzVid3Cgj2KWItjrgH 0+nEUeUROji+KcvaLZp0upvj/NucG2kJ8s78trk/8HIko8AHnINT+CwULaU/n4yx7hHc G9YbbodS+zC259uwNyXs7ikzpuXljKRzUYRO7ipGONiV+wRxZWu4/6oj1coWzFhZEXf+ knLBZyox7dbgk4skqC/jc8b0BHI4ctbUKRFARRIg1Klr6d5+lq/dn39ow7AwC8+VskEE 4hC8q8XN2r/+ADAzOT2ARueBXiMbDoTMxDwLucRzgeuCK4D8sn5uUBU05UHeMf3QTnLL 4dIQ== Received: by 10.50.213.1 with SMTP id no1mr5971143igc.71.1343842937905; Wed, 01 Aug 2012 10:42:17 -0700 (PDT) Received: by 10.50.213.1 with SMTP id no1mr5971135igc.71.1343842937790; Wed, 01 Aug 2012 10:42:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.7.228 with HTTP; Wed, 1 Aug 2012 10:41:57 -0700 (PDT) In-Reply-To: <5016D07C.2030508@callenish.com> References: <5016D07C.2030508@callenish.com> From: Takeshi Yoshino Date: Thu, 2 Aug 2012 02:41:57 +0900 Message-ID: To: Bruce Atherton Content-Type: multipart/alternative; boundary=14dae934071bf0df7d04c637d083 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlOUw3XHhs/Z9xFQB1eHmgQtn4lYLNlwXEJR024V1jrotBwxslIYrEKef3ycinbICGOVTgLvoHQbGHzzZHppnJ+lUD5ygEVkcSanyxkjUTmtjix2zMNCrTecKsjqxzUGvz0jplk/XHw05zuUrqocuT1xwAqs+l6Ajo3skL1AfyInghEfR8= Cc: hybi@ietf.org Subject: Re: [hybi] Revising handshake and AddChannelRequest considering HTTP/2.0 X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Aug 2012 17:42:28 -0000 --14dae934071bf0df7d04c637d083 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Jul 31, 2012 at 3:20 AM, Bruce Atherton wrote: > > These headers (except for ext-for-logical-ch) are meaningful only when > performing HTTP Upgrade and establishing physical connection. > > > I agree for most of these, but I am uncertain about the Sec-WebSocket-Key. > The point of that (and the Sec-WebSocket-Accept) is to guarantee that both > ends are actually WS endpoints. Are there not usecases where a datacenter > frontend might split a muxed connection and send the channels to different > servers? If so, I think we need to validate all the endpoints of channels > by sending a nonce and receiving the correct hash back. > Yes. When un-bundling the muxed connection into WebSocket, the frontend needs to re-add the header and validate the response. It might be a little load reduction for such intermediaries if we keep Sec-WebSocket-Key/Accept generated/validated by endpoints and exchanged over mux. But that's all, I think. > ( > It looks like moving these headers to mux's extension parameter make > sense. But please note that we can't do it because of the requirement > that WebSocket server w/o mux support should be able to accept the > connection by just rejecting mux extension. Like this: > > HTTP/1.1 101 Switching Protocols > ... > Sec-WebSocket-Extensions: ext-for-logical-ch > ... > ) > > > Do you mean adding any number of headers as parameters to the mux > extension declaration in the Sec-Websocket-Extensions header? A list of > headers inside a single header seems needlessly complicated to me, even > without the need for a fallback for non-muxing servers. > Yes. > > > Response headers are also broken down into two groups. The following > headers should be excluded from delta encoding base. > > Upgrade: websocket > Connection: Upgrade > Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= > > (It's off topic but needs discussion whether we should send reply to > implicitly opened channel by physical channel handshake response or we > should send a separate AddChannelResponse for that. The latter allows > opening mux connection even when the request for implicitly opened channel > is bad e.g. 404) > > > IMHO the 404 should result in the connection being handled the same way it > would for an HTTP XHR request. Ditto for 300 statuses where the resource > might have moved to another server that requires a different connection to > be established. > > What if, in a particular session, there was only going to be that one > channel request that had failed? A useless connection would be hanging > around for no reason. If there is a second channel request that would be > successful, then that can be the implicitly opened channel that establishes > the mux connection. > Good point. > If we think of the framing layer as separate from both Websockets and HTTP > 2.0, we can look at the headers and consider which they belong to. > > I think the Upgrade header belongs to the framing layer. Maybe it should > be "Upgrade: frames" with another header "Sec-Framing-Protocols: http2, > websocket" to establish the protocols that should be carried. Who knows, > perhaps eventually there will be others such as a peer-to-peer protocol > between browsers. > > Yes. We can reuse WebSocket headers but we don't have to. The headers you suggested may reflect the concept more clearly. > A server response could indicate which protocols it actually supported. > This would not be backward compatible with the WS 1.0 handshake, but > servers could support both methods fairly easily. > Yes. --14dae934071bf0df7d04c637d083 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Tue, Jul 31, 2012 at 3:20 AM, Bruce Atherton <bruce@callenish.com= > wrote:
=20 =20 =20

These headers (except for ext-f= or-logical-ch) are meaningful only when performing HTTP Upgrade and establishing physical connection.

I agree for most of these, but I am uncertain about the Sec-WebSocket-Key. The point of that (and the Sec-WebSocket-Accept) is to guarantee that both ends are actually WS endpoints. Are there not usecases where a datacenter frontend might split a muxed connection and send the channels to different servers? If so, I think we need to validate all the endpoints of channels by sending a nonce and receiving the correct hash back.
<= br>
Yes. When un-bundling the muxed connection into WebSocket, th= e frontend needs to re-add the header and validate the response. It might b= e a little load reduction for such intermediaries if we keep Sec-WebSocket-= Key/Accept generated/validated by endpoints and exchanged over mux. But tha= t's all, I think.
=A0
(
It looks like moving these headers to mux's extension parameter make sense. But please note that we can't do it because of the requirement that=A0WebSocket server w/o mux support should be able to accept the connection=A0by just rejecting mux extension. Like this:

=A0 HTTP/1.1 101 Switching Protocols
=A0 ...
=A0 Sec-WebSocket-Extensions: ext-for-logical-ch
=A0 ...
)

Do you mean adding any number of headers as parameters to the mux extension declaration in the Sec-Websocket-Extensions header? A list of headers inside a single header seems needlessly complicated to me, even without the need for a fallback for non-muxing servers.
<= /blockquote>

Yes.
=A0


Response headers are also broken down into two groups. The following headers should be excluded from delta encoding base.

=A0 Upgrade: websocket
=A0 Connection: Upgrade
=A0 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=3D

(It's=A0off topic but needs discussion whether we should sen= d reply to implicitly opened channel by physical channel handshake response or we should send a separate AddChannelResponse for that. The latter allows opening mux connection even when the request for implicitly opened channel is bad e.g. 404)

IMHO the 404 should result in the connection being handled the same way it would for an HTTP XHR request. Ditto for 300 statuses where the resource might have moved to another server that requires a different connection to be established.

What if, in a particular session, there was only going to be that one channel request that had failed? A useless connection would be hanging around for no reason. If there is a second channel request that would be successful, then that can be the implicitly opened channel that establishes the mux connection.
Good point.
=A0
<= div bgcolor=3D"#FFFFFF" text=3D"#000000"> If we think of the framing layer as separate from both Websockets and HTTP 2.0, we can look at the headers and consider which they belong to.

I think the Upgrade header belongs to the framing layer. Maybe it should be "Upgrade: frames" with another header "Sec-Framing-Protocols: http2, websocket" to establish the pr= otocols that should be carried. Who knows, perhaps eventually there will be others such as a peer-to-peer protocol between browsers.


Yes. We can reuse WebSocket = headers but we don't have to. The headers you suggested may reflect the= concept more clearly.
=A0
A server response could indicate which protocols it actually supported. This would not be backward compatible with the WS 1.0 handshake, but servers could support both methods fairly easily.

Yes.=A0
--14dae934071bf0df7d04c637d083-- From hapner.mark@huawei.com Sat Aug 4 14:46:39 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 847FD21F87F1 for ; Sat, 4 Aug 2012 14:46:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[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 ip4QR6a-Vw5e for ; Sat, 4 Aug 2012 14:46:39 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id D3BBD21F8658 for ; Sat, 4 Aug 2012 14:46:38 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIN19010; Sat, 04 Aug 2012 13:46:38 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sat, 4 Aug 2012 14:46:28 -0700 Received: from DFWEML506-MBX.china.huawei.com ([10.124.31.111]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.003; Sat, 4 Aug 2012 14:46:33 -0700 From: Hapner mark To: "hybi@ietf.org" Thread-Topic: [hybi] draft-hapner-hybi-messagebroker-subprotocol-02 Thread-Index: AQHNcoqc6CA4nJvN10eruFt1O55hQw== Date: Sat, 4 Aug 2012 21:46:32 +0000 Message-ID: <92457F4F764A5C4785FCDBDDDD76477A4532FF01@dfweml506-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.145.85] Content-Type: multipart/alternative; boundary="_000_92457F4F764A5C4785FCDBDDDD76477A4532FF01dfweml506mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "csuconic@redhat.com" Subject: [hybi] draft-hapner-hybi-messagebroker-subprotocol-02 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 04 Aug 2012 21:46:39 -0000 --_000_92457F4F764A5C4785FCDBDDDD76477A4532FF01dfweml506mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I've submitted an updated version of the MBWS WebSocket Subprotocol that re= duces the control messages for reconnect from 6 to 2. -- Mark A new version of I-D, draft-hapner-hybi-messagebroker-subprotocol-02.txt has been successfully submitted by Mark Hapner and posted to the IETF repository. Filename: draft-hapner-hybi-messagebroker-subprotocol Revision: 02 Title: The MessageBroker WebSocket Subprotocol Creation date: 2012-08-06 WG ID: Individual Submission Number of pages: 13 URL: http://www.ietf.org/internet-drafts/draft-hapner-hybi-mess= agebroker-subprotocol-02.txt Status: http://datatracker.ietf.org/doc/draft-hapner-hybi-messageb= roker-subprotocol Htmlized: http://tools.ietf.org/html/draft-hapner-hybi-messagebroker= -subprotocol-02 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-hapner-hybi-messa= gebroker-subprotocol-02 --_000_92457F4F764A5C4785FCDBDDDD76477A4532FF01dfweml506mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I've submitted an updated version of the MBWS WebSocket Subprotocol that= reduces the control messages for reconnect from 6 to 2.

 

-- Mark

 

A new version of I-D, draft-hapner-hybi-= messagebroker-subprotocol-02.txt
has been successfully submitted by Mark Hapner and posted to the
IETF repository.

Filename:        draft-hapner-hybi-messa= gebroker-subprotocol
Revision:        02
Title:           The Mess= ageBroker WebSocket Subprotocol
Creation date:   2012-08-06
WG ID:           Individu= al Submission
Number of pages: 13
URL:            = ; http://www.ietf.org/internet-drafts/draft-hapner-hybi-messagebroker-subprot= ocol-02.txt
Status:          http://datatracker.ietf.org/doc/draft-hapner-hybi-messagebroker-subprotocol=
Htmlized:        http://tools.ietf.org/html/draft-hapner-hybi-messagebroker-subprotocol-02
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-hapner-hybi-messagebroker-subproto= col-02

--_000_92457F4F764A5C4785FCDBDDDD76477A4532FF01dfweml506mbx_-- From kedrot@gmail.com Mon Aug 6 15:21:49 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A7211E80BF for ; Mon, 6 Aug 2012 15:21:49 -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 KVbDrBdqyFn5 for ; Mon, 6 Aug 2012 15:21:47 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD7311E80A5 for ; Mon, 6 Aug 2012 15:21:47 -0700 (PDT) Received: by ghbg16 with SMTP id g16so943693ghb.31 for ; Mon, 06 Aug 2012 15:21:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=pAGqZ6qIG9Llx492Nt9BkjET2188jcTtAtMVz09zh1Y=; b=AVlT0MoXostJMjYEjFeawZbWjeud7mBNC4rHsi3wXPDY/yPRzW5EuvxwpBX8hXxzAB o2jFjxvDjeaOEA1v2c6ZAuz9k1LtqHaiGdKEuCHjkgsIHey1qDA8ZZYvuYr6Un3iunbq bFIVWfaK4Ab12z828rYUi2KGfIY23ljNsYS2M1qwg3Y+hcfw9Ys8EbBsu/xFpOgELXoe ESq3CwIYTKAbOu1Vj/EqsouIvUQeiI2OUdIFvYO1zmes9qTVjESqsdReWxujtmR3ck77 UmFFssMllV4tDwFYyFJsEQUSpMFzB4gfFwd1z3BX6EKB9JPi50Pc1iSkIFOoqlUKrzdh ANHw== Received: by 10.236.197.3 with SMTP id s3mr11620181yhn.1.1344291707134; Mon, 06 Aug 2012 15:21:47 -0700 (PDT) Received: from ?IPv6:2001:470:5:60d:227:eff:fe03:da90? ([2001:470:5:60d:227:eff:fe03:da90]) by mx.google.com with ESMTPS id v8sm33763049yhi.15.2012.08.06.15.21.45 (version=SSLv3 cipher=OTHER); Mon, 06 Aug 2012 15:21:46 -0700 (PDT) Message-ID: <50204377.70604@gmail.com> Date: Mon, 06 Aug 2012 19:21:43 -0300 From: Tordek User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.5) Gecko/20120624 Icedove/10.0.5 MIME-Version: 1.0 To: hybi@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 06 Aug 2012 16:08:09 -0700 Subject: [hybi] Question about TCP reuse. X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 06 Aug 2012 22:23:44 -0000 Can a TCP connection be reused for WS after an HTTP request has been made? Is a client allowed such an optimization? Is the server allowed or expected to accept this behavior? In short, what should the behavior of this interaction be: Open a connection S to example.com. s <- "GET / HTTP/1.1 Host: example.com" s -> read data (presumably a script requesting a websocket into ws://example.com.) s <- "GET / HTTP/1.1 Host: example.com Connection: Upgrade Upgrade: websocket" s -> ? From internet-drafts@ietf.org Tue Aug 7 07:00:30 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8E21F8699; Tue, 7 Aug 2012 07:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.578 X-Spam-Level: X-Spam-Status: No, score=-102.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 RfgYb9gYCIqE; Tue, 7 Aug 2012 07:00:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3FD21F867C; Tue, 7 Aug 2012 07:00:29 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807140029.16850.40340.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 07:00:29 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-04.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Aug 2012 14:00:30 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTTP Wo= rking Group of the IETF. Title : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-04.txt Pages : 38 Date : 2012-08-07 Abstract: The WebSocket Protocol [RFC6455] requires a new transport connection for every WebSocket connection. This presents a scalability problem when many clients connect to the same server, and is made worse by having multiple clients running in different tabs of the same user agent. This extension provides a way for separate logical WebSocket connections to share an underlying transport connection. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-websocket-multiplexing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-hybi-websocket-multiplexing-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From derhoermi@gmx.net Tue Aug 7 08:51:05 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9AA21F8610 for ; Tue, 7 Aug 2012 08:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 0r+TxUrdgxpX for ; Tue, 7 Aug 2012 08:51: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 41CCA21F8611 for ; Tue, 7 Aug 2012 08:51:02 -0700 (PDT) Received: (qmail invoked by alias); 07 Aug 2012 15:51:01 -0000 Received: from p5B233924.dip.t-dialin.net (EHLO netb.fritz.box) [91.35.57.36] by mail.gmx.net (mp024) with SMTP; 07 Aug 2012 17:51:01 +0200 X-Authenticated: #723575 X-Provags-ID: V01U2FsdGVkX1/4tgdsSOj4OoD2zL1OJs11HiWrimkydqZH/SJlcg pmXHzFRi0/Xcx1 From: Bjoern Hoehrmann To: Tordek Date: Tue, 07 Aug 2012 17:51:02 +0200 Message-ID: <04e228d3oa3hg0ob944akjrf7hbfu9v027@hive.bjoern.hoehrmann.de> References: <50204377.70604@gmail.com> In-Reply-To: <50204377.70604@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] Question about TCP reuse. X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 07 Aug 2012 15:51:05 -0000 * Tordek wrote: >Can a TCP connection be reused for WS after an HTTP request has been >made? Last I heard the Working Group's position was that the protocol is HTTP until after the Websocket handshake has been completed and I'm not aware of the RFC saying anything to the contrary; so, sure, that is an option, and depending on intermediaries, it might be hard to avoid. -- 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 mcmanus@ducksong.com Tue Aug 7 20:02:16 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148C921F8600 for ; Tue, 7 Aug 2012 20:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgWmT7WjcexI for ; Tue, 7 Aug 2012 20:02:15 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 9063D21F85F4 for ; Tue, 7 Aug 2012 20:02:15 -0700 (PDT) Received: from [192.168.16.245] (cpe-74-78-161-41.twcny.res.rr.com [74.78.161.41]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by linode.ducksong.com (Postfix) with ESMTPSA id 317AE101AA; Tue, 7 Aug 2012 23:02:14 -0400 (EDT) Message-ID: <5021D6B1.2040505@ducksong.com> Date: Tue, 07 Aug 2012 23:02:09 -0400 From: Patrick McManus User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: Bjoern Hoehrmann References: <50204377.70604@gmail.com> <04e228d3oa3hg0ob944akjrf7hbfu9v027@hive.bjoern.hoehrmann.de> In-Reply-To: <04e228d3oa3hg0ob944akjrf7hbfu9v027@hive.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Tordek , hybi@ietf.org Subject: Re: [hybi] Question about TCP reuse. X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 08 Aug 2012 03:02:16 -0000 On 8/7/2012 11:51 AM, Bjoern Hoehrmann wrote: > * Tordek wrote: >> Can a TCP connection be reused for WS after an HTTP request has been >> made? > Last I heard the Working Group's position was that the protocol is HTTP > until after the Websocket handshake has been completed and I'm not aware > of the RFC saying anything to the contrary; so, sure, that is an option, > and depending on intermediaries, it might be hard to avoid. yes - firefox actually will reuse an idle persistent connection to bootstrap into websockets if it is convenient to do so. Saves a round trip. From tyoshino@google.com Wed Aug 8 09:03:02 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8952E11E810A for ; Wed, 8 Aug 2012 09:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.321 X-Spam-Level: X-Spam-Status: No, score=-102.321 tagged_above=-999 required=5 tests=[AWL=-0.637, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, 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 QobMwoR-VQwy for ; Wed, 8 Aug 2012 09:03:02 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5DE311E8109 for ; Wed, 8 Aug 2012 09:03:01 -0700 (PDT) Received: by qcac10 with SMTP id c10so650200qca.31 for ; Wed, 08 Aug 2012 09:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record; bh=+04eOCi6P3LnA3dgvw9jH/7GykTaUMGb7aHhyeACrpM=; b=XoUPUkf9KLFAgykvaFB+/N/4Vl6jmLobkelcA1kiHy97xRU04/ThFiGUR7V10Yzh5C MX1nOo8ttLqca0FpohEKrIuZ5ClGfpkM5cypgoAp8pW/SPaifRZN306PFgrWfypAS2SF XcyaItg92IzM2C2bSUHK+Y0YmgzZIkQRYX3BMHrGrVnfT5gDAo3yaomT6cJ2rffKezbj 726VEjo9ZpG1SUqdLDLh+waDOKhcU6vHnI+VvPUsqNSWNH547FO4C42Yq6QBgf8g1wHy NEZdwACio+sQuECNVp0UzVNfhq9A2yJJiGfdXzzzt1o3o9n0f1eBWvgbNeEiQH1hcHqE R2oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record:x-gm-message-state; bh=+04eOCi6P3LnA3dgvw9jH/7GykTaUMGb7aHhyeACrpM=; b=DHFQeld9XZu5P7m+KkVGXrcPZ74UEwrmEs6EoK9KlCaTzJuAlvOyPQhLTG1YuFLgbr MGph1MDuMSj8q9KsCKMjapaGlly+tA+iTjDRWWUxQn6wWlVLooxQ0x0x/06a9QTO2y7+ NeBfz2YNyfJnX5NL040gnig3nS0fLe24u+BMsTGkNxWJgR+GEhMBajJ7iGw1hRyMr8UQ tcPUhoYwGSHah1jIvGn66CsE1PCGoOI/XNtJvHGbjtHWrwUjDh12nxo+ZCDW3A18+KlL tf+V8nMNsmbgKLPcxfNklfPzvoQTcXElPN5xrcZ51PMI62ouEZ4DxWf205oHqu5vUCTT aGgA== Received: by 10.50.186.130 with SMTP id fk2mr313628igc.60.1344441780961; Wed, 08 Aug 2012 09:03:00 -0700 (PDT) Received: by 10.50.186.130 with SMTP id fk2mr313617igc.60.1344441780799; Wed, 08 Aug 2012 09:03:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.7.228 with HTTP; Wed, 8 Aug 2012 09:02:40 -0700 (PDT) In-Reply-To: <20120807140029.16850.40340.idtracker@ietfa.amsl.com> References: <20120807140029.16850.40340.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 9 Aug 2012 01:02:40 +0900 Message-ID: Cc: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae9340695c4089904c6c33e49 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn+ln46S+x5pjsSF5ILzc1Z2aEuqfjS4bVMPFHhp+SUN4nZ6yE/L5ilzt20F3LNvIdO7SW+Ue9Ln9gZ4gi8xS1OybCWMxmHje1v9H7cJkTEWSBXToGDOrKK59BPYpODlNyjbH5mFVsPefuIOiJsXjQEVxQKGj/kNdXts8dpDTcLA7/rzQSOtmXxqQxBIA9ytGRO3lOd Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-04.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Aug 2012 16:03:02 -0000 --14dae9340695c4089904c6c33e49 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here's -03 -> -04 change summary - added Extension Negotiation section - defined drop reason codes - removed F frag from DropChannel - changed length header encoding in multiplex control blocks to the same encoding as payload length - clarified which headers AddChannelRequest/Response inherit from physical connection handshake - clarified how the server should respond to AddChannelRequest - added physical channel fallback suggestion bit to NewChannelSlot - removed nesting consideration section --14dae9340695c4089904c6c33e49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Here's -03 -> -04 change summary

- added Ex= tension Negotiation section
- defined drop = reason codes
- removed F frag from DropChannel
- changed length header encoding in multiplex control blo= cks to the same encoding as payload length
= - clarified which headers AddChannelRequest/Response inherit from physical = connection handshake
- clarified how the server should respond to Add= ChannelRequest
- added physical channel fal= lback suggestion bit to NewChannelSlot
- re= moved nesting consideration section

--14dae9340695c4089904c6c33e49-- From tyoshino@google.com Wed Aug 8 19:43:19 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D731111E813A for ; Wed, 8 Aug 2012 19:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.308 X-Spam-Level: X-Spam-Status: No, score=-102.308 tagged_above=-999 required=5 tests=[AWL=-0.624, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, 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 OHKuLxZQB1AS for ; Wed, 8 Aug 2012 19:43:19 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B0E511E80A5 for ; Wed, 8 Aug 2012 19:43:19 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1668263ghb.31 for ; Wed, 08 Aug 2012 19:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record; bh=jhGaxtsIfooMmyjBZ2oBQm8CHN5fWdTcLK6AnY+5boE=; b=lGd5Lu58tabRVF68OmTB15p9oJXvM9LYHWT/2o18KXyV9FAY9dM145P/5mFKgFO9WA +lX73q5+ENRYtAwvKg6FDvmy1PHEk2YX1Wg/ZB9LQGrXrPOOEdIu3milftQUVCsCt1I4 wumQOjkpE2FtxEvqQ3mq1C6tW2M08LAmJEQbPhokFbsVkeGVS8TiilX2EaZUBhtigp0o bA6ktElCyneLHB7jTKHv3mTcQHeiaiqgVRs7bC1T8/soTnG0D1IqRSoL+vhYxrFoJMMw 2i8mbSd/7DS1SXj803gxzV5wWgf557o4f7xe+AOAdTYEO/VR8H2RYUR9WlEaUWHlKwQI 7DcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record:x-gm-message-state; bh=jhGaxtsIfooMmyjBZ2oBQm8CHN5fWdTcLK6AnY+5boE=; b=TLINNw/6uHo3kEADdnaIf57pOAe+GmalSkmVAZ144oOLwrkP5cIBqJt2KSja7q12oe aTuGQovdQQYrHSpSSyoRVKzypzH5D2aK5geITnU1a/+jkbm+8YL9Q0/LXxN2jtCefxkk DfJ83SXvr32Xeht7vC+GL0b/A5JnvH8UC6VaTUb1slnMhHFdqTQcWNKdEE1X3xpEPG5E 5DmvrkvxSYcACiMC+MYsy9vgdItr0qNcjMOaHDN7KUxXn/bPF3iNzSkR9hux9hgp7lMj gVYdXr3cXL1aZb857uYW1ZjbEUnKkkKmgH/4dwZpfMEZSOqnHsBuCk80rKH5IX81W5h2 c2wg== Received: by 10.50.170.3 with SMTP id ai3mr894200igc.9.1344480198134; Wed, 08 Aug 2012 19:43:18 -0700 (PDT) Received: by 10.50.170.3 with SMTP id ai3mr894192igc.9.1344480197922; Wed, 08 Aug 2012 19:43:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.7.228 with HTTP; Wed, 8 Aug 2012 19:42:57 -0700 (PDT) In-Reply-To: References: <20120807140029.16850.40340.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 9 Aug 2012 11:42:57 +0900 Message-ID: Cc: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f23464f9acf6c04c6cc3022 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlKWdHWhNVXwxFCN/W6WcclkwnF0vvIdfx/I0WyMgdmZqBNB6VW1pa3mDZ2RTr5MZLfnaetY4QYec9kLEmQlH/VHVNvrsYKBCfPQAYDKhhqzNZ1Y3gT5pEMsaEmiyUEzSV/J622m0FxvnVLG9ThcBmZQYzuPTHqdX89lYGMp7x7XY9wH9gyLKDiU4ZGbilKYqpbY3vl Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-04.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Aug 2012 02:43:20 -0000 --e89a8f23464f9acf6c04c6cc3022 Content-Type: text/plain; charset=ISO-8859-1 re: change on number encoding I support John's argument made here about channel ID encoding. http://www.ietf.org/mail-archive/web/hybi/current/msg09555.html Smaller overhead is expected when number of active channels is small. But payload length is not a good fit for this. Channel ID is independent from message size. The cost doesn't become negligible even when the assigned ID is big. But still use of 3 types of number encoding seemed not so good. So, instead of channel ID, I've replaced number fields in multiplex control blocks which were representing "size". 3B and 9B overhead are negligible as the data they're representing gets bigger. Replenished send quota field is not followed by data, but big quota is sent expecting big data. I think it's reasonable to take it as negligible cost for a channel with such traffic. You can just reuse the code for read/write the RFC 6455 payload length. --e89a8f23464f9acf6c04c6cc3022 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
re: change on number encoding

I support John&= #39;s argument made here about channel ID encoding.
http://www.ietf.o= rg/mail-archive/web/hybi/current/msg09555.html

Smaller overhead is expected when number of active chan= nels is small. But payload length is not a good fit for this. Channel ID is= independent from message size. The cost doesn't become negligible even= when the assigned ID is big.

But still u= se of 3 types of number encoding seemed not so good. So, instead of channel= ID, I've replaced number fields in multiplex control blocks which were= representing "size".=A03B and 9B overhead are negligible as the = data they're representing gets bigger. Replenished send quota field is = not followed by data, but big quota is sent expecting big data. I think it&= #39;s reasonable to take it as negligible cost for a channel with such traf= fic. You can just reuse the code for read/write the RFC 6455 payload length= .

--e89a8f23464f9acf6c04c6cc3022-- From art.barstow@nokia.com Thu Aug 9 06:16:02 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C04121F8628 for ; Thu, 9 Aug 2012 06:16:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5MMjaAuqgXEE for ; Thu, 9 Aug 2012 06:16:01 -0700 (PDT) Received: from mgw-sa02.nokia.com (smtp.nokia.com [147.243.1.48]) by ietfa.amsl.com (Postfix) with ESMTP id 31A8A21F85E1 for ; Thu, 9 Aug 2012 06:16:00 -0700 (PDT) Received: from bsdhcp175151.americas.nokia.com (bsdhcp175151.americas.nokia.com [172.19.175.151]) by mgw-sa02.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q79DFv72029116; Thu, 9 Aug 2012 16:15:58 +0300 Message-ID: <5023B80E.1070308@nokia.com> Date: Thu, 09 Aug 2012 09:15:58 -0400 From: Arthur Barstow User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: public-webapps , "hybi@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Nokia-AV: Clean X-Mailman-Approved-At: Thu, 09 Aug 2012 06:55:40 -0700 Subject: [hybi] RfC: LCWD of WebSocket API; deadline August 30 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 09 Aug 2012 13:25:41 -0000 This is a Request for Comments for the 9 August 2012 LCWD version of the WebSocket API . The comment deadline is August 30 and all comments should be sent to the public-webapps@w3.org list [Archive]. The Bugzilla component for the API is [Bugz] and the Call for Consensus to publish this LC is [CfC]. I Cc'ed the hybi list as an FYI and comments from that list's subscribers are welcome. -Thanks, AB [Bugz] [Archive] http://lists.w3.org/Archives/Public/public-webapps/ [CfC] From Gabriel.Montenegro@microsoft.com Mon Aug 13 17:22:11 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57E8521F8648 for ; Mon, 13 Aug 2012 17:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.01 X-Spam-Level: X-Spam-Status: No, score=-6.01 tagged_above=-999 required=5 tests=[AWL=-2.412, 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 fUoKIzbZU1Er for ; Mon, 13 Aug 2012 17:22:10 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 6146D21F8647 for ; Mon, 13 Aug 2012 17:22:10 -0700 (PDT) Received: from mail178-co1-R.bigfish.com (10.243.78.238) by CO1EHSOBE015.bigfish.com (10.243.66.78) with Microsoft SMTP Server id 14.1.225.23; Tue, 14 Aug 2012 00:22:09 +0000 Received: from mail178-co1 (localhost [127.0.0.1]) by mail178-co1-R.bigfish.com (Postfix) with ESMTP id 95105A40385; Tue, 14 Aug 2012 00:22:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zzc85fhc25dL4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail178-co1: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail178-co1 (localhost.localdomain [127.0.0.1]) by mail178-co1 (MessageSwitch) id 1344903728328432_4509; Tue, 14 Aug 2012 00:22:08 +0000 (UTC) Received: from CO1EHSMHS025.bigfish.com (unknown [10.243.78.248]) by mail178-co1.bigfish.com (Postfix) with ESMTP id 4478D9E004D; Tue, 14 Aug 2012 00:22:08 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS025.bigfish.com (10.243.66.35) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 14 Aug 2012 00:22:07 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.309.3; Tue, 14 Aug 2012 00:22:01 +0000 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0309.003; Mon, 13 Aug 2012 17:22:00 -0700 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: confirming change in compression from per-frame to per-message Thread-Index: Ac15scnVscJ7q0FhSpGkYwvqygM8CQ== Date: Tue, 14 Aug 2012 00:22:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D765BTK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [hybi] confirming change in compression from per-frame to per-message X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 14 Aug 2012 00:22:11 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D765BTK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Per Takeshi's msg: http://www.ietf.org/mail-archive/web/hybi/current/msg09776.html as well as the agenda: http://tools.ietf.org/wg/hybi/agenda we discussed the change from per-frame to per-message compression in Vancou= ver. The chairs sensed the WG's consensus in the room to go ahead with this= change. This means the WG will "unadopt" the per-frame draft: http://tools.ietf.org/wg/hybi/draft-ietf-hybi-websocket-perframe-compressio= n/ Instead, the WG will adopt the per-message draft and continue work on it to= wards proposed standard RFC: http://tools.ietf.org/html/draft-tyoshino-hybi-permessage-compression/ The above will be renamed draft-ietf-hybi-websocket-permessage-compression. This message is to confirm our reading of the WG consensus. Any comments, p= lease send them by Friday Aug 17. Thanks, Chairs --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D765BTK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Per Takeshi’s msg:

http://www.ietf.org/mail-archive/web/hybi/current/m= sg09776.html

 

as well as the agenda:

htt= p://tools.ietf.org/wg/hybi/agenda

 

we discussed the change from per-frame to per-messag= e compression in Vancouver. The chairs sensed the WG’s consensus in t= he room to go ahead with this change.

 

This means the WG will “unadopt” the per= -frame draft:

http://tools.ietf.org/wg/hybi/draft-i= etf-hybi-websocket-perframe-compression/

 

Instead, the WG will adopt the per-message draft and= continue work on it towards proposed standard RFC:

http://tools.ietf.org/html/draft-tyoshino-hy= bi-permessage-compression/

 

The above will be renamed draft-ietf-hybi-websocket-= permessage-compression.

 

This message is to confirm our reading of the WG con= sensus. Any comments, please send them by Friday Aug 17.

 

Thanks,

 

Chairs

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D765BTK5EX14MBXW604w_-- From margy9003@hotmail.com Tue Aug 14 12:54:41 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1990521E809B for ; Tue, 14 Aug 2012 12:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 NVSY0GU-WYcR for ; Tue, 14 Aug 2012 12:54:40 -0700 (PDT) Received: from snt0-omc2-s4.snt0.hotmail.com (snt0-omc2-s4.snt0.hotmail.com [65.55.90.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8084B21E809A for ; Tue, 14 Aug 2012 12:54:40 -0700 (PDT) Received: from SNT112-W59 ([65.55.90.73]) by snt0-omc2-s4.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Aug 2012 12:54:40 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9ced7447-96d1-4e0d-b619-3e43819889fd_" X-Originating-IP: [64.76.48.140] From: Maria Margarita Gonzalez Ramirez To: Date: Tue, 14 Aug 2012 14:54:40 -0500 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 14 Aug 2012 19:54:40.0612 (UTC) FILETIME=[A4506240:01CD7A56] X-Mailman-Approved-At: Tue, 14 Aug 2012 13:28:24 -0700 Subject: [hybi] information about websockets X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 14 Aug 2012 20:23:52 -0000 --_9ced7447-96d1-4e0d-b619-3e43819889fd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello=2C My name is Margarita Gonzalez and I'm trying to do an application with webs= ockets=2C using the protocol TCP/IP.I'd like to know the differents functio= ns of the websockets=2C I Know only those: =20 websocket.onopen =3D GetRef(onOpen) websocket.onclose =3D GetRef(onClose= ) websocket.onmessage =3D GetRef(onMessage) websocket.onerror =3D GetRef(= onError) there are other? Where can I find it? = --_9ced7447-96d1-4e0d-b619-3e43819889fd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello=2C

My name is Margarita Gonzalez and I'm trying to do an= application with websockets=2C using the protocol TCP/IP.
I'd li= ke to know the differents functions of the websockets=2C I Know only those:=  =3B

 =3B websocket.onopen =3D GetRe= f(onOpen)
 =3B websocket.onclose =3D GetRef(onClose)
 =3B websocket.onmessage =3D GetRef(onMessage)
 =3B web= socket.onerror =3D GetRef(onError)

there are other= ? Where can I find it? =3B
 =3B =3B
= = --_9ced7447-96d1-4e0d-b619-3e43819889fd_-- From hapnermw@gmail.com Tue Aug 14 22:04:56 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8CB621E8086 for ; Tue, 14 Aug 2012 22:04:56 -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 d-rljX167HIT for ; Tue, 14 Aug 2012 22:04:55 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5121E805E for ; Tue, 14 Aug 2012 22:04:55 -0700 (PDT) Received: by ghbg16 with SMTP id g16so1496507ghb.31 for ; Tue, 14 Aug 2012 22:04:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=hZBaK0antvmMXvVL7nZpj0kAgwTy9LbvZU+ZxeCC+HA=; b=mJvqir3lMFEBSyjNJBsyvVV0yjnI7JSG/YpT2IcNcIRc+Cz358EnZAET0GKLUwWRWF PfZ0OhLvhw6qy0tVjti05d1vGQIuVEMEYENy6KqcVwcrrd3Mk16xNJ2Jzsfyg4gIZ32j xTaFPJct3CdHxFtedPNHKsVbJojeCXDqnFzSm/iPN5UfIo3rBbpoxIXUwKJH71YG2eei 6a/mvZEPjnhvXl91LdTp3u279TdIoLYT8oQPsTU8jC3MqeBzd+c9kchHqb6TJEv243Ir T6V0lGIDY8i1Vsl7KO4TzcuCTohGsCdrkSBeTlnzB7zt4G4lPM5qcgbpLBNoocOkGkVW zl5A== MIME-Version: 1.0 Received: by 10.68.200.8 with SMTP id jo8mr24766673pbc.148.1345007094120; Tue, 14 Aug 2012 22:04:54 -0700 (PDT) Received: by 10.68.192.66 with HTTP; Tue, 14 Aug 2012 22:04:54 -0700 (PDT) Date: Tue, 14 Aug 2012 22:04:54 -0700 Message-ID: From: Mark Hapner To: hybi@ietf.org, Clebert Suconic Content-Type: multipart/alternative; boundary=047d7b15b17510c1ff04c746de50 Subject: [hybi] draft-hapner-hybi-messagebroker-subprotocol-03 X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 15 Aug 2012 05:04:56 -0000 --047d7b15b17510c1ff04c746de50 Content-Type: text/plain; charset=ISO-8859-1 This version of the MBWS Subprotocol closed a small QoS issue with close. It now insures that both endpoints acknowledge receipt of the last message each receives. A new version of I-D, draft-hapner-hybi-messagebroker-subprotocol-03.txt has been successfully submitted by Mark Hapner and posted to the IETF repository. Filename: draft-hapner-hybi-messagebroker-subprotocol Revision: 03 Title: The MessageBroker WebSocket Subprotocol Creation date: 2012-08-13 WG ID: Individual Submission Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-hapner-hybi-messagebroker-subprotocol-03.txt Status: http://datatracker.ietf.org/doc/draft-hapner-hybi-messagebroker-subprotocol Htmlized: http://tools.ietf.org/html/draft-hapner-hybi-messagebroker-subprotocol-03 Diff: http://www.ietf.org/rfcdiff?url2=draft-hapner-hybi-messagebroker-subprotocol-03 Abstract: The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides a subprotocol extension facility. The MessageBroker WebSocket Subprotocol (MBWS) is a WebSocket Subprotocol used by messaging clients to send messages to, and receive messages from an internet message broker (herein called a message broker). A message broker is a messaging intermediary that queues messages sent by its clients for asynchronous delivery to its clients. Messages are addressed to message-broker-specific address names. Clients send messages to addresses and consume messages from addresses. Clients do not send messages directly to other clients. Message brokers provide a range of functionality that is outside the scope of MBWS. Typically an internet message broker provides a REST API for working with this functionality; such as configuring client credentials; setting client access controls; configuring address routing; etc. MBWS limits its scope to the definition of a WebSocket subprotocol that provides a full duplex, reliable message transport protocol between message brokers and their clients; and, between message brokers. Since reliable message transport is often independent of a broker's particular features, MBWS can be used as the message transport protocol for a wide range of message brokers. The MBWS subprotocol defines a binary message frame and a text message frame. Both types of frame carry the same protocol; however, the protocol bindings differ slightly. The binary frame is a WebSocket binary message that contains an MBWS binary header followed by a binary message body. The text frame is a WebSocket UTF-8 text message that contains an MBWS text header followed by a text message body. The IETF Secretariat --047d7b15b17510c1ff04c746de50 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This version of the MBWS Subprotocol closed a small QoS issue with close. I= t now insures that both endpoints acknowledge receipt of the last message e= ach receives.


A new version of I-D, draft-hapner-h= ybi-messagebroker-subprotocol= -03.txt
has been successfully submitted by M= ark Hapner and posted to the
IETF repository.

Filename:=A0=A0=A0=A0=A0=A0=A0=A0draft-hapner-hybi-messagebroker-subprotocol<= /div>
Revision:=A0=A0=A0=A0=A0=A0=A0=A003
Title:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= The MessageBroker WebSocket Subprotocol
Creation date:=A0=A0 2012-08-13
WG ID:=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Individual Submi= ssion
Number of pages: 14

Abstract:
=A0=A0=A0The WebSocket protocol [I-D.ietf-hybi-thewebsocketprotocol] provides
=A0=A0=A0a subprotocol extension facility.=A0=A0The MessageBr= oker WebSocket
=A0=A0=A0Subprotocol (MBWS) is a WebSocket Subprotocol used b= y messaging
=A0=A0=A0clients to send messages to, and receive messages fr= om an internet
=A0=A0=A0message broker (herein called a message broker).=A0= =A0A message broker is
=A0=A0=A0a messaging intermediary that queues messages sent b= y its clients for
=A0=A0=A0asynchronous delivery to its clients.

=A0=A0=A0Messages = are addressed to message-broker-specific address names.
=A0=A0=A0Clients send messages to addresses and consume messa= ges from
=A0=A0=A0addresses.=A0=A0Clients do not send messages directl= y to other clients.

=A0=A0=A0Message brokers provide a range of= functionality that is outside the
=A0=A0=A0scope of MBWS.=A0=A0Typically an internet message br= oker provides a REST
=A0=A0=A0API for working with this functionality; such as con= figuring client
=A0=A0=A0credentials; setting client access controls; configu= ring address
=A0=A0=A0routing; etc.

=A0=A0=A0MBWS limi= ts its scope to the definition of a WebSocket subprotocol
=A0=A0=A0that provides a full duplex, reliable message transp= ort protocol
=A0=A0=A0between message brokers and their clients; and, betw= een message
=A0=A0=A0brokers.

=A0=A0=A0Since rel= iable message transport is often independent of a broker's
=A0=A0=A0particular features, MBWS can be used as the message= transport
=A0=A0=A0protocol for a wide range of message brokers.=

=A0=A0=A0The MBWS subprotocol defines a bin= ary message frame and a text
=A0=A0=A0message frame.=A0=A0Both types of frame carry the sa= me protocol; however,
=A0=A0=A0the protocol bindings differ slightly.=A0=A0The bina= ry frame is a
=A0=A0=A0WebSocket binary message that contains an MBWS binar= y header followed
=A0=A0=A0by a binary message body.=A0=A0The text frame is a W= ebSocket UTF-8 text
=A0=A0=A0message that contains an MBWS text header followed b= y a text message
=A0=A0=A0body.



<= br style=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px= ;background-color:rgb(255,255,255)">
The IETF Secretariat
--047d7b15b17510c1ff04c746de50-- From Gabriel.Montenegro@microsoft.com Wed Aug 15 13:42:19 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B6011E80B8 for ; Wed, 15 Aug 2012 13:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.708 X-Spam-Level: X-Spam-Status: No, score=-5.708 tagged_above=-999 required=5 tests=[AWL=-2.110, 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 uUB+Ub2jehtp for ; Wed, 15 Aug 2012 13:42:19 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 876B911E809A for ; Wed, 15 Aug 2012 13:42:18 -0700 (PDT) Received: from mail116-db3-R.bigfish.com (10.3.81.240) by DB3EHSOBE006.bigfish.com (10.3.84.26) with Microsoft SMTP Server id 14.1.225.23; Wed, 15 Aug 2012 20:42:17 +0000 Received: from mail116-db3 (localhost [127.0.0.1]) by mail116-db3-R.bigfish.com (Postfix) with ESMTP id 74BDC40091 for ; Wed, 15 Aug 2012 20:42:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VS-21(zzc85fh4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail116-db3: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14HUBC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail116-db3 (localhost.localdomain [127.0.0.1]) by mail116-db3 (MessageSwitch) id 1345063335732586_21559; Wed, 15 Aug 2012 20:42:15 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.254]) by mail116-db3.bigfish.com (Postfix) with ESMTP id A7B39400115 for ; Wed, 15 Aug 2012 20:42:15 +0000 (UTC) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (131.107.125.8) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 15 Aug 2012 20:42:15 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 15 Aug 2012 20:41:50 +0000 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) with Microsoft SMTP Server (TLS) id 14.2.309.3; Wed, 15 Aug 2012 13:41:50 -0700 Received: from TK5EX14MBXW604.wingroup.windeploy.ntdev.microsoft.com ([169.254.4.170]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi id 14.02.0309.003; Wed, 15 Aug 2012 13:41:50 -0700 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: IETF 84 HyBi minutes available Thread-Index: Ac17Jiwfh3MffokSTiWpErg+o8kLFg== Date: Wed, 15 Aug 2012 20:41:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D98FETK5EX14MBXW604w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: [hybi] IETF 84 HyBi minutes available X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 15 Aug 2012 20:42:20 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D98FETK5EX14MBXW604w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've uploaded the minutes for the Vancouver meeting: http://www.ietf.org/proceedings/84/minutes/minutes-84-hybi Please send text for corrections or suggestions. Thanks, Gabriel --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D98FETK5EX14MBXW604w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I’ve uploaded the minutes for the Vancouver me= eting:

 

http://www.ietf.org/proceedings/84/minutes/minutes-84-hy= bi

 

Please send text for corrections or suggestions.

 

Thanks,

 

Gabriel

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480D98FETK5EX14MBXW604w_-- From tyoshino@google.com Thu Aug 16 00:42:03 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E639221F8630 for ; Thu, 16 Aug 2012 00:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 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_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPG3V1WVpA+v for ; Thu, 16 Aug 2012 00:42:02 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 06B9221F8599 for ; Thu, 16 Aug 2012 00:42:01 -0700 (PDT) Received: by ghbg16 with SMTP id g16so2862951ghb.31 for ; Thu, 16 Aug 2012 00:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record; bh=IzxReHIURBklbfqnj7iV58EAn77bJi061PFTLRK2qu8=; b=FllCCP9k7+fYqjm7weE64FKCmGdrYXzLc+dSRhU2VgaX3XfeJAZ3/3Uw67najTYstZ P8yVMf/CQDLbS7AoeNp43EvZ2eIi1EW9xVHAJ2Bf0nQ//Ud/SA/eU6bYtnmRkNpO+h5b vJLIKNBQojdrL1LE266Fx23MDJTl5Yn3c+cWbh7x/QS6HF9dj79a+oO4rOLC8FZxkAi0 I/1UFv9fO4QuVmwFRb1G2u0dIk81ts7oenX1QOfPiBCQP99CFg9tcsD/c4irv/7JVW1S 73B9vuOQPUI+wRdwCVWEAfZENY9GlHsLBFALH6T6H8Ylm5W5xwYzDAe8/ZeI2KqlAjd1 LJZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-system-of-record:x-gm-message-state; bh=IzxReHIURBklbfqnj7iV58EAn77bJi061PFTLRK2qu8=; b=RKDREcaHedSd4TQzMHE2sXctzG/X7m0dZ92cq/RKM6Q9ocVzfeSOB/JzpstfoGj86y kVYNqH1sRfbi39Iij21aGjrt/QzkNhtPtLkSPocxYzMODzQJpipTXkLM6YSmGpNe7XRn Je51FPYlgJ4nCN+FaWwdzSKtdpNge2bTf6YDeCBCLmlUCN2Dui57KZAww9ZXAHCYk5r0 tIBKpEVf8ML/GQDzHI/r5M/1UL+5kLj0JD38E+XbIEgj7Ffas8im5Rt1ZKd7xtOt8Q7A fArP0BW85yCTbj6SsoD8p/tPvFIJmPSOg8X43EL/shvJk0mT0Mf2Bjr4oc2r+IlMufaE A7pA== Received: by 10.50.242.71 with SMTP id wo7mr213705igc.55.1345102921182; Thu, 16 Aug 2012 00:42:01 -0700 (PDT) Received: by 10.50.242.71 with SMTP id wo7mr213692igc.55.1345102921057; Thu, 16 Aug 2012 00:42:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.22 with HTTP; Thu, 16 Aug 2012 00:34:09 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 16 Aug 2012 16:34:09 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d044787cdcbc61f04c75d2dd6 X-System-Of-Record: true X-Gm-Message-State: ALoCoQmYaS/4pOAMzGpjcrd+Gza356eG4HUKFQ7bWJPeLNzDqkB6S58EMkd0NEp3rPO53wLwuTg4eVoP/8doio21UdRAducr1Ec/0Ba/JTKvlTKAbAzcMoNKK/sNYDuz2ofgnIXUHqmCN57ov+lM8hl/D6HKlv868jMsIRQoyidv9T4JAua4hfXgh/Likcu8EVS4k8kUb1Bi Subject: [hybi] Finalize flow control metric X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 16 Aug 2012 07:42:03 -0000 --f46d044787cdcbc61f04c75d2dd6 Content-Type: text/plain; charset=ISO-8859-1 In WebSocket multiplexing, each stream transports not only message payload but message boundary information which also spends octets on wire. I'd like to make flow control mechanism consider this point. I've talked about this on the thread about -03 update and f2f meeting in Vancouver. Thanks for feedback. I want to finalize this point on -05 update. Requirements: a) reflect each stream's processing power, size of buffer, etc. (receiver can control amount of incoming data to some extent) b) receiver can compute the amount of quota the sender spent for the received data without ambiguity by looking at it c) quota consumption is (almost) proportional to bandwidth for fairness d) fragmentation made by multiplexer's matter should not affect quota consumption Current flow control almost satisfies (c) but cannot prevent flooding by zero-sized messages. So, I want to have each encapsulated message consume extra quota. I thought just counting in header overhead is fine, and was going to suggest +1 octet for each frame (Encapsulation overhead is also not negligible but it seems good enough once we have 1 octet penalty). Each stream can also try to use more octets on wire by flushing data byte by byte. But as we required in the spec that each logical stream cannot use frame-wise signal, we can skip forwarding zero-sized frame (NOT zero-sized message). So, at least 1 octet will be consumed from quota for each flushing. It's enough I think. However, we should also satisfy (d). Fragmentation made before mux and one made by mux are not distinguishable. So, I think we shouldn't consume quota headers of second and later encapsulated frame. Encapsulation overhead (length representation and masking belong to this layer) also shouldn't be counted in. (Note: if many control frames are injected on one message before mux, there'll be a lot of non-unfragmentable points. But each control frames themselves also consume quota, we can prevent flooding.) === So, I suggested 1 octet (the size of encapsulated FIN, RSV1-3, opcode of the first fragment) per message (NOT per frame) extra quota consumption in addition to consumption equal to the length of payload. This satisfies (a)-(d). Alternatives - count in second and later fragment's header but giving up satisfying (d) - count in encapsulation overhead - allocate RSV2 as MUX FIN bit, encapsulate one frame into multiple encapsulating messages - ... --f46d044787cdcbc61f04c75d2dd6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In WebSocket multiplexing, each stream transports not only message pay= load but message boundary information which also spends octets on wire. I&#= 39;d like to make flow control mechanism consider this point.

I've talked about this on the thread about -03 update an= d f2f meeting in Vancouver. Thanks for feedback. I want to finalize this po= int on -05 update.

Requirements:
a) refl= ect each stream's processing power, size of buffer, etc. (receiver can = control amount of incoming data to some extent)
b) receiver can compute the amount of quota the sender spent for the r= eceived data without ambiguity by looking at it
c) quota consumption is (almost) proportional to bandwidth for fairnes= s
d) fragmentation made by multiplexer's matter should not af= fect quota consumption

Current flow control almost satisfies (c) but cannot=A0= prevent flooding by zero-sized messages. So, I want to have each encapsulat= ed message consume extra quota. I thought just counting in header overhead = is fine, and was going to suggest +1 octet for each frame (Encapsulation ov= erhead is also not negligible but it seems good enough once we have 1 octet= penalty).

Each stream can also try to use more octets on wir= e by flushing data byte by byte. But as we required in the spec that each l= ogical stream cannot use frame-wise signal, we can skip forwarding zero-siz= ed frame (NOT zero-sized message). So, at least 1 octet will be consumed fr= om quota for each flushing. It's enough I think.

However, we should also satisfy (d). Fragmentatio= n made before mux and one made by mux are not distinguishable. So, I think = we shouldn't consume quota headers of second and later encapsulated fra= me. Encapsulation overhead (length representation and masking belong to thi= s layer) also shouldn't be counted in.

(Note: if many control frames are injected on one messa= ge before mux, there'll be a lot of non-unfragmentable points. But each= control frames themselves also consume quota, we can prevent flooding.)

=3D=3D=3D

So, I suggested 1 oc= tet (the size of encapsulated FIN, RSV1-3, opcode of the first fragment) pe= r message (NOT per frame) extra quota consumption in addition to consumptio= n equal to the length of payload. This satisfies (a)-(d).

Alternatives
- count in second and later frag= ment's header but giving up satisfying (d)
- count in encapsu= lation overhead
- allocate RSV2 as MUX FIN bit, encapsulate one f= rame into multiple encapsulating messages
- ...

--f46d044787cdcbc61f04c75d2dd6-- From tyoshino@google.com Thu Aug 16 01:05:58 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD71721F85F3 for ; Thu, 16 Aug 2012 01:05:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 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_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udPFg1MfhLAt for ; Thu, 16 Aug 2012 01:05:58 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id E167721F84C5 for ; Thu, 16 Aug 2012 01:05:52 -0700 (PDT) Received: by yenm5 with SMTP id m5so2874449yen.31 for ; Thu, 16 Aug 2012 01:05:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=M7+0sMDYTGBWFN3mExdaj+t0VCv9Eq8SWO1+ZF92SmA=; b=WJMS4yAQa3TiFY18EWYVNfdZIDC8OlwOb3GMN7OfAM/QyloqDb/k/BnmvhPmrsbDNF dXyT0UgjjLitxHiODmq/Fw9TJ8M74FwEl/Py2erA/lxVD9ScS3IbZp7kbDGZ2WxajHWI 6z5Fxc3Jo1ZoxYgKLuml1kqnoYx6arIQvcIW3zmec7qsClN0U5HBJ9+TRQlXPM9BgnoO q+Dptxa+kFEqBXKnJe3GroZyqKNeUqKb22/tTLZCSoNwBxx8r7Q98pqklHv95l+kBvDU pJYpONoHNTItGDzBagv5fOzRTohOjiy6cJC4rKB/WJ5C0woOfBy+bje4FvlFCW95FDoN P9YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=M7+0sMDYTGBWFN3mExdaj+t0VCv9Eq8SWO1+ZF92SmA=; b=J6fOoPO75iNaj4C6IguUEvoSeLWJE0sikud2Y4VecRwDVVKYLSezAumkPAwmnRivqE yK1r4/rANmxINpqta1fxscIifpnPPS4u/puM4E0RjnaKj6Hn8vNYc0gbG17INkZGewvq utwRVsCl8r+d2E4WB2rlYZhk5KMAuv33h9olD9qEUKOHDynYe2ikvm0lT79Z6b1P44Ao N+ktii45G+MPFAxGJGm2OvdzCsk/EJ6f8iS9ivFpSSOiYaZtVTuqesbnEKn5WCd5P6AE yGRzdbx9QhDwasFdkCxsqLA1kqgq/oihH/tmhpAvFQIbs7j4n0cTDfMl3MtTpKeJ6Yd4 tgEg== Received: by 10.50.189.134 with SMTP id gi6mr1202849igc.55.1345104352198; Thu, 16 Aug 2012 01:05:52 -0700 (PDT) Received: by 10.50.189.134 with SMTP id gi6mr1202838igc.55.1345104352000; Thu, 16 Aug 2012 01:05:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.193.22 with HTTP; Thu, 16 Aug 2012 01:05:31 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 16 Aug 2012 17:05:31 +0900 Message-ID: To: Maria Margarita Gonzalez Ramirez Content-Type: multipart/alternative; boundary=14dae9340a1b163ae404c75d8374 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn2kN4+i5U8ML1VsissYb65thYmlxkz3CTWQYrOXvMVekxqgNUQTdi9sN9nXDYPp/iF6LEu+rstHngM2TBgeQH8tj0owwHQ3v4pfVF2e7XAkk3xZlZefjKghW4uYA6B1ogzZzHdOxhL1pm43p4pj6GPvM6IBf0va12l2noDB6U9NTul8pDnjeFsfIkBQTijfrD7jvG9 Cc: hybi@ietf.org Subject: Re: [hybi] information about websockets X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 16 Aug 2012 08:05:58 -0000 --14dae9340a1b163ae404c75d8374 Content-Type: text/plain; charset=ISO-8859-1 JavaScript API for WebSocket is being standardized at W3C and WHATWG. Not here. Please take a look at the latest WebSocket API specification here. http://dev.w3.org/html5/websockets/ For general help about WebSocket based application development, please use howto sites written by developers, client/server vendors, etc. Takeshi On Wed, Aug 15, 2012 at 4:54 AM, Maria Margarita Gonzalez Ramirez < margy9003@hotmail.com> wrote: > Hello, > > My name is Margarita Gonzalez and I'm trying to do an application with > websockets, using the protocol TCP/IP. > I'd like to know the differents functions of the websockets, I Know only > those: > > websocket.onopen = GetRef(onOpen) > websocket.onclose = GetRef(onClose) > websocket.onmessage = GetRef(onMessage) > websocket.onerror = GetRef(onError) > > there are other? Where can I find it? > > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > > --14dae9340a1b163ae404c75d8374 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable JavaScript API for WebSocket is being standardized at W3C and WHATWG. Not h= ere.

Please take a look at the latest WebSocket API spec= ification here.

For general help about WebSocket based applicatio= n development, please use howto sites written by developers, client/server = vendors, etc.

Takeshi


On Wed, Aug 15, 2012 at 4:54 AM, Maria M= argarita Gonzalez Ramirez <margy9003@hotmail.com> wrote:=
Hello,

My name is Margarita Gonzalez and I'm trying to do = an application with websockets, using the protocol TCP/IP.
I'= d like to know the differents functions of the websockets, I Know only thos= e: =A0

=A0 websocket.onopen =3D GetRef(onOpen)
= =A0 websocket.onclose =3D GetRef(onClose)
=A0 websocket.onmessage= =3D GetRef(onMessage)
=A0 websocket.onerror =3D GetRef(onError)<= /div>

there are other? Where can I find it?=A0
=A0=A0
<= /div>

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


--14dae9340a1b163ae404c75d8374-- From Gabriel.Montenegro@microsoft.com Mon Aug 20 11:20:53 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F331E21F86B6 for ; Mon, 20 Aug 2012 11:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.974 X-Spam-Level: X-Spam-Status: No, score=-6.974 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqKZjZsT+AwJ for ; Mon, 20 Aug 2012 11:20:51 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 9CAEA21F8698 for ; Mon, 20 Aug 2012 11:20:51 -0700 (PDT) Received: from mail32-tx2-R.bigfish.com (10.9.14.241) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Mon, 20 Aug 2012 18:20:51 +0000 Received: from mail32-tx2 (localhost [127.0.0.1]) by mail32-tx2-R.bigfish.com (Postfix) with ESMTP id 3BD9480165 for ; Mon, 20 Aug 2012 18:20:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VS-25(zzc85fhc25dL4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail32-tx2: domain of microsoft.com designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=Gabriel.Montenegro@microsoft.com; helo=TK5EX14MLTC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail32-tx2 (localhost.localdomain [127.0.0.1]) by mail32-tx2 (MessageSwitch) id 1345486849412259_27014; Mon, 20 Aug 2012 18:20:49 +0000 (UTC) Received: from TX2EHSMHS015.bigfish.com (unknown [10.9.14.248]) by mail32-tx2.bigfish.com (Postfix) with ESMTP id 563FE1C0047 for ; Mon, 20 Aug 2012 18:20:49 +0000 (UTC) Received: from TK5EX14MLTC101.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS015.bigfish.com (10.9.99.115) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 20 Aug 2012 18:20:47 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14MLTC101.redmond.corp.microsoft.com (157.54.79.178) with Microsoft SMTP Server (TLS) id 14.2.298.5; Mon, 20 Aug 2012 18:20:43 +0000 Received: from TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com ([169.254.3.36]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0309.003; Mon, 20 Aug 2012 11:20:42 -0700 From: Gabriel Montenegro To: "hybi@ietf.org" Thread-Topic: [hybi] confirming change in compression from per-frame to per-message Thread-Index: Ac15scnVscJ7q0FhSpGkYwvqygM8CQFTmp6w Date: Mon, 20 Aug 2012 18:20:41 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.43] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480F6DF4TK5EX14MBXW603w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Subject: Re: [hybi] confirming change in compression from per-frame to per-message X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 20 Aug 2012 18:20:53 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480F6DF4TK5EX14MBXW603w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This message confirms the unadopt/adopt as noted below. We will proceed. Thanks, Gabriel From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gab= riel Montenegro Sent: Monday, 13 August, 2012 17:22 To: hybi@ietf.org Subject: [hybi] confirming change in compression from per-frame to per-mess= age Per Takeshi's msg: http://www.ietf.org/mail-archive/web/hybi/current/msg09776.html as well as the agenda: http://tools.ietf.org/wg/hybi/agenda we discussed the change from per-frame to per-message compression in Vancou= ver. The chairs sensed the WG's consensus in the room to go ahead with this= change. This means the WG will "unadopt" the per-frame draft: http://tools.ietf.org/wg/hybi/draft-ietf-hybi-websocket-perframe-compressio= n/ Instead, the WG will adopt the per-message draft and continue work on it to= wards proposed standard RFC: http://tools.ietf.org/html/draft-tyoshino-hybi-permessage-compression/ The above will be renamed draft-ietf-hybi-websocket-permessage-compression. This message is to confirm our reading of the WG consensus. Any comments, p= lease send them by Friday Aug 17. Thanks, Chairs --_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480F6DF4TK5EX14MBXW603w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This message confirms = the unadopt/adopt as noted below. We will proceed.

 

Thanks,

 

Gabriel

 

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Gabriel Montenegro
Sent: Monday, 13 August, 2012 17:22
To: hybi@ietf.org
Subject: [hybi] confirming change in compression from per-frame to p= er-message

 

Per Takeshi’s msg:

http://www.ietf.org/mail-archive/web/hybi/current/m= sg09776.html

 

as well as the agenda:

htt= p://tools.ietf.org/wg/hybi/agenda

 

we discussed the change from per-frame to per-messag= e compression in Vancouver. The chairs sensed the WG’s consensus in t= he room to go ahead with this change.

 

This means the WG will “unadopt” the per= -frame draft:

http://tools.ietf.org/wg/hybi/draft-i= etf-hybi-websocket-perframe-compression/

 

Instead, the WG will adopt the per-message draft and= continue work on it towards proposed standard RFC:

http://tools.ietf.org/html/draft-tyoshino-hy= bi-permessage-compression/

 

The above will be renamed draft-ietf-hybi-websocket-= permessage-compression.

 

This message is to confirm our reading of the WG con= sensus. Any comments, please send them by Friday Aug 17.

 

Thanks,

 

Chairs

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C11480F6DF4TK5EX14MBXW603w_-- From internet-drafts@ietf.org Tue Aug 21 00:21:23 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8886511E80F6; Tue, 21 Aug 2012 00:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.322 X-Spam-Level: X-Spam-Status: No, score=-102.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvx-NeD-G0vQ; Tue, 21 Aug 2012 00:21:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA9421F8575; Tue, 21 Aug 2012 00:21:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120821072123.15277.13400.idtracker@ietfa.amsl.com> Date: Tue, 21 Aug 2012 00:21:23 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:21:23 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTTP Wo= rking Group of the IETF. Title : WebSocket Per-message Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-permessage-compression-00.txt Pages : 17 Date : 2012-08-20 Abstract: This specification defines a WebSocket extension that adds compression functionality to the WebSocket Protocol. It compresses the payload of non-control WebSocket messages using specified compression algorithm. One reserved bit RSV1 in the WebSocket frame header is allocated to control application of compression for each message. This specification provides one compression method available for the extension using DEFLATE. Please send feedback to the hybi@ietf.org mailing list. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tyoshino@google.com Tue Aug 21 00:28:40 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5327B21F85F3 for ; Tue, 21 Aug 2012 00:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=-0.613, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b98aRSkc269J for ; Tue, 21 Aug 2012 00:28: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 E69D221F85BB for ; Tue, 21 Aug 2012 00:28:38 -0700 (PDT) Received: by iabz21 with SMTP id z21so3763412iab.31 for ; Tue, 21 Aug 2012 00:28:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record; bh=9qNRK9K/UrhzBt5gcR4njjpDzEfO+j3+YVrEM+xVam8=; b=YNqj37A3w3QGorzltoNFpuxTtE1MWuyxzHZxVEPeStnKYhP5Hnqj9f2Bq/r1xOJoVL vJKVLTSlklxuG1k+enVPxDaj4Ms/s3/TIplrJA3uSoGjGmhlWyqT3n6pXWrRu8hPyH6U zQmdBaAYPmray7GJRQYBpsWZ7tPZyfX7u/7uWEC363eD55VmF2wE49PCYz4r6OJpBhCh YRkGQX0Tg+Hxza81C0wJqqemlrqjNpbJFtazFDPO8vYyrUCc8iygcRz5i6LV94ISbLhk u6v+rrX5xskaoGyfr+BbLLUCoDHQXgozxO1Qbkd3r8d2L7EnkZwp2xd9vhfp7fKB9x4s wPZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type:x-system-of-record:x-gm-message-state; bh=9qNRK9K/UrhzBt5gcR4njjpDzEfO+j3+YVrEM+xVam8=; b=p2rmqwPKsCW+nLOu5uztetMbs2EKgk0X2QtYbMGgGyhwGuJsTXvi2fP/dRJ/mTp5SC LlNICcIoJOfHGEJekoLWFMH9SG88sykXZ9wGZYUT1vIhz1YojgmFjiV731upuaEZBVcm 9l83LzhT3pEETN7aqTD0fvCvy68BLC62HhMuPV+q8izryIsHs/eXlgzA1uAZOPVBg9Pd GNPflf9QDqMkf3DvPTvKekXWXSE3PgeWuypK6fakPhZ7dIcakPO/dVlwb5hn7Cygwxr2 87bQVCNHUjNsJl2hUEFPs4LTuBGSg1UgH+GzRU7e4Q5C6WtTm3ob+bsgYOaAfFmjCPRG he4w== Received: by 10.50.212.98 with SMTP id nj2mr12309462igc.35.1345534118149; Tue, 21 Aug 2012 00:28:38 -0700 (PDT) Received: by 10.50.212.98 with SMTP id nj2mr12309450igc.35.1345534117948; Tue, 21 Aug 2012 00:28:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.56.231 with HTTP; Tue, 21 Aug 2012 00:28:16 -0700 (PDT) In-Reply-To: <20120821072123.15277.13400.idtracker@ietfa.amsl.com> References: <20120821072123.15277.13400.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Tue, 21 Aug 2012 16:28:16 +0900 Message-ID: Cc: hybi@ietf.org Content-Type: multipart/alternative; boundary=14dae93404f1222c1b04c7c193fa X-System-Of-Record: true X-Gm-Message-State: ALoCoQlwiIU+i2wtautjskuyYHMy5oldP6hMgOZoUySkPGT2NOleooDQurraO+VKXLe0AFxnlrlTunhqqFIpgZE1NobprJ4dwDdoYIinTAgxr/q3PcqMzVDZ1oCTOo51pPK8heyaZmAe6RU7CygsuIRwp8bFSxktYfh4koxCbw+Ud6xebrk79J4cxOrlJiFmx5DmQe9bAHnQ Subject: Re: [hybi] I-D Action: draft-ietf-hybi-permessage-compression-00.txt X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:28:40 -0000 --14dae93404f1222c1b04c7c193fa Content-Type: text/plain; charset=ISO-8859-1 Nothing changed from draft-tyoshino-hybi-permessage-compression-00. http://tools.ietf.org//rfcdiff?url1=draft-tyoshino-hybi-permessage-compression-00&url2=draft-ietf-hybi-permessage-compression-00 Takeshi On Tue, Aug 21, 2012 at 4:21 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the BiDirectional or Server-Initiated HTTP > Working Group of the IETF. > > Title : WebSocket Per-message Compression > Author(s) : Takeshi Yoshino > Filename : draft-ietf-hybi-permessage-compression-00.txt > Pages : 17 > Date : 2012-08-20 > > Abstract: > This specification defines a WebSocket extension that adds > compression functionality to the WebSocket Protocol. It compresses > the payload of non-control WebSocket messages using specified > compression algorithm. One reserved bit RSV1 in the WebSocket frame > header is allocated to control application of compression for each > message. This specification provides one compression method > available for the extension using DEFLATE. > > Please send feedback to the hybi@ietf.org mailing list. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-hybi-permessage-compression > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-hybi-permessage-compression-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > --14dae93404f1222c1b04c7c193fa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Nothing changed from=A0draft-tyoshino-hybi-permessage-compression-00.<= /div>http://tools.ietf.org//rfcdiff?url1=3Ddraft-tyoshino-hybi-permessage-co= mpression-00&url2=3Ddraft-ietf-hybi-permessage-compression-00

Takeshi


On Tue, Aug 21, 2012 at 4:21 PM, <internet-drafts@ietf.org> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
=A0This draft is a work item of the BiDirectional or Server-Initiated HTTP = Working Group of the IETF.

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : WebSocket Per-message Compressi= on
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Takeshi Yoshino
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-hybi-permessage-compre= ssion-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 17
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-08-20

Abstract:
=A0 =A0This specification defines a WebSocket extension that adds
=A0 =A0compression functionality to the WebSocket Protocol. =A0It compresse= s
=A0 =A0the payload of non-control WebSocket messages using specified
=A0 =A0compression algorithm. =A0One reserved bit RSV1 in the WebSocket fra= me
=A0 =A0header is allocated to control application of compression for each =A0 =A0message. =A0This specification provides one compression method
=A0 =A0available for the extension using DEFLATE.

=A0 =A0Please send feedback to the hybi@ie= tf.org mailing list.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-hybi= -permessage-compression

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-hybi-permessa= ge-compression-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

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

--14dae93404f1222c1b04c7c193fa--