From internet-drafts@ietf.org Mon Apr 2 02:37: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 461DF21F889E; Mon, 2 Apr 2012 02:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qxf7TcAh2SS3; Mon, 2 Apr 2012 02:37:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C31621F8898; Mon, 2 Apr 2012 02:37:10 -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.00 Message-ID: <20120402093710.15576.56215.idtracker@ietfa.amsl.com> Date: Mon, 02 Apr 2012 02:37:10 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-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: Mon, 02 Apr 2012 09:37:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTT= P Working Group of the IETF. Title : WebSocket Per-frame Compression Author(s) : Takeshi Yoshino Filename : draft-ietf-hybi-websocket-perframe-compression-00.txt Pages : 14 Date : 2012-04-02 This specification defines a general scheme to add per-frame compression functionality to the WebSocket Protocol using its extension mechanism, and one specific compression extension using DEFLATE. In this scheme, the "Application data" part of WebSocket data frames is compressed using specified compression algorithm, and one reserved bit in the WebSocket frame header is allocated to control application of compression for each frame. Please send feedback to the hybi@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-websocket-perframe-comp= ression-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-websocket-perframe-compr= ession-00.txt From arman@noemax.com Mon Apr 2 06:04: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 38AE221F8444 for ; Mon, 2 Apr 2012 06:04:23 -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 wPp+s0q+RcCx for ; Mon, 2 Apr 2012 06:04:22 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 3392221F8442 for ; Mon, 2 Apr 2012 06:04:22 -0700 (PDT) Received: from vista1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id MRG13523; Mon, 02 Apr 2012 16:04:23 +0300 From: "Arman Djusupov" To: "'John Tamplin'" References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> <005d01cd0ced$a8c6dd80$fa549880$@noemax.com> <000501cd0d7a$991dca50$cb595ef0$@noemax.com> <003201cd0e6a$2b871e10$82955a30$@noemax.com> In-Reply-To: Date: Mon, 2 Apr 2012 16:04:14 +0300 Message-ID: <002b01cd10d1$1eaa50e0$5bfef2a0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CD10EA.43F89A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAJixsSUAcHoFyEB2DsVhgLSPJtbAXlAGB4BaXQDtQJIEPnGAnHF/xYBnJfzNZiLmyYQ Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] MUC: channel ID semantics X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 02 Apr 2012 13:04:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01CD10EA.43F89A50 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable As for arguing against it now, I think it greatly complicates the = protocol (some examples: how do you represent the parameters of all the = channels, what happens when one of the channels can't be created as = requested, =20 It is likely that several channels muxed within the same connection will = share the same target URI and have the same parameters. The delta = encoding that is proposed/TBD in the spec provides the ability to send a = sequence of AddChannel requests that would reuse the handshake of the = first logical channel. But currently there is a limitation that only the = handshake of the first logical channel can be reused. By extending this = a little bit, it will be possible to enable the reuse of handshakes for = channels with similar parameters. This would speed up the allocation of = logical channels in general. =20 DoS considerations currently blocked by one creation in flight at a = time, complicates buffer space handling, etc) and provides limited = benefits. =20 The current specification already allows multiple AddChannel requests to = be batched into a single binary message. Sending to the server a large = pre-generated sequence of separate AddChannel requests would force the = server to perform a large sequence of handshakes, gradually allocating = resources until it reaches a limit and has to refuse new logical = channels. When receiving a single AddChannel request batch with a single = handshake and the specified final number of channels required, the = server can either allocate the requested channels sequentially as in the = previous case or refuse the entire batch with minimal effort. Neither = case blocks DoS considerations. =20 Predicting more than one logical channel will be needed soon sounds like = it reduces to the halting problem to me, so I wouldn't hold my breath on = anything better than a raw guess. =20 Maybe for browsers it is seems as an unforeseeable use case. But for = example, when an intermediary needs to move a large set of logical = channels to a failover (or just another) connection, it would need to = establish a known number of logical channels fast. =20 I disagree, but it doesn't matter; at hybi we are only discussing the = wire protocol -- if someone wants to build an API that exposes all of = that, fine. We already leave it up to the client for the choice of = when/how to use MUX, so if you are building your own non-browser client = you can already do as you wish. =20 If others don=E2=80=99t support this, I don=E2=80=99t insist. =20 --=20 John A. Tamplin Software Engineer (GWT), Google =20 With best regards, Arman =20 =20 =20 ------=_NextPart_000_002C_01CD10EA.43F89A50 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

As for = arguing against it now, I think it greatly complicates the protocol = (some examples: how do you represent the parameters of all the channels, = what happens when one of the channels can't be created as = requested,

 

It is likely that several channels muxed within the same connection = will share the same target URI and have the same parameters. The delta = encoding that is proposed/TBD in the spec provides the ability to send a = sequence of AddChannel requests that would reuse the handshake of the = first logical channel. But currently there is a limitation that only the = handshake of the first logical channel can be reused. By extending this = a little bit, it will be possible to enable the reuse of handshakes for = channels with similar parameters. This would speed up the allocation of = logical channels in general.

 

DoS considerations = currently blocked by one creation in flight at a time, complicates = buffer space handling, etc) and provides limited benefits.

 

The current specification already allows multiple AddChannel requests = to be batched into a single binary message. Sending to the server a = large pre-generated sequence of separate AddChannel requests would force = the server to perform a large sequence of handshakes, gradually = allocating resources until it reaches a limit and has to refuse new = logical channels. When receiving a single AddChannel request batch with = a single handshake and the specified final number of channels required, = the server can either allocate the requested channels sequentially as in = the previous case or refuse the entire batch with minimal effort. = Neither case blocks DoS considerations.

 

Predicting more than = one logical channel will be needed soon sounds like it reduces to the = halting problem to me, so I wouldn't hold my breath on anything better = than a raw guess.

 

Maybe for browsers it is seems as an unforeseeable use case. But for = example, when an intermediary needs to move a large set of logical = channels to a failover (or just another) connection, it would need to = establish a known number of logical channels = fast.

 

I disagree, but it = doesn't matter; at hybi we are only discussing the wire protocol -- if = someone wants to build an API that exposes all of that, fine.  We = already leave it up to the client for the choice of when/how to use MUX, = so if you are building your own non-browser client you can already do as = you wish.

 

If others don=E2=80=99t support this, I don=E2=80=99t = insist.

 

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

 

With best regards,

Arman

 

 

 

------=_NextPart_000_002C_01CD10EA.43F89A50-- From internet-drafts@ietf.org Wed Apr 4 09:23:57 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 A2D8021F87FF; Wed, 4 Apr 2012 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, 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 07V0tA5ofKZZ; Wed, 4 Apr 2012 09:23:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4349821F87ED; Wed, 4 Apr 2012 09:23:57 -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.00 Message-ID: <20120404162357.13874.69320.idtracker@ietfa.amsl.com> Date: Wed, 04 Apr 2012 09:23:57 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-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: Wed, 04 Apr 2012 16:23:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTT= P Working Group of the IETF. Title : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-00.txt Pages : 32 Date : 2012-04-04 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-websocket-multiplexing-= 00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-websocket-multiplexing-0= 0.txt From tyoshino@google.com Wed Apr 4 09:30:44 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 4A1F121F8754 for ; Wed, 4 Apr 2012 09:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZFwm7CqvPvw for ; Wed, 4 Apr 2012 09:30:43 -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 9898E21F8720 for ; Wed, 4 Apr 2012 09:30:43 -0700 (PDT) Received: by yhkk25 with SMTP id k25so315532yhk.31 for ; Wed, 04 Apr 2012 09:30:43 -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 :content-type:x-system-of-record; bh=DEk/bq+ivFbmKQ3x4EYt1mTO4ZRPHekSjrU9rA4wsPM=; b=QYDm0Tn1Qmi5i9GIkFRTQ1gb25ve3mAIXXk5FdRmLsmGhQtnOwwTuidRvHKgJQIWYE CGsUxaivT++Ibxzz5zQBAOB7pUpfZCBU0JTFSSMHmsB467ExlpLs+d3kTnyQ98u2oL8l 8hfdQhUwfwASPwz8O7Z0Y5Sh5TBgrI5fSFUERXUClkQOhifO8dISCiOgxLDVs5IGmkBq Yif7i35p7TmPDITmabEXsen+VrlvEtQ0HSg1Cymag1LkK05zXJ3WRumb+5MJQYEO7V6b QI3GbGP6lcqpzhNM7z5Rhebgd6q7auMjkx2cFbcMGM5b/xai/x7FYiWr/7SQnZfDEcsV tVcw== 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 :content-type:x-system-of-record:x-gm-message-state; bh=DEk/bq+ivFbmKQ3x4EYt1mTO4ZRPHekSjrU9rA4wsPM=; b=I6HA2h+4ndO6eOPpqY3cZjWbiNXuq8BPci6KQYjD6rcH1OB8DJ7cVNGKCO3tVwPe13 voahTCgj2SM4C+UF9YQQAfD6RAB5wN9/kAyjnLXr2zkqo8OZS92SBQyV1xDrSCd52Cla MQZrGoAa581jyxIv+hNN/o6d9mJvZMuGHE8B7VWV3TzeofgiISQP2PACMoy8oE5v3IOY LABrCxnCbJAgIYMWKZVe9rOjGllQzZWdOYMr5I41cTXbwD5FpGl50YgDMY68/jgNgB6f flzc9hzuoifYv4HR45ZniKEMnkSzqd627WbQqJRueYOTkMId641bh8FZoxif0EznOSQZ jqRQ== Received: by 10.101.131.10 with SMTP id i10mr4789842ann.72.1333557043201; Wed, 04 Apr 2012 09:30:43 -0700 (PDT) Received: by 10.101.131.10 with SMTP id i10mr4789829ann.72.1333557042745; Wed, 04 Apr 2012 09:30:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Wed, 4 Apr 2012 09:30:20 -0700 (PDT) In-Reply-To: <20120404162357.13874.69320.idtracker@ietfa.amsl.com> References: <20120404162357.13874.69320.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 5 Apr 2012 01:30:20 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=001636c922cad211cb04bcdcf1f7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnQ0kMW+ttYUfevtdbpYypD1YxQ/qcDEkGiQWxVHhPN1dv5NJtFKKh9P8+BgZ+I4FVXvphhZV7bf41M74jhKJVXwqQ7FIaaJPbWA9u+g+EaK7rubCByntatCM1C7lHAZ2dx3kHq Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-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: Wed, 04 Apr 2012 16:30:44 -0000 --001636c922cad211cb04bcdcf1f7 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here's the initial version of multiplexing extension spec as HyBi WG item. Change from tamplin-03 http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03 are: - rephrasing -- physical channel -> physical connection -- logical channel -> logical channel and multiplexed connection --- logical channel: logical data channels one for exchanging control information and the others for transferring data for multiplexed connection --- multiplexed connection: virtual WebSocket connection -- multiplex control frame -> multiplex control block -- uncompressed -> identity -- some other issues pointed out by Greg's comments - clarified that channel ID is assigned by client side on issuing AddChannelRequest - added EncapsulatedControlFrame block not to confuse intermediaries - added diagrams for each multiplex opcode - put description of multiplex control blocks into subsections instead of using the list element - replaced x-google-mux with mux - sending a frame before waiting for AddChannelResponse (channel 1 is still disallowed to do so) is now allowed for multiplexed channels - added what intermediaries must do - cite RFC 6455 in AddChannelRequest/Response description - note about reuse of channel ID - fail when AddChannelRequest is pointing already active channel ID - AddChanneResponse with F=1: "Enc is ignored" -> "Enc MUST be identity" --001636c922cad211cb04bcdcf1f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Here's the initial version of multiplexing e= xtension spec as HyBi WG item.

Change from tamplin= -03=A0http://tools.ietf.org/html/draft-tamplin-hybi-google-mux-03=A0are:

- rephrasing
-- physical channel -> p= hysical connection
-- logical channel -> logical channel and m= ultiplexed connection
--- logical channel: logical data channels = one for exchanging control information and the others for transferring data= for multiplexed connection
--- multiplexed connection: virtual WebSocket connection
-- = multiplex control frame -> multiplex control block
-- uncompre= ssed -> identity
-- some other issues pointed out by Greg'= s comments
- clarified that channel ID is assigned by client side on issuing AddC= hannelRequest
- added EncapsulatedControlFrame block not to confu= se intermediaries
- added diagrams for each multiplex opcode
- put description of multiplex control blocks into subsections instead= of using the list element
- replaced x-google-mux with mux
=
- sending a frame before waiting for AddChannelResponse (channel 1 is = still disallowed to do so) is now allowed for multiplexed channels
- added what intermediaries must do
- cite RFC 6455 in AddCh= annelRequest/Response description
- note about reuse of channel I= D
- fail when AddChannelRequest is pointing already active channe= l ID
- AddChanneResponse with F=3D1: "Enc is ignored" -> "= ;Enc MUST be identity"

--001636c922cad211cb04bcdcf1f7-- From tyoshino@google.com Wed Apr 4 09:35:10 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 9E1A021F87AB for ; Wed, 4 Apr 2012 09:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNWsavAvUkVZ for ; Wed, 4 Apr 2012 09:35:10 -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 E0AF221F879F for ; Wed, 4 Apr 2012 09:35:09 -0700 (PDT) Received: by yhkk25 with SMTP id k25so319321yhk.31 for ; Wed, 04 Apr 2012 09:35:09 -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 :content-type:x-system-of-record; bh=PIEIo5b7R1+ScXJpLnKHrYKFS5pv4EWP/aOBmIGKMRI=; b=C4FpEA8/EZumiPAtOPOJSR1r7DeB2FBP6L9Mb7iB3pBPUt4Kdf8DyOV8hAQfJHzfEt +Z/LldqjPKTgE2CJ+ixmf6+RJNZ++yFVyFdMGhNSXhfVzcu5ZuVLNdM6YmclKd780BLm GaTshh/IWnFtbzcDUQTcfHPFZTa7f6lVlEElSJBPnh44waDvqncLmH0AFVpjbQ1zEW8c IVkGk90pR0DL2fRtsXpPYaJDeW9pNDHFMw3kM0iek+krXI0ncVjRPSaiieagOB065jSq cZ0Ie00Y72V13goJgxKsc/EyJWSSCL58V6VJhbQSp+JM77/GrtRZ+V/9ZZPvlkNylC0O 63FA== 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 :content-type:x-system-of-record:x-gm-message-state; bh=PIEIo5b7R1+ScXJpLnKHrYKFS5pv4EWP/aOBmIGKMRI=; b=MJw21RakRQhs9IgGTjFuigd4WJfmaSNYWvmO0rNurgjHY6DjnJvvQM+81j5cAFCJxp iHJ//XjFErt01vo8svIN5B27PXQ4XFQFFec+7aGo++X/q2baN2LBpWhr3fAWKCT77Awh +oKzaI1Osu4v6H7RqUWjoDECFaJxObK+hp1AmtlDRe7K4Furm/sGyDBz1eFtaCgZay1Q u6v9ruIPiwgfimbpgtIuqJMm1KzW9t/foDDiSsaz2LiUjmjT2ptOJVjaASPX9fKhyF7w QKatLk1ldKoeawOkVi3LJZ4F+D07oEGgNSJJVuWcGfS8OQcd8XW5Mqu3HzS1Vhm+MpqS dO4A== Received: by 10.236.181.8 with SMTP id k8mr6394772yhm.100.1333557309492; Wed, 04 Apr 2012 09:35:09 -0700 (PDT) Received: by 10.236.181.8 with SMTP id k8mr6394764yhm.100.1333557309388; Wed, 04 Apr 2012 09:35:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Wed, 4 Apr 2012 09:34:49 -0700 (PDT) In-Reply-To: <20120402093710.15576.56215.idtracker@ietfa.amsl.com> References: <20120402093710.15576.56215.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Thu, 5 Apr 2012 01:34:49 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf305e2535b6b74c04bcdd01f4 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkmfw/uKKV68ngzBeP6WEYMG8SOLvTLYgGiluS9XrI2wRLk4bBWLH8iguWFyt/moVcBtv1usDKmJzC0sJDJZ8haKJrn6Ux1+JMtaXWbtgjpqlw0gCpFqFXYcc2QJ5yF/bc4V/iu Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-perframe-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: Wed, 04 Apr 2012 16:35:10 -0000 --20cf305e2535b6b74c04bcdd01f4 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here's the initial version of compression extension spec as HyBi WG item. Changes from tyoshino-06 http://tools.ietf.org/html/draft-tyoshino-hybi-websocket-perframe-deflate-06 are: - added short text to explain why we've chosen DEFLATE as the first example - mentioned what intermediaries are allowed to do explicitly - rephrasing After discussing a bit more, I'd like to get consensus on how we componentize per-frame compression (extensions for each algorithm OR one extension with algorithm parameter). It's left TBD for this -00 version. --20cf305e2535b6b74c04bcdd01f4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Here's the initial version of com= pression extension spec as HyBi WG item.


- added short text to explain why we've chosen DEFL= ATE as the first example
- mentioned what intermediaries are allo= wed to do explicitly
- rephrasing

After = discussing a bit more, I'd like to get consensus on how we componentize= per-frame compression (extensions for each algorithm OR one extension with= algorithm parameter). It's left TBD for this -00 version.

--20cf305e2535b6b74c04bcdd01f4-- From tyoshino@google.com Thu Apr 5 02:12: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 796F121F8674 for ; Thu, 5 Apr 2012 02:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVMRy9OpMpYl for ; Thu, 5 Apr 2012 02:12:28 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3B8721F8656 for ; Thu, 5 Apr 2012 02:12:27 -0700 (PDT) Received: by ghbg16 with SMTP id g16so666638ghb.31 for ; Thu, 05 Apr 2012 02:12:27 -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:content-type :x-system-of-record; bh=TeaVrdngeI9ng2Hixkgu4xx2vfQm9UAArQjUpBKfFWM=; b=n+CgI9VU7M+t6bcxQ51KHNrzeIhhygRKR1ETdL2qb96QTW8FCP1Rr7FhDPSF9NRFdz UwdIuCv09yv2XDwMZ/fGVuvhsPkoGtHlhYfcbQ4PomHX5a9RTt/GlqLg4+ytLwoGXTcE O12NZf1FAz1nXwxdBzFvRrYMVH83+bwIUwELPiXa6fHEzRq2kTWCNLe0cFfUyRgHSqgw 7F8iQKMbhMHke/BR89s3PZZ3Pk5C5f7gwDU2+6ujurzMRhke7lRpVeg1CwfV5P9aW7wf ecUjOJnTDgOSg4i1rpeoap/9GqvSfLp/2JUcafvi/Whfig7g729GDPjYaEFwKWvyancy /VIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=TeaVrdngeI9ng2Hixkgu4xx2vfQm9UAArQjUpBKfFWM=; b=XRIWHavRM3HqlN8LCEWz35v+yJHf8gxTQVMMY8znVUXPNS+Qsy88WQneSN4yGivLnO Ks0dUfU3A8MHseO30rZ2o9KQwJflUS3O4Fc2RJu3PGwiubHdzF1O+yFDgDGRmUOvNwZi Mz44SAjNvzTuDe3BjOuKWQHNzTtlh4e1i9SCH4PrtehcXtzYLaq9gpFLkh66i1DSi0sW FePWWu52fK8kjH3LDHPOiUH/hMJSH6WDlQ3un6wYBv9/ihC5OcFUn5xccTenGr/51YY+ IBQf6VuBpODjrycdoiTJY0GgJp0eGcl69Fa7zM7bjEv1biPhJMfy4p7Plw+WVLQqOmtL rS2Q== Received: by 10.236.170.41 with SMTP id o29mr1388267yhl.83.1333617147501; Thu, 05 Apr 2012 02:12:27 -0700 (PDT) Received: by 10.236.170.41 with SMTP id o29mr1388262yhl.83.1333617147413; Thu, 05 Apr 2012 02:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Thu, 5 Apr 2012 02:12:07 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 5 Apr 2012 18:12:07 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=20cf303b38e35686a604bceaf07c X-System-Of-Record: true X-Gm-Message-State: ALoCoQkNO74LXzvKslf66U7e5ZQ0SzcDMgpouu8Zs9D9gAQd/FdWv9RRewCgUQLsBWnHIetJJ1iaZ4VXvfPssBcqYJd6NNlbdV4CdZyYJHeb5yFzZDOe9shcIe20UelPGaOAbKtdcKlL Subject: [hybi] Multiplexing: Efficiency of multiple multiplex controls in one WebSocket 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: Thu, 05 Apr 2012 09:12:28 -0000 --20cf303b38e35686a604bceaf07c Content-Type: text/plain; charset=ISO-8859-1 Hi, Current multiplexing spec allows putting multiple multiplex control blocks in one WebSocket message. Maybe this is optimization to reduce overhead (WebSocket header (2-10 octet), masking (4 octet, only C->S direction) and channel ID of 0 (1 octet)) by merging multiple multiplex controls into one message (especially for FlowControl which is exchanged frequently). Right, John? (multiplex control is not user data, so we don't have to give different masks for each of them) To allow multiple blocks, this optimization introduced one more framing mechanism (we already have two (payload, channel ID)) and 1-4 octet overhead inside. 6 octet/control overhead reduction looks beneficial. However having three non-trivial length encodings sounds not so good. Should we 1) just map one multiplex control to one message or at least 2) reuse either payload encoding or channel ID encoding for length of additional data? I don't have strong objection to current spec. I want to check if it's ok before we proceed. Thanks Takeshi --20cf303b38e35686a604bceaf07c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Current multiplexing spec allows putting = multiple multiplex control blocks in one WebSocket message. Maybe this is o= ptimization to reduce overhead (WebSocket header (2-10 octet), masking (4 o= ctet, only C->S direction) and channel ID of 0 (1 octet)) by merging mul= tiple multiplex controls into one message (especially for FlowControl which= is exchanged frequently). Right, John?

(multiplex control is not user data, so we don't ha= ve to give different masks for each of them)

To al= low multiple blocks, this optimization introduced one more framing mechanis= m (we already have two (payload, channel ID)) and 1-4 octet overhead inside= .=A06 octet/control overhead reduction looks beneficial. However having thr= ee non-trivial length encodings sounds not so good.

Should we
1) just map one multiplex control t= o one message
or at least
2) reuse either payload encod= ing or channel ID encoding for length of additional data?

I don't have strong objection to current spec. I want to che= ck if it's ok before we proceed.

Thanks
Takeshi
--20cf303b38e35686a604bceaf07c-- From jat@google.com Thu Apr 5 02:21:20 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA0021F86A2 for ; Thu, 5 Apr 2012 02:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQq2oydd1nNq for ; Thu, 5 Apr 2012 02:21:18 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9641F21F8656 for ; Thu, 5 Apr 2012 02:21:18 -0700 (PDT) Received: by qaea16 with SMTP id a16so774011qae.10 for ; Thu, 05 Apr 2012 02:21: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=/Rs1ggK5hBu1Blsw/mLseveLngPVy/w8xTps6ugpeFo=; b=E/7cL2dYvpsowgVLycmew90kXTNe5Z1cbEVl2V91F/alfLtj63Y+OAi18kDNH5BCXK I+p8xz1thA/wy4or1wX6u7mg26MoXiW14MfAFayoPpl+i4zzgK0JaTOntDEDqT/afYkA lB2aCA0aFhINjVhpoAJLxAEUlNYlwMunQcxMpe2doA9EMDHCGwWgQeqbjSnjZxi0se59 iIVxAuZ1uDBGJmP3oi1vv/oJGeqnS3Xjhg0fDLTpk9fZBOWA6X8SSE7cbcd31qVA5BFh IEMYrC/kTutY9SqMJI6QbT2d5mbd2coJbcBS4YC6UjHQ5iPDygX02hoyvqKKIK1xG2ym PWHQ== 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=/Rs1ggK5hBu1Blsw/mLseveLngPVy/w8xTps6ugpeFo=; b=gsAONTCb8oOWSYHNiPyweABwauHBBtAuJ2mA7coKZ1ZRz65L5E8wmJMiuC68LSe1s2 3fTzqfsF8Zvj/yWOOD3RF5YVBiP7q6LQC1dJkLt6ZygcWjF8qCrcWpETblsVauAffKdj Dm0BTz4LSR+R4rbuycGpfKecKBookfXEQobz8ZMhKZD4/r1FLt7UDfY1Qhqd3c3t6y0L yVjv63chLSiO9sIxJ7urhd5YiW0kii2NjEsmg/MpqyttlJr+Ps3pqvnK+UDZ3GRHfxrv 5c9++f2iAxKwvLYWRmxBN+LZh0+bf3EzkzgVL5+8PLetVT1qMUBAEUta4VP0riLaVAt8 d3YA== Received: by 10.224.176.208 with SMTP id bf16mr2968571qab.48.1333617678149; Thu, 05 Apr 2012 02:21:18 -0700 (PDT) Received: by 10.224.176.208 with SMTP id bf16mr2968562qab.48.1333617678050; Thu, 05 Apr 2012 02:21:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.235.148 with HTTP; Thu, 5 Apr 2012 02:20:57 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Thu, 5 Apr 2012 05:20:57 -0400 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf30334e8bf7666b04bceb0f4a X-System-Of-Record: true X-Gm-Message-State: ALoCoQkD0SgTkdGlKQj/bFn6sP3+70IKM77Psg6Ue5W5wA6V7z4yQvCfUHuJErYbffo8tubRSUsV78cqn+3Ryc5JhW6/j92gqEyU0noMJrs2mkkpY+Y/f1SQhUxE7BxpY19ppj99JO9X Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Efficiency of multiple multiplex controls in one WebSocket 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: Thu, 05 Apr 2012 09:21:20 -0000 --20cf30334e8bf7666b04bceb0f4a Content-Type: text/plain; charset=UTF-8 On Thu, Apr 5, 2012 at 5:12 AM, Takeshi Yoshino wrote: > Current multiplexing spec allows putting multiple multiplex control blocks > in one WebSocket message. Maybe this is optimization to reduce overhead > (WebSocket header (2-10 octet), masking (4 octet, only C->S direction) and > channel ID of 0 (1 octet)) by merging multiple multiplex controls into one > message (especially for FlowControl which is exchanged frequently). Right, > John? > Yes, the idea was that flow control messages, in particular, will be very frequent so we need to aggregate them to have acceptable efficiency. -- John A. Tamplin Software Engineer (GWT), Google --20cf30334e8bf7666b04bceb0f4a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 5, 2012 at 5:12 AM, Takeshi Yoshino = <tyoshino@googl= e.com> wrote:
Current multiplexing spec allows putting multiple multiplex control bl= ocks in one WebSocket message. Maybe this is optimization to reduce overhea= d (WebSocket header (2-10 octet), masking (4 octet, only C->S direction)= and channel ID of 0 (1 octet)) by merging multiple multiplex controls into= one message (especially for FlowControl which is exchanged frequently). Ri= ght, John?

Yes, the idea was that flow control messag= es, in particular, will be very frequent so we need to aggregate them to ha= ve acceptable efficiency.

--
John A. Tamplin<= br> Software Engineer (GWT), Google
--20cf30334e8bf7666b04bceb0f4a-- From gregw@intalio.com Wed Apr 11 16:28: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 225F511E8108 for ; Wed, 11 Apr 2012 16:28:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OBweFzyGg-7D for ; Wed, 11 Apr 2012 16:28:38 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id 6977811E809D for ; Wed, 11 Apr 2012 16:28:38 -0700 (PDT) Received: by qafi31 with SMTP id i31so4020851qaf.15 for ; Wed, 11 Apr 2012 16:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=WWxFGFWb3n+WOq9pRVB/BAf670NKc0kpTvX5zs20poU=; b=XBIjKArCfGdsHWu5D8n/Cza/QOCjh66hEb+Y4u82BedKbjQEqEQIxMyVjKc7TjNuG1 4cVauIsY2czE1SAvBm2x6Vi0wEE1kAg4pNShrxxExxIgoDYTQVtmaB4iRlDhLUVPQLG/ fKBpg3zlhKBeBEfzLWqGaf/3VxuCVPaMbJ9leabyz/IyqA2wGtPpUc5vY8tA+7ZYD/A8 5ZUvGOr8xZx5qLv4Ut3SAWzYhmJxrSEM+bvrC6UdjtuJssfnZV2Imda66161INXBYQjS sZMTDA1PKJtsVMnesqslGoNHVxlA2U8g8FgTHM/GBgou60bh/UftyMPruWwdUUMaXLC9 bIZw== MIME-Version: 1.0 Received: by 10.224.214.66 with SMTP id gz2mr1176068qab.22.1334186917709; Wed, 11 Apr 2012 16:28:37 -0700 (PDT) Received: by 10.229.249.18 with HTTP; Wed, 11 Apr 2012 16:28:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 12 Apr 2012 09:28:37 +1000 Message-ID: From: Greg Wilkins To: John Tamplin Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkBtbNUG1pvV9W4eH9oqqMShU+hQSVrd31tXNs1BqUOQSDyAdGUr8qFop2NiB+ZKLloshNt Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Efficiency of multiple multiplex controls in one WebSocket 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: Wed, 11 Apr 2012 23:28:39 -0000 Note that I think the nature of sending flow control messages is that there will be little opportunity to aggregate them into a single message while sending. Typically a flow control message will be sent as some channel specific buffer it consumed below some threshhold. It may then be more work (and latency) to attempt to build a queue of such control messages in order to be able to send them as a single message - it is probably simpler to just immediately frame them and add them to the byte buffer that is being flushed. So my hunch is that we will mostly end up sending a single control frame per message. However, I don't see too much complexity or problems in allowing them to be batched into a single message, so I think it is low cost for a possible low gain. But to be really clear, the current draft says: Binary frames with a channel ID of 0 contain zero or more multiplex control blocks in "Payload data". This is written in terms of frames rather than messages. Does this mean we can assume that a channel ID 0 frame will never be fragmented, even by intermediaries? It would certainly make it easier to handle if they were restricted to frames, as control blocks would not be split over multiple frames - but I'm not sure we can guarantee this? what if we had 100,000 flow control ops in a single frame - would intermediaries be prevented from fragmenting that? If they did fragment, they would have to put channelIDs into the fragments, but would we also insist that they break the frames on control block boundaries? cheers On 5 April 2012 19:20, John Tamplin wrote: > On Thu, Apr 5, 2012 at 5:12 AM, Takeshi Yoshino wrote: >> >> Current multiplexing spec allows putting multiple multiplex control blocks >> in one WebSocket message. Maybe this is optimization to reduce overhead >> (WebSocket header (2-10 octet), masking (4 octet, only C->S direction) and >> channel ID of 0 (1 octet)) by merging multiple multiplex controls into one >> message (especially for FlowControl which is exchanged frequently). Right, >> John? > > > Yes, the idea was that flow control messages, in particular, will be very > frequent so we need to aggregate them to have acceptable efficiency. > > -- > John A. Tamplin > Software Engineer (GWT), Google > > _______________________________________________ > hybi mailing list > hybi@ietf.org > https://www.ietf.org/mailman/listinfo/hybi > From ibc@aliax.net Thu Apr 12 01:59:48 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8039021F8683 for ; Thu, 12 Apr 2012 01:59:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.614 X-Spam-Level: X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBZlZNEsZ-xw for ; Thu, 12 Apr 2012 01:59:47 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA13721F8682 for ; Thu, 12 Apr 2012 01:59:47 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1421922vbb.31 for ; Thu, 12 Apr 2012 01:59:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :content-transfer-encoding:x-gm-message-state; bh=OqBvC3sEG1LXemjWU/cLE5V+XDt0bK3usMfPQbdaYMs=; b=Mjxivk1ECxkJKV4M1jG05dF0zPZdgOPWR89D8z9OxQZhb26YTpG9ys7UN7qKdQjIyh aFQYGflwkjpuz9Kbau6RIjMdjLOWuoPTb9EpsutDMTwxKOqWPSmY1nUytxROfg0P9A9a e2zdjI569I98/vuy81DkBMNM1X5SieyJwGZ+KZFswUz1dTVBAheagHhMDpPo9nQgaLFB vl1z4pp+eH3p+l6GLA+LYx59IqoLjuFnbDauTDMrBkbS9LaxRP+sVJFbXAyv8XnVkcIm 6O8xSy2xBnLCdnZPB/YJuxCp0qlFFTeNYbEQC1NqdN5rqixQ5r1AMiUqiR+j+8qmit6A BRhQ== Received: by 10.52.91.72 with SMTP id cc8mr800616vdb.17.1334221187251; Thu, 12 Apr 2012 01:59:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 12 Apr 2012 01:59:26 -0700 (PDT) From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 12 Apr 2012 10:59:26 +0200 Message-ID: To: hybi@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQl6JwmYTAbD/5rjZgqGVDfvPY50+W4uYSefgKGLpnQwf0meKUJ6CB+rLreNiCnUJDZ1wBXi Subject: [hybi] [OT] Does HTML5 "mandate" WebSocket in HTML5 browsers? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 12 Apr 2012 08:59:48 -0000 Hi folks, a simple question: Is WebSocket "designed" or "mandated" by W3C for HTML5 capable browsers? This is, could I reference http://dev.w3.org/html5/websockets/ as a specification that "defines" WebSocket for HTML5? Thanks a lot. --=20 I=C3=B1aki Baz Castillo From tyoshino@google.com Thu Apr 12 02:35: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 DCAAC21F8670 for ; Thu, 12 Apr 2012 02:35:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTXrJAqM+tKZ for ; Thu, 12 Apr 2012 02:35:05 -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 B138721F866C for ; Thu, 12 Apr 2012 02:35:04 -0700 (PDT) Received: by yenm5 with SMTP id m5so1057882yen.31 for ; Thu, 12 Apr 2012 02:35:04 -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=FwR0cXQBfP2I1j3PomJOs5fQ8kWFWlze/Ge1JhT7m2I=; b=QdIDMoAWxLN0A3sH/J+qDckCLVqaVX9USXUQ/W4tn9ga91u6AAxxIbLaY4TJrAZ7vq KZ9WW5PkS6xhf4T9w/CytnD+yQP00U7s3I/TnOnlL146x8VZSTNeD6SOD31fpCKQZuAH 4bXH8z1Bxb76uI6AqDCqq58pm1tGxQ24VyUm+X9+nt5Wbr6tJ0nLKVpZAj4s7XS8CUvE b6KpTRDWAknKLpNbaPnf4VVvZjHAlJptivPmG5Qxu8yI9Zy0nvgtlHrK6CgLMIConnZ4 jr7Aky9FwcQxFH3FpJ47rYwEdVMab6kWBTiubBzjpt4eazoqgBUQkGwHnhupFX+9Qm4x YbqA== 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=FwR0cXQBfP2I1j3PomJOs5fQ8kWFWlze/Ge1JhT7m2I=; b=KIghNxzhR9ipdcbTNwn80Gwl+5zde6787MrvP3Be73N4JcbgPmQRWi2BEdc47NcZeD S94ND687HCai34LsoEfqT3OLSyRSlXawrc3ImO21aiA4uGNN1yY1x7OdghNymyMCtxQ8 z7KWuWWpWzEPwwcxVk/VZWWFP+ev9Xdu2pnwrl52rRmAPWu3zAA4jt0ofDEI+q4BhU+N Rw3FAOukcfL2mab68xqi+GFJ2aAkFOcfietVueZIWiuxOYsA69ABZOiZ3H1nASHHrBgV pXPZLHP4H6+5hJS7HUxMXrsQB7Q8hlWuNeOmB13s6F8FXuY5x/6fl+MEJjeVWjV8O72b rLeQ== Received: by 10.236.76.41 with SMTP id a29mr1307805yhe.117.1334223304122; Thu, 12 Apr 2012 02:35:04 -0700 (PDT) Received: by 10.236.76.41 with SMTP id a29mr1307797yhe.117.1334223304043; Thu, 12 Apr 2012 02:35:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Thu, 12 Apr 2012 02:34:43 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 12 Apr 2012 18:34:43 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=20cf303b40e316aab504bd781274 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlWEsmFmow2H7SyJ8NayYaduIysL+KwZQZfFe6aLfIlP2Y0/WX39G/dLyEpAJ3pi9oDIUl9G8llcmjYscTAcOcNwdMWHVI7CO2sRu3qL3JjsQxsNMEp5WDgeIK4CgciIPIo5tLw Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Efficiency of multiple multiplex controls in one WebSocket 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: Thu, 12 Apr 2012 09:35:06 -0000 --20cf303b40e316aab504bd781274 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Apr 12, 2012 at 08:28, Greg Wilkins wrote: > So my hunch is that we will mostly end up sending a single control > frame per message. However, I don't see too much complexity or > problems in allowing them to be batched into a single message, so I > think it is low cost for a possible low gain. > Thanks for your opinion. I think we should avoid the 1 extra octet overhead if it's estimated to be really rare that we get a chance to merge multiple FlowControls into one message. > But to be really clear, the current draft says: > > Binary frames with a channel ID of 0 contain zero or more multiplex > control blocks in "Payload data". > > This is written in terms of frames rather than messages. Does this > Good point. I left this part unclear by mistake. I didn't intend to mean that channel 0 messages MUST NOT be fragmented at a point in the middle of a control block by this text. This point is open for discussion. > mean we can assume that a channel ID 0 frame will never be fragmented, > even by intermediaries? It would certainly make it easier to > handle if they were restricted to frames, as control blocks would not > be split over multiple frames - but I'm not sure we can guarantee > this? what if we had 100,000 flow control ops in a single frame - would intermediaries be prevented from fragmenting that? If they > did fragment, they would have to put channelIDs into the fragments, > but would we also insist that they break the frames on control block > boundaries? > I thought it's fine that a control block may be split into two or more fragments. As far as control blocks are sent in-order (relative to both other control blocks and data of multiplexed channels), it's not a problem. I don't see significant advantage from neither of them. Prohibition of fragmentation might make message processing easier as you said above, but adding constraints to care should be avoided unless we really need basically. (Maybe this is Patrick's original suggestion which made control frame unfragmentable and limited its length up to 125 http://trac.tools.ietf.org/wg/hybi/trac/ticket/19#comment:1) Rather I think we should add a text to say that fragments of a channel ID 0 message MUST NOT be interleaved with other channels. Such operation makes it unclear at which point (of stream of the objective channel) the operation should be applied. --20cf303b40e316aab504bd781274 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 12, 2012 at 08:28, Greg Wilkins <gr= egw@intalio.com> wrote:
<snip>
So my hunch is that we will mostly end up sending a single control
frame per message. However, I don't see too much complexity or
problems in allowing them to be batched into a single message, so I
think it is low cost for a possible low gain.

Thanks for your opinion.

I think we should = avoid the 1 extra octet overhead if it's estimated to be really rare th= at we get a chance to merge multiple FlowControls into one message.
=A0
But to be really clear, the current draft says:

=A0 Binary frames with a channel ID of 0 contain zero or more multiplex =A0 control blocks in "Payload data".

This is written in terms of frames rather than messages. =A0 =A0Does this

Good point. I left this part unclear by = mistake.

I didn't intend to mean that channel = 0 messages MUST NOT be fragmented at a point in the middle of a control blo= ck by this text. This point is open for discussion.
=A0
mean we can assume that a channel ID 0 frame will never be fragmented,
even by intermediaries? =A0 =A0 It would certainly make it easier to
handle if they were restricted to frames, as control blocks would not
be split over multiple frames - but I'm not sure we can guarantee
this? =A0what if we had 100,000 flow control ops in a single frame -
would intermediaries be prevented from fragmenting that? =A0 =A0If they
did fragment, they would have to put channelIDs into the fragments,
but would we also insist that they break the frames on control block
boundaries?

I thought it's fine tha= t a control block may be split into two or more fragments. As far as contro= l blocks are sent in-order (relative to both other control blocks and data = of multiplexed channels), it's not a problem.

I don't see significant advantage from neither of t= hem. Prohibition of fragmentation might make message processing easier as y= ou said above, but adding constraints to care should be avoided unless we r= eally need=A0basically.
(Maybe this is Patrick's original suggestion which made contr= ol frame unfragmentable and limited its length up to 125=A0http://trac.tools.i= etf.org/wg/hybi/trac/ticket/19#comment:1)

Rather I think we should= add a text to say that fragments of a channel ID 0 message MUST NOT be int= erleaved with other channels. Such operation makes it unclear at which poin= t (of stream of the objective channel) the operation should be applied.

--20cf303b40e316aab504bd781274-- From julian.reschke@gmx.de Thu Apr 12 03:11: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 26F9321F8661 for ; Thu, 12 Apr 2012 03:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.105 X-Spam-Level: X-Spam-Status: No, score=-103.105 tagged_above=-999 required=5 tests=[AWL=-0.806, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tsJNJ4sosiF7 for ; Thu, 12 Apr 2012 03:11:55 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 97A0121F865C for ; Thu, 12 Apr 2012 03:11:54 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 10:11:50 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp029) with SMTP; 12 Apr 2012 12:11:50 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX18rllRS/Ykr+qBuh5hyZvtohmw3+whxCxtxElc4Q2 P/vaDgralDnR/V Message-ID: <4F86AA67.6080905@gmx.de> Date: Thu, 12 Apr 2012 12:11:51 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] [OT] Does HTML5 "mandate" WebSocket in HTML5 browsers? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 12 Apr 2012 10:11:56 -0000 On 2012-04-12 10:59, Iñaki Baz Castillo wrote: > Hi folks, a simple question: Is WebSocket "designed" or "mandated" by > W3C for HTML5 capable browsers? > > This is, could I reference http://dev.w3.org/html5/websockets/ as a > specification that "defines" WebSocket for HTML5? > > Thanks a lot. It defines the WebSocket API for browsers. It has nothing specific to do with HTML5. Maybe you can explain what exactly you're trying to do? Best regards, Julian From ibc@aliax.net Thu Apr 12 03:23:25 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 749C421F8647 for ; Thu, 12 Apr 2012 03:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.616 X-Spam-Level: X-Spam-Status: No, score=-2.616 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DdZ6l0wxKBw0 for ; Thu, 12 Apr 2012 03:23:25 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id DFAE621F861D for ; Thu, 12 Apr 2012 03:23:24 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1473229vcb.31 for ; Thu, 12 Apr 2012 03:23:24 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=p5M+fY1M5Xvu6kfwSlMESDbZl5QN57MF7SFI12fmEMc=; b=MA8D5UTMonLmaqz+p5EXsMQK1EKVIj2W/YsdtJV+6YxxTpaOJDylwvU9TXnZgCVShV G9lyV3vJr0EIDHAWmYl4w5Wr+PhuqFtnyutwrh4wMduXq/2U0CjfD4pYxfRD+Pvqqmmz ZLB+AnDD71M7lHq1oqzOhH2GRtga+5PYcO6lqTE/ZXQnqyS1HV9y70L+AWNH9nLJGPue k11nAQSSSuDVbKUDVcpb52S8DSwwktUGyc10JEFqu0o9wvgw8MbkxgQ6RhILbtA3zn9L eYgL1JBkldMS/PUszob0LXWxeQLjeOvtYbhi/C+Vpdhr0fyk0S+iMJiB1lwmyJ8+JA4Q KWvA== Received: by 10.220.140.196 with SMTP id j4mr1094740vcu.22.1334226204387; Thu, 12 Apr 2012 03:23:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 12 Apr 2012 03:23:04 -0700 (PDT) In-Reply-To: <4F86AA67.6080905@gmx.de> References: <4F86AA67.6080905@gmx.de> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 12 Apr 2012 12:23:04 +0200 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkw7w0dLzSHEleQIJcxSo+JeQPJhP/9I4NcCNfJfDVNjyU/AQ1rpNxjgGjVXX8BfUyjq31d Cc: hybi@ietf.org Subject: Re: [hybi] [OT] Does HTML5 "mandate" WebSocket in HTML5 browsers? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 12 Apr 2012 10:23:25 -0000 2012/4/12 Julian Reschke : > On 2012-04-12 10:59, I=C3=B1aki Baz Castillo wrote: >> >> Hi folks, a simple question: Is WebSocket "designed" or "mandated" by >> W3C for HTML5 capable browsers? >> >> This is, could I reference http://dev.w3.org/html5/websockets/ as a >> specification that "defines" WebSocket for HTML5? >> >> Thanks a lot. > > > It defines the WebSocket API for browsers. It has nothing specific to do > with HTML5. Ok, I just wanted to know if "WebSocket API for browsers" is within the whole "HTML5" :) > Maybe you can explain what exactly you're trying to do? Adding a reference to a IETF draft. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From julian.reschke@gmx.de Thu Apr 12 03:29: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 0DAE521F84F8 for ; Thu, 12 Apr 2012 03:29:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.99 X-Spam-Level: X-Spam-Status: No, score=-102.99 tagged_above=-999 required=5 tests=[AWL=-0.691, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pwH8FHQS2QS for ; Thu, 12 Apr 2012 03:29:01 -0700 (PDT) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 2899F21F84EE for ; Thu, 12 Apr 2012 03:29:00 -0700 (PDT) Received: (qmail invoked by alias); 12 Apr 2012 10:28:59 -0000 Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp036) with SMTP; 12 Apr 2012 12:28:59 +0200 X-Authenticated: #1915285 X-Provags-ID: V01U2FsdGVkX1+T7/Jzhg2TcwHOlU1FhSnGPaLbBaUKN/rhaUpcZ7 JSmtZL4gCW6bln Message-ID: <4F86AE67.6080808@gmx.de> Date: Thu, 12 Apr 2012 12:28:55 +0200 From: Julian Reschke User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= References: <4F86AA67.6080905@gmx.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Cc: hybi@ietf.org Subject: Re: [hybi] [OT] Does HTML5 "mandate" WebSocket in HTML5 browsers? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 12 Apr 2012 10:29:02 -0000 On 2012-04-12 12:23, Iñaki Baz Castillo wrote: > 2012/4/12 Julian Reschke: >> On 2012-04-12 10:59, Iñaki Baz Castillo wrote: >>> >>> Hi folks, a simple question: Is WebSocket "designed" or "mandated" by >>> W3C for HTML5 capable browsers? >>> >>> This is, could I reference http://dev.w3.org/html5/websockets/ as a >>> specification that "defines" WebSocket for HTML5? >>> >>> Thanks a lot. >> >> >> It defines the WebSocket API for browsers. It has nothing specific to do >> with HTML5. > > Ok, I just wanted to know if "WebSocket API for browsers" is within > the whole "HTML5" :) It depends on whom you ask, and whether you believe in precise technical terminology or just marketing speak :-). In the former case, no. >> Maybe you can explain what exactly you're trying to do? > > Adding a reference to a IETF draft. Well, a reference to what? Best regards, Julian From ibc@aliax.net Thu Apr 12 03:46: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 CDEA321F8653 for ; Thu, 12 Apr 2012 03:46:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aO3vX1lf5T8N for ; Thu, 12 Apr 2012 03:46:49 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFE9221F864F for ; Thu, 12 Apr 2012 03:46:48 -0700 (PDT) Received: by vcbfk13 with SMTP id fk13so1486419vcb.31 for ; Thu, 12 Apr 2012 03:46:48 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=LJntooXhTFXkZ/LUFDOO6d807jbRRwsRO3S6mE3RXdo=; b=WVe8zhpEPyXBr2Wlk2IPpoWy47EKGUepkY25cExtR3aXTyH+wgMfh0BcZg8oOy68tK VbBlvAcgowctOz3RbXoTTUmOHOg5LxPqSEZOm6V9pvGV52fD/rheCDdKxTGV+MiYJBnR SXItDvo91pYpIwgCMxG7GlCZ2sbBcPNgkIFJEVgMay8wF+opTs9vpSq07hhy29/0ubd5 2vXrLjxGJnrdDwZCnRNJsu1U2eSOWcj51DIlZUxccq050dfMYgP3ppbpgxgGKBb5q8Co CNI/PHUTEqbt4seN/hon2K62257x3qGM4guS6l5WNmWoSWoZ9PCZcE+eluC2/EmpPGIq zd5w== Received: by 10.52.15.233 with SMTP id a9mr909315vdd.34.1334227608448; Thu, 12 Apr 2012 03:46:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.170.165 with HTTP; Thu, 12 Apr 2012 03:46:28 -0700 (PDT) In-Reply-To: <4F86AE67.6080808@gmx.de> References: <4F86AA67.6080905@gmx.de> <4F86AE67.6080808@gmx.de> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 12 Apr 2012 12:46:28 +0200 Message-ID: To: Julian Reschke Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnUQAavYt/vrKr1gdUACS7JAJvsCRWy2w4jknAW2DI1URVDiW0pWnutzawueDzC4i+TT9j7 Cc: hybi@ietf.org Subject: Re: [hybi] [OT] Does HTML5 "mandate" WebSocket in HTML5 browsers? X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 12 Apr 2012 10:46:49 -0000 2012/4/12 Julian Reschke : >> Adding a reference to a IETF draft. > > Well, a reference to what? Just an informative reference about the "expected" adoption of the WebSocket protocol (given that modern web browsers will or already implement it). I just wanted to know if all this stuff is within the whole HTML5 ecosystem or not. Thanks a lot. --=20 I=C3=B1aki Baz Castillo From hapner.mark@huawei.com Thu Apr 12 11:27: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 4BB0921F84EF for ; Thu, 12 Apr 2012 11:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du0168YJ9wUM for ; Thu, 12 Apr 2012 11:27:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 4E08621F84EE for ; Thu, 12 Apr 2012 11:27:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AEW12627; Thu, 12 Apr 2012 14:27:29 -0400 (EDT) Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 12 Apr 2012 11:26:02 -0700 Received: from DFWEML505-MBX.china.huawei.com ([10.124.31.100]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0323.003; Thu, 12 Apr 2012 11:25:50 -0700 From: Hapner mark To: "hybi@ietf.org" Thread-Topic: [HyBi] MBWS Subprotocol Thread-Index: AQHNDKekW2KuKoBfG0iiuCMT/k96KpaXmIUZ Date: Thu, 12 Apr 2012 18:25:50 +0000 Message-ID: <92457F4F764A5C4785FCDBDDDD76477A33187469@dfweml505-mbx> References: <92457F4F764A5C4785FCDBDDDD76477A33184B5D@dfweml505-mbx> In-Reply-To: <92457F4F764A5C4785FCDBDDDD76477A33184B5D@dfweml505-mbx> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.9.109] Content-Type: multipart/alternative; boundary="_000_92457F4F764A5C4785FCDBDDDD76477A33187469dfweml505mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Sohrab modi , "smalladi@ebay.com" , "csuconic@redhat.com" , "tonyng@ebay.com" , Gaoyongguang Subject: Re: [hybi] [HyBi] MBWS Subprotocol X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Apr 2012 18:27:30 -0000 --_000_92457F4F764A5C4785FCDBDDDD76477A33187469dfweml505mbx_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I haven't seen any feedback from the WG on the MBWS Subprotocol as yet. If = anyone has any concerns or comments about its design or function please let= us know. A registration request for the two Subprotocol names it defines h= as been submitted to IANA. -- Mark ________________________________ From: Hapner mark Sent: Tuesday, March 27, 2012 10:57 PM To: hybi@ietf.org Cc: csuconic@redhat.com; tonyng@ebay.com; smalladi@ebay.com; Gaoyongguang; = smodi@huawei.com Subject: [HyBi] MBWS Subprotocol This version of the Message Broker Web Socket Subprotocols (MBWS and MBLWS)= ) has been revised to conform to RFC 6455's definition of a WebSocket Subpr= otocol. The purpose of this subprotocol remains the same - to add the metad= ata required to support a message queueing intermediary that allows clients= to communicate via a shared set of message addresses without having to dir= ectly expose themselves to; or, know about the other clients of the interme= diary. Clebert and I would be very interested in HyBi's feedback on this draft. If= there are no significant issues, we plan to register the two subprotocols = it defines with IANA. A binary binding is provided that allows binary WebSocket messages to trans= mit both binary and text subprotocol messages. A text binding for text WebS= ocket messages is defined for those applications that prefer to transmit on= ly text. http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.txt http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.pdf http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.xml --_000_92457F4F764A5C4785FCDBDDDD76477A33187469dfweml505mbx_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I haven't seen any feedback from the WG on the MBWS Subprotocol as yet. If = anyone has any concerns or comments about its design or function please let= us know. A registration request for the two Subprotocol names it defines h= as been submitted to IANA.

-- Mark
From: Hapner mark
Sent: Tuesday, March 27, 2012 10:57 PM
To: hybi@ietf.org
Cc: csuconic@redhat.com; tonyng@ebay.com; smalladi@ebay.com; Gaoyong= guang; smodi@huawei.com
Subject: [HyBi] MBWS Subprotocol


This version of the Message Broker Web Socket Subprotocols (MBWS and M= BLWS)) has been revised to conform to RFC 6455's definition of a WebSocket = Subprotocol. The purpose of this subprotocol remains the same - to add the = metadata required to support a message queueing intermediary that allows clients to communicate via a shared set = of message addresses without having to directly expose themselves to; or, k= now about the other clients of the intermediary.

Clebert and I would be very interested in HyBi's feedback on this draf= t. If there are no significant issues, we plan to register the two subproto= cols it defines with IANA. 

A binary binding is provided that allows binary WebSocket messages to = transmit both binary and text subprotocol messages. A text binding for text= WebSocket messages is defined for those applications that prefer to transm= it only text.

http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.= txt
http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.= pdf
http://www.ietf.org/id/draft-hapner-hybi-messagebroker-subprotocol-01.= xml
--_000_92457F4F764A5C4785FCDBDDDD76477A33187469dfweml505mbx_-- From gregw@intalio.com Thu Apr 12 16:00: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 ACF3D21F8751 for ; Thu, 12 Apr 2012 16:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DM9btt14A0Cc for ; Thu, 12 Apr 2012 16:00:52 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 9088121F8753 for ; Thu, 12 Apr 2012 16:00:52 -0700 (PDT) Received: by qaea16 with SMTP id a16so1871746qae.10 for ; Thu, 12 Apr 2012 16:00:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=s+e/oTa9PO88Vd2DT7ufvruWg4RUjv7CXFCSzGbmEEs=; b=c/X/S82sSB8HoMd4xZVV2wZsqqyKNjHNTrWNTNufqntpuCXz/bpsSipToUpCxar4fI bmdOH4RlWz/KCMPge5u4klxQ00v197f5UM/SelCYa1CdqKsNWGV6yODkk96ibBMZ+JV/ RcEJn0bxj0LgFc45RMB4It6sFahwZcshts5G4YHfXGSLGK/mNUb8uQIIQSlMUHdFKVUZ uf3EN1SWvuZg8lRzD3zCAk1zSWIDRNCOBjyHYTW475Vub5oLU2qI/Qbrh+FwT8wB9NYp Tc0z0n6CvBl9mLxHRbNwNVj+mA8reArrHCAMK5wznln/fPlBGr8j3ooNviHn/8OYPAbj u3MA== MIME-Version: 1.0 Received: by 10.224.202.66 with SMTP id fd2mr622291qab.9.1334271652100; Thu, 12 Apr 2012 16:00:52 -0700 (PDT) Received: by 10.229.249.18 with HTTP; Thu, 12 Apr 2012 16:00:52 -0700 (PDT) In-Reply-To: References: Date: Fri, 13 Apr 2012 09:00:52 +1000 Message-ID: From: Greg Wilkins To: Takeshi Yoshino Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQk8KmjsaV0uHbJtLLAGBORaXb7xky4dZhEQpoIhYe21AiMzdp23Lbl3V/hMaK/BM+oDY76g Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Efficiency of multiple multiplex controls in one WebSocket 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: Thu, 12 Apr 2012 23:00:53 -0000 On 12 April 2012 19:34, Takeshi Yoshino wrote: > > I thought it's fine that a control block may be split into two or more > fragments. As far as control blocks are sent in-order (relative to both > other control blocks and data of multiplexed channels), it's not a proble= m. > > I don't see significant advantage from neither of them. Prohibition of > fragmentation might make message processing easier as you said above, but > adding constraints to care should be avoided unless we really > need=A0basically. > (Maybe this is Patrick's original suggestion which made control frame > unfragmentable and limited its length up to > 125=A0http://trac.tools.ietf.org/wg/hybi/trac/ticket/19#comment:1) > > Rather I think we should add a text to say that fragments of a channel ID= 0 > message MUST NOT be interleaved with other channels. Such operation makes= it > unclear at which point (of stream of the objective channel) the operation > should be applied. Takeshi, I think to constrain channel 0 fragments to be not interleaved is just as hard (if not harder) than saying they can't be fragmented and it still represents adding a constraint either way. So I believe we should strive to allow entirely normal fragmentation of channel 0 messages, thus avoiding any constraint. If we have to have a constraint, then I'd prefer no fragmentation or fragmentation on block boundaries rather than a restriction on interleaving. The problem with normal fragmentation of channel0, is as you say, to determine when an operation should be applied. Is there a problem with saying that the operations within a channel 0 message will only be applied once the entire message is received? As I've said previously, I think it highly unlikely that we will have many blocks in the same message, so I think fragmentation is unlikely to occur..... but if it did, are there any bad consequences of delaying processing? I note that the current draft says in 7.5 Multiplex control blocks are sent in data frames, so they can be fragmented. Processing of a multiplex control block MAY be done once the block is received completely without waiting for the whole binary message is received (and becomes available after decoding if any). Which say they MAY be processed as they are completely received, suggesting that there is no MUST about processing them immediately - I certainly can't think of a reason. So perhaps this is the most flexible way - obviously blocks MUST be processed when the entire message is received, but MAY be processed as each frame is decoded. I can't see any problems with early processing either. I guess my only concern is that it would allow different behaviour which might allow for future complications, so I'd be OK with enforcing either early or later processing of the blocks. Note also that 7.5 only applies to encapsulated control frames - so perhaps this text needs to be applied to all block types? cheers From tyoshino@google.com Thu Apr 12 22:28:32 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 3835021F863F for ; Thu, 12 Apr 2012 22:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-QUZcjyL3Sn for ; Thu, 12 Apr 2012 22:28:31 -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 5794B21F863E for ; Thu, 12 Apr 2012 22:28:31 -0700 (PDT) Received: by yhkk25 with SMTP id k25so1645175yhk.31 for ; Thu, 12 Apr 2012 22:28:30 -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=FHTCZrsYmqcWASE8+Z7ILzZDgcRFgQM6oOBFfw/Luds=; b=GNw0yFmyfrzLCegRMLdMEAm/3cnqF3ke0F97jqtzZkpQj/NWwrd2K649+M76UVNlAM bg41qgziINmgemHnRCG62p/GplyI13v69/z31Q5ZnhHES+gT4aInNHgmKQseVsTFzPnZ mHVVFvnOgr+il756qZGqig4Erzqq5R8yHS2wrDzV6GxfLcg8cQaFI2MRx0aFdPVzTguQ thWyf56OtoNbUDL3pwi09dvUojIqCMgCV9M7awHINClRWsXewBTkWUcjppUM9+9Vh482 7QQlQE+cUmEGgH83rDamO4muGkL7WivhepHpzalSn9hQvMtNSMADUutJfJAfSTi9q4L4 CJ3w== 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=FHTCZrsYmqcWASE8+Z7ILzZDgcRFgQM6oOBFfw/Luds=; b=IMcfrKgDStpbsnVWhrZcNPcQ+A//0d+Gtgyq+YQ4nmdm7JJ0KJKw4ZcchAahcj/NtG 8NbEfv6BTNjHv/OSZgWqnuAn5LQh3zInI07R+s8yL96W1I+Rymvu5MvBl8r169ZRfrR/ D3DKohuIsQ3TnPuW7DpiHX9QeVRH8EYDpo87cmSqSyur66XyL/UywlvK1a2NyQrL5TXl QfD72gVqvolLQq2Yg0gS3NqXh0E+/+9DwT9omg2UgijNUN8c9eiGifjhVOGMUPrVSpaP xf8QrPYcBS1kKNYXvq14wvxqI/OAl0Ra999vNqtEFhT0eAjan4hjBP9+vYdZFauQUH4h y9+A== Received: by 10.236.76.41 with SMTP id a29mr457079yhe.117.1334294910842; Thu, 12 Apr 2012 22:28:30 -0700 (PDT) Received: by 10.236.76.41 with SMTP id a29mr457071yhe.117.1334294910735; Thu, 12 Apr 2012 22:28:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Thu, 12 Apr 2012 22:28:10 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Fri, 13 Apr 2012 14:28:10 +0900 Message-ID: To: Greg Wilkins Content-Type: multipart/alternative; boundary=20cf303b40e32e15db04bd88be03 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnm43jtiEwabKQFM0vw5/vPWpsZnTTP+zt1IiFEjFa1MB8pPdNlJ+88gYo9hVSpLrJUUrs2KaPSMao2fwBpVbLKF06LPDrcn+0ouK2zN3L4mgCR2S0Y9bFPPcew0ZmkBpHZpmob Cc: hybi@ietf.org Subject: Re: [hybi] Multiplexing: Efficiency of multiple multiplex controls in one WebSocket 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: Fri, 13 Apr 2012 05:28:32 -0000 --20cf303b40e32e15db04bd88be03 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 08:00, Greg Wilkins wrote: > Takeshi, > > I think to constrain channel 0 fragments to be not interleaved is just > as hard (if not harder) than saying they can't be fragmented and it > still represents adding a constraint either way. > I just thought it might be better to keep fragmentation available but it's totally useless to allow interleaving between 0 and non-zero channel. OK, I'm fine with your idea. > So I believe we should strive to allow entirely normal fragmentation > of channel 0 messages, thus avoiding any constraint. If we have to > have a constraint, then I'd prefer no fragmentation or fragmentation > on block boundaries rather than a restriction on interleaving. > > The problem with normal fragmentation of channel0, is as you say, to > determine when an operation should be applied. Is there a problem > with saying that the operations within a channel 0 message will only > be applied once the entire message is received? As I've said > previously, I think it highly unlikely that we will have many blocks > in the same message, so I think fragmentation is unlikely to > occur..... but if it did, are there any bad consequences of delaying > processing? > Agreed. If control blocks in the same message are split into fragments, the benefit of multiple-blocks-in-a-message is already lost because overhead (see my first post for detail) is added on fragmentation. If the sender is really concerned with such delay, it can just use two messages and put such blocks in the first message instead of fragmentation. > > > I note that the current draft says in 7.5 > > Multiplex control blocks are sent in data frames, so they can be > fragmented. Processing of a multiplex control block MAY be done once > the block is received completely without waiting for the whole binary > message is received (and becomes available after decoding if any). > > Which say they MAY be processed as they are completely received, > suggesting that there is no MUST about processing them immediately - I > certainly can't think of a reason. So perhaps this is the most > flexible way - obviously blocks MUST be processed when the entire > message is received, but MAY be processed as each frame is decoded. > Yes, that's what I meant. > I can't see any problems with early processing either. I guess my > only concern is that it would allow different behaviour which might > allow for future complications, so I'd be OK with enforcing either > early or later processing of the blocks. > Let's just take your proposal "the operations within a channel 0 message will only be applied once the entire message is received" Now I don't see any problem with this simplest one. > Note also that 7.5 only applies to encapsulated control frames - so > perhaps this text needs to be applied to all block types? > Yes! Thanks. --20cf303b40e32e15db04bd88be03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 13, 2012 at 08:00, Greg Wilkins <gr= egw@intalio.com> wrote:
Takeshi,

I think to constrain channel 0 fragments to be not interleaved is just
as hard (if not harder) than saying they can't be fragmented and it
still represents adding a constraint either way.

<= /div>
I just thought=A0it might be better to keep fragmentation availab= le but it's totally useless to allow interleaving between 0 and non-zer= o channel. OK, I'm fine with your idea.
=A0
So I believe we should strive = to allow entirely normal fragmentation
of channel 0 messages, thus avoiding any constraint. =A0If we have to
have a constraint, then I'd prefer no fragmentation or fragmentation on block boundaries rather than a restriction on interleaving.

The problem with normal fragmentation of channel0, is as you say, to
determine when an operation should be applied. =A0Is there a problem
with saying that the operations within a channel 0 message will only
be applied once the entire message is received? =A0 As I've said
previously, I think it highly unlikely that we will have many blocks
in the same message, so I think fragmentation is unlikely to
occur..... but if it did, are there any bad consequences of delaying
processing?

Agreed. If control blocks i= n the same message are split into fragments, the benefit of multiple-blocks= -in-a-message is already lost because overhead (see my first post for detai= l) is added on fragmentation. If the sender is really concerned with such d= elay, it can just use two messages and put such blocks in the first message= instead of fragmentation.
=A0


I note that the current draft says in 7.5

=A0 Multiplex control blocks are sent in data frames, so they can be
=A0 fragmented. =A0Processing of a multiplex control block MAY be done onc= e
=A0 the block is received completely without waiting for the whole binary<= br> =A0 message is received (and becomes available after decoding if any).

Which say they MAY be processed as they are completely received,
suggesting that there is no MUST about processing them immediately - I
certainly can't think of a reason. =A0 So perhaps this is the most
flexible way - obviously blocks MUST be processed when the entire
message is received, but MAY be processed as each frame is decoded.

Yes, that's what I meant.
=A0
I can't see any problems with early processing either. =A0 I guess my only concern is that it would allow different behaviour which might
allow for future complications, so I'd be OK with enforcing either
early or later processing of the blocks.

Let's just take your proposal
"the operations within a= channel 0 message will only=A0be applied once the entire message is receiv= ed"
Now I don't see any problem with this simplest one.
=A0<= /div>
Note also that 7.5 only applies to encapsulated control frames - so
perhaps this text needs to be applied to all block types?
<= div>
Yes!

Thanks.

--20cf303b40e32e15db04bd88be03-- From tyoshino@google.com Fri Apr 13 00:05: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 BA52021F8668 for ; Fri, 13 Apr 2012 00:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOGAvnTGzoTs for ; Fri, 13 Apr 2012 00:05:55 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 72C2B21F8496 for ; Fri, 13 Apr 2012 00:05:55 -0700 (PDT) Received: by ggmi1 with SMTP id i1so1678849ggm.31 for ; Fri, 13 Apr 2012 00:05:49 -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=FSgAZ82+L5g8cHufQoDjc+ryA4w5TXmG1adTp245TPs=; b=eqjQ548Iy8eMo75mfb6zn+PNjv++k4UQEF+a6q7HdAFzbIjr+cvq+E6pLdxAJPCANb EHUx346JzvY41euaEMKlUO/4E2JF/l3j+z/i+IGc7vW+mBOWl9PtmQOLzE70gDvUEWpz CtMf6qYdsU9iVrRIC7nGWjeZupk1YwirV//Da0GpIIyESwnL6yJ8asEevs2IZ4o0Rjnt 3UBpXWckPsIVJYjwFCnvRbAbKhs8ykhBGMIKy+HVBTeNwubnRZXqsOdTGyIR4dNA99GA /r+A3Q75vwePujgRYoYVdw/It2VQc+9I0JJWEhZJzdx3wXEngfjgWjgaPJsmd9yTmzqO AMaQ== 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=FSgAZ82+L5g8cHufQoDjc+ryA4w5TXmG1adTp245TPs=; b=i/em4oeOSvTgp8t70WvmmXdedrndljb2fA+3iwrRy27i66XsMAiHxaLudmxrIVwwDh ZYuU74FOJ9bLsdneK7A+4zCyYuIM4Oi8WEAFUZBCt4wUpk+efSKWKgP/I6/YbsLsA+iT enoLB3MaPBoEPwkbUUUV0W0bvWgHmhWqep6cjdJk+HwUK6D6846EhHEG7qKrd9qoUZVL 24MFEodL1tyTAWFiPRQu0wHnY6dPrkny5BaCKPloAdswB/N04AHkoov1Q6pAHZMfR2Rf G+EF8th6WfQMlXfmnlvQ/RUUmUpU96a8cWZsHBVhYwV9X9cJySOBarXiKAjGMnvPY52b FjWw== Received: by 10.101.3.16 with SMTP id f16mr197857ani.60.1334300749696; Fri, 13 Apr 2012 00:05:49 -0700 (PDT) Received: by 10.101.3.16 with SMTP id f16mr197848ani.60.1334300749560; Fri, 13 Apr 2012 00:05:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Fri, 13 Apr 2012 00:05:29 -0700 (PDT) In-Reply-To: <002b01cd10d1$1eaa50e0$5bfef2a0$@noemax.com> References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> <005d01cd0ced$a8c6dd80$fa549880$@noemax.com> <000501cd0d7a$991dca50$cb595ef0$@noemax.com> <003201cd0e6a$2b871e10$82955a30$@noemax.com> <002b01cd10d1$1eaa50e0$5bfef2a0$@noemax.com> From: Takeshi Yoshino Date: Fri, 13 Apr 2012 16:05:29 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=0016368e2b46337d9c04bd8a1a77 X-System-Of-Record: true X-Gm-Message-State: ALoCoQly2uiszCMiYWyTmo4fMCQ5pJVNn94PXCmwZEpFp2fpVcwiyeYnuPBV3E0OeO1YILKaBZDBzUVLuANz1Qe/J5/BDvwJqMK8d7RrO28LI0nMx2qJuSO5lJvg5JEASzSrNZAfdEH6 Cc: hybi@ietf.org Subject: Re: [hybi] MUC: channel ID semantics X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 07:05:56 -0000 --0016368e2b46337d9c04bd8a1a77 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Apr 2, 2012 at 22:04, Arman Djusupov wrote: > As for arguing against it now, I think it greatly complicates the protocol > (some examples: how do you represent the parameters of all the channels, > what happens when one of the channels can't be created as requested,**** > > ** ** > > It is likely that several channels muxed within the same connection will > share the same target URI and have the same parameters. The delta encoding > that is proposed/TBD in the spec provides the ability to send a sequence of > AddChannel requests that would reuse the handshake of the first logical > channel. But currently there is a limitation that only the handshake of the > first logical channel can be reused. By extending this a little bit, it > will be possible to enable the reuse of handshakes for channels with > similar parameters. This would speed up the allocation of logical channels > in general.**** > > ** > It's true that there's some gain from such optimization. But WebSocket connections are expected to last for long time. Amount of data spent for handshake is little relatively. Different from SPDY for which reduction of bandwidth spent for headers is really significant, I don't think it's so beneficial to inflate the spec to add much optimization. If it's really useful, I'd just add some flag "DIFF_BASE" to AddChannelRequest and AddChannelResponse to mark certain request/response as a key entry based on which the following entries with diff-based compression are processed. Browser may use some heuristics behind JS, and any other non-browser applications may employ as they like it to optimize batch allocation. Just change the spec of delta-encoded to refer "last AddChannelRequest with Enc=identify" as base for diff is also fine. > ** > > DoS considerations currently blocked by one creation in flight at a time, > complicates buffer space handling, etc) and provides limited benefits.**** > > ** ** > > The current specification already allows multiple AddChannel requests to > be batched into a single binary message. Sending to the server a large > pre-generated sequence of separate AddChannel requests would force the > server to perform a large sequence of handshakes, gradually allocating > resources until it reaches a limit and has to refuse new logical channels. > When receiving a single AddChannel request batch with a single handshake > and the specified final number of channels required, the server can either > allocate the requested channels sequentially as in the previous case or > refuse the entire batch with minimal effort. Neither case blocks DoS > considerations.**** > > ** > It's just missing in the current spec. This point is open for discussion. That said, as: - different from raw WebSocket, sending multiple AddChannel requests doesn't increase TCP connection attempts - under multiplexing, there's no worry that WebSocket is used to DoS normal HTTP server. (de-multiplexing proxy must place the limit again.) we can allow simultaneous AddChannelRequests. Thoughts? --0016368e2b46337d9c04bd8a1a77 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Mon, Apr 2, 2012 at 22:04, Arman Djusupov <arman@noemax.com= > wrote:
<= p class=3D"MsoNormal">As for arguing against it now, I think it greatly com= plicates the protocol (some examples: how do you represent the parameters o= f all the channels, what happens when one of the channels can't be crea= ted as requested,

=A0<= /p>

It is likely tha= t several channels muxed within the same connection will share the same tar= get URI and have the same parameters. The delta encoding that is proposed/T= BD in the spec provides the ability to send a sequence of AddChannel reques= ts that would reuse the handshake of the first logical channel. But current= ly there is a limitation that only the handshake of the first logical chann= el can be reused. By extending this a little bit, it will be possible to en= able the reuse of handshakes for channels with similar parameters. This wou= ld speed up the allocation of logical channels in general.=

=


It's true= that there's some gain from such optimization. But WebSocket connectio= ns are expected to last for long time. Amount of data spent for handshake i= s little relatively. Different from SPDY for which reduction of bandwidth s= pent for headers is really significant, I don't think it's so benef= icial to inflate the spec to add much optimization.

If it's really useful, I'd just add some flag &= quot;DIFF_BASE" to AddChannelRequest and AddChannelResponse to mark ce= rtain request/response as a key entry based on which the following entries = with diff-based compression are processed. Browser may use some heuristics = behind JS, and any other non-browser applications may employ as they like i= t to optimize batch allocation.

Just change the spec of delta-encoded to refer "la= st AddChannelRequest with Enc=3Didentify" as base for diff is also fin= e.
=A0
<= p class=3D"MsoNormal">=A0

DoS considerations currently blocked by one creation in flight at a time, c= omplicates buffer space handling, etc) and provides limited benefits.

=A0<= /p>

The current spec= ification already allows multiple AddChannel requests to be batched into a = single binary message. Sending to the server a large pre-generated sequence= of separate AddChannel requests would force the server to perform a large = sequence of handshakes, gradually allocating resources until it reaches a l= imit and has to refuse new logical channels. When receiving a single AddCha= nnel request batch with a single handshake and the specified final number o= f channels required, the server can either allocate the requested channels = sequentially as in the previous case or refuse the entire batch with minima= l effort. Neither case blocks DoS considerations.

=


It's just= missing in the current spec. This point is open for discussion. That said,= as:
- different from raw WebSocket, sending multiple AddChannel requests d= oesn't increase TCP connection attempts
- under multiplexing,= there's no worry that WebSocket is used to DoS normal HTTP server. (de= -multiplexing proxy must place the limit again.)
we can allow simultaneous AddChannelRequests.

Thoughts?

--0016368e2b46337d9c04bd8a1a77-- From tyoshino@google.com Fri Apr 13 00:45: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 DD66821F8655 for ; Fri, 13 Apr 2012 00:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2cIZYi0Zczah for ; Fri, 13 Apr 2012 00:45:53 -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 2F4D921F8699 for ; Fri, 13 Apr 2012 00:45:53 -0700 (PDT) Received: by yenm5 with SMTP id m5so1684982yen.31 for ; Fri, 13 Apr 2012 00:45: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=IpHjPSUZ/2KFOd2GzNQZv1zk+C6iykNBq/P7r3uizy0=; b=bsAUU+295dWkzJSaYady/ydq6ewuh/opajxCnEjNQSwuknV/rzZYBkRZTJ7sHzJY9n unY0icgsAqPwn6S6coH/wf8Bjq3uCNUKE1cWY0o75Aggy7wIDAdTGBfPUgCDZSvERgBA kpt4V3jYynmw+q75kyENVXOdEXqdQuXyDuK5zBHL5mgS1OgdR9GuKIkOolZRQRVRp4mp iy5Sikj5cqWdzAq0dd2SyS+z9Va0OrLy82/dHI09CDVHKUpONcuo8eTuGblZKWjAvcbx bOrPhjGtkpY5SkbGj0T8CR6wikyW+e8wIyNEQmi0cXKXgwHCtyxRFVHKqN5n9k359tV3 s9Zw== 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=IpHjPSUZ/2KFOd2GzNQZv1zk+C6iykNBq/P7r3uizy0=; b=O0bn0vVRaiLusepXZn92/Ve/Vf0q2XLrlRtbI320AnXWVeAFbcxC47ZMKqORwndQv3 gb7fFjgyKPHHDZES7YJsbh4lxyeBaXg6sDG+3k4CooZNtvZmEjHzdDVNnI/pRvLY3MOo LdQR1kAEbyx18fatKHERIa5Bsox5iJnDKfZVlC2LR1rbJFiLFeKtDfWcR7ln/u7YwzbE 9Fd/PoL8IWQ0J9yqJt20STec3hzMGK8zQigbHQhlqB6FQZ4vFLAKoiMxtMp9Gm5VaHls +9ZProFKB6r5j8BafAS6OH1ZVy8miDZLgeCDE1g+SHDePXwiB1+Law9BYC4yEdiGo2KM ATog== Received: by 10.236.136.198 with SMTP id w46mr731725yhi.68.1334303152736; Fri, 13 Apr 2012 00:45:52 -0700 (PDT) Received: by 10.236.136.198 with SMTP id w46mr731719yhi.68.1334303152633; Fri, 13 Apr 2012 00:45:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.155.5 with HTTP; Fri, 13 Apr 2012 00:45:32 -0700 (PDT) In-Reply-To: References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> <005d01cd0ced$a8c6dd80$fa549880$@noemax.com> <000501cd0d7a$991dca50$cb595ef0$@noemax.com> <003201cd0e6a$2b871e10$82955a30$@noemax.com> <002b01cd10d1$1eaa50e0$5bfef2a0$@noemax.com> From: Takeshi Yoshino Date: Fri, 13 Apr 2012 16:45:32 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=20cf303ddb906f781504bd8aa92c X-System-Of-Record: true X-Gm-Message-State: ALoCoQnTzRIXADfSJa+vPXxYppPtu3HVUssecwO8rK/OQrHGq4Ia+NxyISXoYpbspCUhM2/5Kj9EYpaitee1KnMdndV0GcCSm/J1JT3QzL36aCgPKRflv2PbmBJr4W1WZuOGcx6PebiC Cc: hybi@ietf.org Subject: Re: [hybi] MUC: channel ID semantics X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 07:45:54 -0000 --20cf303ddb906f781504bd8aa92c Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 13, 2012 at 16:05, Takeshi Yoshino wrote: > DoS considerations currently blocked by one creation in flight at a time, >> complicates buffer space handling, etc) and provides limited benefits.*** >> * >> >> ** ** >> >> The current specification already allows multiple AddChannel requests to >> be batched into a single binary message. Sending to the server a large >> pre-generated sequence of separate AddChannel requests would force the >> server to perform a large sequence of handshakes, gradually allocating >> resources until it reaches a limit and has to refuse new logical channels. >> When receiving a single AddChannel request batch with a single handshake >> and the specified final number of channels required, the server can either >> allocate the requested channels sequentially as in the previous case or >> refuse the entire batch with minimal effort. Neither case blocks DoS >> considerations.**** >> >> ** >> > > It's just missing in the current spec. This point is open for discussion. > That said, as: > - different from raw WebSocket, sending multiple AddChannel requests > doesn't increase TCP connection attempts > - under multiplexing, there's no worry that WebSocket is used to DoS > normal HTTP server. (de-multiplexing proxy must place the limit again.) > we can allow simultaneous AddChannelRequests. > > Thoughts? > Correction. It "WAS" missing in tamplin-03 but it's in from ietf-00. http://tools.ietf.org/html/draft-ietf-hybi-websocket-multiplexing-00#section-7.1 The same limit on simultaneous opening handshake as specified in Section 4.1 of [RFC6455] is applied to AddChannelRequests for multiplexed channels. --20cf303ddb906f781504bd8aa92c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 13, 2012 at 16:05, Takeshi Yoshino <= span dir=3D"ltr"><tyoshino@google= .com> wrote:

DoS considerations currently blocked by one creation in flight at a ti= me, complicates buffer space handling, etc) and provides limited benefits.<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">

=A0<= /p>

The current spec= ification already allows multiple AddChannel requests to be batched into a = single binary message. Sending to the server a large pre-generated sequence= of separate AddChannel requests would force the server to perform a large = sequence of handshakes, gradually allocating resources until it reaches a l= imit and has to refuse new logical channels. When receiving a single AddCha= nnel request batch with a single handshake and the specified final number o= f channels required, the server can either allocate the requested channels = sequentially as in the previous case or refuse the entire batch with minima= l effort. Neither case blocks DoS considerations.


It's just missing in t= he current spec. This point is open for discussion. That said, as:
- different from raw WebSocket, sending multiple AddChannel requests d= oesn't increase TCP connection attempts
- under multiplexing,= there's no worry that WebSocket is used to DoS normal HTTP server. (de= -multiplexing proxy must place the limit again.)
we can allow simultaneous AddChannelRequests.

Thoughts?

Correction.

It "W= AS" missing in tamplin-03 but it's in from ietf-00.

=

=A0 =A0The same limit on simultaneous openin= g handshake as specified in
=A0 =A0Section 4.1 of [RFC6455] is ap= plied to AddChannelRequests for
=A0 =A0multiplexed channels.

--20cf303ddb906f781504bd8aa92c-- From arman@noemax.com Fri Apr 13 04:09:38 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 5E14521F87BE for ; Fri, 13 Apr 2012 04:09:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OLPWXzbN7fUD for ; Fri, 13 Apr 2012 04:09:35 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEEA21F87BC for ; Fri, 13 Apr 2012 04:09:35 -0700 (PDT) Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id XPW82736; Fri, 13 Apr 2012 14:09:36 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> <005d01cd0ced$a8c6dd80$fa549880$@noemax.com> <000501cd0d7a$991dca50$cb595ef0$@noemax.com> <003201cd0e6a$2b871e10$82955a30$@noemax.com> <002b01cd10d1$1eaa50e0$5bfef2a0$@noemax.com> In-Reply-To: Date: Fri, 13 Apr 2012 14:09:20 +0300 Message-ID: <002101cd1965$e42e8e20$ac8baa60$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01CD197F.097BC620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQBwER93EEogAGIwJzoTe3koNCITEAEvBhKRAcewlzkBvQv4oAJixsSUAcHoFyEB2DsVhgLSPJtbAXlAGB4BaXQDtQJIEPnGAnHF/xYBnJfzNQEgfeuSALuIZdEB6u58uZh+kCwg Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] MUC: channel ID semantics X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Apr 2012 11:09:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01CD197F.097BC620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello Takeshi, It's true that there's some gain from such optimization. But WebSocket connections are expected to last for long time. Amount of data spent for handshake is little relatively. Different from SPDY for which reduction of bandwidth spent for headers is really significant, I don't think it's so beneficial to inflate the spec to add much optimization. Using delta encoding would enable the fast allocation of channels in batches if necessary. IMO it's preferable to send a batch of multiple AddChannelRequest in a single control message and then receive a batch of AddChannel responses, rather than sending a complex single AddChannel request that is supposed to create more than one channel. We don't really need to change much in the specification, we just need to optimize the delta encoding that is already there. If it's really useful, I'd just add some flag "DIFF_BASE" to AddChannelRequest and AddChannelResponse to mark certain request/response as a key entry based on which the following entries with diff-based compression are processed. Browser may use some heuristics behind JS, and any other non-browser applications may employ as they like it to optimize batch allocation. Just change the spec of delta-encoded to refer "last AddChannelRequest with Enc=identify" as base for diff is also fine. I think that an encoding based on the last 'identify' handshake is fine, and is as simple as an encoding based on the first one. A mux intermediary / server will simply have to remember the last handshake rather than first one. It's just missing in the current spec. This point is open for discussion. That said, as: - different from raw WebSocket, sending multiple AddChannel requests doesn't increase TCP connection attempts - under multiplexing, there's no worry that WebSocket is used to DoS normal HTTP server. (de-multiplexing proxy must place the limit again.) we can allow simultaneous AddChannelRequests. Thoughts? Note that Section 4 of RFC 6455 has requirements that apply mostly to browsers and it limits the number of concurrent connections in CONNECTING state and does not explicitly mention concurrent handshakes. In case of a mux channel the network connection is one and it is CONNECTED, so this needs a bit of clarification if this paragraph will remain in the spec. As you mentioned above the DoS attack against non-WebSocket servers is not applicable when creating logical channels. The only concern that comes to mind is that a malicious script can flood the high priority channel ID 0 with AddChannel requests using long header values, this way trying to disrupt the communication of other channels on the same connection. But such behavior can be detected and limited by the browser. BTW: "Different from non-multiplexed WebSocket connection, data frames of multiplexed channel except for the channel 1 opened by default MAY be sent before receiving AddChannelResponse as far as there's sufficient send quota. In case the AddChannelRequest fails, those frames are ignored by the other peer." As far as I had previously understood, until a new logical channel receives the AddChannelResponse its flow control quota is 0. The initial quota is assumed to be 64K but this quota applies only once the channel is accepted and the handshake did not include/specify a quota that overrides this value. Wouldn't this mean that the logical channel cannot send anything prior it was accepted due to the 0 quota even if the specification permits it to send messages, or did I miss something? With best regards, Arman ------=_NextPart_000_0022_01CD197F.097BC620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Takeshi,

 

It's true that = there's some gain from such optimization. But WebSocket connections are = expected to last for long time. Amount of data spent for handshake is = little relatively. Different from SPDY for which reduction of bandwidth = spent for headers is really significant, I don't think it's so = beneficial to inflate the spec to add much = optimization.

 

Using delta encoding would enable the fast allocation of channels in = batches if necessary. IMO it’s preferable to send a batch of = multiple AddChannelRequest in a single control message and then receive = a batch of AddChannel responses, rather than sending a complex single = AddChannel request that is supposed to create more than one channel. We = don’t really need to change much in the specification, we just = need to optimize the delta encoding that is already = there.

 

If it's really useful, I'd just add some flag = "DIFF_BASE" to AddChannelRequest and AddChannelResponse to = mark certain request/response as a key entry based on which the = following entries with diff-based compression are processed. Browser may = use some heuristics behind JS, and any other non-browser applications = may employ as they like it to optimize batch = allocation.

 

Just change the spec of delta-encoded to refer = "last AddChannelRequest with Enc=3Didentify" as base for diff = is also fine.

 

I think that an encoding based on the last ‘identify’ = handshake is fine, and is as simple as an encoding based on the first = one. A mux intermediary / server will simply have to remember the last = handshake rather than first one.

 

It's just = missing in the current spec. This point is open for discussion. That = said, as:

- different from raw = WebSocket, sending multiple AddChannel requests doesn't increase TCP = connection attempts

- under = multiplexing, there's no worry that WebSocket is used to DoS normal HTTP = server. (de-multiplexing proxy must place the limit = again.)

we can allow simultaneous = AddChannelRequests.

 

Thoughts?

 

Note that Section 4 of RFC 6455 has requirements that apply mostly to =
browsers and it limits the number of concurrent connections in =
CONNECTING state and does not explicitly mention concurrent handshakes. =
In case of a mux channel the network  connection is one and it is =
CONNECTED, so this needs a bit of clarification if this paragraph will =
remain in the spec.
 
As you mentioned above the DoS attack against non-WebSocket servers =
 is not applicable when creating logical channels. The only concern =
that comes to mind is that a malicious script can flood the high =
priority channel ID 0 with AddChannel requests using long header values, =
this way trying to disrupt the communication of other channels on the =
same connection. But such behavior can be detected and limited by the =
browser.
 
BTW:
“Different from =
non-multiplexed WebSocket connection, data frames of multiplexed channel =
except for the channel 1 opened by default MAY be sent before receiving =
AddChannelResponse as far as there's =
sufficient
send quota.  In case the =
AddChannelRequest fails, those frames are ignored by the other =
peer.”
 

As far as I had previously understood, until a new logical channel = receives the AddChannelResponse its flow control quota is 0. The initial = quota is assumed to be 64K but this quota applies only once the channel = is accepted and the handshake did not include/specify a quota that = overrides this value. Wouldn’t this mean that the logical channel = cannot send anything prior it was accepted due to the 0 quota even if = the specification permits it to send messages, or did I miss = something?

 

With best regards,

Arman

 

 

------=_NextPart_000_0022_01CD197F.097BC620-- From tyoshino@google.com Wed Apr 18 01:03: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 D2D1E21F8653 for ; Wed, 18 Apr 2012 01:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTaGi-enhYSc for ; Wed, 18 Apr 2012 01:03:53 -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 710CD21F86A3 for ; Wed, 18 Apr 2012 01:03:29 -0700 (PDT) Received: by iazz13 with SMTP id z13so12291933iaz.31 for ; Wed, 18 Apr 2012 01:03:29 -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=zOaGM2+71FCNWvuAnbM59XRcPCux6xMCNNkm6/P3O3c=; b=Nal9EBwG+hyCDiK6NQvbUp6ja3C19OTxGKBNkQXl518AakP6Ins5MIXD8qTco7F7lB bIOrxOrHUd9LWtLtCv8qxj90v+a1EIFgkqhFy45vo5hKnFy4nmN8VZEpHG58XvW6hcYb GY3QvdWdjFFEhw6K0UCqNn/ebxsanpnrFf8EpmVPYfmjC55iMfaYYgNGWEOgYnpxysCV IUZYOyrbqDBdz9CNWl4QcO9VGoOEdcO/d2QS9SacQMalYxWbCDlCSXTdvEFcXvRGl2aO UrI+78eRoTIdEL0jAi6yMFFUJF7IZNo6+pLzvjU5FTp1UOqV274v1Tmw7Ns2GR7R/Sw3 SeXA== 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=zOaGM2+71FCNWvuAnbM59XRcPCux6xMCNNkm6/P3O3c=; b=msNN6EQwNt/KbNJ9B5NV6qmOMvjKl4eypByPILVsy+cynxXIUnJRbZAnFA23xE7X59 EBqHKp7z7z7dolVeC4aKSVbuuO+Wfv2r5OsTCmBicqyb3EUQy1Mb0CKxJfhO2BLkaIqn HDctU4qbwInOoy+pRsdmwkQV0pGPtELodhF4TV1l1DUEEXxA5QIJfzqiGgVQN4Aka/GH 41aJzP7jAMs+ZOoab8Hdd2we4WD41mSl6LzZvj9rPjyXyTOxgvjLd+BGmTKR1lRdwrk8 DvKlgfPybVIlR2Kj5eIQO2/YjpQntEZAOMWh48K14dfWDhAx/kdvl4LibqPBzxClvnyW eoIA== Received: by 10.50.168.67 with SMTP id zu3mr890558igb.28.1334736209081; Wed, 18 Apr 2012 01:03:29 -0700 (PDT) Received: by 10.50.168.67 with SMTP id zu3mr890550igb.28.1334736209002; Wed, 18 Apr 2012 01:03:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Wed, 18 Apr 2012 01:03:08 -0700 (PDT) In-Reply-To: <002101cd1965$e42e8e20$ac8baa60$@noemax.com> References: <4F72FB42.8080600@stpeter.im> <004101cd0cdb$e75bd9e0$b6138da0$@noemax.com> <4F730535.8040901@stpeter.im> <004301cd0ce2$464f0b60$d2ed2220$@noemax.com> <005d01cd0ced$a8c6dd80$fa549880$@noemax.com> <000501cd0d7a$991dca50$cb595ef0$@noemax.com> <003201cd0e6a$2b871e10$82955a30$@noemax.com> <002b01cd10d1$1eaa50e0$5bfef2a0$@noemax.com> <002101cd1965$e42e8e20$ac8baa60$@noemax.com> From: Takeshi Yoshino Date: Wed, 18 Apr 2012 17:03:08 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f83adf99b41b104bdef7d71 X-System-Of-Record: true X-Gm-Message-State: ALoCoQkBCcd9sPFjn6y7SRYWfo0YFiPPRosQcRueJz3YriXKvTPhHbF47neKZoUoKxU1E6DmbxEg2rK4anfdE9jAugVhnkvkEAjDPgYQkxGo/j576E5IJQ7GGeiT2zyR50/xdU5EncYv Cc: hybi@ietf.org Subject: Re: [hybi] MUC: channel ID semantics X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 18 Apr 2012 08:03:53 -0000 --e89a8f83adf99b41b104bdef7d71 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, On Fri, Apr 13, 2012 at 20:09, Arman Djusupov wrote: > Using delta encoding would enable the fast allocation of channels in > batches if necessary. IMO it=92s preferable to send a batch of multiple > AddChannelRequest in a single control message and then receive a batch of > AddChannel responses, rather than sending a complex single AddChannel > request that is supposed to create more than one channel. We don=92t real= ly > need to change much in the specification, we just need to optimize the > delta encoding that is already there. > OK. > I think that an encoding based on the last =91identify=92 handshake is fi= ne, > and is as simple as an encoding based on the first one. A mux intermediar= y > / server will simply have to remember the last handshake rather than firs= t > one. > OK. I'll do so. > ** > Note that Section 4 of RFC 6455 has requirements that apply mostly to > browsers and it limits the number of concurrent connections in CONNECTING > state and does not explicitly mention concurrent handshakes. In case of a > mux channel the network connection is one and it is CONNECTED, so this > needs a bit of clarification if this paragraph will remain in the spec. > Thanks. Yes, even in case we keep the requirement, we need to rephrase current one. --e89a8f83adf99b41b104bdef7d71 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi,

On Fri, Apr 13, 2012 at 20:09, Arman= Djusupov <arman@n= oemax.com> wrote:

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">Using delta encoding would enable the fast allocation of channels in= batches if necessary. IMO it=92s preferable to send a batch of multiple Ad= dChannelRequest in a single control message and then receive a batch of Add= Channel responses, rather than sending a complex single AddChannel request = that is supposed to create more than one channel. We don=92t really need to= change much in the specification, we just need to optimize the delta encod= ing that is already there.


OK.
=A0

I think that an encoding based on the last = =91identify=92 handshake is fine, and is as simple as an encoding based on = the first one. A mux intermediary / server will simply have to remember the= last handshake rather than first one.


OK. I'll do so.
= =A0

Note that Secti= on 4 of RFC 6455 has requirements that apply mostly to browsers and it limi= ts the number of concurrent connections in CONNECTING state and does not ex= plicitly mention concurrent handshakes. In case of a mux channel the networ= k =A0connection is one and it is CONNECTED, so this needs a bit of clarific= ation if this paragraph will remain in the spec.

Thanks. Yes, even in case we keep th= e requirement, we need to rephrase current one.

<= /div> --e89a8f83adf99b41b104bdef7d71-- From tyoshino@google.com Wed Apr 18 01:15:29 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 B552D21F85FC for ; Wed, 18 Apr 2012 01:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnk7nkAVyf87 for ; Wed, 18 Apr 2012 01:15:27 -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 EA81F21F85DD for ; Wed, 18 Apr 2012 01:15:26 -0700 (PDT) Received: by iazz13 with SMTP id z13so12309533iaz.31 for ; Wed, 18 Apr 2012 01:15:26 -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=h3LuKZjGk2wMxZ4kj/Ih+7whdyWxiwUCrZNAspiz+bE=; b=d+cLdmEugl9FwdshUesu4Kz11Pge++0+zbwEII9SAgILIuwaecHY5ce6496R1QRCSJ qD0Jb81VPMnGbPvyaGr8AmUPA8PVRfwFuFtHEH0ji9+Fol6W7E+koFfdOOeeXGge5l6r LRRwnhr7JYFISIMwYCqcnmyzQgtDRwkTV7RxBqxYiwKHrjH8JQeBsYwgzdgSXHy+RVrP /h0C99XsSrK8hcjMrXvViDR8QAnjq18XadXubwSnzt2ttJ55tWMRsZVt4iiyZ1eYtWlJ uwixUB8iujsUZACpSlpattDwr3k93CR1Bqk0w70Jgx2FaOVy99ngw4xTWCf5s6+GJub4 Xxuw== 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=h3LuKZjGk2wMxZ4kj/Ih+7whdyWxiwUCrZNAspiz+bE=; b=PGimJTx3MOY5onPnosw+BxG2MXStiVWdMIJf+jWNFBTxm5blHRsHwsAvCtvY9oZ9Tz l6CbdY+nSt6VN4+toH+ScAAv7RZjTy8Op7yeolwK6r8tf3IlewJFeJa6cFPz1CD/vR8o MfaHZy2pZQlXLL7+Lvq3FSVK6qQh6YjXpgXAZ4vz+shucjNjalc5LbNt4j5xLFsg8pT0 5KFKY5x91mpkuoJjKi1TqvvEzZZ5dNviBkXliUcGkJLHUaxGjA1TkwrBE4ifma2x9PU3 4dskNdpC4W5MXpcXcGkaOWpxYva1iUrOlgxPgGyQhRuqZoRM3NyEGY8/XR85ARJGLgok EWhw== Received: by 10.50.156.229 with SMTP id wh5mr12151267igb.28.1334736926603; Wed, 18 Apr 2012 01:15:26 -0700 (PDT) Received: by 10.50.156.229 with SMTP id wh5mr12151258igb.28.1334736926514; Wed, 18 Apr 2012 01:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Wed, 18 Apr 2012 01:15:06 -0700 (PDT) From: Takeshi Yoshino Date: Wed, 18 Apr 2012 17:15:06 +0900 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=e89a8f2346a95f9f8604bdefa862 X-System-Of-Record: true X-Gm-Message-State: ALoCoQn4O6OcQbe8+bZKc4ujxxBHTbLOhd+phvPLg7VQSLOG3sxjK629VlZ/UdAAYUZwuUXNy2GHgT8t/ZkZ7msPuqoIMisCNimO/KQ/I3RYkpyzJqSRVTY6OsBx0Rdu4ffDeS/Tq/t3 Cc: hybi@ietf.org Subject: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 18 Apr 2012 08:15:29 -0000 --e89a8f2346a95f9f8604bdefa862 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Fri, Apr 13, 2012 at 20:09, Arman Djusupov wrote: > BTW: > > =93Different from non-multiplexed WebSocket connection, data frames of mu= ltiplexed channel except for the channel 1 opened by default MAY be sent be= fore receiving AddChannelResponse as far as there's sufficient**** > > send quota. In case the AddChannelRequest fails, those frames are ignore= d by the other peer.=94**** > > ** ** > > As far as I had previously understood, until a new logical channel > receives the AddChannelResponse its flow control quota is 0. The initial > quota is assumed to be 64K but this quota applies only once the channel i= s > accepted and the handshake did not include/specify a quota that overrides > this value. Wouldn=92t this mean that the logical channel cannot send > anything prior it was accepted due to the 0 quota even if the specificati= on > permits it to send messages, or did I miss something? > You're right. In the latest spec, it's not explicitly specified what the value of send quota is until AddChannelResponse is received. There're several options we can take. a) specify the fixed value of send quota before AddChannelResponse in the spec b) add a new parameter "pre_handshake_quota" to multiplexing extension to negotiate the value of send quota before AddChannelResponse c) drop the feature to configure initial quota for each logical channel, and redefine the quota parameter as pre-handshake send quota for all logical channels I'm not sure how many people really want to configure initial quota for each logical channel independently. Comment please. --e89a8f2346a95f9f8604bdefa862 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
On Fri, Apr 13, 2012 at 20:09, Arman Djusupov <arman@noemax.com> wrote:

<= span style=3D"color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size= :11pt">BTW:

=93Different from non-multiplexed WebSocket conn=
ection, data frames of multiplexed channel except for the channel 1 opened =
by default MAY be sent before receiving AddChannelResponse as far as there&=
#39;s sufficient
send quota.=A0 In case the AddChannelRequest fails, those frames are i=
gnored by the other peer.=94
=A0
As far as I had previous=
ly understood, until a new logical channel receives the AddChannelResponse =
its flow control quota is 0. The initial quota is assumed to be 64K but thi=
s quota applies only once the channel is accepted and the handshake did not=
 include/specify a quota that overrides this value. Wouldn=92t this mean th=
at the logical channel cannot send anything prior it was accepted due to th=
e 0 quota even if the specification permits it to send messages, or did I m=
iss something?

You're right. In the latest spec= , it's not explicitly specified what the value of send quota is until A= ddChannelResponse is received.

There're severa= l options we can take.

a) specify the fixed value of send quota before AddChan= nelResponse in the spec
b) add a new parameter "pre_handshak= e_quota" to multiplexing extension to negotiate the value of send quot= a before AddChannelResponse
c) drop the feature to configure initial quota for each logical channe= l, and redefine the quota parameter as pre-handshake send quota for all log= ical channels

I'm not sure how many people rea= lly want to configure initial quota for each logical channel independently.=

Comment please.

--e89a8f2346a95f9f8604bdefa862-- From jat@google.com Wed Apr 18 05:01: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 4FBDE21F85A8 for ; Wed, 18 Apr 2012 05:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+7K86YfbMU2 for ; Wed, 18 Apr 2012 05:01:45 -0700 (PDT) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2D721F859B for ; Wed, 18 Apr 2012 05:01:45 -0700 (PDT) Received: by vcbfo1 with SMTP id fo1so1106974vcb.31 for ; Wed, 18 Apr 2012 05:01:45 -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=zQy+fkpySgBNZLEVwroJ/+bVzO9E3WilPs6knH0eA+M=; b=QsMBltAj+SP+e2y16N+T85ZrmzObBKUpvNeIiIwEuVxk1np2qdmNc8uyt7pHGt60h2 phWySqYcSMprSV6mdCrXZjeyqLLKe2RREMX0J4mwZpJo0wvR6DzMn7jCC12hPN6EjDMb 4Yb0qw+fNW7a/387Vs+pXym+ws2EVfiQQVQEfdLcuCJdGk9f9Fn1toKJT6ibkvA7oMXc TKdXH6PNRO77N+VTSVBu6r2erIeIGUwjY7EOSD6TyD4+z2Pd4WeOjs+ajJfissyZmgkl 9+4SFa3sif8qvdP9j3CZJ29gorG6NzbBg4ZxDA8bwS0H0qbJqvW0WuSRIRoursGvP+me L7dQ== 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=zQy+fkpySgBNZLEVwroJ/+bVzO9E3WilPs6knH0eA+M=; b=i4AstVzGxOUYOsWlC5gaWlwhGEmmBbb7P/jfXtTEdTXfa4tblmOWaHtCefEJyUYL+P ftvWy4ZsM0/8vnDABMS3bTbViOkyPERzNR8/6Ax9Tis2fArfIFIVpwCa73bkuWOSrVEJ LcZOuuUrR4knczztJGDf92LBpI9/ZIhktW5l3p/KtZ4wVTn2f0fHg4bqmTPZdtav4B0w Jv9UAe2EGPYFcRjsFe8GJf8fgcBWyv9lKlQgVRxghEs6LVrTzwOGisDeeWQWg/COVqLP GebYOvShiKNedEjT0dTZN1Wwp0rvEI+LXigwIvIigfRQ4v0aU9LJFa302l/IB5kX7si3 cW+g== Received: by 10.52.240.232 with SMTP id wd8mr802829vdc.96.1334750504891; Wed, 18 Apr 2012 05:01:44 -0700 (PDT) Received: by 10.52.240.232 with SMTP id wd8mr802822vdc.96.1334750504728; Wed, 18 Apr 2012 05:01:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.17.193 with HTTP; Wed, 18 Apr 2012 05:01:24 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Wed, 18 Apr 2012 08:01:24 -0400 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=20cf307cfd04b2b88e04bdf2d1f7 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlZc95Yj8iy5xWghL0q+g9RQYw4Ia/NEloOv5iXZZuEKmw8+RfTjiylt4uBDkui0UD9KAwwFfYCK7MAUuihIt6tAMqUZGSkNRYPtN8jMKp5BTmb+cKzjtq9KdcquIrg6sA5Rjx7 Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 18 Apr 2012 12:01:46 -0000 --20cf307cfd04b2b88e04bdf2d1f7 Content-Type: text/plain; charset=UTF-8 On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino wrote: > You're right. In the latest spec, it's not explicitly specified what the > value of send quota is until AddChannelResponse is received. > > There're several options we can take. > > a) specify the fixed value of send quota before AddChannelResponse in the > spec > b) add a new parameter "pre_handshake_quota" to multiplexing extension to > negotiate the value of send quota before AddChannelResponse > c) drop the feature to configure initial quota for each logical channel, > and redefine the quota parameter as pre-handshake send quota for all > logical channels > Until we know the AddChannel was accepted, how can we send data anyway? This seems just like the initial handshake on a new connection -- you wouldn't consider sending that data until you knew the connection was accepted. Since we are avoiding TCP setup requirements, this will be much less latency than if the connection were created without multiplexing. I suppose it would be possible to send the data while keeping it buffered as an optimization, but since adding a channel should be infrequent compared to sending data on it, I don't see it as that important to optimize for. -- John A. Tamplin Software Engineer (GWT), Google --20cf307cfd04b2b88e04bdf2d1f7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino= <tyoshino@goog= le.com> wrote:
You're right. In the latest spec, it= 9;s not explicitly specified what the value of send quota is until AddChann= elResponse is received.

There're several optio= ns we can take.

a) specify the fixed value of send quota before AddChan= nelResponse in the spec
b) add a new parameter "pre_handshak= e_quota" to multiplexing extension to negotiate the value of send quot= a before AddChannelResponse
c) drop the feature to configure initial quota for each logical channe= l, and redefine the quota parameter as pre-handshake send quota for all log= ical channels

Until we know the= AddChannel was accepted, how can we send data anyway? =C2=A0This seems jus= t like the initial handshake on a new connection -- you wouldn't consid= er sending that data until you knew the connection was accepted. =C2=A0Sinc= e we are avoiding TCP setup requirements, this will be much less latency th= an if the connection were created without multiplexing.

I suppose it would be possible to send the data while k= eeping it buffered as an optimization, but since adding a channel should be= infrequent compared to sending data on it, I don't see it as that impo= rtant to optimize for.

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--20cf307cfd04b2b88e04bdf2d1f7-- From arman@noemax.com Wed Apr 18 06:18:47 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 E5A6E21F84EB for ; Wed, 18 Apr 2012 06:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7lZWmX5Cynu for ; Wed, 18 Apr 2012 06:18:47 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 19C4921F846F for ; Wed, 18 Apr 2012 06:18:47 -0700 (PDT) Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id CRK62150; Wed, 18 Apr 2012 16:18:50 +0300 From: "Arman Djusupov" To: "'John Tamplin'" , "'Takeshi Yoshino'" References: In-Reply-To: Date: Wed, 18 Apr 2012 16:18:36 +0300 Message-ID: <001f01cd1d65$c75807f0$560817d0$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01CD1D7E.ECA53FF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDpAB3Ba5pDAvrAhMo3RFqWK7Q0QGeXeAIl6aPzWA= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 18 Apr 2012 13:18:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0020_01CD1D7E.ECA53FF0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I also feel it is unnecessary to let the client send some payload that = would need to be discarded if the channel is not accepted.=20 =20 But if this feature is needed for some use cases then I would opt for = using the quota negotiated during the initial handshake as the initial = quota for all logical channels (and wouldn=E2=80=99t negotiate an = initial quota for logical channels since they already have it granted). =20 With best regards, Arman =20 From: John Tamplin [mailto:jat@google.com]=20 Sent: Wednesday, April 18, 2012 3:01 PM To: Takeshi Yoshino Cc: Arman Djusupov; hybi@ietf.org Subject: Re: Send quota value before receiving AddChannelResponse (was: = Re: [hybi] MUC: channel ID semantics) =20 On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino = wrote: You're right. In the latest spec, it's not explicitly specified what the = value of send quota is until AddChannelResponse is received. =20 There're several options we can take. =20 a) specify the fixed value of send quota before AddChannelResponse in = the spec b) add a new parameter "pre_handshake_quota" to multiplexing extension = to negotiate the value of send quota before AddChannelResponse c) drop the feature to configure initial quota for each logical channel, = and redefine the quota parameter as pre-handshake send quota for all = logical channels =20 Until we know the AddChannel was accepted, how can we send data anyway? = This seems just like the initial handshake on a new connection -- you = wouldn't consider sending that data until you knew the connection was = accepted. Since we are avoiding TCP setup requirements, this will be = much less latency than if the connection were created without = multiplexing. =20 I suppose it would be possible to send the data while keeping it = buffered as an optimization, but since adding a channel should be = infrequent compared to sending data on it, I don't see it as that = important to optimize for. =20 --=20 John A. Tamplin Software Engineer (GWT), Google ------=_NextPart_000_0020_01CD1D7E.ECA53FF0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I also feel it is unnecessary to let the client send some payload = that would need to be discarded if the channel is not accepted. =

 

But if this feature is needed for some use cases then I would opt for = using the quota negotiated during the initial handshake as the initial = quota for all logical channels (and wouldn=E2=80=99t negotiate an = initial quota for logical channels since they already have it = granted).

 

With best regards,

Arman

 

From:= = John Tamplin [mailto:jat@google.com]
Sent: Wednesday, April = 18, 2012 3:01 PM
To: Takeshi Yoshino
Cc: Arman = Djusupov; hybi@ietf.org
Subject: Re: Send quota value before = receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID = semantics)

 

On Wed, = Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <tyoshino@google.com> = wrote:

You're right. In the = latest spec, it's not explicitly specified what the value of send quota = is until AddChannelResponse is received.

 

There're several options we can = take.

 

a) specify the fixed value of send quota before = AddChannelResponse in the spec

b) add a new parameter "pre_handshake_quota" = to multiplexing extension to negotiate the value of send quota before = AddChannelResponse

c) drop = the feature to configure initial quota for each logical channel, and = redefine the quota parameter as pre-handshake send quota for all logical = channels

 

Until we know the AddChannel was accepted, how can we = send data anyway?  This seems just like the initial handshake on a = new connection -- you wouldn't consider sending that data until you knew = the connection was accepted.  Since we are avoiding TCP setup = requirements, this will be much less latency than if the connection were = created without multiplexing.

 

I = suppose it would be possible to send the data while keeping it buffered = as an optimization, but since adding a channel should be infrequent = compared to sending data on it, I don't see it as that important to = optimize for.

 

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

------=_NextPart_000_0020_01CD1D7E.ECA53FF0-- From tyoshino@google.com Wed Apr 18 09:50:15 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8439E21F85AF for ; Wed, 18 Apr 2012 09:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.676 X-Spam-Level: X-Spam-Status: No, score=-102.676 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zxlrxxzfmdgs for ; Wed, 18 Apr 2012 09:50:15 -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 A82A221F8593 for ; Wed, 18 Apr 2012 09:50:14 -0700 (PDT) Received: by yenm5 with SMTP id m5so4358965yen.31 for ; Wed, 18 Apr 2012 09:50:14 -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=GI46+E78OYJRpL21DFe2dtcdsLb+EmHlAzfRbn8/0oY=; b=e83UezfS4QdOHOEYQnmecHHj2aG6VljJBkASxroL4Oc45QQoaZgAFVEpyVmiMCpj3m EMIY0os8FnuQAhIIFht0BzBpvKFngFCNZvKCsPmUOm/gfDlIozUIgDoNvWK8/c3iHwOr 0TWKZoZY/v7EnWKdJwcsMcR23lnytIqSetZAnzlPvcdsKDz8vjHSlAOOmmQwbXuSrpnL Z6RVlbDyHU4UhSESD4qz587E6k45dhXTVf3btNYNmUfre3agVgdCi70TAbyA416OuvBB /o49v/qcoSNeou7iRK7cIWbQ+oBuJqsWkYAUDmnf1GkXoZjZx7PAoRbNXeadMhU3WvwY Si3A== 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=GI46+E78OYJRpL21DFe2dtcdsLb+EmHlAzfRbn8/0oY=; b=YkdQZI82dXbb26q5yC/6xcPs0o9ujJ91s8x8U09S+NRwgm0FL5nOgKn/FpC5NoarhG Qev94fUTkmblfiy3KaYe0zTTAW7qg8XyweJX8c4seRtl82uu83+/R9Qdg7MCEgyCAUPg B/V8Zi0jvnQwOJxWnp/aj18xJOrns8BaREKMPA8hei0NrF+baiEewcMZ9T+80yITzB6m F1EcGeNEviO7UdnqP2ACHKFldhAQW4kJTWc9bm7En4HS9pkLVfAyCUxWFhS4flESkUl1 n+keGvP8d3IbepHi7GxfYKvxieJDGrY+IGBTUoo/+cI6IDVInaGLNBXpqwV2EKBAjIec pU8g== Received: by 10.50.194.232 with SMTP id hz8mr2800449igc.38.1334767813915; Wed, 18 Apr 2012 09:50:13 -0700 (PDT) Received: by 10.50.194.232 with SMTP id hz8mr2800438igc.38.1334767813794; Wed, 18 Apr 2012 09:50:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Wed, 18 Apr 2012 09:49:53 -0700 (PDT) In-Reply-To: References: From: Takeshi Yoshino Date: Thu, 19 Apr 2012 01:49:53 +0900 Message-ID: To: John Tamplin , Gabriel Montenegro Content-Type: multipart/alternative; boundary=14dae93405a1661d4604bdf6d9ed X-System-Of-Record: true X-Gm-Message-State: ALoCoQl0X29roy8cJpJRZb4JwAAhT/DuqBeqdnvd3LzNJLUhhQJYKwj/x4o6i84sDxssbS48TfDP1DxqgWx/6SQ3sBdN6v1Ln99kX5Jdh2W5zLX85TKocJSyFfchnOyfl47sQjVKF5EL Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 18 Apr 2012 16:50:15 -0000 --14dae93405a1661d4604bdf6d9ed Content-Type: text/plain; charset=ISO-8859-1 On Wed, Apr 18, 2012 at 21:01, John Tamplin wrote: > On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino wrote: > >> You're right. In the latest spec, it's not explicitly specified what the >> value of send quota is until AddChannelResponse is received. >> >> There're several options we can take. >> >> a) specify the fixed value of send quota before AddChannelResponse in the >> spec >> b) add a new parameter "pre_handshake_quota" to multiplexing extension to >> negotiate the value of send quota before AddChannelResponse >> c) drop the feature to configure initial quota for each logical channel, >> and redefine the quota parameter as pre-handshake send quota for all >> logical channels >> > > Until we know the AddChannel was accepted, how can we send data anyway? > This seems just like the initial handshake on a new connection -- you > wouldn't consider sending that data until you knew the connection was > accepted. Since we are avoiding TCP setup requirements, this will be much > less latency than if the connection were created without multiplexing. > > I suppose it would be possible to send the data while keeping it buffered > as an optimization, but since adding a channel should be infrequent > compared to sending data on it, I don't see it as that important to > optimize for. > Yes. It's infrequent. If the information the impatient client want to send is small, it can also be just embeded into URL or subprotocol to avoid the additional RTT. If no one really needs this feature and has justification, I'm fine with keeping the same restriction (no transmission until AddChannelResponse) as no-mux connection. IIRC, Gabriel was interested in this optimization. Gabriel, do you have any comment about this? --14dae93405a1661d4604bdf6d9ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Apr 18, 2012 at 21:01, John Tamplin <jat@google.com><= /span> wrote:
On Wed, Apr 18, 2012 at 4:15 A= M, Takeshi Yoshino <tyoshino@google.com> wrote:
You're right. In the latest spec, it= 9;s not explicitly specified what the value of send quota is until AddChann= elResponse is received.

There're several optio= ns we can take.

a) specify the fixed value of send quota before AddChan= nelResponse in the spec
b) add a new parameter "pre_handshak= e_quota" to multiplexing extension to negotiate the value of send quot= a before AddChannelResponse
c) drop the feature to configure initial quota for each logical channe= l, and redefine the quota parameter as pre-handshake send quota for all log= ical channels

Until we kn= ow the AddChannel was accepted, how can we send data anyway? =A0This seems = just like the initial handshake on a new connection -- you wouldn't con= sider sending that data until you knew the connection was accepted. =A0Sinc= e we are avoiding TCP setup requirements, this will be much less latency th= an if the connection were created without multiplexing.

I suppose it would be possible to send the data while k= eeping it buffered as an optimization, but since adding a channel should be= infrequent compared to sending data on it, I don't see it as that impo= rtant to optimize for.

Yes. It's infrequent.

If the information the impatient client want to send i= s small, it can also be just embeded into URL or subprotocol to avoid the a= dditional RTT.

If no one really needs this feature and has justificati= on, I'm fine with keeping the same restriction (no transmission until A= ddChannelResponse) as no-mux connection.

IIRC, Gab= riel was interested in this optimization. Gabriel, do you have any comment = about this?

--14dae93405a1661d4604bdf6d9ed-- From Gabriel.Montenegro@microsoft.com Wed Apr 18 21:12:38 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 CAA5111E8079 for ; Wed, 18 Apr 2012 21:12:38 -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 wuA+7BOvTKe4 for ; Wed, 18 Apr 2012 21:12:37 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id A292711E80BA for ; Wed, 18 Apr 2012 21:12:37 -0700 (PDT) Received: from mail190-tx2-R.bigfish.com (10.9.14.237) by TX2EHSOBE003.bigfish.com (10.9.40.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 04:12:36 +0000 Received: from mail190-tx2 (localhost [127.0.0.1]) by mail190-tx2-R.bigfish.com (Postfix) with ESMTP id A48C91E0229; Thu, 19 Apr 2012 04:12:36 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic89bhc857h98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) 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 Received-SPF: pass (mail190-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=TK5EX14HUBC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail190-tx2 (localhost.localdomain [127.0.0.1]) by mail190-tx2 (MessageSwitch) id 1334808754222581_2871; Thu, 19 Apr 2012 04:12:34 +0000 (UTC) Received: from TX2EHSMHS046.bigfish.com (unknown [10.9.14.245]) by mail190-tx2.bigfish.com (Postfix) with ESMTP id 268222E0047; Thu, 19 Apr 2012 04:12:34 +0000 (UTC) Received: from TK5EX14HUBC104.redmond.corp.microsoft.com (131.107.125.8) by TX2EHSMHS046.bigfish.com (10.9.99.146) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 04:12:32 +0000 Received: from TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com (157.54.71.68) by TK5EX14HUBC104.redmond.corp.microsoft.com (157.54.80.25) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 19 Apr 2012 04:12:31 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.247]) by TK5EX14MLTW652.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.68]) with mapi id 14.02.0298.005; Wed, 18 Apr 2012 21:12:30 -0700 From: Gabriel Montenegro To: John Tamplin , Takeshi Yoshino Thread-Topic: Impacts of mux and compression extension on the WebSocket API (was: Re: [hybi] MUC: channel ID semantics) Thread-Index: AQHNDX6B1m2DuqIkVUa8dlZmOOMSv5aB40kAgB8gU4A= Date: Thu, 19 Apr 2012 04:12:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA0D98TK5EX14MBXW602w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "hybi@ietf.org" Subject: Re: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 19 Apr 2012 04:12:38 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA0D98TK5EX14MBXW602w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 X0V4dGVuc2lvbnMgSW4gVXNlXyBkb2VzIG5vdCBzZWVtIGxpa2UgYSAqbmV3KiByZXF1aXJlbWVu dCwgYXMgaXQgd2FzIGFscmVhZHkgc3BlbGxlZCBvdXQgaW4gUkZDNjQ1NSBhbmQgaW5jbHVkZWQg aW4gdGhlIEFQSToNCg0KVGhlIF9FeHRlbnNpb25zIEluIFVzZV8NCiAgIGlzIGRlZmluZWQgdG8g YmUgYSAocG9zc2libHkgZW1wdHkpIHN0cmluZywgdGhlIHZhbHVlIG9mIHdoaWNoIGlzDQogICBl cXVhbCB0byB0aGUgdmFsdWUgb2YgdGhlIHxTZWMtV2ViU29ja2V0LUV4dGVuc2lvbnN8IGhlYWRl ciBmaWVsZA0KICAgc3VwcGxpZWQgYnkgdGhlIHNlcnZlcidzIGhhbmRzaGFrZSBvciB0aGUgbnVs bCB2YWx1ZSBpZiB0aGF0IGhlYWRlcg0KICAgZmllbGQgd2FzIG5vdCBwcmVzZW50IGluIHRoZSBz ZXJ2ZXIncyBoYW5kc2hha2UuDQoNCkFuZCBpbiB0aGUgQVBJIGF0IGh0dHA6Ly93d3cudzMub3Jn L1RSL3dlYnNvY2tldHMvIGl0IGlzOg0KcmVhZG9ubHkgYXR0cmlidXRlIERPTVN0cmluZyBleHRl bnNpb25zPGh0dHA6Ly93d3cudzMub3JnL1RSL3dlYnNvY2tldHMvI2RvbS13ZWJzb2NrZXQtZXh0 ZW5zaW9ucz47DQoNClRoZSBwcm90b2NvbCBhbHNvIGRlZmluZXMgdGhlIGZvcm1hdCAo4oCcZXF1 YWwgdG8gdGhlIHZhbHVlIG9mIHRoZSB8U2VjLVdlYnNvY2tldC1FeHRlbnNpb25zfCBoZWFkZXIg ZmllbGTigJ0gd2hvc2UgQUJORiBpcyBkZWZpbmVkIGluIFJGQzY0NTUuIE9yIGFyZSB5b3UgcmVm ZXJyaW5nIHRvIHNvbWV0aGluZyBlbHNlPw0KDQpGcm9tOiBKb2huIFRhbXBsaW4gW21haWx0bzpq YXRAZ29vZ2xlLmNvbV0NClNlbnQ6IFRodXJzZGF5LCAyOSBNYXJjaCwgMjAxMiA4OjU2DQpUbzog VGFrZXNoaSBZb3NoaW5vDQpDYzogR2FicmllbCBNb250ZW5lZ3JvOyBoeWJpQGlldGYub3JnDQpT dWJqZWN0OiBSZTogSW1wYWN0cyBvZiBtdXggYW5kIGNvbXByZXNzaW9uIGV4dGVuc2lvbiBvbiB0 aGUgV2ViU29ja2V0IEFQSSAod2FzOiBSZTogW2h5YmldIE1VQzogY2hhbm5lbCBJRCBzZW1hbnRp Y3MpDQoNCk9uIFRodSwgTWFyIDI5LCAyMDEyIGF0IDM6MzQgQU0sIFRha2VzaGkgWW9zaGlubyA8 dHlvc2hpbm9AZ29vZ2xlLmNvbTxtYWlsdG86dHlvc2hpbm9AZ29vZ2xlLmNvbT4+IHdyb3RlOg0K Tm90IHRoZSBpc3N1ZSBkaXNjdXNzZWQgaW4gdGhlIGYyZiBtZWV0aW5nLCBidXQgSSdtIHN1cmUg dGhhdCBpbnRyb2R1Y3Rpb24gb2YgZXh0ZW5zaW9ucyB3ZSdyZSBub3cgd29ya2luZyBvbiBpbXBh Y3RzIGV4dGVuc2lvbnMgYXR0cmlidXRlIG9mIHRoZSBXZWJTb2NrZXQgQVBJLg0KDQoxLiB0aGUg QVBJIG11c3QgZGVmaW5lIGluIHdoYXQgZm9ybSBpdCBleHBvcnRzIF9FeHRlbnNpb25zIEluIFVz ZV8uIFdoYXQgdG8gaW5jbHVkZSAoanVzdCB0b2tlbj8gcGFyYW1ldGVycyB0b2dldGhlcj8pLCBm b3JtYXR0aW5nLCBldGMuDQoNCkFoLCBJIHdhc24ndCBhd2FyZSB0aGV5IGFkZGVkIHRoYXQuICBN YWtpbmcgV2VTb2NrZXQuZXh0ZW5zaW9ucyBiZSBhIERPTVN0cmluZyBzZWVtcyBsaWtlIGEgcG9v ciBpZGVhLCBhcyB5b3Ugbm93IGhhdmUgdG8gZW5jb2RlIHRoZSBsaXN0IG9mIGV4dGVuc2lvbnMg KHBvc3NpYmx5IHdpdGggdGhlaXIgcGFyYW1ldGVycykgaW50byBhIHN0cmluZywgYW5kIHRoZSBK UyB3aWxsIGhhdmUgdG8gZGVjb2RlIGl0LiAgSXQgc2VlbXMgbWFraW5nIGl0IHJldHVybiBhIGxp c3Qgb2Ygb2JqZWN0cyB3aXRoIGRlZmluZWQgcHJvcGVydGllcyB3b3VsZCBiZSBtdWNoIGJldHRl ci4NCg0KMi4gdW5kZXIgdXNlIG9mIHRoZSBtdWx0aXBsZXhpbmcgZXh0ZW5zaW9uLCBTZWMtV2Vi U29ja2V0LUV4dGVuc2lvbnMgaGVhZGVyIHdpbGwgY29udGFpbiBib3RoIGV4dGVuc2lvbnMgYXBw bGllZCB0byBwaHlzaWNhbCBjaGFubmVsIGFuZCBsb2dpY2FsIGNoYW5uZWxzLiBXZSBtdXN0IGZp Z3VyZSBvdXQgd2hhdCBzaG91bGQgYmUgZXhwb3J0ZWQgZnJvbSB0aGlzIG1peHR1cmUgYW5kIHdo aWNoIHNpZGUgc2hvdWxkIGRvIHN1Y2ggdHJhbnNmb3JtYXRpb24gaWYgYW55IGJ5IGNvb3JkaW5h dGluZyB3aXRoIHdlYmFwcHMgV0cuDQoNClNpbmNlIHRoZSBXZWJTb2NrZXQgb2JqZWN0IGluIHRo ZSBicm93c2VyIG1heSBiZSBhIHBoeXNpY2FsIG9yIGxvZ2ljYWwgY2hhbm5lbCBhbmQgYXBwbGlj YXRpb25zIHNob3VsZG4ndCBrbm93IHRoZSBkaWZmZXJlbmNlLCBpdCBzZWVtcyB0byBtZSB0aGF0 IHRoZSBleHRlbnNpb25zIGhhdmUgdG8gYmUgdGhhdCBvZiB0aGUgbG9naWNhbCBjaGFubmVsIGlu IHRoZSBtdXggY2FzZS4NCg0KLS0NCkpvaG4gQS4gVGFtcGxpbg0KU29mdHdhcmUgRW5naW5lZXIg KEdXVCksIEdvb2dsZQ0K --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA0D98TK5EX14MBXW602w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOmR0PSJ1dWlkOkMyRjQxMDEwLTY1QjMtMTFkMS1B MjlGLTAwQUEwMEMxNDg4MiIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9v ZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0 MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0i TWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0K CW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47 DQoJbWFyZ2luLWxlZnQ6MjQuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5fPGk+RXh0ZW5zaW9u cyBJbiBVc2U8L2k+XyBkb2VzIG5vdCBzZWVtIGxpa2UgYSAqPGI+bmV3PC9iPiogcmVxdWlyZW1l bnQsIGFzIGl0IHdhcyBhbHJlYWR5IHNwZWxsZWQgb3V0IGluIFJGQzY0NTUgYW5kIGluY2x1ZGVk IGluIHRoZSBBUEk6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPlRoZSBfRXh0ZW5zaW9ucyBJbiBVc2VfPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGlzIGRlZmluZWQgdG8gYmUgYSAocG9zc2libHkgZW1wdHkpIHN0 cmluZywgdGhlIHZhbHVlIG9mIHdoaWNoIGlzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFu Zz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IGVxdWFsIHRvIHRoZSB2YWx1ZSBvZiB0aGUgfFNlYy1XZWJTb2NrZXQtRXh0ZW5zaW9u c3wgaGVhZGVyIGZpZWxkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IHN1cHBs aWVkIGJ5IHRoZSBzZXJ2ZXIncyBoYW5kc2hha2Ugb3IgdGhlIG51bGwgdmFsdWUgaWYgdGhhdCBo ZWFkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IGZpZWxkIHdhcyBub3QgcHJlc2VudCBpbiB0aGUgc2VydmVy J3MgaGFuZHNoYWtlLiZuYnNwOw0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkFuZCBpbiB0aGUgQVBJIGF0IGh0dHA6Ly93d3cudzMu b3JnL1RSL3dlYnNvY2tldHMvIGl0IGlzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjYuMHB0IDEyLjBwdCA2LjBwdCAxMi4wcHQ7YmFja2dyb3VuZDojRUVFRUVF O21hcmdpbi1sZWZ0OjI0LjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNFRUVFRUU7Ym9yZGVyOm5vbmU7cGFkZGluZzowaW4iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5yZWFkb25seSBhdHRyaWJ1dGUgRE9NU3RyaW5nDQo8YSBocmVm PSJodHRwOi8vd3d3LnczLm9yZy9UUi93ZWJzb2NrZXRzLyNkb20td2Vic29ja2V0LWV4dGVuc2lv bnMiIHRpdGxlPSJkb20tV2ViU29ja2V0LWV4dGVuc2lvbnMiPg0KZXh0ZW5zaW9uczwvYT47PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPlRoZSBwcm90b2NvbCBhbHNvIGRlZmluZXMgdGhlIGZvcm1hdCAo4oCc ZXF1YWwgdG8gdGhlIHZhbHVlIG9mIHRoZSB8U2VjLVdlYnNvY2tldC1FeHRlbnNpb25zfCBoZWFk ZXIgZmllbGTigJ0gd2hvc2UgQUJORiBpcyBkZWZpbmVkIGluIFJGQzY0NTUuIE9yIGFyZSB5b3Ug cmVmZXJyaW5nDQogdG8gc29tZXRoaW5nIGVsc2U/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBKb2huIFRhbXBsaW4gW21haWx0bzpqYXRAZ29vZ2xlLmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgMjkgTWFyY2gsIDIwMTIgODo1Njxicj4NCjxiPlRv OjwvYj4gVGFrZXNoaSBZb3NoaW5vPGJyPg0KPGI+Q2M6PC9iPiBHYWJyaWVsIE1vbnRlbmVncm87 IGh5YmlAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IEltcGFjdHMgb2YgbXV4IGFu ZCBjb21wcmVzc2lvbiBleHRlbnNpb24gb24gdGhlIFdlYlNvY2tldCBBUEkgKHdhczogUmU6IFto eWJpXSBNVUM6IGNoYW5uZWwgSUQgc2VtYW50aWNzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFRodSwgTWFyIDI5LCAyMDEyIGF0IDM6MzQgQU0sIFRha2VzaGkgWW9z aGlubyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnR5b3NoaW5vQGdvb2dsZS5jb20iPnR5b3NoaW5vQGdv b2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ob3QgdGhlIGlzc3VlIGRpc2N1c3NlZCBpbiB0aGUgZjJmIG1lZXRpbmcsIGJ1 dCBJJ20gc3VyZSB0aGF0IGludHJvZHVjdGlvbiBvZiBleHRlbnNpb25zIHdlJ3JlIG5vdyB3b3Jr aW5nIG9uIGltcGFjdHMgZXh0ZW5zaW9ucyBhdHRyaWJ1dGUgb2YgdGhlIFdlYlNvY2tldCBBUEku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjEu IHRoZSBBUEkgbXVzdCBkZWZpbmUgaW4gd2hhdCBmb3JtIGl0IGV4cG9ydHMgX0V4dGVuc2lvbnMg SW4gVXNlXy4gV2hhdCB0byBpbmNsdWRlIChqdXN0IHRva2VuPyBwYXJhbWV0ZXJzIHRvZ2V0aGVy PyksIGZvcm1hdHRpbmcsIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QWgsIEkgd2Fzbid0IGF3YXJlIHRoZXkgYWRkZWQgdGhhdC4gJm5i c3A7TWFraW5nIFdlU29ja2V0LmV4dGVuc2lvbnMgYmUgYSBET01TdHJpbmcgc2VlbXMgbGlrZSBh IHBvb3IgaWRlYSwgYXMgeW91IG5vdyBoYXZlIHRvIGVuY29kZSB0aGUgbGlzdCBvZiBleHRlbnNp b25zIChwb3NzaWJseSB3aXRoIHRoZWlyIHBhcmFtZXRlcnMpIGludG8gYSBzdHJpbmcsIGFuZCB0 aGUgSlMgd2lsbCBoYXZlIHRvIGRlY29kZSBpdC4gJm5ic3A7SXQNCiBzZWVtcyBtYWtpbmcgaXQg cmV0dXJuIGEgbGlzdCBvZiBvYmplY3RzIHdpdGggZGVmaW5lZCBwcm9wZXJ0aWVzIHdvdWxkIGJl IG11Y2ggYmV0dGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gdW5kZXIgdXNlIG9mIHRoZSBtdWx0aXBsZXhpbmcg ZXh0ZW5zaW9uLCBTZWMtV2ViU29ja2V0LUV4dGVuc2lvbnMgaGVhZGVyIHdpbGwgY29udGFpbiBi b3RoIGV4dGVuc2lvbnMgYXBwbGllZCB0byBwaHlzaWNhbCBjaGFubmVsIGFuZCBsb2dpY2FsIGNo YW5uZWxzLiBXZSBtdXN0IGZpZ3VyZSBvdXQgd2hhdCBzaG91bGQgYmUgZXhwb3J0ZWQgZnJvbSB0 aGlzIG1peHR1cmUgYW5kIHdoaWNoIHNpZGUgc2hvdWxkDQogZG8gc3VjaCB0cmFuc2Zvcm1hdGlv biBpZiBhbnkgYnkgY29vcmRpbmF0aW5nIHdpdGggd2ViYXBwcyBXRy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2lu Y2UgdGhlIFdlYlNvY2tldCBvYmplY3QgaW4gdGhlIGJyb3dzZXIgbWF5IGJlIGEgcGh5c2ljYWwg b3IgbG9naWNhbCBjaGFubmVsIGFuZCBhcHBsaWNhdGlvbnMgc2hvdWxkbid0IGtub3cgdGhlIGRp ZmZlcmVuY2UsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIGV4dGVuc2lvbnMgaGF2ZSB0byBiZSB0 aGF0IG9mIHRoZSBsb2dpY2FsIGNoYW5uZWwgaW4gdGhlIG11eCBjYXNlLiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gPGJyPg0K Sm9obiBBLiBUYW1wbGluPGJyPg0KU29mdHdhcmUgRW5naW5lZXIgKEdXVCksIEdvb2dsZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA0D98TK5EX14MBXW602w_-- From jat@google.com Wed Apr 18 21:14: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 9C8C421F8450 for ; Wed, 18 Apr 2012 21:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.826 X-Spam-Level: X-Spam-Status: No, score=-102.826 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 ldlvoDKBhmye for ; Wed, 18 Apr 2012 21:14:49 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DA9AA11E8079 for ; Wed, 18 Apr 2012 21:14:48 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so6304876vbb.31 for ; Wed, 18 Apr 2012 21:14:48 -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=H+XacpE7Xa4Opssslig6T5lLDN+0nYGVSSGz0eb7lVs=; b=H9woeu2iOLNzNaNyopNoCzI38zgNrOnG7/+4x8a91mpI8FBtMfNCaRngVhyOY8arcw udXglddLXLbQreraYBOL3PsoSwskK3POlNWgR2ClUpxHxdkiOwuGnpve45Nu6EHfmGDQ HH8+CES0OXUlByc0N6cpvqX7fmumTFv9Na1zefyeUgB2qyX/tZNZGbxeTGaoJVkfF9SP avxNPEhs+jTr+xWJ9xmQ+uvC4aEXXKFbVOBuphHrl76yFExmgtLJTtpMK4r7E7ORIW+b k6unOV46jjeTDWqrJ8KO67BZKNzfNxLAheHFE843GyPMW5gkPhMK9ncnI196ivaKjA3X FnqA== 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=H+XacpE7Xa4Opssslig6T5lLDN+0nYGVSSGz0eb7lVs=; b=N2pHqdPLGyqBq5O0G3pgSsBszFib63IONVawUw0OwZIzzpU1OpzZKWNOrkWiTm6280 h+8vp3jwD0ngEoIj/Ywx9EoDRV/teXrqmlQjrwlGycp5ZyFrd9X6mH9n8NWmwb9ATZp1 wGdxNcK4eifXxpxmuu+Qs3wWZ4AIkXxljlmjJLkA3hwt9q3CN9uzt7+8DOnMUeI0KJkY rxg94jvS2DESEhk2JSQa8ZaQ82/uC3or2HbEWtjzLSBTrqlpKJ7DO2jjPDW0XDFcKLg7 C7qyk5np54OjOtwW8i/n8RRd9iPYBQ9mD36qzkvU6JG6PQXWZu9mew4tFfKx6b5WS424 +WOQ== Received: by 10.220.228.200 with SMTP id jf8mr342433vcb.0.1334808887937; Wed, 18 Apr 2012 21:14:47 -0700 (PDT) Received: by 10.220.228.200 with SMTP id jf8mr342425vcb.0.1334808887824; Wed, 18 Apr 2012 21:14:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.17.193 with HTTP; Wed, 18 Apr 2012 21:14:27 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Thu, 19 Apr 2012 00:14:27 -0400 Message-ID: To: Gabriel Montenegro Content-Type: multipart/alternative; boundary=14dae9cdc0f99a102804be0069bf X-System-Of-Record: true X-Gm-Message-State: ALoCoQmcKePmmylWuvt7fv68FMHMmIAR3q/OkO8P4kgVaspb5pOlFf5QoKcvOyd9yBDaOjHf647S/dpFJCcHGfu7FDFnooqrWFnh8uYGRVruhJS9xOnGyz8X1+CUJ2XbzLlDFhpvk4EV Cc: "hybi@ietf.org" Subject: Re: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 19 Apr 2012 04:14:49 -0000 --14dae9cdc0f99a102804be0069bf Content-Type: text/plain; charset=UTF-8 On Thu, Apr 19, 2012 at 12:12 AM, Gabriel Montenegro < Gabriel.Montenegro@microsoft.com> wrote: > _*Extensions In Use*_ does not seem like a **new** requirement, as it > was already spelled out in RFC6455 and included in the API: > To clarify - I meant "added since I last looked closely at the spec under development". -- John A. Tamplin Software Engineer (GWT), Google --14dae9cdc0f99a102804be0069bf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 19, 2012 at 12:12 AM, Gabriel Monten= egro <Gabriel.Montenegro@microsoft.com> wrote:

_Extensions In Use= _ does not seem like a *new* requirement, as it was already spelled = out in RFC6455 and included in the API:


To clarify - I meant "add= ed since I last looked closely at the spec under development".=C2=A0

--
John A. Tamplin
Software Engineer (GWT),= Google
--14dae9cdc0f99a102804be0069bf-- From Gabriel.Montenegro@microsoft.com Wed Apr 18 22:41:38 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 14BA721F84E1 for ; Wed, 18 Apr 2012 22:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[AWL=-1.500, 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 Ld-7LjYDmTdH for ; Wed, 18 Apr 2012 22:41:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 803C921F84DF for ; Wed, 18 Apr 2012 22:41:35 -0700 (PDT) Received: from mail25-am1-R.bigfish.com (10.3.201.235) by AM1EHSOBE004.bigfish.com (10.3.204.24) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 05:41:34 +0000 Received: from mail25-am1 (localhost [127.0.0.1]) by mail25-am1-R.bigfish.com (Postfix) with ESMTP id 360F9E03AB; Thu, 19 Apr 2012 05:41:34 +0000 (UTC) X-SpamScore: -24 X-BigFish: VS-24(zz9371Ic85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC104.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail25-am1: 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=TK5EX14MLTC104.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail25-am1 (localhost.localdomain [127.0.0.1]) by mail25-am1 (MessageSwitch) id 1334814091727279_31609; Thu, 19 Apr 2012 05:41:31 +0000 (UTC) Received: from AM1EHSMHS004.bigfish.com (unknown [10.3.201.232]) by mail25-am1.bigfish.com (Postfix) with ESMTP id ACF26A01BD; Thu, 19 Apr 2012 05:41:31 +0000 (UTC) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS004.bigfish.com (10.3.207.104) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 05:41:31 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 19 Apr 2012 05:41:01 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.247]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0298.005; Wed, 18 Apr 2012 22:41:01 -0700 From: Gabriel Montenegro To: Takeshi Yoshino , John Tamplin Thread-Topic: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics) Thread-Index: AQHNHYNZVNCvN/MkuEa7uhOfYIR9cZahobhQ Date: Thu, 19 Apr 2012 05:41:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.90] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0TK5EX14MBXW602w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "hybi@ietf.org" Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 19 Apr 2012 05:41:38 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0TK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In all previous discussions in this WG there has been relentless push to op= timize any RTTs out of the protocol. Consistent with this is being able to = use the lightweight channel setup (as is possible in SPDY) in which data tr= ansmission is possible without requiring the ack. If I'm the only one askin= g about this, perhaps the WG is no longer interested in such optimizations,= but I'd still be interested in understanding the change of heart. From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, 18 April, 2012 9:50 To: John Tamplin; Gabriel Montenegro Cc: Arman Djusupov; hybi@ietf.org Subject: Re: Send quota value before receiving AddChannelResponse (was: Re:= [hybi] MUC: channel ID semantics) On Wed, Apr 18, 2012 at 21:01, John Tamplin > wrote: On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino > wrote: You're right. In the latest spec, it's not explicitly specified what the va= lue of send quota is until AddChannelResponse is received. There're several options we can take. a) specify the fixed value of send quota before AddChannelResponse in the s= pec b) add a new parameter "pre_handshake_quota" to multiplexing extension to n= egotiate the value of send quota before AddChannelResponse c) drop the feature to configure initial quota for each logical channel, an= d redefine the quota parameter as pre-handshake send quota for all logical = channels Until we know the AddChannel was accepted, how can we send data anyway? Th= is seems just like the initial handshake on a new connection -- you wouldn'= t consider sending that data until you knew the connection was accepted. S= ince we are avoiding TCP setup requirements, this will be much less latency= than if the connection were created without multiplexing. I suppose it would be possible to send the data while keeping it buffered a= s an optimization, but since adding a channel should be infrequent compared= to sending data on it, I don't see it as that important to optimize for. Yes. It's infrequent. If the information the impatient client want to send is small, it can also = be just embeded into URL or subprotocol to avoid the additional RTT. If no one really needs this feature and has justification, I'm fine with ke= eping the same restriction (no transmission until AddChannelResponse) as no= -mux connection. IIRC, Gabriel was interested in this optimization. Gabriel, do you have any= comment about this? --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0TK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In all previous discussio= ns in this WG there has been relentless push to optimize any RTTs out of th= e protocol. Consistent with this is being able to use the lightweight channel setup (as is possible in SPDY) in which data transmiss= ion is possible without requiring the ack. If I’m the only one asking= about this, perhaps the WG is no longer interested in such optimizations, = but I’d still be interested in understanding the change of heart.

 <= /p>

From: Takeshi = Yoshino [mailto:tyoshino@google.com]
Sent: Wednesday, 18 April, 2012 9:50
To: John Tamplin; Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: Send quota value before receiving AddChannelResponse (w= as: Re: [hybi] MUC: channel ID semantics)

 

On Wed, Apr 18, 2012 at 21:01, John Tamplin <jat@google.com> wrote:

On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <= ;tyoshino@google.c= om> wrote:

You're right. In the latest spec, it's not explicitl= y specified what the value of send quota is until AddChannelResponse is rec= eived.

 

There're several options we can take.

 

a) specify the fixed value of send quota before AddC= hannelResponse in the spec

b) add a new parameter "pre_handshake_quota&quo= t; to multiplexing extension to negotiate the value of send quota before Ad= dChannelResponse

c) drop the feature to configure initial quota for e= ach logical channel, and redefine the quota parameter as pre-handshake send= quota for all logical channels

 

Until we know the AddChannel was accepted, how can w= e send data anyway?  This seems just like the initial handshake on a n= ew connection -- you wouldn't consider sending that data until you knew the= connection was accepted.  Since we are avoiding TCP setup requirements, this will be much less latency than if th= e connection were created without multiplexing.

 

I suppose it would be possible to send the data whil= e keeping it buffered as an optimization, but since adding a channel should= be infrequent compared to sending data on it, I don't see it as that impor= tant to optimize for.

 

Yes. It's infrequent.

 

If the information the impatient client want to send= is small, it can also be just embeded into URL or subprotocol to avoid the= additional RTT.

 

If no one really needs this feature and has justific= ation, I'm fine with keeping the same restriction (no transmission until Ad= dChannelResponse) as no-mux connection.

 

IIRC, Gabriel was interested in this optimization. G= abriel, do you have any comment about this?

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA4EA0TK5EX14MBXW602w_-- From arman@noemax.com Thu Apr 19 03:13: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 BD83B21F8594 for ; Thu, 19 Apr 2012 03:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmfkJ+Dut7mo for ; Thu, 19 Apr 2012 03:13:25 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 8178F21F858A for ; Thu, 19 Apr 2012 03:13:25 -0700 (PDT) Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id DOG18328; Thu, 19 Apr 2012 13:13:28 +0300 From: "Arman Djusupov" To: "'Gabriel Montenegro'" , "'Takeshi Yoshino'" , "'John Tamplin'" References: In-Reply-To: Date: Thu, 19 Apr 2012 13:13:14 +0300 Message-ID: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CD1E2E.31DD0670" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDpAB3Ba5pDAvrAhMo3RFqWK7Q0QGeXeAIAYMcRbwA5LM+P5eUrvRQ Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 19 Apr 2012 10:13:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0026_01CD1E2E.31DD0670 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We are simply considering whether letting the client to send frames before the logical channel is accepted is worth it in order to remove this short RTT. This feature would also require that the sever buffers the frames of the logical channel until it is accepted. On the server side the procedure of adding logical channels is not certain to be fast. It may involve querying the database or establishing a new physical connection. For the duration of this operation the server would have to spend some amount of its resources despite it would be unclear whether the new logical channel is accepted or not. The best solution would be to have the server control this by using a default value for the initial quota during the physical channel handshake. For example, the server could set the quota explicitly to "0" during the physical channel handshake, in which case all logical channels (including first one) would be prohibited from sending any data until the channel is accepted and so all clients would have to wait for the first flow control message to arrive from the server side. Note that this flow control message may arrive in the same frame as the AddChannelResponse without any additional RTT. Practically we don't need to change much in the spec, we just need to be able to negotiate the default quotas during the physical channel handshake. Any additional quotas can be easily granted using the flow control messages that may arrive in the same frame as AddChannelRequest or AddChannelResponse. With best regards, Arman From: Gabriel Montenegro [mailto:Gabriel.Montenegro@microsoft.com] Sent: Thursday, April 19, 2012 8:41 AM To: Takeshi Yoshino; John Tamplin Cc: Arman Djusupov; hybi@ietf.org Subject: RE: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics) In all previous discussions in this WG there has been relentless push to optimize any RTTs out of the protocol. Consistent with this is being able to use the lightweight channel setup (as is possible in SPDY) in which data transmission is possible without requiring the ack. If I'm the only one asking about this, perhaps the WG is no longer interested in such optimizations, but I'd still be interested in understanding the change of heart. From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, 18 April, 2012 9:50 To: John Tamplin; Gabriel Montenegro Cc: Arman Djusupov; hybi@ietf.org Subject: Re: Send quota value before receiving AddChannelResponse (was: Re: [hybi] MUC: channel ID semantics) On Wed, Apr 18, 2012 at 21:01, John Tamplin wrote: On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino wrote: You're right. In the latest spec, it's not explicitly specified what the value of send quota is until AddChannelResponse is received. There're several options we can take. a) specify the fixed value of send quota before AddChannelResponse in the spec b) add a new parameter "pre_handshake_quota" to multiplexing extension to negotiate the value of send quota before AddChannelResponse c) drop the feature to configure initial quota for each logical channel, and redefine the quota parameter as pre-handshake send quota for all logical channels Until we know the AddChannel was accepted, how can we send data anyway? This seems just like the initial handshake on a new connection -- you wouldn't consider sending that data until you knew the connection was accepted. Since we are avoiding TCP setup requirements, this will be much less latency than if the connection were created without multiplexing. I suppose it would be possible to send the data while keeping it buffered as an optimization, but since adding a channel should be infrequent compared to sending data on it, I don't see it as that important to optimize for. Yes. It's infrequent. If the information the impatient client want to send is small, it can also be just embeded into URL or subprotocol to avoid the additional RTT. If no one really needs this feature and has justification, I'm fine with keeping the same restriction (no transmission until AddChannelResponse) as no-mux connection. IIRC, Gabriel was interested in this optimization. Gabriel, do you have any comment about this? ------=_NextPart_000_0026_01CD1E2E.31DD0670 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We are simply considering whether letting the client to send frames = before the logical channel is accepted is worth it in order to remove = this short RTT. This feature would also require that the sever buffers = the frames of the logical channel until it is accepted. On the server = side the procedure of adding logical channels is not certain to be fast. = It may involve querying the database or establishing a new physical = connection. For the duration of this operation the server would have to = spend some amount of its resources despite it would be unclear whether = the new logical channel is accepted or not.

 

The best solution would be to have the server control this by using a = default value for the initial quota during the physical channel = handshake. For example, the server could set the quota explicitly to = “0” during the physical channel handshake, in which case all = logical channels (including first one) would be prohibited from sending = any data until the channel is accepted and so all clients would have to = wait for the first flow control message to arrive from the server side. = Note that this flow control message may arrive in the same frame as the = AddChannelResponse without any additional RTT.

 

Practically we don’t need to change much in the spec, we just = need to be able to negotiate the default quotas during the physical = channel handshake. Any additional quotas can be easily granted using the = flow control messages that may arrive in the same frame as = AddChannelRequest or AddChannelResponse.

 

With best regards,

Arman

 

From:= = Gabriel Montenegro [mailto:Gabriel.Montenegro@microsoft.com] =
Sent: Thursday, April 19, 2012 8:41 AM
To: Takeshi = Yoshino; John Tamplin
Cc: Arman Djusupov; = hybi@ietf.org
Subject: RE: Send quota value before receiving = AddChannelResponse (was: Re: [hybi] MUC: channel ID = semantics)

 

In all previous discussions in this WG there has been relentless push = to optimize any RTTs out of the protocol. Consistent with this is being = able to use the lightweight channel setup (as is possible in SPDY) in = which data transmission is possible without requiring the ack. If = I’m the only one asking about this, perhaps the WG is no longer = interested in such optimizations, but I’d still be interested in = understanding the change of heart.

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]=
Sent: Wednesday, 18 April, 2012 9:50
To: John = Tamplin; Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: = Send quota value before receiving AddChannelResponse (was: Re: [hybi] = MUC: channel ID semantics)

 

On Wed, = Apr 18, 2012 at 21:01, John Tamplin <jat@google.com> = wrote:

On Wed, Apr 18, 2012 = at 4:15 AM, Takeshi Yoshino <tyoshino@google.com> = wrote:

You're right. In the = latest spec, it's not explicitly specified what the value of send quota = is until AddChannelResponse is received.

 

There're several options we can = take.

 

a) specify the fixed value of send quota before = AddChannelResponse in the spec

b) add a new parameter "pre_handshake_quota" = to multiplexing extension to negotiate the value of send quota before = AddChannelResponse

c) drop = the feature to configure initial quota for each logical channel, and = redefine the quota parameter as pre-handshake send quota for all logical = channels

 

Until we know the AddChannel was accepted, how can we = send data anyway?  This seems just like the initial handshake on a = new connection -- you wouldn't consider sending that data until you knew = the connection was accepted.  Since we are avoiding TCP setup = requirements, this will be much less latency than if the connection were = created without multiplexing.

 

I = suppose it would be possible to send the data while keeping it buffered = as an optimization, but since adding a channel should be infrequent = compared to sending data on it, I don't see it as that important to = optimize for.

 

Yes. = It's infrequent.

 

If the information the impatient client want to send = is small, it can also be just embeded into URL or subprotocol to avoid = the additional RTT.

 

If no one really needs this feature and has = justification, I'm fine with keeping the same restriction (no = transmission until AddChannelResponse) as no-mux = connection.

 

IIRC, Gabriel was interested in this optimization. = Gabriel, do you have any comment about this?

 

------=_NextPart_000_0026_01CD1E2E.31DD0670-- From Gabriel.Montenegro@microsoft.com Thu Apr 19 08:15:10 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 13AD821F8624 for ; Thu, 19 Apr 2012 08:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 9qbVEqocC4Br for ; Thu, 19 Apr 2012 08:15:06 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAA121F85A4 for ; Thu, 19 Apr 2012 08:15:05 -0700 (PDT) Received: from mail61-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE005.bigfish.com (10.3.204.25) with Microsoft SMTP Server id 14.1.225.23; Thu, 19 Apr 2012 15:15:03 +0000 Received: from mail61-am1 (localhost [127.0.0.1]) by mail61-am1-R.bigfish.com (Postfix) with ESMTP id B598D360BD2; Thu, 19 Apr 2012 15:14:20 +0000 (UTC) X-SpamScore: -29 X-BigFish: VS-29(zz9371I3071Mc85fh98dKzz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14HUBC101.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail61-am1: 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=TK5EX14HUBC101.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail61-am1 (localhost.localdomain [127.0.0.1]) by mail61-am1 (MessageSwitch) id 1334848446873417_30689; Thu, 19 Apr 2012 15:14:06 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.229]) by mail61-am1.bigfish.com (Postfix) with ESMTP id BC15A3E0054; Thu, 19 Apr 2012 15:14:06 +0000 (UTC) Received: from TK5EX14HUBC101.redmond.corp.microsoft.com (131.107.125.8) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 19 Apr 2012 15:13:59 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.2.283.4; Thu, 19 Apr 2012 15:13:51 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.247]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0298.005; Thu, 19 Apr 2012 08:13:51 -0700 From: Gabriel Montenegro To: Arman Djusupov , 'Takeshi Yoshino' , 'John Tamplin' Thread-Topic: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) Thread-Index: AQHNHhUWs7D0ipFvwUGcrI5D8c49nZaiQRgQ Date: Thu, 19 Apr 2012 15:13:50 +0000 Message-ID: References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> In-Reply-To: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.42] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA9596TK5EX14MBXW602w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "hybi@ietf.org" Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 19 Apr 2012 15:15:10 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA9596TK5EX14MBXW602w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not sure "short RTT" is a valid expression any more. At any rate, I'm f= ine with adding safeguards, but ultimately, it would be a shame to preclude= data from flowing along with the AddChannel request. From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Arm= an Djusupov Sent: Thursday, 19 April, 2012 3:13 To: Gabriel Montenegro; 'Takeshi Yoshino'; 'John Tamplin' Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (w= as: Re: MUC: channel ID semantics) We are simply considering whether letting the client to send frames before = the logical channel is accepted is worth it in order to remove this short R= TT. This feature would also require that the sever buffers the frames of th= e logical channel until it is accepted. On the server side the procedure of= adding logical channels is not certain to be fast. It may involve querying= the database or establishing a new physical connection. For the duration o= f this operation the server would have to spend some amount of its resource= s despite it would be unclear whether the new logical channel is accepted o= r not. The best solution would be to have the server control this by using a defau= lt value for the initial quota during the physical channel handshake. For e= xample, the server could set the quota explicitly to "0" during the physica= l channel handshake, in which case all logical channels (including first on= e) would be prohibited from sending any data until the channel is accepted = and so all clients would have to wait for the first flow control message to= arrive from the server side. Note that this flow control message may arriv= e in the same frame as the AddChannelResponse without any additional RTT. Practically we don't need to change much in the spec, we just need to be ab= le to negotiate the default quotas during the physical channel handshake. A= ny additional quotas can be easily granted using the flow control messages = that may arrive in the same frame as AddChannelRequest or AddChannelRespons= e. With best regards, Arman From: Gabriel Montenegro [mailto:Gabriel.Montenegro@microsoft.com] Sent: Thursday, April 19, 2012 8:41 AM To: Takeshi Yoshino; John Tamplin Cc: Arman Djusupov; hybi@ietf.org Subject: RE: Send quota value before receiving AddChannelResponse (was: Re:= [hybi] MUC: channel ID semantics) In all previous discussions in this WG there has been relentless push to op= timize any RTTs out of the protocol. Consistent with this is being able to = use the lightweight channel setup (as is possible in SPDY) in which data tr= ansmission is possible without requiring the ack. If I'm the only one askin= g about this, perhaps the WG is no longer interested in such optimizations,= but I'd still be interested in understanding the change of heart. From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Wednesday, 18 April, 2012 9:50 To: John Tamplin; Gabriel Montenegro Cc: Arman Djusupov; hybi@ietf.org Subject: Re: Send quota value before receiving AddChannelResponse (was: Re:= [hybi] MUC: channel ID semantics) On Wed, Apr 18, 2012 at 21:01, John Tamplin > wrote: On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino > wrote: You're right. In the latest spec, it's not explicitly specified what the va= lue of send quota is until AddChannelResponse is received. There're several options we can take. a) specify the fixed value of send quota before AddChannelResponse in the s= pec b) add a new parameter "pre_handshake_quota" to multiplexing extension to n= egotiate the value of send quota before AddChannelResponse c) drop the feature to configure initial quota for each logical channel, an= d redefine the quota parameter as pre-handshake send quota for all logical = channels Until we know the AddChannel was accepted, how can we send data anyway? Th= is seems just like the initial handshake on a new connection -- you wouldn'= t consider sending that data until you knew the connection was accepted. S= ince we are avoiding TCP setup requirements, this will be much less latency= than if the connection were created without multiplexing. I suppose it would be possible to send the data while keeping it buffered a= s an optimization, but since adding a channel should be infrequent compared= to sending data on it, I don't see it as that important to optimize for. Yes. It's infrequent. If the information the impatient client want to send is small, it can also = be just embeded into URL or subprotocol to avoid the additional RTT. If no one really needs this feature and has justification, I'm fine with ke= eping the same restriction (no transmission until AddChannelResponse) as no= -mux connection. IIRC, Gabriel was interested in this optimization. Gabriel, do you have any= comment about this? --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA9596TK5EX14MBXW602w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m not sure “= ;short RTT” is a valid expression any more. At any rate, I’m fi= ne with adding safeguards, but ultimately, it would be a shame to preclude = data from flowing along with the AddChannel request.

 <= /p>

From: hybi-bou= nces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Arman Djusupov
Sent: Thursday, 19 April, 2012 3:13
To: Gabriel Montenegro; 'Takeshi Yoshino'; 'John Tamplin'
Cc: hybi@ietf.org
Subject: Re: [hybi] Send quota value before receiving AddChannelResp= onse (was: Re: MUC: channel ID semantics)

 

We are simply considering= whether letting the client to send frames before the logical channel is ac= cepted is worth it in order to remove this short RTT. This feature would also require that the sever buffers the frames of the logica= l channel until it is accepted. On the server side the procedure of adding = logical channels is not certain to be fast. It may involve querying the dat= abase or establishing a new physical connection. For the duration of this operation the server would have to sp= end some amount of its resources despite it would be unclear whether the ne= w logical channel is accepted or not.

 <= /p>

The best solution would b= e to have the server control this by using a default value for the initial = quota during the physical channel handshake. For example, the server could set the quota explicitly to “0” during the ph= ysical channel handshake, in which case all logical channels (including fir= st one) would be prohibited from sending any data until the channel is acce= pted and so all clients would have to wait for the first flow control message to arrive from the server side. Note that t= his flow control message may arrive in the same frame as the AddChannelResp= onse without any additional RTT.

 <= /p>

Practically we don’= t need to change much in the spec, we just need to be able to negotiate the= default quotas during the physical channel handshake. Any additional quotas can be easily granted using the flow control messages that may arri= ve in the same frame as AddChannelRequest or AddChannelResponse.=

 <= /p>

With best regards,

Arman

 <= /p>

From: Gabriel = Montenegro [mailto:Gabrie= l.Montenegro@microsoft.com]
Sent: Thursday, April 19, 2012 8:41 AM
To: Takeshi Yoshino; John Tamplin
Cc: Arman Djusupov; hybi@ietf.org
Subject: RE: Send quota value before receiving AddChannelResponse (w= as: Re: [hybi] MUC: channel ID semantics)

 

In all previous discussio= ns in this WG there has been relentless push to optimize any RTTs out of th= e protocol. Consistent with this is being able to use the lightweight channel setup (as is possible in SPDY) in which data transmiss= ion is possible without requiring the ack. If I’m the only one asking= about this, perhaps the WG is no longer interested in such optimizations, = but I’d still be interested in understanding the change of heart.

 <= /p>

From: Takeshi = Yoshino [mailto:tyoshino@google.com= ]
Sent: Wednesday, 18 April, 2012 9:50
To: John Tamplin; Gabriel Montenegro
Cc: Arman Djusupov; hybi@ietf.org
Subject: Re: Send quota value before receiving AddChannelResponse (w= as: Re: [hybi] MUC: channel ID semantics)

 

On Wed, Apr 18, 2012 at 21:01, John Tamplin <jat@google.com> wrote:

On Wed, Apr 18, 2012 at 4:15 AM, Takeshi Yoshino <= ;tyoshino@google.c= om> wrote:

You're right. In the latest spec, it's not explicitl= y specified what the value of send quota is until AddChannelResponse is rec= eived.

 

There're several options we can take.

 

a) specify the fixed value of send quota before AddC= hannelResponse in the spec

b) add a new parameter "pre_handshake_quota&quo= t; to multiplexing extension to negotiate the value of send quota before Ad= dChannelResponse

c) drop the feature to configure initial quota for e= ach logical channel, and redefine the quota parameter as pre-handshake send= quota for all logical channels

 

Until we know the AddChannel was accepted, how can w= e send data anyway?  This seems just like the initial handshake on a n= ew connection -- you wouldn't consider sending that data until you knew the= connection was accepted.  Since we are avoiding TCP setup requirements, this will be much less latency than if th= e connection were created without multiplexing.

 

I suppose it would be possible to send the data whil= e keeping it buffered as an optimization, but since adding a channel should= be infrequent compared to sending data on it, I don't see it as that impor= tant to optimize for.

 

Yes. It's infrequent.

 

If the information the impatient client want to send= is small, it can also be just embeded into URL or subprotocol to avoid the= additional RTT.

 

If no one really needs this feature and has justific= ation, I'm fine with keeping the same restriction (no transmission until Ad= dChannelResponse) as no-mux connection.

 

IIRC, Gabriel was interested in this optimization. G= abriel, do you have any comment about this?

 

--_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FA9596TK5EX14MBXW602w_-- From internet-drafts@ietf.org Thu Apr 19 22:00: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 713D221F86F5; Thu, 19 Apr 2012 22:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, 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 2EMYlxECS9R9; Thu, 19 Apr 2012 22:00:04 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A768621F86F1; Thu, 19 Apr 2012 22:00:04 -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.00 Message-ID: <20120420050004.2740.14810.idtracker@ietfa.amsl.com> Date: Thu, 19 Apr 2012 22:00:04 -0700 Cc: hybi@ietf.org Subject: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-01.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: Fri, 20 Apr 2012 05:00:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the BiDirectional or Server-Initiated HTT= P Working Group of the IETF. Title : A Multiplexing Extension for WebSockets Author(s) : John A. Tamplin Takeshi Yoshino Filename : draft-ietf-hybi-websocket-multiplexing-01.txt Pages : 33 Date : 2012-04-19 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-hybi-websocket-multiplexing-= 01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-hybi-websocket-multiplexing-0= 1.txt From tyoshino@google.com Thu Apr 19 23:08: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 542C321E8034 for ; Thu, 19 Apr 2012 23:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.646 X-Spam-Level: X-Spam-Status: No, score=-102.646 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, 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 inoWoWJmFAXt for ; Thu, 19 Apr 2012 23:08:52 -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 C58AE21E8027 for ; Thu, 19 Apr 2012 23:08:52 -0700 (PDT) Received: by iazz13 with SMTP id z13so15759589iaz.31 for ; Thu, 19 Apr 2012 23:08: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 :content-type:x-system-of-record; bh=ZT05aCCN/w9ThPIBnn9OTgCzYQFnD7fKauMSxY6jNV8=; b=gbi1VFsn7+U/mTpK14Qc0W5CjBUv5AfC2Yz2Zdf6+kPwU1oq8MsT9601o7EiPPTqrt YA4Sn1LmHAguiPrKYfCT0iO1Ru7z1nvVz3v6dVuSonIn4gcXk5XoYXr0m2h38mMIyP2z L14inMKpd3FzQKXHz5c7HAUj/TeXHIisucED1J8235F75YnKmGApwgfcylXJQV5MSPYj vuHk0TI3k527w0xO0KPjHm6Q6jijtztuQRN6RXdLDB2qxU7HIFh70wwP8QmhuDEZ/tPG Scn6qJh7FTnRq4jGcovubvSTTlEUaxwE1o/RFIScParLGidLrAAp99gQxvgZbQPPD6MT MqdA== 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 :content-type:x-system-of-record:x-gm-message-state; bh=ZT05aCCN/w9ThPIBnn9OTgCzYQFnD7fKauMSxY6jNV8=; b=MWuolXSRJlZyQ/KuXaEbOZ2anlpWH5+sfQJ9U6OBENz0P89co18eF0otIbk61ODSo2 S7UWk4rd7vwL7tw4uK8VbXCLalzWfovx4+xgo4d2LRIIsZL7pxmPp6G3ESltbEbDAyOI 6/bDemWzkxeNVr8HIZgBrXfXbc7U8ckcSkebHL1q/pvhGiFg4EIg0F4t4rb4rr06zgUu RvU2FOlMZkCBqKcHaRUk8bLaeWPEZ+KBIe2ll5riB3w5N0FVreqEKVbXB+KFj0lRbok8 CFrmPcEE1BGVYv5hJlagjphyNAe02ihE5qwbMusCRHtIGrxj0p2RUx3yloH16LEcRgu5 rCnw== Received: by 10.50.153.134 with SMTP id vg6mr8680337igb.38.1334902132378; Thu, 19 Apr 2012 23:08:52 -0700 (PDT) Received: by 10.50.153.134 with SMTP id vg6mr8680332igb.38.1334902132308; Thu, 19 Apr 2012 23:08:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.176.164 with HTTP; Thu, 19 Apr 2012 23:08:32 -0700 (PDT) In-Reply-To: <20120420050004.2740.14810.idtracker@ietfa.amsl.com> References: <20120420050004.2740.14810.idtracker@ietfa.amsl.com> From: Takeshi Yoshino Date: Fri, 20 Apr 2012 15:08:32 +0900 Message-ID: To: hybi@ietf.org Content-Type: multipart/alternative; boundary=e89a8f23593767fb6b04be161f4a X-System-Of-Record: true X-Gm-Message-State: ALoCoQmyuC7bZNlxeqyl7IOHRshX6W1Z4YgFIy7VHiDq95iJTdSwdxGEHZC4t0vhDLBdxMTK6uNsIicAwKBZHp7K+pPNqp97dKlfiRtjTp4R/Zjs2g9PL5eeqC7hq9Cy7E1BHh2d/W7q Subject: Re: [hybi] I-D Action: draft-ietf-hybi-websocket-multiplexing-01.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: Fri, 20 Apr 2012 06:08:53 -0000 --e89a8f23593767fb6b04be161f4a Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here's the ietf -01 version of multiplexing spec. Diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-hybi-websocket-multiplexing-01.txt Changes from -00 are: - now multiplex control blocks MUST be interpreted when the entire message containing them has arrived - now the base for delta-encode of handshake is the last AddChannelRequest/Response with Enc=identity - clarified how much the send quota is until receiving reply -- note that this is still open for discussion - a server MUST _Fail the Physical Channel_ when there's inconsistency between Sec-WebSocket-Extensions in AddChannelRequest/AddChannelResponse (e.g. some value that need to be the same for all logical channels is altered) -- another option is to just _Fail the Logical Channel_ - style/readability -- new term "multiplexed connection" to clarify the difference between logical channels (used for both control and transferring multiplexed connection's data) and multiplexed WebSocket connections -- new term "Implicitly Opened Connection" defined to reduce text -- made definition of send quota and quota parameter in Flow Control section more detailed --e89a8f23593767fb6b04be161f4a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,

Here's the ietf -01 version of mu= ltiplexing spec.


Changes from -00=A0are:
- now multiplex contr= ol blocks MUST be interpreted when the entire message containing them has a= rrived
- now the base for delta-encode of handshake is the last A= ddChannelRequest/Response with Enc=3Didentity
- clarified how much the send quota is until receiving reply
-- note that this is still open for discussion
- a server MUST _= Fail the Physical Channel_ when there's inconsistency between Sec-WebSo= cket-Extensions in AddChannelRequest/AddChannelResponse (e.g. some value th= at need to be the same for all logical channels is altered)
-- another option is to just _Fail the Logical Channel_
- st= yle/readability
-- new term "multiplexed connection" to= clarify the difference between logical channels (used for both control and= transferring multiplexed connection's data) and multiplexed WebSocket = connections
-- new term "Implicitly Opened Connection" defined to reduce= text
-- made definition of send quota and quota parameter in Flo= w Control section more detailed

--e89a8f23593767fb6b04be161f4a-- From mcmanus@ducksong.com Sun Apr 22 16:32: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 3D7D221F85C5 for ; Sun, 22 Apr 2012 16:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, 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 lemYrjLT9GzY for ; Sun, 22 Apr 2012 16:32:22 -0700 (PDT) Received: from linode.ducksong.com (linode.ducksong.com [64.22.125.164]) by ietfa.amsl.com (Postfix) with ESMTP id 4D43321F85C4 for ; Sun, 22 Apr 2012 16:32:22 -0700 (PDT) Received: from [192.168.16.236] (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 7C26C10195 for ; Sun, 22 Apr 2012 19:32:39 -0400 (EDT) Message-ID: <4F9494FD.5070106@ducksong.com> Date: Sun, 22 Apr 2012 19:32:13 -0400 From: Patrick McManus User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: hybi@ietf.org References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070809030106000900050900" Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2012 23:32:23 -0000 This is a multi-part message in MIME format. --------------070809030106000900050900 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/19/2012 11:13 AM, Gabriel Montenegro wrote: > > I'm not sure "short RTT" is a valid expression any more. At any rate, > I'm fine with adding safeguards, but ultimately, it would be a shame > to preclude data from flowing along with the AddChannel request. > I agree with Gabriel. TCP has been trying to get data-with-the-syn on and off for decades (fast-open is the current effort), and sending the request (subject to some reasonable but non-trivial flow control) with the channel open is a large reason for spdy's performance boost.. websockets mux would be pretty broken if it didn't learn that lesson. -P --------------070809030106000900050900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 4/19/2012 11:13 AM, Gabriel Montenegro wrote:

I’m not sure “short RTT” is a valid expression any more. At any rate, I’m fine with adding safeguards, but ultimately, it would be a shame to preclude data from flowing along with the AddChannel request.

 


I agree with Gabriel. TCP has been trying to get data-with-the-syn on and off for decades (fast-open is the current effort), and sending the request (subject to some reasonable but non-trivial flow control) with the channel open is a large reason for spdy's performance boost.. websockets mux would be pretty broken if it didn't learn that lesson.

-P

--------------070809030106000900050900-- From gregw@intalio.com Mon Apr 23 23:04:33 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 2869221F855D for ; Mon, 23 Apr 2012 23:04:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIgb0GeZpwJG for ; Mon, 23 Apr 2012 23:04:32 -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 30B7321F8541 for ; Mon, 23 Apr 2012 23:04:32 -0700 (PDT) Received: by qcsq13 with SMTP id q13so181936qcs.31 for ; Mon, 23 Apr 2012 23:04:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=iLZod4deZtN+uvhsTxGXscjohzPnilKruo28Mq7fRjU=; b=D4Gf+s0cloTnuOiK+fvkhLEfO2BQ3dTfoL/8DgJUor3kjqCuGSVume2bvBq1ZOcPLi DrBJopDGUYxRA2nGu3nk3ryiDyPQfbqgXGxRIEtNGAAX9T7iYeGHAW66ADpkb8qLvYD7 pyKVi7e0GRDNVH+e/zIIylLNLntwjH4UJgSBE5CKNasTPqeEO3sHZWFlTae2qFeBmcJe SXN/75o4I/B11ELa9RX6vKp9zamslFTHbcfegguG7M38fzI18WxC4/ZBxUx/IUZl1d+C osPDyfBJ8l7yR69y5GMPdxfuRvTe+7GoIAvjh2lZrV0WvJQ/tzBkpB4rJb0xILOqRyJx fE/g== MIME-Version: 1.0 Received: by 10.229.135.81 with SMTP id m17mr2736460qct.26.1335247471604; Mon, 23 Apr 2012 23:04:31 -0700 (PDT) Received: by 10.229.68.99 with HTTP; Mon, 23 Apr 2012 23:04:31 -0700 (PDT) In-Reply-To: <4F9494FD.5070106@ducksong.com> References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> <4F9494FD.5070106@ducksong.com> Date: Tue, 24 Apr 2012 16:04:31 +1000 Message-ID: From: Greg Wilkins To: Patrick McManus Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkPx2j034S5uCfL5C1xFn4pZ1vJEuqn4knY80JHcmM6pb2/s2v8Sv5/XJ0lTmIxNx8YqRiZ Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Apr 2012 06:04:33 -0000 In the case of MUX, the server has already accepted the main connection from the client and agreed to the the MUX extensions. Thus I would think that rejecting addChannel would be an extraordinarily rare occurrence. Perhaps it might be provoked by a different channel extension, but if we don't expose the extension choice to the application then I would expect the same extension and settings for all channels anyway (hence the worth of the delta header design). So I think that a quick start for sending data can be another benefit of using MUX. cheers From arman@noemax.com Tue Apr 24 01:16:38 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 E07BB21F856F for ; Tue, 24 Apr 2012 01:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.326, 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 3fT974CqRfJV for ; Tue, 24 Apr 2012 01:16:37 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9F42921F869D for ; Tue, 24 Apr 2012 01:16:36 -0700 (PDT) Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id IMO12536; Tue, 24 Apr 2012 11:16:36 +0300 From: "Arman Djusupov" To: "'Greg Wilkins'" , "'Patrick McManus'" References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> <4F9494FD.5070106@ducksong.com> In-Reply-To: Date: Tue, 24 Apr 2012 11:16:25 +0300 Message-ID: <000301cd21f2$8ee30fa0$aca92ee0$@noemax.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDpAB3Ba5pDAvrAhMo3RFqWK7Q0QGeXeAIAYMcRbwA5LM+PwFTEQc0AU3uHbkBMBQUXgG+D031l2/xj+A= Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Apr 2012 08:16:38 -0000 The server might refuse the channel due to reaching the maximum number of mux logical channels on the same connection. The issue is not only with the cases when the channel is refused but also when the server can't allocate a new channel fast, which would force the server to buffer frames of pending logical channels until they get accepted in order to read from the wire the subsequent frames belonging to already established channels. For this reason the server needs a way to control a default quota. My suggestion was to let the server define the default quota for the logical channel during the physical channel handshake rather than hardcoding it into the spec. As I already mentioned in a previous message, according to the current specification (a) the client may send data prior to receiving an AddChannelResponse, but (b) it doesn't have any flow control quota until an AddChannelResponse with or without quota parameter is received. These two obviously contradict each other. So if we want the client to be able to send some data right after the AddChannelResponse is sent then we need to define how the default quota is negotiated. In such a case we actually don't need any quota parameter in the AddChannelResponse handshake. In other words the part of the spec that describes the initial flow control quota negotiation has to change anyway. PS: I totally agree on the evilness of 'RTT', but there has to be a clean way to control the amount of data that the client can send before the channel is accepted, preferably not just a hardcoded default quota for all clients in all cases. With best regards, Arman -----Original Message----- From: hybi-bounces@ietf.org [mailto:hybi-bounces@ietf.org] On Behalf Of Greg Wilkins Sent: Tuesday, April 24, 2012 9:05 AM To: Patrick McManus Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) In the case of MUX, the server has already accepted the main connection from the client and agreed to the the MUX extensions. Thus I would think that rejecting addChannel would be an extraordinarily rare occurrence. Perhaps it might be provoked by a different channel extension, but if we don't expose the extension choice to the application then I would expect the same extension and settings for all channels anyway (hence the worth of the delta header design). So I think that a quick start for sending data can be another benefit of using MUX. cheers _______________________________________________ hybi mailing list hybi@ietf.org https://www.ietf.org/mailman/listinfo/hybi From jat@google.com Tue Apr 24 06:19:15 2012 Return-Path: X-Original-To: hybi@ietfa.amsl.com Delivered-To: hybi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D53121F8821 for ; Tue, 24 Apr 2012 06:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.876 X-Spam-Level: X-Spam-Status: No, score=-102.876 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_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 nElKLioomQxW for ; Tue, 24 Apr 2012 06:19:14 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6D521F8806 for ; Tue, 24 Apr 2012 06:19:14 -0700 (PDT) Received: by ghbg16 with SMTP id g16so368378ghb.31 for ; Tue, 24 Apr 2012 06:19:13 -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=CxrOqrv3E+nS9MWp+zrrHiSPo/aIPdElZBXn3jkefm4=; b=KT9vPPpqW145/qkAZ3MIKyULQ1Vo8MHEHv45Yjoha6Zzr0McNaDg3nQpFLuSxW6J2N VN4Y4n2uLDTbDZs52GENq2mYFXx/oOzlrgI6DwDHEr7LBKDhg4RN0Ca285s0GDLk7T2i xDdT4eMNl+BjIsXAoBwOr3t84fU9GHJSeOzz6SsssG6/FCma7OIGteA0lzWtIn02i0TW E5jWgOZfq4K+zL8Q0UalR0PLaTIsasRk32VoAdqEfy7f9K/C2QlQkvecfxeSNHdOEfRf +QzqdZPYj2HU/p72boIQu403nHRDoQ4c7Y57yOP+MNVUAncfUvIxqhttCZJNceAdFNjQ 9Y3A== 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=CxrOqrv3E+nS9MWp+zrrHiSPo/aIPdElZBXn3jkefm4=; b=QHcWuBwJGc1IJYrz98YvqI9lwW5fV75cXE04mWBZmFTGOC17E3B8bUof0KFqUGd6Aj +/UacfnQnRlLSvVPffgcjAfyixYTAENyB+B2SbXLTwfPBftXXSPHHnIV0JqysTAOMmJu pdfDylHsfH9mLlWjQVTAtdRNJPeMfhfpiSSZXfZS0mucpWx8i6QeXIUgNJprcr3pQB7Y IIWddbNPFlDxYhQ4pXUv4bxTXtsN1A94LhPxnjRjVLwHyIkbOw00+Xen5tDez3TMk+4u X7l9bHucliELJLw7BxbjZ3Iz6EUY2Jf9ul1uyQMtoE+MHgzyNGi/qHzk3iSvm4HTE+eN Q5IQ== Received: by 10.50.217.164 with SMTP id oz4mr9887636igc.70.1335273553387; Tue, 24 Apr 2012 06:19:13 -0700 (PDT) Received: by 10.50.217.164 with SMTP id oz4mr9887617igc.70.1335273553251; Tue, 24 Apr 2012 06:19:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.9.169 with HTTP; Tue, 24 Apr 2012 06:18:52 -0700 (PDT) In-Reply-To: <000301cd21f2$8ee30fa0$aca92ee0$@noemax.com> References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> <4F9494FD.5070106@ducksong.com> <000301cd21f2$8ee30fa0$aca92ee0$@noemax.com> From: John Tamplin Date: Tue, 24 Apr 2012 09:18:52 -0400 Message-ID: To: Arman Djusupov Content-Type: multipart/alternative; boundary=14dae934052fd1ccb704be6c9921 X-System-Of-Record: true X-Gm-Message-State: ALoCoQnqyLf1dR0VxXgA11mqlSptNkd6xHP4fEVUcwBsjWazuvIOtkLxsQbdgNIWYaEj8ntKQxHEMjE2rJN1Geh0nzNwTp2He3JYLWRcaFPsC1dBXJgKawbQ7TsBbsucaYQoYJZmd6kg Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Apr 2012 13:19:15 -0000 --14dae934052fd1ccb704be6c9921 Content-Type: text/plain; charset=UTF-8 On Tue, Apr 24, 2012 at 4:16 AM, Arman Djusupov wrote: > The server might refuse the channel due to reaching the maximum number of > mux logical channels on the same connection. The issue is not only with the > cases when the channel is refused but also when the server can't allocate a > new channel fast, which would force the server to buffer frames of pending > logical channels until they get accepted in order to read from the wire the > subsequent frames belonging to already established channels. For this > reason > the server needs a way to control a default quota. My suggestion was to let > the server define the default quota for the logical channel during the > physical channel handshake rather than hardcoding it into the spec. > The problem is that you are using up buffer space in the client to buffer any frames which might need to be re-sent if the logical connection is not successful. So, having the server specify that seems backwards to me. Since frames can be nearly arbitrarily large, that means that the client might have to buffer an arbitrarily large amount of data (even if it refragments it and sends only part of it, it has to hold onto the rest). So, the only way I think it makes sense to send data with the connection are when we know it can't fail or when we pass off responsibility for buffering the data to the client. Ie, in a hypothetical API where you can send data with the open, you explicitly say that data will be dropped if the connection is not successful, so the code calling WebSocket.open is responsible for re-sending the data on a later connection attempt. > As I already mentioned in a previous message, according to the current > specification (a) the client may send data prior to receiving an > AddChannelResponse, but (b) it doesn't have any flow control quota until an > AddChannelResponse with or without quota parameter is received. These two > obviously contradict each other. No, there is no conflict - a client is always free to send up to its quota, and the quota is held to zero until you get a connection. That means there are fewer special-cases to consider, both in validating the spec and implementing it > PS: I totally agree on the evilness of 'RTT', but there has to be a clean > way to control the amount of data that the client can send before the > channel is accepted, preferably not just a hardcoded default quota for all > clients in all cases. > Ok, but who decides, and who bears the buffering cost of that decision? -- John A. Tamplin Software Engineer (GWT), Google --14dae934052fd1ccb704be6c9921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Apr 24, 2012 = at 4:16 AM, Arman Djusupov <arman@noemax.com> wrote:
The server might refuse the channel due to reaching the maximum number of mux logical channels on the same connection. The issue is not only with the=
cases when the channel is refused but also when the server can't alloca= te a
new channel fast, which would force the server to buffer frames of pending<= br> logical channels until they get accepted in order to read from the wire the=
subsequent frames belonging to already established channels. For this reaso= n
the server needs a way to control a default quota. My suggestion was to let=
the server define the default quota for the logical channel during the
physical channel handshake rather than hardcoding it into the spec.

The problem is that you are using up buffer sp= ace in the client to buffer any frames which might need to be re-sent if th= e logical connection is not successful. =C2=A0So, having the server specify= that seems backwards to me. =C2=A0Since frames can be nearly arbitrarily l= arge, that means that the client might have to buffer an arbitrarily large = amount of data (even if it refragments it and sends only part of it, it has= to hold onto the rest).

So, the only way I think it makes sense to send data wi= th the connection are when we know it can't fail or when we pass off re= sponsibility for buffering the data to the client. =C2=A0Ie, in a hypotheti= cal API where you can send data with the open, you explicitly say that data= will be dropped if the connection is not successful, so the code calling W= ebSocket.open is responsible for re-sending the data on a later connection = attempt.
=C2=A0
As I already mentioned in a previous message, according to the current
specification (a) the client may send data prior to receiving an
AddChannelResponse, but (b) it doesn't have any flow control quota unti= l an
AddChannelResponse with or without quota parameter is received. These two obviously contradict each other.

No, there = is no conflict - a client is always free to send up to its quota, and the q= uota is held to zero until you get a connection. =C2=A0That means there are= fewer special-cases to consider, both in validating the spec and implement= ing it
=C2=A0
PS: I totally agree on the = evilness of 'RTT', but there has to be a clean
way to control the amount of data that the client can send before the
channel is accepted, preferably not just a hardcoded default quota for all<= br> clients in all cases.

Ok, but who decid= es, and who bears the buffering cost of that decision?

=
--
John A. Tamplin
Software Engineer (GWT), Google
--14dae934052fd1ccb704be6c9921-- From Gabriel.Montenegro@microsoft.com Tue Apr 24 09:46:13 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 EA04821F8740 for ; Tue, 24 Apr 2012 09:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 igBuiUSuP5rd for ; Tue, 24 Apr 2012 09:46:13 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7046D21F873E for ; Tue, 24 Apr 2012 09:46:12 -0700 (PDT) Received: from mail192-ch1-R.bigfish.com (10.43.68.239) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 24 Apr 2012 16:46:11 +0000 Received: from mail192-ch1 (localhost [127.0.0.1]) by mail192-ch1-R.bigfish.com (Postfix) with ESMTP id 839A5180129; Tue, 24 Apr 2012 16:46:11 +0000 (UTC) X-SpamScore: -25 X-BigFish: VS-25(zz9371Ic857h98dK4015Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839hd25h) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC102.redmond.corp.microsoft.com; RD:none; EFVD:NLI Received-SPF: pass (mail192-ch1: 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=TK5EX14MLTC102.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail192-ch1 (localhost.localdomain [127.0.0.1]) by mail192-ch1 (MessageSwitch) id 1335285970124640_10647; Tue, 24 Apr 2012 16:46:10 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail192-ch1.bigfish.com (Postfix) with ESMTP id 195912A00FE; Tue, 24 Apr 2012 16:46:10 +0000 (UTC) Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.8) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 24 Apr 2012 16:46:07 +0000 Received: from TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com (157.54.24.14) by TK5EX14MLTC102.redmond.corp.microsoft.com (157.54.79.180) with Microsoft SMTP Server (TLS) id 14.2.298.5; Tue, 24 Apr 2012 16:46:07 +0000 Received: from TK5EX14MBXW602.wingroup.windeploy.ntdev.microsoft.com ([169.254.2.247]) by TK5EX14MLTW653.wingroup.windeploy.ntdev.microsoft.com ([157.54.24.14]) with mapi id 14.02.0298.005; Tue, 24 Apr 2012 09:46:06 -0700 From: Gabriel Montenegro To: John Tamplin Thread-Topic: Impacts of mux and compression extension on the WebSocket API (was: Re: [hybi] MUC: channel ID semantics) Thread-Index: AQHNDX6B1m2DuqIkVUa8dlZmOOMSv5aB40kAgB8gU4CAARyRgIAIN2Zw Date: Tue, 24 Apr 2012 16:46:06 +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.42] Content-Type: multipart/alternative; boundary="_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FBEFC1TK5EX14MBXW602w_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com Cc: "hybi@ietf.org" , "Thomas Roessler \(tlr@w3.org\)" Subject: Re: [hybi] Impacts of mux and compression extension on the WebSocket API (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 24 Apr 2012 16:46:14 -0000 --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FBEFC1TK5EX14MBXW602w_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 K1Rob21hcywgdzNjIGxpYWlzb24uDQoNCkJhc2VkIG9uIHRoZSB0aHJlYWQgb24gdGhlIG1haWxp bmcgbGlzdCBhbmQgYWZ0ZXIgZGlzY3Vzc2lvbiB3aXRoIFNhbHZhdG9yZSwgdGhlIGNoYWlycyBk byBub3Qgc2VlIGFueSBuZXcgcmVxdWlyZW1lbnRzIGZvciB0aGUgV2ViU29ja2V0IEFQSSBhdCB0 aGlzIHBvaW50Lg0KDQpUaGFua3MsDQoNCkdhYnJpZWwNCg0KRnJvbTogSm9obiBUYW1wbGluIFtt YWlsdG86amF0QGdvb2dsZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIDE4IEFwcmlsLCAyMDEyIDIx OjE0DQpUbzogR2FicmllbCBNb250ZW5lZ3JvDQpDYzogVGFrZXNoaSBZb3NoaW5vOyBoeWJpQGll dGYub3JnDQpTdWJqZWN0OiBSZTogSW1wYWN0cyBvZiBtdXggYW5kIGNvbXByZXNzaW9uIGV4dGVu c2lvbiBvbiB0aGUgV2ViU29ja2V0IEFQSSAod2FzOiBSZTogW2h5YmldIE1VQzogY2hhbm5lbCBJ RCBzZW1hbnRpY3MpDQoNCk9uIFRodSwgQXByIDE5LCAyMDEyIGF0IDEyOjEyIEFNLCBHYWJyaWVs IE1vbnRlbmVncm8gPEdhYnJpZWwuTW9udGVuZWdyb0BtaWNyb3NvZnQuY29tPG1haWx0bzpHYWJy aWVsLk1vbnRlbmVncm9AbWljcm9zb2Z0LmNvbT4+IHdyb3RlOg0KX0V4dGVuc2lvbnMgSW4gVXNl XyBkb2VzIG5vdCBzZWVtIGxpa2UgYSAqbmV3KiByZXF1aXJlbWVudCwgYXMgaXQgd2FzIGFscmVh ZHkgc3BlbGxlZCBvdXQgaW4gUkZDNjQ1NSBhbmQgaW5jbHVkZWQgaW4gdGhlIEFQSToNCg0KVG8g Y2xhcmlmeSAtIEkgbWVhbnQgImFkZGVkIHNpbmNlIEkgbGFzdCBsb29rZWQgY2xvc2VseSBhdCB0 aGUgc3BlYyB1bmRlciBkZXZlbG9wbWVudCIuDQoNCi0tDQpKb2huIEEuIFRhbXBsaW4NClNvZnR3 YXJlIEVuZ2luZWVyIChHV1QpLCBHb29nbGUNCg== --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FBEFC1TK5EX14MBXW602w_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxATVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQgMiA1IDggMyA0O30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox Mi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mIzQzO1Rob21hcywgdzNjIGxp YWlzb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5CYXNlZCBvbiB0aGUgdGhyZWFkIG9uIHRoZSBtYWlsaW5nIGxpc3Qg YW5kIGFmdGVyIGRpc2N1c3Npb24gd2l0aCBTYWx2YXRvcmUsIHRoZSBjaGFpcnMgZG8gbm90IHNl ZSBhbnkgbmV3IHJlcXVpcmVtZW50cyBmb3IgdGhlIFdlYlNvY2tldCBBUEkgYXQgdGhpcyBwb2lu dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkdhYnJpZWw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEpvaG4gVGFtcGxpbiBbbWFpbHRvOmphdEBnb29nbGUu Y29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgMTggQXByaWwsIDIwMTIgMjE6MTQ8 YnI+DQo8Yj5Ubzo8L2I+IEdhYnJpZWwgTW9udGVuZWdybzxicj4NCjxiPkNjOjwvYj4gVGFrZXNo aSBZb3NoaW5vOyBoeWJpQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBJbXBhY3Rz IG9mIG11eCBhbmQgY29tcHJlc3Npb24gZXh0ZW5zaW9uIG9uIHRoZSBXZWJTb2NrZXQgQVBJICh3 YXM6IFJlOiBbaHliaV0gTVVDOiBjaGFubmVsIElEIHNlbWFudGljcyk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEFwciAxOSwgMjAxMiBhdCAxMjoxMiBBTSwg R2FicmllbCBNb250ZW5lZ3JvICZsdDs8YSBocmVmPSJtYWlsdG86R2FicmllbC5Nb250ZW5lZ3Jv QG1pY3Jvc29mdC5jb20iPkdhYnJpZWwuTW9udGVuZWdyb0BtaWNyb3NvZnQuY29tPC9hPiZndDsg d3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPl88aT5FeHRlbnNp b25zIEluIFVzZTwvaT5fIGRvZXMgbm90IHNlZW0gbGlrZSBhICo8Yj5uZXc8L2I+KiByZXF1aXJl bWVudCwgYXMgaXQgd2FzIGFscmVhZHkgc3BlbGxlZA0KIG91dCBpbiBSRkM2NDU1IGFuZCBpbmNs dWRlZCBpbiB0aGUgQVBJOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyBjbGFyaWZ5IC0gSSBtZWFudCAmcXVvdDth ZGRlZCBzaW5jZSBJIGxhc3QgbG9va2VkIGNsb3NlbHkgYXQgdGhlIHNwZWMgdW5kZXIgZGV2ZWxv cG1lbnQmcXVvdDsuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4tLSA8YnI+DQpKb2huIEEuIFRhbXBsaW48YnI+DQpTb2Z0d2FyZSBF bmdpbmVlciAoR1dUKSwgR29vZ2xlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_CA566BAEAD6B3F4E8B5C5C4F61710C1147FBEFC1TK5EX14MBXW602w_-- From arman@noemax.com Wed Apr 25 06:33:44 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 54FBA21F86B4 for ; Wed, 25 Apr 2012 06:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0wahngLTflr for ; Wed, 25 Apr 2012 06:33:43 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 674E721F86B1 for ; Wed, 25 Apr 2012 06:33:43 -0700 (PDT) Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id JRG03141; Wed, 25 Apr 2012 16:33:41 +0300 From: "Arman Djusupov" To: "'John Tamplin'" References: <002501cd1e15$0c8d8480$25a88d80$@noemax.com> <4F9494FD.5070106@ducksong.com> <000301cd21f2$8ee30fa0$aca92ee0$@noemax.com> In-Reply-To: Date: Wed, 25 Apr 2012 16:33:02 +0300 Message-ID: <003f01cd22e7$f4a47220$dded5660$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01CD2301.19F330C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFDpAB3Ba5pDAvrAhMo3RFqWK7Q0QGeXeAIAYMcRbwA5LM+PwFTEQc0AU3uHbkBMBQUXgG+D031AQ8BDg8AtqCt+Zdjpurg Content-Language: en-us Cc: hybi@ietf.org Subject: Re: [hybi] Send quota value before receiving AddChannelResponse (was: Re: MUC: channel ID semantics) X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 25 Apr 2012 13:33:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0040_01CD2301.19F330C0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The problem is that you are using up buffer space in the client to = buffer any frames which might need to be re-sent if the logical = connection is not successful. So, having the server specify that seems = backwards to me. Since frames can be nearly arbitrarily large, that = means that the client might have to buffer an arbitrarily large amount = of data (even if it refragments it and sends only part of it, it has to = hold onto the rest). =20 If the API permits a message to be sent while the socket is not yet = connected, the implementation would have to buffer any amount of data = being pushed into the Socket unless this amount is less than the default = quota. Currently the default quota is 0, so it will have to buffer = everything. As you have pointed out, even if a quota is available, all = data sent before the logical channel is established will have to be = buffered in order to be resent if the connection fails. Note that if the = API permits this than it would also have to buffer in cases when mux is = not used since the API has no knowledge whether mux is present or not. =20 Ok, but who decides, and who bears the buffering cost of that decision? =20 So far I can imagine these options to determine the initial quota: =20 1) Change spec so that, by default, 64k are granted as initial = quota to all logical channels before receiving the AddChannelResponse. = Spec decides, both bear cost, w/o RTT. 2) Leave the default initial quota as is at zero. But then why = permit the client to send data before the AddChannelResponse when we = know that it doesn=E2=80=99t have any available quota. Nobody decides, = nobody bears cost, w/ RTT. 3) Let the server set the default quota for all logical channels = during the first handshake. Server decides, cost depends on decision, = w/o RTT. 4) Let the client set a =E2=80=9Cself-granted=E2=80=9D quota for = every channel, so that the server either accepts it or refuses the = logical channel. Client decides, cost depends on decision, w/o RTT. 5) Let the client request a =E2=80=9Cdesired=E2=80=9D quota for all = logical channels, and the server grant an equal or lower quota during = the first handshake. Server decides, cost depends on decision, w/o RTT. =20 --=20 John A. Tamplin Software Engineer (GWT), Google =20 With best regards, Arman =20 ------=_NextPart_000_0040_01CD2301.19F330C0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

The = problem is that you are using up buffer space in the client to buffer = any frames which might need to be re-sent if the logical connection is = not successful.  So, having the server specify that seems backwards = to me.  Since frames can be nearly arbitrarily large, that means = that the client might have to buffer an arbitrarily large amount of data = (even if it refragments it and sends only part of it, it has to hold = onto the rest).

 

If the API permits a message to be sent while the socket is not yet = connected, the implementation would have to buffer any amount of data = being pushed into the Socket unless this amount is less than the default = quota. Currently the default quota is 0, so it will have to buffer = everything.  As you have pointed out, even if a quota is available, = all data sent before the logical channel is established will have to be = buffered in order to be resent if the connection fails. Note that if the = API permits this than it would also have to buffer in cases when mux is = not used since the API has no knowledge whether mux is present or = not.

 

Ok, but who decides, and who bears the buffering cost = of that decision?

 

So far I can imagine these options to determine the initial = quota:

 

1)      = Change spec so that, by default, 64k are granted as initial quota to = all logical channels before receiving the AddChannelResponse. Spec = decides, both bear cost, w/o RTT.

2)      = Leave the default initial quota as is at zero. But then why permit = the client to send data before the AddChannelResponse when we know that = it doesn=E2=80=99t have any available quota. Nobody decides, nobody = bears cost, w/ RTT.

3)      = Let the server set the default quota for all logical channels during = the first handshake. Server decides, cost depends on decision, w/o = RTT.

4)      = Let the client set a =E2=80=9Cself-granted=E2=80=9D quota for every = channel, so that the server either accepts it or refuses the logical = channel. Client decides, cost depends on decision, w/o = RTT.

5)      = Let the client request a =E2=80=9Cdesired=E2=80=9D quota for all = logical channels, and the server grant an equal or lower quota during = the first handshake. Server decides, cost depends on decision, w/o = RTT.

 

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

 

With best regards,

Arman

 

------=_NextPart_000_0040_01CD2301.19F330C0-- From tyoshino@google.com Wed Apr 25 21:24:10 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 DDBFC21F8897 for ; Wed, 25 Apr 2012 21:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.921 X-Spam-Level: X-Spam-Status: No, score=-102.921 tagged_above=-999 required=5 tests=[AWL=0.055, 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 d3W3d4Z7HSIw for ; Wed, 25 Apr 2012 21:24:09 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 42B9511E8085 for ; Wed, 25 Apr 2012 21:24:09 -0700 (PDT) Received: by lagj5 with SMTP id j5so662670lag.31 for ; Wed, 25 Apr 2012 21:24:08 -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:content-type :x-system-of-record; bh=uAgiQ170EVYQhFAxb+UTsP8nViUvKfcmM3rm3oJlXag=; b=nbsAPq+kQB7XuX8AAumpOqdhntOPZaWjMt0zE5qFXmXvaI+HHX6WqBc7Vwbed5c3Xh KadHsDRjThZynyswUMKdy2MTuAgBH/k+0GmiUcPury2MNiYpsVqYTmfUOd8XHPaVlXii GNZc1Ux3g+Pp2MOazgr+DnIXOYBde4LDBxwOQOWkj4VCp1vdnnuT3Z+9L0qZMl1xAUvS 72C2RiXZAJ3pXZ6KdmIJl3Sx6rJ4wRoy3MqslVS2V/2+pm6UuwHAQVHXf8PhEWNuTETH nrFyiykP7wI4zCMzxeRvGo4pSOeO04wwQEHT9IEdOfxswtWyktNbUHGULDQCyK9Lgz24 nDXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type :x-system-of-record:x-gm-message-state; bh=uAgiQ170EVYQhFAxb+UTsP8nViUvKfcmM3rm3oJlXag=; b=c5J2qkfXpQTAwr4nfOC8fe2POGOdPbBFW4CA8oa+sOkey6C1io3z2HlDdB2PGNx7v2 zfJgImQEl8Bl7ZeosXdV6WWqIj4l/6AytLarxwphNyjOz1V79CyOkPU3v+xQnCmH7zQB HMNxFrnuoADGA3Yk6F6YVjef/xWqq1K1KFfvfuDnMJhhxMqIMvwCmn7zOymBmJPfLYy6 Z7dxhLhU83EUsKKl6Yybf2LIP0XKldht6WPR+B5xctDf12fdBUqw6Serl3AnbMcPiGaf X2z3VraKWt7XuWsp5Uypg//ax1LgtJsIRIwcyFQhvuQja0hL8OCDdvX1KjqB7gg9kQXj MygA== Received: by 10.112.29.99 with SMTP id j3mr1975262lbh.47.1335414247905; Wed, 25 Apr 2012 21:24:07 -0700 (PDT) Received: by 10.112.29.99 with SMTP id j3mr1975252lbh.47.1335414247770; Wed, 25 Apr 2012 21:24:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.48.165 with HTTP; Wed, 25 Apr 2012 21:23:47 -0700 (PDT) From: Takeshi Yoshino Date: Thu, 26 Apr 2012 13:23:47 +0900 Message-ID: To: hybi@ietf.org, John Tamplin , Arman Djusupov , Greg Wilkins Content-Type: multipart/alternative; boundary=f46d040167e3ddca3904be8d5b3a X-System-Of-Record: true X-Gm-Message-State: ALoCoQm9DrRxm++UApI2qY1EB7unv0ivqdyGjBxKQ+MnWxqXfRKYWjHwwVrX6/PetxVcqYT2I1pDmmG8UUVIfRtgH/T8sYkCw2tK8jG6dUACZCuhMtHhMOqDumPBtlhQfyGD9oQthUrj Subject: [hybi] Compression spec decoupling X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Apr 2012 04:24:11 -0000 --f46d040167e3ddca3904be8d5b3a Content-Type: text/plain; charset=ISO-8859-1 As the target data is close, I'd like to list options with concrete examples and call for opinions to settle this topic. See also this thread: http://www.ietf.org/mail-archive/web/hybi/current/msg09469.html We have two options. (I saw slight objection to add a new handshake header to pass algorithm parameter in f2f meeting) a) One per-frame compression extension for all compression algorithm draft-ietf-hybi-websocket-perframe-compression defines - an extension "perframe-compress" and how it frames data including usage of RSV1 - an extension parameter "algorithm" and its format - an algorithm parameter "deflate" and how it transforms data RSV1 is given to perframe-compress extension. It might make incompatible extension checking easier. There something does "per-frame compression" but needs framing beyond what we define in this spec might come in the future. Then, we need to choose either of break this 1:1 assignment or forbid it to use RSV1. Example: Sec-WebSocket-Extensions: perframe-compress; algorithm="foo; foo-param1=123, bar; bar-param1=abc"; general-param1=xyz", ... Example (with mux): Sec-WebSocket-Extensions: perframe-compress; algorithm="... (algorithms for pre-mux) ...", mux, perframe-compress; algorithm="... (algorithms for post-mux) ..." b) One extension for each per-frame compression algorithm draft-ietf-hybi-websocket-perframe-compression defines - a method how to frame data with per-frame compression including usage of RSV1 - an extension "deflate-frame" which uses the framing method and how to transforms data RSV1 is given to any extension that does per-frame compression. Endpoints need to sort out mutually exclusive extensions. Any future per-frame compression extension may or may not refer to the framing method defined in draft-ietf-hybi-websocket-perframe-compression. Example: Sec-WebSocket-Extensions: foo-compress; foo-param1=123, bar-compress; bar-param-1=abc, ... Example (with mux): Sec-WebSocket-Extensions: ... (extensions for pre-mux) ...", mux, ... (extensions for post-mux) ..." --f46d040167e3ddca3904be8d5b3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As the target data is close, I'd like to list options with concret= e examples and call for opinions to settle this topic.

=

We have two options.
(I saw slight objection = to add a new handshake header to pass algorithm=A0parameter=A0in f2f meetin= g)

a) One per-frame compression extension for all = compression algorithm

draft-ietf-hybi-websocket-perframe-compression=A0define= s
- an extension "perframe-compress" and=A0how it frame= s data including usage of RSV1
- an extension parameter "alg= orithm" and its format
- an algorithm parameter "deflate" and how it transforms dat= a

RSV1 is given to perframe-compress extension. It= might make incompatible extension=A0checking easier.

There something does "per-frame compression" but needs frami= ng beyond what we define in this spec might come in the future. Then, we ne= ed to choose either of break this 1:1 assignment or forbid it to use RSV1.<= /div>

Example:
Sec-WebSocket-Extensions: perfr= ame-compress; algorithm=3D"foo; foo-param1=3D123, bar; bar-param1=3Dab= c"; general-param1=3Dxyz", ...

Example (= with mux):
Sec-WebSocket-Extensions: perframe-compress; algorithm=3D"... (al= gorithms for pre-mux) ...", mux, perframe-compress; algorithm=3D"= ... (algorithms for post-mux) ..."

b) One extension for each per-frame compression algorithm
<= br>
draft-ietf-hybi-websocket-perframe-compression=A0defines
=
- a method how to frame data with per-frame compression including usag= e of RSV1
- an extension "deflate-frame" which uses the framing method= and how to transforms data

RSV1 is given to= any extension that does per-frame compression. Endpoints need to sort out = mutually exclusive extensions.

Any future per-frame compression extension may or may n= ot refer to the framing method defined in draft-ietf-hybi-websocket-perfram= e-compression.

Example:
Sec-We= bSocket-Extensions: foo-compress; foo-param1=3D123, bar-compress; bar-param= -1=3Dabc, ...

Example (with mux):
Sec-WebSocket-Extensions:= ... (extensions for pre-mux) ...", mux, ... (extensions for post-mux)= ..."

--f46d040167e3ddca3904be8d5b3a-- From jat@google.com Wed Apr 25 21:30:29 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 A3BFA21F8897 for ; Wed, 25 Apr 2012 21:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.901 X-Spam-Level: X-Spam-Status: No, score=-102.901 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8I8GKLN73YvD for ; Wed, 25 Apr 2012 21:30:29 -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 DBB9421F86FD for ; Wed, 25 Apr 2012 21:30:28 -0700 (PDT) Received: by iazz13 with SMTP id z13so1220787iaz.31 for ; Wed, 25 Apr 2012 21:30:28 -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=WzlvYCDcZygmNJlomv3Vepw6rJSkqU89CbxJ+sYyxSw=; b=XYXv7ibIp12xhbHDiSDFZZwDMJup6l7+L0AT6AzOCCMPinlHEx5dVIXYsmrvWZ/l8T E4eRrixS4Orj1qYCwTDIdo1sfT2DCptA6nxMvFH2DmptSU2wMqK4yPX4t2HYEPwg/cfp AiTPNv5gijvXFSr7rucmtptCE1XlXYdQsAy/pWPARu4qpuTR3jPxbBSvgjJ+BwVV406F ANZyvTgTVugsMW0Gcmgb3yz3wZzKpYDEC8M9eVEsKcRCYK16qSlu8pf+pof/cGlOd4lh HsESkNHIWCqI8MjkNm7kbgt1FMjI0f+5VCeknDx6gBt/Xek+kxZgUB3aPqg8WFXunFQq ZKuw== 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=WzlvYCDcZygmNJlomv3Vepw6rJSkqU89CbxJ+sYyxSw=; b=e1SBB3M+kOy7HC+MSGl+6QsSMw0w+/Lp90mlAaj0sl5DKyffAFNL5+Rn+F1HM8PsFw OKi3fRWKwhjJ5wI/JL6U8c3SMUVc8K2ojJcE/vuRiO4raf48a/z3a0UFWlBUXRoaL3iG e3F8xjYLviS03x1ULwCYdpBXJzN1X2isz10SIN5BZX4mBevEhKLPg9dWhC6kYSzpwxU6 B3jL3T3dEJZMlynzTGsT6h/R3sdNrLZhcuVoV6q61DtA9IKF9m/nBzrfLXq4PeWMaX3H ms2RvDA4odZ8rb5PqpHYjJw2H/QfyI+VebEIUK7gyu5X2S2exPOPMFTanezkWu0rY3aC VAoQ== Received: by 10.50.219.199 with SMTP id pq7mr4761905igc.70.1335414628580; Wed, 25 Apr 2012 21:30:28 -0700 (PDT) Received: by 10.50.219.199 with SMTP id pq7mr4761588igc.70.1335414619522; Wed, 25 Apr 2012 21:30:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.64.9.169 with HTTP; Wed, 25 Apr 2012 21:29:59 -0700 (PDT) In-Reply-To: References: From: John Tamplin Date: Thu, 26 Apr 2012 00:29:59 -0400 Message-ID: To: Takeshi Yoshino Content-Type: multipart/alternative; boundary=14dae9340f3306466c04be8d7205 X-System-Of-Record: true X-Gm-Message-State: ALoCoQm8k1qc9a97cfhU+4E+NavyNO9r2HPR2NK7u5v+0Z6d9NA47Y8ij0TzbPd/IteMdDoWTjoyAjP8PWclyQVj54BMK3j+ajon4xAlVlUNKdYdMcVf7lVcvCUAnYNs3AoNFAXKiMQM Cc: Greg Wilkins , hybi@ietf.org Subject: Re: [hybi] Compression spec decoupling X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Apr 2012 04:30:29 -0000 --14dae9340f3306466c04be8d7205 Content-Type: text/plain; charset=UTF-8 On Thu, Apr 26, 2012 at 12:23 AM, Takeshi Yoshino wrote: > As the target data is close, I'd like to list options with concrete > examples and call for opinions to settle this topic. > I am fine with either, as long as if it is option b) the spec is mostly about the generic per-frame compression extension, and the deflate-compression mandatory extension is confined to one section. -- John A. Tamplin Software Engineer (GWT), Google --14dae9340f3306466c04be8d7205 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Apr 26, 2012 at 12:23 AM, Takeshi Yoshin= o <tyoshino@google.com> wrote:
As the target data is close, I'd like to list options with concret= e examples and call for opinions to settle this topic.

I am fine with either, as long as if it is option b) the = spec is mostly about the generic per-frame compression extension, and the d= eflate-compression mandatory extension is confined to one section.=C2=A0

--
John A. Tamplin
Software Engineer (GWT), Goo= gle
--14dae9340f3306466c04be8d7205-- From arman@noemax.com Thu Apr 26 02:11: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 B332F21F8776 for ; Thu, 26 Apr 2012 02:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Cv4EkYZv6aX for ; Thu, 26 Apr 2012 02:11:28 -0700 (PDT) Received: from mail.noemax.com (mail.noemax.com [64.34.201.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9868921F8773 for ; Thu, 26 Apr 2012 02:11:28 -0700 (PDT) Received: from ArmanPC1 by mail.noemax.com (IceWarp 9.4.1) with ASMTP (SSL) id KNL48525; Thu, 26 Apr 2012 12:11:25 +0300 From: "Arman Djusupov" To: "'Takeshi Yoshino'" , , "'John Tamplin'" , "'Greg Wilkins'" References: In-Reply-To: Date: Thu, 26 Apr 2012 12:11:16 +0300 Message-ID: <002001cd238c$8d5a6e80$a80f4b80$@noemax.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0021_01CD23A5.B2A9F070" X-Mailer: Microsoft Outlook 14.0 thread-index: AQI/uA5G45eE+kelT2vnGxaAwCWfjJXHqFxA Content-Language: en-us Subject: Re: [hybi] Compression spec decoupling X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Apr 2012 09:11:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0021_01CD23A5.B2A9F070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I'm also fine with both options. With best regards, Arman From: Takeshi Yoshino [mailto:tyoshino@google.com] Sent: Thursday, April 26, 2012 7:24 AM To: hybi@ietf.org; John Tamplin; Arman Djusupov; Greg Wilkins Subject: Compression spec decoupling As the target data is close, I'd like to list options with concrete examples and call for opinions to settle this topic. See also this thread: http://www.ietf.org/mail-archive/web/hybi/current/msg09469.html We have two options. (I saw slight objection to add a new handshake header to pass algorithm parameter in f2f meeting) a) One per-frame compression extension for all compression algorithm draft-ietf-hybi-websocket-perframe-compression defines - an extension "perframe-compress" and how it frames data including usage of RSV1 - an extension parameter "algorithm" and its format - an algorithm parameter "deflate" and how it transforms data RSV1 is given to perframe-compress extension. It might make incompatible extension checking easier. There something does "per-frame compression" but needs framing beyond what we define in this spec might come in the future. Then, we need to choose either of break this 1:1 assignment or forbid it to use RSV1. Example: Sec-WebSocket-Extensions: perframe-compress; algorithm="foo; foo-param1=123, bar; bar-param1=abc"; general-param1=xyz", ... Example (with mux): Sec-WebSocket-Extensions: perframe-compress; algorithm="... (algorithms for pre-mux) ...", mux, perframe-compress; algorithm="... (algorithms for post-mux) ..." b) One extension for each per-frame compression algorithm draft-ietf-hybi-websocket-perframe-compression defines - a method how to frame data with per-frame compression including usage of RSV1 - an extension "deflate-frame" which uses the framing method and how to transforms data RSV1 is given to any extension that does per-frame compression. Endpoints need to sort out mutually exclusive extensions. Any future per-frame compression extension may or may not refer to the framing method defined in draft-ietf-hybi-websocket-perframe-compression. Example: Sec-WebSocket-Extensions: foo-compress; foo-param1=123, bar-compress; bar-param-1=abc, ... Example (with mux): Sec-WebSocket-Extensions: ... (extensions for pre-mux) ...", mux, ... (extensions for post-mux) ..." ------=_NextPart_000_0021_01CD23A5.B2A9F070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m also fine with both options.

 

With best regards,

Arman

 

From:= = Takeshi Yoshino [mailto:tyoshino@google.com]
Sent: Thursday, = April 26, 2012 7:24 AM
To: hybi@ietf.org; John Tamplin; Arman = Djusupov; Greg Wilkins
Subject: Compression spec = decoupling

 

As the = target data is close, I'd like to list options with concrete examples = and call for opinions to settle this topic.

 

 

We have two options.

(I saw slight objection to add a new handshake header = to pass algorithm parameter in f2f = meeting)

 

a) One per-frame compression extension for all = compression algorithm

 

draft-ietf-hybi-websocket-perframe-compression def= ines

- an extension = "perframe-compress" and how it frames data including = usage of RSV1

- an = extension parameter "algorithm" and its = format

- an algorithm = parameter "deflate" and how it transforms = data

 

RSV1 is given to perframe-compress extension. It might = make incompatible extension checking = easier.

 

There something does "per-frame compression" = but needs framing beyond what we define in this spec might come in the = future. Then, we need to choose either of break this 1:1 assignment or = forbid it to use RSV1.

 

Example:

Sec-WebSocket-Extensions: perframe-compress; = algorithm=3D"foo; foo-param1=3D123, bar; bar-param1=3Dabc"; = general-param1=3Dxyz", ...

 

Example (with mux):

Sec-WebSocket-Extensions: perframe-compress; = algorithm=3D"... (algorithms for pre-mux) ...", mux, = perframe-compress; algorithm=3D"... (algorithms for post-mux) = ..."

 

b) One extension for each per-frame compression = algorithm

 

draft-ietf-hybi-websocket-perframe-compression def= ines

- a method how = to frame data with per-frame compression including usage of = RSV1

- an extension = "deflate-frame" which uses the framing method and how to = transforms data

 

RSV1 is given to any extension that does per-frame = compression. Endpoints need to sort out mutually exclusive = extensions.

 

Any future per-frame compression extension may or may = not refer to the framing method defined in = draft-ietf-hybi-websocket-perframe-compression.

=

 

Example:

Sec-WebSocket-Extensions: foo-compress; = foo-param1=3D123, bar-compress; bar-param-1=3Dabc, = ...

 

Example (with mux):

Sec-WebSocket-Extensions: ... (extensions for pre-mux) = ...", mux, ... (extensions for post-mux) = ..."

 

------=_NextPart_000_0021_01CD23A5.B2A9F070-- From gregw@intalio.com Thu Apr 26 02:12:42 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 9882621F87A2 for ; Thu, 26 Apr 2012 02:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Whz054qFCOhL for ; Thu, 26 Apr 2012 02:12:42 -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 CC66221F879A for ; Thu, 26 Apr 2012 02:12:41 -0700 (PDT) Received: by qcsq13 with SMTP id q13so652082qcs.31 for ; Thu, 26 Apr 2012 02:12:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding:x-gm-message-state; bh=aIWCM90XsZvjwbISgpzigVVFQX3n7JAd69cYXWeZCfo=; b=aW/sbSUo9zBOAxpklWaXS7YkKUgynqmvj1az4RHgyNbKm19FteZT7ZZamngWo/APx4 BFborbGRRsUwQlG9tPYFAcrXYEt/09XDsnyDJXuwwXPfHNghmG4yHYy/bxqfPGen7Ey7 oQfGVskr7r4i6Rq/X+1I7ehR65R22MMWWDFht74KUbAluszx5SCJeb1DQSPbtwLJvwGs IovaTB6bgkWlDF7qxnke/Q1/QPaAXs+LAq2qqKPTRpCnZdwywWhzp3UJN6GA/MJJjADP a3QV6tqub1NkW/iCv9fCxNZDwCfPrmWLXlkYCl+DqKO2xEOzxb52Xx3bFfoee3yPE8Xw GfTA== MIME-Version: 1.0 Received: by 10.229.135.10 with SMTP id l10mr1348102qct.6.1335431561249; Thu, 26 Apr 2012 02:12:41 -0700 (PDT) Sender: gregw@intalio.com Received: by 10.229.68.99 with HTTP; Thu, 26 Apr 2012 02:12:41 -0700 (PDT) In-Reply-To: <002001cd238c$8d5a6e80$a80f4b80$@noemax.com> References: <002001cd238c$8d5a6e80$a80f4b80$@noemax.com> Date: Thu, 26 Apr 2012 19:12:41 +1000 X-Google-Sender-Auth: sIzx_82b28JAltl95-bxFemFMew Message-ID: From: Greg Wilkins To: Arman Djusupov Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlvKuGkuWV8FXQ/fD9IKE79llcLXT+yNKsRzeNtfKBzu5LHVOq9lvUqEddvz9OABpvMcyA2 Cc: hybi@ietf.org Subject: Re: [hybi] Compression spec decoupling X-BeenThere: hybi@ietf.org X-Mailman-Version: 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, 26 Apr 2012 09:12:42 -0000 I prefer a) to b), but don't strongly object to b) cheers On 26 April 2012 19:11, Arman Djusupov wrote: > I=92m also fine with both options. > > > > With best regards, > > Arman > > > > From: Takeshi Yoshino [mailto:tyoshino@google.com] > Sent: Thursday, April 26, 2012 7:24 AM > To: hybi@ietf.org; John Tamplin; Arman Djusupov; Greg Wilkins > Subject: Compression spec decoupling > > > > As the target data is close, I'd like to list options with concrete examp= les > and call for opinions to settle this topic. > > > > See also this > thread:=A0http://www.ietf.org/mail-archive/web/hybi/current/msg09469.html > > > > We have two options. > > (I saw slight objection to add a new handshake header to pass > algorithm=A0parameter=A0in f2f meeting) > > > > a) One per-frame compression extension for all compression algorithm > > > > draft-ietf-hybi-websocket-perframe-compression=A0defines > > - an extension "perframe-compress" and=A0how it frames data including usa= ge of > RSV1 > > - an extension parameter "algorithm" and its format > > - an algorithm parameter "deflate" and how it transforms data > > > > RSV1 is given to perframe-compress extension. It might make incompatible > extension=A0checking easier. > > > > There something does "per-frame compression" but needs framing beyond wha= t > we define in this spec might come in the future. Then, we need to choose > either of break this 1:1 assignment or forbid it to use RSV1. > > > > Example: > > Sec-WebSocket-Extensions: perframe-compress; algorithm=3D"foo; foo-param1= =3D123, > bar; bar-param1=3Dabc"; general-param1=3Dxyz", ... > > > > Example (with mux): > > Sec-WebSocket-Extensions: perframe-compress; algorithm=3D"... (algorithms= for > pre-mux) ...", mux, perframe-compress; algorithm=3D"... (algorithms for > post-mux) ..." > > > > b) One extension for each per-frame compression algorithm > > > > draft-ietf-hybi-websocket-perframe-compression=A0defines > > - a method how to frame data with per-frame compression including usage o= f > RSV1 > > - an extension "deflate-frame" which uses the framing method and how to > transforms data > > > > RSV1 is given to any extension that does per-frame compression. Endpoints > need to sort out mutually exclusive extensions. > > > > Any future per-frame compression extension may or may not refer to the > framing method defined in draft-ietf-hybi-websocket-perframe-compression. > > > > Example: > > Sec-WebSocket-Extensions: foo-compress; foo-param1=3D123, bar-compress; > bar-param-1=3Dabc, ... > > > > Example (with mux): > > Sec-WebSocket-Extensions: ... (extensions for pre-mux) ...", mux, ... > (extensions for post-mux) ..." > > From nataraju.sip@gmail.com Fri Apr 27 02:05:29 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 9D8E821F86F5 for ; Fri, 27 Apr 2012 02:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.233 X-Spam-Level: X-Spam-Status: No, score=-2.233 tagged_above=-999 required=5 tests=[AWL=0.481, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 2AU8bVEt-Mmw for ; Fri, 27 Apr 2012 02:05:29 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 825C921F86F3 for ; Fri, 27 Apr 2012 02:05:28 -0700 (PDT) Received: by lbbgm13 with SMTP id gm13so373865lbb.31 for ; Fri, 27 Apr 2012 02:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=6vbPvQ553V8TJx+rxcAbrouV0dOPOCMhltkf7Ga4XWA=; b=YANs9KLctITbV/9/BsozsIkONBBv34Stodm9S5eTsWxX5Qw3j5A2EDv8YzL63EIDKG vuxXK+bhYqvOXzbAIRFl3txnhdAqME+pT9EaqAbuPBu0ode1N4wNBHXtAKCuZsarYR2x ImLHGPbFyMuOe7uIZ6M10dYkpAOtzvISc34ZxVDumKy6aBxR5dM5g0mnMOhVN+opAHnm UJv8xgpIMsDIudrPCcvHYolUnSV6PM+7K1Nbsybt5v5ydGEfDGl35i5c10gpYrOak02n EdcfvKuebTRDWIlaLJ7CAXjasjtC6jGkc6k9zlR6Ca4VzSd7H+FKcwCRVpNWPPppdr3h Gb0w== MIME-Version: 1.0 Received: by 10.152.128.201 with SMTP id nq9mr3138291lab.26.1335517527480; Fri, 27 Apr 2012 02:05:27 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Fri, 27 Apr 2012 02:05:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 27 Apr 2012 14:35:27 +0530 Message-ID: From: "Nataraju A.B" To: hybi@ietf.org Content-Type: multipart/alternative; boundary=f46d042d0596d119ae04bea5672f Cc: ifette+ietf@google.com Subject: [hybi] Fwd: RFC 6455 - conflicting statements X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:05:29 -0000 --f46d042d0596d119ae04bea5672f Content-Type: text/plain; charset=ISO-8859-1 Hi All, Following is the snippet from the RFC6455. 2. Conformance Requirements All diagrams, examples, and notes in this specification are non- normative, as are all sections explicitly marked non-normative. *Everything *else in this specification is normative. 1.9. Subprotocols Using the WebSocket Protocol _This section is non-normative._ The client can request that the server use a specific subprotocol by including the |Sec-WebSocket-Protocol| field in its handshake. If it is specified, the server needs to include the same field and one of the selected subprotocol values in its response for the connection to be established. 3. WebSocket URIs This specification defines two URI schemes, using the ABNF syntax defined in RFC 5234 [RFC5234], and terminology and ABNF productions defined by the URI specification RFC 3986 [RFC3986]. ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ] host = port = path = query = *Comment*: According to statement in sec 2, section 3 - WebSocket URIs (for example) is normative. But I don't think that it correct. Section 3, 4, 5, 6, 7, 8 must also be changed as non-normative text by inserting the text "_This section is non-normative._". Otherwise, Am I missing something here ??? Thanks, Nataraju A.B. --f46d042d0596d119ae04bea5672f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi All,

Following is the snippet from the RFC6455.

=
<RFC6455>
2.  Conformance Requir=
ements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.=


1.9.  Sub=
protocols Using the WebSocket Protocol

   _This section is non-normative._

   The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

3.  WebSo=
cket URIs

   This specification defines two URI schemes, using the ABNF syntax
   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
   defined by the URI specification RFC 3986 [RFC3986].

          ws-URI =3D "ws:" "//" host [ ":" po=
rt ] path [ "?" query ]
          wss-URI =3D "wss:" "//" host [ ":" =
port ] path [ "?" query ]

          host =3D <host, defined in [RFC3986], Section 3.2.2>
          port =3D <port, defined in [RFC3986], Section 3.2.3>
          path =3D <path-abempty, defined in [RFC3986], Section 3.3>
          query =3D <query, defined in [RFC3986], Section 3.4>
</RFC6455>

Comment: According to statement in sec 2= , section 3 -=A0WebSocket URIs (for example= )=A0is normative. But I don't think that it correct.=A0Section 3, 4, 5, 6, 7, 8 must also be changed as non-normative text b= y inserting the text "_This section is= non-normative._".

Otherwise, Am I missing something here ???

 Thanks,
Nataraju A.B.
--f46d042d0596d119ae04bea5672f-- From ibc@aliax.net Fri Apr 27 02:19: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 3496D21F87C0 for ; Fri, 27 Apr 2012 02:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9r2N9+paeyj for ; Fri, 27 Apr 2012 02:19:55 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7B721F87BF for ; Fri, 27 Apr 2012 02:19:55 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so434346vbb.31 for ; Fri, 27 Apr 2012 02:19:54 -0700 (PDT) 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:content-transfer-encoding:x-gm-message-state; bh=B76yJ3eV9uUha+/lCbd9IeyqUP0sOWWu9f5fblYYnlo=; b=a6BljdurVZIY8vzLyw4k1KrkgAxeNwvxnmdelhtQp1HX3MScz3/Hae3iKV8sIeFDwE oG4EcdQ6LnYojQ099xWBhSv4SyA1xUjNy2/BPfXQoFfz5/1BFowKoGBdP2/6C3nWaFb1 +hWskfy6DNtOJRpNCpd7qp0frsHtmok2VQkUMTQl4decuI+GKQxnTzJ3orZRv48mHXcf 5ilycQfkF51aJ84QHOxP5ukQn8QRvLwUTT4dTARUUpy7bDXyt5d1zDDYdHcFEWq3i7mC R1+u8lkceMh/yW2d30fRIKcE0V0JA0JBvZV4IoivOhUF8RQJ/0OROAueMQlPjPxerOpa b6rg== Received: by 10.52.15.233 with SMTP id a9mr9322595vdd.34.1335518394705; Fri, 27 Apr 2012 02:19:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.107.199 with HTTP; Fri, 27 Apr 2012 02:19:34 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Fri, 27 Apr 2012 11:19:34 +0200 Message-ID: To: "Nataraju A.B" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmlzllmvOMvBC9FVN7bVVeayLHxzKJWN3irGiStkPJDjFdWGJ5yua0/9FSx/BJyyM4zFj7Z Cc: hybi@ietf.org, ifette+ietf@google.com Subject: Re: [hybi] Fwd: RFC 6455 - conflicting statements X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:19:56 -0000 2012/4/27 Nataraju A.B : > Comment: According to statement in sec 2, section 3 -=C2=A0WebSocket URIs= (for > example)=C2=A0is normative. But I don't think that it correct.=C2=A0Secti= on 3, 4, 5, > 6, 7, 8 must also be changed as non-normative text by inserting the text > "_This section is non-normative._". > > Otherwise, Am I missing something here ??? Hi Nataraju, since it's too late for changing an already published RFC, I suggest you that, in case the issue is confirmed, report it in http://www.rfc-editor.org/errata.php#reportnew. Regards. --=20 I=C3=B1aki Baz Castillo From alexey.melnikov@isode.com Fri Apr 27 02:41: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 77F5B21F8775 for ; Fri, 27 Apr 2012 02:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.71 X-Spam-Level: X-Spam-Status: No, score=-100.71 tagged_above=-999 required=5 tests=[AWL=-0.392, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PpqQGmZ+rkv5 for ; Fri, 27 Apr 2012 02:41:38 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 4DEDE21F873C for ; Fri, 27 Apr 2012 02:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335519696; d=isode.com; s=selector; i=@isode.com; bh=hrvarvzw7xPuDbnWA5JAfs7LjnEuJ54Q1Ps98iNz0UE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=chZF5FOKcvKRN977fjpUIdMZr6s9oVgx/6Ep+W1vMtJZLMeAJmm/OCQV+wT6bD0tWIEd80 /Q+LzGpISzWC7Bo1MRSWQ/p1MrqgxBWH2l3n304FcWsrADGtV8uvH/kqJzgtWozHxiLamm GANNjY4PSXjhlgNSETKcdkHRZ5JL55c=; Received: from [188.28.179.219] (188.28.179.219.threembb.co.uk [188.28.179.219]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 27 Apr 2012 10:41:36 +0100 References: In-Reply-To: Message-Id: <996C3E66-90B8-4C86-885C-AD436D94E61C@isode.com> X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Fri, 27 Apr 2012 10:41:29 +0100 To: "Nataraju A.B" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=Apple-Mail-27BF7C70-F069-49E7-A92F-383BF83CFC12 Content-Transfer-Encoding: 7bit Cc: "hybi@ietf.org" , "ifette+ietf@google.com" Subject: Re: [hybi] RFC 6455 - conflicting statements X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 09:41:39 -0000 --Apple-Mail-27BF7C70-F069-49E7-A92F-383BF83CFC12 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 27 Apr 2012, at 10:05, "Nataraju A.B" wrote: > Hi All, Hi, >=20 > Following is the snippet from the RFC6455. >=20 > > 2. Conformance Requirements >=20 > All diagrams, examples, and notes in this specification are non- > normative, as are all sections explicitly marked non-normative. > Everything else in this specification is normative. >=20 > 1.9. Subprotocols Using the WebSocket Protocol >=20 > _This section is non-normative._ >=20 > The client can request that the server use a specific subprotocol by > including the |Sec-WebSocket-Protocol| field in its handshake. If it > is specified, the server needs to include the same field and one of > the selected subprotocol values in its response for the connection to > be established. >=20 > 3. WebSocket URIs >=20 > This specification defines two URI schemes, using the ABNF syntax > defined in RFC 5234 [RFC5234], and terminology and ABNF productions > defined by the URI specification RFC 3986 [RFC3986]. >=20 > ws-URI =3D "ws:" "//" host [ ":" port ] path [ "?" query ] > wss-URI =3D "wss:" "//" host [ ":" port ] path [ "?" query ] >=20 > host =3D > port =3D > path =3D > query =3D > >=20 > Comment: According to statement in sec 2, section 3 - WebSocket URIs (for e= xample) is normative. But I don't think that it correct. Section 3, 4, 5, 6,= 7, 8 must also be changed as non-normative text by inserting the text "_Thi= s section is non-normative._". >=20 Can you elaborate why you think that these sections are non-normative? > Otherwise, Am I missing something here ??? >=20 > Thanks, > Nataraju A.B. --Apple-Mail-27BF7C70-F069-49E7-A92F-383BF83CFC12 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
On 27 Apr 2012, at 10:05, "Nataraju A.B" <nataraju.sip@gmail.com> wrote:

Hi All,

Hi,

Following is the snippet from the RFC6455.

<RFC6455>
2.  Conformance Requirements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.

1.9.  Subprotocols Using the WebSocket Protocol

   _This section is non-normative._

   The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

3.  WebSocket URIs

   This specification defines two URI schemes, using the ABNF syntax
   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
   defined by the URI specification RFC 3986 [RFC3986].

          ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
          wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

          host = <host, defined in [RFC3986], Section 3.2.2>
          port = <port, defined in [RFC3986], Section 3.2.3>
          path = <path-abempty, defined in [RFC3986], Section 3.3>
          query = <query, defined in [RFC3986], Section 3.4>
</RFC6455>

Comment: According to statement in sec 2, section 3 - WebSocket URIs (for example) is normative. But I don't think that it correct. Section 3, 4, 5, 6, 7, 8 must also be changed as non-normative text by inserting the text "_This section is non-normative._".


Can you elaborate why you think that these sections are non-normative?

Otherwise, Am I missing something here ???

Thanks,
Nataraju A.B.
--Apple-Mail-27BF7C70-F069-49E7-A92F-383BF83CFC12-- From nataraju.sip@gmail.com Fri Apr 27 03:21: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 C15AF21F8835 for ; Fri, 27 Apr 2012 03:21:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.254 X-Spam-Level: X-Spam-Status: No, score=-2.254 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 FzyNedOoLqxa for ; Fri, 27 Apr 2012 03:21:02 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 635D621F87A8 for ; Fri, 27 Apr 2012 03:21:01 -0700 (PDT) Received: by lagj5 with SMTP id j5so422954lag.31 for ; Fri, 27 Apr 2012 03:21:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=E9EwQZJQ8IQcFN5qClQrE7U5ibnY4A2TMDeoOp40io8=; b=Vz78zQZ49tHy5pO9gmCXxMyYs+gla5WBONwvEeXVSP8ngJy7RVz5XqTpNHTn9jn/P7 owMohZEafMX/LlPMeTwnqUtlYQO7t5LwErkAv2RPg0DUeXhnmthm/Ckg4zMKC4hS+6CY j1vgaIeoE1T4Po+e7zuOvIITJoWM2RkNJeV7LwFaC442uJNVfy4iuAT0QmaFHp/CLvjg U/MY1DWtlAJCBkCYuXpMStgSZw8vgnyVDOoiNRDJp1DlnkF/i/Lj0AIVktb+oVgCz+86 crUp01LHowrMRQB7g74RKvsJ+GDyknET2Rc7/FSfcZpI0o8TEMFBNcvt3Uh0aB4pPcin qTqg== MIME-Version: 1.0 Received: by 10.152.128.201 with SMTP id nq9mr3361227lab.26.1335522060315; Fri, 27 Apr 2012 03:21:00 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Fri, 27 Apr 2012 03:21:00 -0700 (PDT) In-Reply-To: <996C3E66-90B8-4C86-885C-AD436D94E61C@isode.com> References: <996C3E66-90B8-4C86-885C-AD436D94E61C@isode.com> Date: Fri, 27 Apr 2012 15:51:00 +0530 Message-ID: From: "Nataraju A.B" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d042d0596feac7304bea675f2 Cc: "hybi@ietf.org" , "ifette+ietf@google.com" Subject: Re: [hybi] RFC 6455 - conflicting statements X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2012 10:21:02 -0000 --f46d042d0596feac7304bea675f2 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 27, 2012 at 3:11 PM, Alexey Melnikov wrote: > On 27 Apr 2012, at 10:05, "Nataraju A.B" wrote: > > Hi All, > > > Hi, > > > Following is the snippet from the RFC6455. > > > > 2. Conformance Requirements > > All diagrams, examples, and notes in this specification are non- > normative, as are all sections explicitly marked non-normative. > *Everything *else in this specification is normative. > > > 1.9. Subprotocols Using the WebSocket Protocol > > _This section is non-normative._ > > The client can request that the server use a specific subprotocol by > including the |Sec-WebSocket-Protocol| field in its handshake. If it > is specified, the server needs to include the same field and one of > the selected subprotocol values in its response for the connection to > be established. > > > 3. WebSocket URIs > > This specification defines two URI schemes, using the ABNF syntax > defined in RFC 5234 [RFC5234], and terminology and ABNF productions > defined by the URI specification RFC 3986 [RFC3986]. > > ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] > wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ] > > host = > port = > path = > query = > > > > *Comment*: According to statement in sec 2, section 3 - WebSocket URIs > (for example) is normative. But I don't think that it correct. Section 3, > 4, 5, 6, 7, 8 must also be changed as non-normative text by inserting the > text "_This section is non-normative._". > > > Can you elaborate why you think that these sections are non-normative? > [ABN] In this context, We understand normative means informative text. It is not mandatory to implement or refer normative text. But it is mandatory to follow syntax and semantics of non-normative text / information. AFAIU sections 3-8 of rfc6455 are mandatory to implement. Hence it must be mentioned as non-normative text "_This section is non-normative._", like mentioned for sections 1.1-1.9 > > Otherwise, Am I missing something here ??? > > Thanks, > Nataraju A.B. > > -- Thanks, Nataraju A.B. --f46d042d0596feac7304bea675f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Fri, Apr 2= 7, 2012 at 3:11 PM, Alexey Melnikov <alexey.melnikov@isode.com= > wrote:
On 27 Ap= r 2012, at 10:05, "Nataraju A.B" <nataraju.sip@gmail.com> wrote:

Hi All,

Hi,


Following is the snippet from the RFC6455.

=
<RFC6455>
2.  Conformance Requir=
ements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.=


1.9.  Sub=
protocols Using the WebSocket Protocol

   _This section is non-normative._

   The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

3.  WebSo=
cket URIs

   This specification defines two URI schemes, using the ABNF syntax
   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
   defined by the URI specification RFC 3986 [RFC3986].

          ws-URI =3D "ws:" "//" host [ ":" po=
rt ] path [ "?" query ]
          wss-URI =3D "wss:" "//" host [ ":" =
port ] path [ "?" query ]

          host =3D <host, defined in [RFC3986], Section 3.2.2>
          port =3D <port, defined in [RFC3986], Section 3.2.3>
          path =3D <path-abempty, defined in [RFC3986], Section 3.3>
          query =3D <query, defined in [RFC3986], Section 3.4>
</RFC6455>

Comment: According to statement in sec 2= , section 3 -=A0WebSocket URIs (for example= )=A0is normative. But I don't think that it correct.=A0Section 3, 4, 5, 6, 7, 8 must also be changed as non-normative text b= y inserting the text "_This section is= non-normative._".

=

Can you elaborate why you think that these sections are non-normative?
=A0
[ABN] In this context, We understand normat= ive means informative text. It is not mandatory to implement or refer norma= tive text. But it is mandatory to follow syntax and semantics of non-normat= ive text / information. AFAIU sections 3-8 of rfc6455 are mandatory to impl= ement. Hence it must be mentioned as non-normative text "_This section is non-normative._", like mentioned= for sections 1.1-1.9
<= div>
Otherwise, Am I missing something here ???

 Thanks,
Nataraju A.B.



--
Thanks,
Nataraju= A.B.

--f46d042d0596feac7304bea675f2-- From alexey.melnikov@isode.com Sun Apr 29 09:25: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 75D5621F84DF for ; Sun, 29 Apr 2012 09:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.76 X-Spam-Level: X-Spam-Status: No, score=-100.76 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6xvtKQGjMwv for ; Sun, 29 Apr 2012 09:25:27 -0700 (PDT) Received: from rufus.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id 2C87D21F84D9 for ; Sun, 29 Apr 2012 09:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1335716726; d=isode.com; s=selector; i=@isode.com; bh=zIY4t8yPPvjJ5UHM1ioiHnEib0k00zFCTLFBFE0vQNI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=R2QIk3OLACx/MGfke6niq/bg4SIMPaoP1eM6B/WoF9OWb6PsAod1pC8D0wtJEFKQXw7yq5 bdrZi0mf8r6v2QEJXEb3nJWKaxDgNmTuGfQlfG/9udNnOsttPRgfOUleZSH35g6YgWGdHK lbZziXHt6v90FJJPvb79Bx+LMOKHuY0=; Received: from [188.29.134.82] (188.29.134.82.threembb.co.uk [188.29.134.82]) by rufus.isode.com (submission channel) via TCP with ESMTPSA id ; Sun, 29 Apr 2012 17:25:21 +0100 References: <996C3E66-90B8-4C86-885C-AD436D94E61C@isode.com> In-Reply-To: Message-Id: X-Mailer: iPad Mail (9B176) From: Alexey Melnikov Date: Sun, 29 Apr 2012 17:25:14 +0100 To: "Nataraju A.B" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: multipart/alternative; boundary=Apple-Mail-185E629C-6EEE-4FF4-A809-4C840C764D1A Cc: "hybi@ietf.org" , "ifette+ietf@google.com" Subject: Re: [hybi] RFC 6455 - conflicting statements X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 16:25:28 -0000 --Apple-Mail-185E629C-6EEE-4FF4-A809-4C840C764D1A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 27 Apr 2012, at 11:21, "Nataraju A.B" wrote: >=20 >=20 > On Fri, Apr 27, 2012 at 3:11 PM, Alexey Melnikov wrote: > On 27 Apr 2012, at 10:05, "Nataraju A.B" wrote: >=20 >> Hi All, >=20 > Hi, >=20 >>=20 >> Following is the snippet from the RFC6455. >>=20 >> >> 2. Conformance Requirements >>=20 >> All diagrams, examples, and notes in this specification are non- >> normative, as are all sections explicitly marked non-normative. >> Everything else in this specification is normative. >>=20 >> 1.9. Subprotocols Using the WebSocket Protocol >>=20 >> _This section is non-normative._ >>=20 >> The client can request that the server use a specific subprotocol by >> including the |Sec-WebSocket-Protocol| field in its handshake. If it >> is specified, the server needs to include the same field and one of >> the selected subprotocol values in its response for the connection to >> be established. >>=20 >> 3. WebSocket URIs >>=20 >> This specification defines two URI schemes, using the ABNF syntax >> defined in RFC 5234 [RFC5234], and terminology and ABNF productions >> defined by the URI specification RFC 3986 [RFC3986]. >>=20 >> ws-URI =3D "ws:" "//" host [ ":" port ] path [ "?" query ] >> wss-URI =3D "wss:" "//" host [ ":" port ] path [ "?" query ] >>=20 >> host =3D >> port =3D >> path =3D >> query =3D >> >>=20 >> Comment: According to statement in sec 2, section 3 - WebSocket URIs (for= example) is normative. But I don't think that it correct. Section 3, 4, 5, 6= , 7, 8 must also be changed as non-normative text by inserting the text "_Th= is section is non-normative._". >>=20 >=20 > Can you elaborate why you think that these sections are non-normative? > =20 > [ABN] In this context, We understand normative means informative text. It i= s not mandatory to implement or refer normative text. But it is mandatory to= follow syntax and semantics of non-normative text / information. AFAIU sect= ions 3-8 of rfc6455 are mandatory to implement. Hence it must be mentioned a= s non-normative text "_This section is non-normative._", like mentioned for s= ections 1.1-1.9 Sorry, I am very confused. Non-normative and Informative have the say meanin= g. They definitely don't equate to "normative". Specific syntax, like ws: UR= I in Section 3 is normative, as it defines specific rules that are necessary= to follow to implement ws: URI parsing, generation or processing. >=20 >> Otherwise, Am I missing something here ??? >>=20 >> Thanks, >> Nataraju A.B. >=20 --Apple-Mail-185E629C-6EEE-4FF4-A809-4C840C764D1A Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Hi,

On 27 Apr 2012, at 11:21, "Nataraju A.B" <nataraju.sip@gmail.com> wrote:



On Fri, Apr 27, 2012 at 3:11 PM, Alexey Melnikov <alexey.melnikov@isode.com> wrote:
On 27 Apr 2012, at 10:05, "Nataraju A.B" <nataraju.sip@gmail.com> wrote:

Hi All,

Hi,


Following is the snippet from the RFC6455.

<RFC6455>
2.  Conformance Requirements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.

1.9.  Subprotocols Using the WebSocket Protocol

   _This section is non-normative._

   The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

3.  WebSocket URIs

   This specification defines two URI schemes, using the ABNF syntax
   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
   defined by the URI specification RFC 3986 [RFC3986].

          ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ]
          wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ]

          host = <host, defined in [RFC3986], Section 3.2.2>
          port = <port, defined in [RFC3986], Section 3.2.3>
          path = <path-abempty, defined in [RFC3986], Section 3.3>
          query = <query, defined in [RFC3986], Section 3.4>
</RFC6455>

Comment: According to statement in sec 2, section 3 - WebSocket URIs (for example) is normative. But I don't think that it correct. Section 3, 4, 5, 6, 7, 8 must also be changed as non-normative text by inserting the text "_This section is non-normative._".


Can you elaborate why you think that these sections are non-normative?
 
[ABN] In this context, We understand normative means informative text. It is not mandatory to implement or refer normative text. But it is mandatory to follow syntax and semantics of non-normative text / information. AFAIU sections 3-8 of rfc6455 are mandatory to implement. Hence it must be mentioned as non-normative text "_This section is non-normative._", like mentioned for sections 1.1-1.9

Sorry, I am very confused. Non-normative and Informative have the say meaning. They definitely don't equate to "normative". Specific syntax, like ws: URI in Section 3 is normative, as it defines specific rules that are necessary to follow to implement ws: URI parsing, generation or processing.

Otherwise, Am I missing something here ???

Thanks,
Nataraju A.B.

--Apple-Mail-185E629C-6EEE-4FF4-A809-4C840C764D1A-- From nataraju.sip@gmail.com Sun Apr 29 10:02:54 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 7D38521F84EC for ; Sun, 29 Apr 2012 10:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.311 X-Spam-Level: X-Spam-Status: No, score=-2.311 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, 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 CqH3Mo+swEw0 for ; Sun, 29 Apr 2012 10:02:52 -0700 (PDT) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id ED66121F84E7 for ; Sun, 29 Apr 2012 10:02:51 -0700 (PDT) Received: by lagj5 with SMTP id j5so1606805lag.31 for ; Sun, 29 Apr 2012 10:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=HJoPi2tAtxdqrRW+w3LlR7RcpvsLzFsQC98Yq9ywzvk=; b=OZHUez82Go704Jgl/yuj0Fr8Q/Jp2TnpsGnWM8/NOUe2t2FNrDGYJ4Ru2NsN6zi7GI jBSBvyIOBYbI0xO5Hh7/QyN/EDavOhFI1bylOOG52xREhXJrhW8bIVWwIxfv12HR8ubK dDAzwH6k9wxKWETAazZf3suBd0DReelZPWEvc/EDS6QsOL9pPem772dQDXZhv8OHC+jv XT51ihvwJmR12AYu+g0ru+4l2lzhSHjKjSVlIuf4aPNwJvhsMmh+Lg2bmQd25IViQMKf VL/IYZBP1h1+mBJizGZd9QgkE0FF8Q9c02gzKO/NAtGgDIarpSFggJtw3tIq6Hgdfkxg mkzg== MIME-Version: 1.0 Received: by 10.112.101.162 with SMTP id fh2mr8808461lbb.20.1335718970832; Sun, 29 Apr 2012 10:02:50 -0700 (PDT) Received: by 10.112.36.104 with HTTP; Sun, 29 Apr 2012 10:02:50 -0700 (PDT) In-Reply-To: References: <996C3E66-90B8-4C86-885C-AD436D94E61C@isode.com> Date: Sun, 29 Apr 2012 22:32:50 +0530 Message-ID: From: "Nataraju A.B" To: Alexey Melnikov Content-Type: multipart/alternative; boundary=f46d04016a77c6b9a404bed44e10 Cc: "hybi@ietf.org" , "ifette+ietf@google.com" Subject: Re: [hybi] RFC 6455 - conflicting statements X-BeenThere: hybi@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Server-Initiated HTTP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Apr 2012 17:02:54 -0000 --f46d04016a77c6b9a404bed44e10 Content-Type: text/plain; charset=ISO-8859-1 Alex, Sorry for confusion. The comment should have been other way round. I mean sections 1.1-1.9 shall be normative like other sections. For example, Opening Handshake, Closing Handshake, Establishing a Connection are mandatory to implement. Hence these sections must be mentioned as normative text. therefore the text "_This section is non-normative._" shall be removed in these sections. Thanks, Nataraju A B On Sun, Apr 29, 2012 at 9:55 PM, Alexey Melnikov wrote: > Hi, > > > On 27 Apr 2012, at 11:21, "Nataraju A.B" wrote: > > > > On Fri, Apr 27, 2012 at 3:11 PM, Alexey Melnikov < > alexey.melnikov@isode.com> wrote: > >> On 27 Apr 2012, at 10:05, "Nataraju A.B" wrote: >> >> Hi All, >> >> >> Hi, >> >> >> Following is the snippet from the RFC6455. >> >> >> >> 2. Conformance Requirements >> >> All diagrams, examples, and notes in this specification are non- >> normative, as are all sections explicitly marked non-normative. >> *Everything *else in this specification is normative. >> >> >> 1.9. Subprotocols Using the WebSocket Protocol >> >> _This section is non-normative._ >> >> The client can request that the server use a specific subprotocol by >> including the |Sec-WebSocket-Protocol| field in its handshake. If it >> is specified, the server needs to include the same field and one of >> the selected subprotocol values in its response for the connection to >> be established. >> >> >> 3. WebSocket URIs >> >> This specification defines two URI schemes, using the ABNF syntax >> defined in RFC 5234 [RFC5234], and terminology and ABNF productions >> defined by the URI specification RFC 3986 [RFC3986]. >> >> ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] >> wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ] >> >> host = >> port = >> path = >> query = >> >> >> >> *Comment*: According to statement in sec 2, section 3 - WebSocket URIs >> (for example) is normative. But I don't think that it correct. Section >> 3, 4, 5, 6, 7, 8 must also be changed as non-normative text by inserting >> the text "_This section is non-normative._". >> >> >> Can you elaborate why you think that these sections are non-normative? >> > > [ABN] In this context, We understand normative means informative text. It > is not mandatory to implement or refer normative text. But it is mandatory > to follow syntax and semantics of non-normative text / information. AFAIU > sections 3-8 of rfc6455 are mandatory to implement. Hence it must be > mentioned as non-normative text "_This section is non-normative._", like > mentioned for sections 1.1-1.9 > > > Sorry, I am very confused. Non-normative and Informative have the say > meaning. They definitely don't equate to "normative". Specific syntax, like > ws: URI in Section 3 is normative, as it defines specific rules that are > necessary to follow to implement ws: URI parsing, generation or processing. > > >> Otherwise, Am I missing something here ??? >> >> Thanks, >> Nataraju A.B. >> >> > -- Thanks, Nataraju A.B. --f46d04016a77c6b9a404bed44e10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Alex,=A0

Sorry for confusion. The comment shou= ld have been other way round. I mean sections 1.1-1.9 shall be normative li= ke other sections.

= For example,=A0Opening Handshake, Closing Handshake, Establishing a Connection are mandatory to implement. Hence these section= s must be mentioned as normative text. therefore the text "_This section is non-no= rmative._" shall be remove= d in these sections.

Thanks,
Nataraju A B

On Sun, Apr 29, 2012 at 9:55 PM, Alex= ey Melnikov <alexey.melnikov@isode.com> wrote:
Hi,


On 27= Apr 2012, at 11:21, "Nataraju A.B" <nataraju.sip@gmail.com> wrote:



On Fri, Apr 27, 2012 at 3:11 PM, Alexey Melnikov <= alexey.melni= kov@isode.com> wrote:
On 27 Ap= r 2012, at 10:05, "Nataraju A.B" <nataraju.sip@gmail.com> wrote:

Hi All,

Hi,


Following is the snippet from the RFC6455.

=
<RFC6455>
2.  Conformance Requir=
ements

   All diagrams, examples, and notes in this specification are non-
   normative, as are all sections explicitly marked non-normative.
   Everything else in this specification is normative.=


1.9.  Sub=
protocols Using the WebSocket Protocol

   _This section is non-normative._

   The client can request that the server use a specific subprotocol by
   including the |Sec-WebSocket-Protocol| field in its handshake.  If it
   is specified, the server needs to include the same field and one of
   the selected subprotocol values in its response for the connection to
   be established.

3.  WebSo=
cket URIs

   This specification defines two URI schemes, using the ABNF syntax
   defined in RFC 5234 [RFC5234], and terminology and ABNF productions
   defined by the URI specification RFC 3986 [RFC3986].

          ws-URI =3D "ws:" "//" host [ ":" po=
rt ] path [ "?" query ]
          wss-URI =3D "wss:" "//" host [ ":" =
port ] path [ "?" query ]

          host =3D <host, defined in [RFC3986], Section 3.2.2>
          port =3D <port, defined in [RFC3986], Section 3.2.3>
          path =3D <path-abempty, defined in [RFC3986], Section 3.3>
          query =3D <query, defined in [RFC3986], Section 3.4>
</RFC6455>

Comment: According to statement in sec 2= , section 3 -=A0WebSocket URIs (for example= )=A0is normative. But I don't think that it correct.=A0Section 3, 4, 5, 6, 7, 8 must also be changed as non-normative text b= y inserting the text "_This section is= non-normative._".

=

Can you elaborate why you think that these sections are non-normative?
=A0
[ABN] In this context, We understand normat= ive means informative text. It is not mandatory to implement or refer norma= tive text. But it is mandatory to follow syntax and semantics of non-normat= ive text / information. AFAIU sections 3-8 of rfc6455 are mandatory to impl= ement. Hence it must be mentioned as non-normative text "_This section is non-normative._", like mentioned= for sections 1.1-1.9

Sorry, I am very = confused. Non-normative and Informative have the say meaning. They definite= ly don't equate to "normative". Specific syntax, like ws: URI= in Section 3 is normative, as it defines specific rules that are necessary= to follow to implement ws: URI parsing, generation or processing.


Otherwise, Am I missing something here ???

 Thanks,
Nataraju A.B.




--
Thanks,
Nataraju A.B.<= /font>

--f46d04016a77c6b9a404bed44e10--